数据库优化流程

最新推荐文章于 2024-08-18 12:59:15 发布

cuihuang1302

最新推荐文章于 2024-08-18 12:59:15 发布

阅读量230

点赞数

文章标签：数据库操作系统

1。数据采集

制定完优化目标后，需要进一步对系统中的数据进行采集和分析。数据采集包括操作系统数据和数据库的数据。

对于操作系统数据的采集，可以使用vmstat、top、sar、iostat、netstat等工具进行。

对于数据库数据的采集，可是通过多种方式进行。如STATSPACK分析，而对于oracle10g的话，还可以使用AWR报告、ADDM报告和ASH报告。

OEM中的诊断包和调优包是采集数据库状态信息的很有效的工具。使用OEM的实时监控工具的挖掘功能，可以很方便地进行问题定位。

很多DBA都有一些采集数据的独门秘笈，根据不同的数据库的情况，准备一些数据库性能状态采集的脚本是十分必要的。作为性能调优人员，应该准备以下方面的数据库脚本：

a、数据库主要表、索引、分区、表空间等情况的信息采集脚本；

b、数据库表的主要约束关系情况的采集脚本；

c、获取某个数据库对象的DDL语句的脚本；

d、数据库参数的采集脚本（包含隐含参数）；

e、主要缓冲区命中率情况的采集脚本；

f、SQL缓冲区分析脚本；

g、获取长时间运行的SQL脚本；

h、共享池分析的脚本；

i、系统等待事件分析的脚本；

j、闩锁竞争情况采集脚本；

k、主要文件I/O性能分析的脚本；

l、Top会话分析的脚本；

m、会话跟踪的脚本；

n、OPS/RAC性能分析的脚本（可以使用Oracle提供的分析脚本，在？/rdbms目录下）；

o、表空间碎片分析的脚本；

以上脚本中，部分可以在rdbms目录下找得。另外，Metalink上也有大量脚本可以参考。每个DBA都应该根据自己维护的数据库的特点，积累自己的“独门秘笈”。

采集数据是一个十分严密的过程。应该在数据库的不同状态点（或者时间点）进行多次数据采集，而且相同的状态点（或者时间点）最好进行多次采集，并进行对比，找出共同点。差别比较大的话，就要继续采集，直到所有的数据库状态可以被清晰地分析出来为止。

另外，在采集数据的时候，要注意像交响乐一样，每个系统都有自己独特的“节奏”的，这里所说的“节奏”其实就是每个系统独有的运行特征。每个系统的闲时、忙时、业务高峰都有一定的特征，在某个时间段执行的程序也有一定的规律。系统的节奏决定整个优化项目进场的时间。如果进场时间未能根据系统的节奏进行安排，我们甚至可能白白浪费时间。

2。优化方案

所有的数据库和系统状态都已经采集完毕，并确认数据准确以后，就需要对这些数据进行进一步的分析，通过分析制订出优化计划。这时，可能会发现需要采集更多数据才能够定位问题，因此就要进行数据补充，直到所有数据都能够分析清楚，并形成有针对性的优化方案为止。

制订优化计划一般来说无法由一个人完成，而要由一个专家团队来完成。某方面的专家可以提出自己对某个专题的计划，最后汇总为一个统一的计划。计划形成后，需要由一个专业的技术小组来审核该计划。专业小组应该包括下列人员：

应用开发方的技术代表；

小型机（服务器）技术专家；

网络管理员；

Oracle专家和DBA；

系统架构师；

用户代表；

一份优化计划应该包括：

系统软硬件及网络调整和数据库调整方案；

优化方案涉及的所有脚本；

详尽的系统优化操作时间表，需要列出每个步骤的起始和终止时间；

优化完成后的检查方案（含脚本）；

优化过程出现问题的处理预案；

在制订优化实施计划时，一定要考虑保留足够的时间进行必要的备份和保留系统检查及回退的时间。

优化工作不可能100％顺利完成，而DBA的责任是报障在任何情况下，系统都能够正常运行。因此，优化计划应该包含足够的应急预案，以应对在优化工作中碰到的各种异常情况。应急预案应考虑以下情况：

优化工作进度迟缓，无法按时完成；

发现优化工作无法达到预期目标，甚至可能引起新的性能问题；

数据库补丁无法正常完成；

数据库无法正常工作；

数据库崩溃；

系统硬件发生故障；

。。。

所有和本次优化相关的可能出现的问题，都应该根据出现的概率和危害程度制订相关的应急预案。对于危害越大的情况，应急预案也应该越完备。千万不可有侥幸心理。

3。实施优化计划

优化计划的实施一般来说会安排在晚上或者周末进行。有些优化不需要停机进行，而有些优化需要停止或者重启数据库，有些优化需要消耗相当长的时间（比如表或索引存储结构重组）。

实施优化计划前，许亚向项目组提出申请，并由项目组协助安排优化时间。在完成必要的备份等准备工作后再进行实施。实施过程需随时对进度进行审核，发现进度慢于预案的进度估算，甚至可能发生无法在规定停机时间内完成的情况，就需要及时调整方案甚至及时停止实施，比较严重的还要根据应急预案立即恢复。

实施过程中，最好整理有个实施检查表（checklist），完成时，再查看检查表的所有步骤是否都已完成。

4。优化后评估

优化方案实施后，应该安排DBA对数据库进行24小时～72小时的实时观察（根据系统规模不同，实时观察的时间长短也不同）。观察的内容应该包括系统级和应用级两个方面，系统级观察包括：

系统CPU使用情况；

系统I/O情况；

系统内存情况；

系统网络情况；

数据库整体负载情况；

数据库平均SQL响应时间；

关键业务SQL的执行计划；

数据库平均事务响应时间；

主要等待事件；

数据库I/O情况。

除了观察系统状况外，还需要对应用系统进行观察，查看相关应用系统总体的工作状态是否正常。再优化实施之前，应该将对系统影响较大的SQL以及关键业务的主要SQL的执行状态和执行计划都采集下来，优化完成后，对这些SQL的执行情况进行对比。

一般来说优化不是一次就能够完成的，上述过程需要进行多次循环，直到所有的优化目标都已经达到才停止。在这个过程中，也需要对优化目标进行一些修正，如果最初设定的目标实现起来存在风险或者根本无法达到，那么就需要尽快修正优化目标。

下面是一个系统优化前后比较的例子

指标名	旧系统情况	当前情况	变化对比	备注
系统CPU	30％～60％	60%～90％	比以前加大30％	CPU使用率明显提高
系统内存	90%	90%	0%	变化不大
系统I/O等待	40％～50％	0～30％	大幅度减少	目前基本处于正常状态
响应时间	11.47s	3.18s	加快3.37倍
事务数/秒	3.51	9.38	提高2倍多