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

　　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调优结果的好处。