正在阅读：数据库系统变化与性能调优数据库系统变化与性能调优

　　我们都听过一个流行的说法"唯一不变的，就是变化"。变化是不可避免的。对于不断发展的企业，这意味着管理应用数据库环境的时候，IT总在发生重要的变化。通常，昨天还运行良好的数据库系统在今天可能会遇到严重的问题。发生了什么变化呢？这篇文章将和数据库管理员（DBA）和开发者一起讨论如何在不断变化的环境中进行数据库调优，文章中我们将讨论到：

　　通常在数据库环境中发生变化的种类

　　这些变化是如何跟应用性能相关的

　　在数据库环境中跟踪变化的重要性

　　如何应用变化跟踪的信息改善整个数据库系统性能，可用性和稳定性

　　在今天竞争激烈的市场中，IT管理变化的能力是成功的关键。公司希望IT部门提供功能强大的，具有高可用性的和性能已优化的应用系统。当IT部门忽略主动地监测，分析和经常地报告系统性能时，系统性能将开始下降，并且最终用户将开始遭受长的应用响应时间。因此IT的使用效率将大打折扣。这篇文章也将提供改善IT效率的具体方法。

　　
　　变化是成功的关键

　　当业务系统变得反应缓慢，没有效率，过时，或者不可用时，这将减少有效操作业务的能力，对于公司产生的是消极影响。IT部门正在寻找一种方法，通过实施积极有计划地变化的有效方式，改善整个系统健康，减少没有计划地变化所带来的消极影响。一句话，业务必须不断适应有效的操作，并且在市场中具有竞争力。

　　变化过程中计划性非常重要。没有计划地变化会对系统健康产生不利的影响，例如一定字段的意外删除或覆盖，数据库索引的删除，启动错误配置文件和人为错误的数据库或监听过程，包括程序bug和数据入口错误。

　　测量变化对于有计划得变化系统的影响很重要的。例如，当计划硬件升级，负责该任务的IT部门将告诉管理部门升级能带来哪些改善。管理部门将衡量这些改善和实施变化所需的投资成本，确定变化是否有好处，或者以后应该避免什么。

　　IT部门要有计划的对数据库进行调优，就必须不间断的对数据库运行状况进行监测以便及时调整数据库管理策略。IT部门是如何从有计划地变化中测量和报告有益的结果呢？

　　对有计划的变化进行测量的好处

　　在现在的环境中测量有计划地变化所带来的好处是一件令人畏缩的工作。很多IT公司只能大约估计实施这些变化带来的好处，即使对于最重要和成本最高的项目也是如此，在这些项目中测量变化带来好处的信息是最有价值的。没有合适的数据收集和历史报告产物用于测量与变化相关的有利与不利影响，要收集有用的分析指标用于保证结果对系统影响比较小是几乎不可能。

　　当IT部门增加CPU和内存容量时，他们能够通过使用工具或OS命令行，在一定的时间周期中估计变化所带来的好处，比较容易地监测空闲可用资源的总量。但CPU或内存升级是如何影响最终用户性能的？这个问题比较难回答，除非实施不间断地监测解决方案，用于确立过去使用情况模型，比如数据活动等级和应用性能走势。只有这样，IT部门才能主动地比较结果，准确地确定变化所带来的好处，这些好处是与增加CPU或内存资源相关的。

　　与数据库相关的变化种类

　　当仔细地监测时，我们发现以下变化的类型对IT交付更健康系统的能力有一定的影响：系统配置，数据库配置，数据库对象结构，数据库查询优化和用户定义的变化（由DBA或公司发起的有计划地变化）。下面将讨论这些类型的变化。

　　系统配置

　　这种类型的变化是实施良好监测最明显和最有价值的地方。测量和定量系统配置变化带来的好处仍然是个难点。这些变化表现为硬件和操作系统配置的变化，比如：OS参数，CPU，内存，磁盘，网络接口（NIC）和交换文件空间分配的变化。

　　数据库配置

　　这种类型的变化是最复杂的变化类型，因此也是最难于正确跟踪的。数据库配置中的变化引起的影响范围很广，这种变化能够广泛地影响整个数据库性能和所有用户应用。例如，在Oracle中，变化init.ora参数，很可能影响到数据库文件（数据，日志和控制）的位置，大小，状态，回滚片断和临时表空间。在Microsoft SQL Server中，跟踪master数据库配置如文件组，文件，实例配置和数据库定义的变化很重要。master数据库提供了关键的信息如服务器特定的配置，用户登录帐号，运行着的进程数据，系统错误日志，含有初始化用户数据库的信息。另外，Microsoft SQL Server实例中每个数据库所具有的文件组参数，数据库文件（数据，日志和控制）位置，大小和状态信息都跟Oracle有点类似。

　　数据库表对象

　　最近几年随着新的政策安全法规的出台，像Sarbanes-Oxley Act，HIPPA，California SB 1386和其它的公司一样，正在对现有应用进行一些修补，以期改善系统安全。关于数据库服务器，修补的一部分是应用的一些安全策略，这些安全策略与OS和数据库补丁相关；审计那些直接登录访问；使这类网络访问协议不再起作用，这些协议像telnet，FTP和rsh等。但IT部门也需要确定需要捕获什么样的信息用于审计。回溯到2002，Senator Sarbanes和Representative Oxley可能不知道影响它们对美国信任社团或法人的是什么。Sarbanes-Oxley的影响将被摸索好几年，正如它的影响达到其它相关的区域，并且能感觉到它以新的和更严格规定条规的余震。

　　关于数据库本身，当创建，变化，更新或删除数据库对象的时候，IT部门最需要做的是审计变化。一些公司对于跟踪"谁"和"从哪里来"的信息也感兴趣。变化这些对象的一些例子如：创建视图，变化表，编译程序和重建或删除索引。

　　查询执行

　　跟踪SQL查询计划执行的变化被认为是变化数据库和应用的重要地方。当正确地优化SQL语句时，它们的数据库访问和修复速率能够有效地服务，并且不用担心用户应用。然而，如果没有正确地优化，它们就会严重影响应用的性能。几乎所有的DBA，从入门级的到熟练级的，都知道为完成SQL语句苦恼好几个小时的情况。这时，有了正确的SQL调优，这个优化就可以很快完成。在解决应用性能问题时，知道什么时候查询计划在生产环境中变化极其有用。另外，当跟踪这种变化时，捕获变化之前和变化之后的查询计划和它们之间的不同点非常有价值。

　　用户定义

　　这种变化类型是使用最广泛和最有效的类型，用于模仿和跟踪发生在你特有业务环境中的变化。它给IT部门一种方式，测量那些几乎不可能量化的变化项目，就像以下的性能影响：

　　 OS升级或数据库补丁

　　 ERP/CRM应用升级

　　 数据库空间重组

　　 用于执行各种数据库维护任务的特殊脚本

　　 添加新的应用到系统

　　 添加50个新的用户或整个新的分支功能到生产系统

　　这种类型的变化使DBA无从评估，并且通常没有在数量上监测。IT部门始终渴望从这些经常变化的项目中获得好的性能影响信息。

　　这种变化类型可以包含绝大部分任何一种与数据库相关的变化。当公司评估数据库变化跟踪系统时，通过提供方法，输入用户定义的变化来支持这种重要的变化类型是有必要。很容易地采用这些变化和在工具界面中识别这种变化跟踪系统。

　　这种类型的变化能够用于证明影响的出现。例如，当系统管理员安装操作系统补丁时，记录下这个事件能够帮助确定性能中的变化是否直接跟这个事件相关。

　　上面提到的所有变化指出了关键的数据库和应用系统的重要方面，而这些方面需要我们长期持之以恒的监测和跟踪，为了重要的数据库和应用系统。当这些地方发生变化时，不管是有计划的还是无计划的，有见识的IT部门将测量和报告变化的影响。当发现不利的影响时他们能够很快地对变化事件进行管理，或者一旦出现有利的结果，就把这些有利结果报告给管理部门，作为成本理由或投资回报分析的重要数据要点。

　　系统变化用例研究

　　对于系统变化进行跟踪变化，能够及时发现硬件和软件方面的故障，保障公司信息系统良性发展。

　　现在有一些软件比如Quest Central Performance Analysis能够被用来跟踪和诊断变化中的系统。Quest Central Performance Analysis是一个全面的变化跟踪和历史的分析工具，能够被用于帮助解决性能和与性能相关变化的问题。

　　Quest Central's Performance Analysis提供一套全面的变化跟踪工具，它能自动地跟踪和报告发生在Oracle和Microsoft SQLServer数据库环境中的变化。变化跟踪工具与Performance Analysis监测工具集成在一起，提供以下功能：

　　定期地跟踪环境，配置和数据库对象的变化；这些变化可能影响系统和数据库性能

　　使用户能够把变化的出现和数据库活动关联一起，用于识别影响系统性能的变化

　　包括选择常见输出格式的报表，计划和变化种类过滤器，变化种类过滤器能使用户能够重新定义在任一个给定时间周期中显示一系列的变化。

　　IT是怎样工作的

　　Performance Analysis Change Tacking没有试图审计系统变化，而是集中于那些以后可能影响系统性能的变化。例如，如果在日常变化跟踪断点之间创建和删除索引，表或数据库对象，这时这些对象的变化将记录在日常变化跟踪报表中。因此从日常的观点看它们对于性能将没有什么影响，只有间隔几天去看才能看出影响。但如果在开始变化跟踪时存在索引，并且在下个变化跟踪事件发生之前被删除了，那么索引删除将被记录在变化跟踪系统中，因为它以后可能影响性能。

　　事例1Microsoft SQL －Server数据库上的Index Drop

　　在下面的例子中，由于不小心把索引从数据库系统中删除了。让我们回顾一下Performance Analysis将如何发现，诊断问题，并且是如何使DBA采取措施解决这些问题的。

　　但首先让我们快速地看看Performance Analysis监测产品，这样能帮助你更好地理解例子中用到的截图。如果你已经熟悉Quest Central Performance Analysis，那可以跳过下面的例子。

　　Performance Analysis是一个功能全面的数据库产品工具，它具有高级在线缩放，钻取和可产生报告特点的易用界面，使DBA可视化分析它们任一时刻的应用工作量。Performance Analysis利用一个低负载的数据收集机制，收集数据库服务器操作系统度量值，数据库会话统计数据，Top SQL，等待事件和IO性能度量值，给DBA提供横跨整个数据库服务器平台的特有性能视图。Performance Analysis也包括了一个日常Change Tracking模块，它通过在工作活动图表中描绘数据库系统变化，把变化和性能关联在一起。这使DBA能够可视化地确定变化和数据库性能之间的可能关系。Performance Analysis在ERP环境中也提供特定的好处，比如Oracle Application E-Business Suite和PeopleSoft。例如，它通过ERP种类报告性能，这些种类像用户，应用，程序，和报表等，使DBA更好的理解谁位于消费者的顶层，哪个用户或程序引起系统响应缓慢。Performance Analysis使DBA能够趋向于性能，在负责改善整个应用时，确保SLA位于SQL和程序层，排除SQL和锁问题确保快速地解决应用问题。下图显示了Performance Analysis History Area。

Performance Analysis History Area

　　1. 历史区域以流行的类型（USER，PROGRAM，SQL，和其它）提供性能数据片断。其它区域是RECENT和REPORTS。

　　2. 由Performance Analysis跟踪的工作量等待事件类型。

　　3. 简单易用的滚动条和向下钻取的能力使用户能够在任何时候都可以快速地分析。

　　4. Wait event饼图使用户能够下钻到等待事件种类和回顾详细的资源使用情况。

　　5. 通过点击列名对改列的性能数据进行排序。

　　在这个例子中，对于所选择的事件段，已经发生了一些变化，正如下图中颜色指示器所指出的。使用Performance Analysis，DBA能够快速地确定图中提到的最近IO和Latch活动频繁是否由最近的变化引起的。

　　这个揭示了Ron Barret运行一个新脚本，这个脚本删除了不需要的索引。Ron使用User-Defined变化机制输入变化到Performance Analysis Change Tracking系统。正如这篇文章前面显示的，User-Defined变化跟踪使公司能够跟踪发生在它们系统中的重要任务和项目。

User-Defined变化跟踪

　　在下面的图中，运行Ron脚本几分钟后，在ORDER_LINE表中的索引被删除了。这单独不应该引起报警。毕竟，假设Ron脚本用于清理不再使用的索引，所以我们应该看到被删除的索引。

　　要查看所有被Ron脚本删除的索引，我们能够发现他的工程在位于History Area中的"program"，接着选择与"SQL Statement"相关的尺寸。这将在"Change Tracking"标签中显示所有由Ron脚本删除的索引。

Change Tracking

　　在下面的图中，SQL语句的执行计划相对于ORDER_LINE表的运行已经变化。SQL执行计划的变化可能是由于索引被删除了。

ORDER_LINE

　　点击彩色的气球，指出SQL执行计划已经变化，显示执行计划之前和之后对于相关的SQL。下面这种图指出索引的删除对这个SQL查询的性能产生了负面影响。以前，SQL语句使用索引和执行"Index Seek"选项。现在SQL语句使用全局"Table Scan"，结果是SQL计划用于这个操作的成本从0.67上升到了156.90，并且SQL执行时间全部增长。应采取的行动：要求Ron恢复删除的索引，进一步的调查研究，为什么这个索引会被删除。

要求Ron恢复删除的索引

　　在这个例子中，我们已经显示了跟踪与变化相关的性能，这些变化能够影响整个数据库系统的整个响应时间，并且能够帮助DBA识别这些变化是否会引起数据库活动的增长。有时候，这些工作量增长将是有理由的，但这种情况，DBA能够快速确定删除的索引导致SQL性能下降和删除的索引应该恢复。跟踪"有计划地"变化和这些变化是如何影响数据库和应用性能是有价值的工具，它能用于证明改善系统和应用性能的调优努力是否正确，并且给管理部门显示了IT调优结果的好处。