最近几年随着新的政策安全法规的出台，像Sarbanes-Oxley Act，HIPPA，California SB 1386和其它的公司一样，正在对现有应用进行一些修补，以期改善系统安全。关于数据库服务器，修补的一部分是应用的一些安全策略，这些安全策略与OS和数据库补丁相关；审计那些直接登录访问；使这类网络访问协议不再起作用，这些协议像te.net，FTP和rsh等。但IT部门也需要确定需要捕获什么样的信息用于审计。回溯到2002，Senator Sarbanes和Representative Oxley可能不知道影响它们对美国信任社团或法人的是什么。Sarbanes-Oxley的影响将被摸索好几年，正如它的影响达到其它相关的区域，并且能感觉到它以新的和更严格规定条规的余震。
关于数据库本身，当创建，变化，更新或删除数据库对象的时候，IT部门最需要做的是审计变化。一些公司对于跟踪"谁"和"从哪里来"的信息也感兴趣。变化这些对象的一些例子如：创建视图，变化表，编译程序和重建或删除索引。
查询执行
跟踪SQL查询计划执行的变化被认为是变化数据库和应用的重要地方。当正确地优化SQL语句时，它们的数据库访问和修复速率能够有效地服务，并且不用担心用户应用。然而，如果没有正确地优化，它们就会严重影响应用的性能。几乎所有的DBA，从入门级的到熟练级的，都知道为完成SQL语句苦恼好几个小时的情况。这时，有了正确的SQL调优，这个优化就可以很快完成。在解决应用性能问题时，知道什么时候查询计划在生产环境中变化极其有用。另外，当跟踪这种变化时，捕获变化之前和变化之后的查询计划和它们之间的不同点非常有价值。
用户定义
这种变化类型是使用最广泛和最有效的类型，用于模仿和跟踪发生在你特有业务环境中的变化。它给IT部门一种方式，测量那些几乎不可能量化的变化项目，就像以下的性能影响：
OS升级或数据库补丁
ERP/CRM应用升级
数据库空间重组
用于执行各种数据库维护任务的特殊脚本
添加新的应用到系统
添加50个新的用户或整个新的分支功能到生产系统
这种类型的变化使DBA无从评估，并且通常没有在数量上监测。IT部门始终渴望从这些经常变化的项目中获得好的性能影响信息。
这种变化类型可以包含绝大部分任何一种与数据库相关的变化。当公司评估数据库变化跟踪系统时，通过提供方法，输入用户定义的变化来支持这种重要的变化类型是有必要。很容易地采用这些变化和在工具界面中识别这种变化跟踪系统。
这种类型的变化能够用于证明影响的出现。例如，当系统管理员安装操作系统补丁时，记录下这个事件能够帮助确定性能中的变化是否直接跟这个事件相关。
上面提到的所有变化指出了关键的数据库和应用系统的重要方面，而这些方面需要我们长期持之以恒的监测和跟踪，为了重要的数据库和应用系统。当这些地方发生变化时，不管是有计划的还是无计划的，有见识的IT部门将测量和报告变化的影响。当发现不利的影响时他们能够很快地对变化事件进行管理，或者一旦出现有利的结果，就把这些有利结果报告给管理部门，作为成本理由或投资回报分析的重要数据要点。
系统变化用例研究
在2004年，我能够在示范机中出现的内存故障影响应用性能之前快速地发现它。我们使用这个示范机向客户介绍我们的产品解决方案，所以要求这个示范机有个好的性能。这个机器有两条512M的内存条共计1G的内存。其中一条内存条是完全坏了，这使得系统运行缓慢。首先，我没想到内存坏了。毕竟，我加载"demo"数据和运行一些报表，并且认为虽然系统看起来比平常运行慢多了，但还是可以解释为什么性能下降了。之后，我再一次确认这机器不能合理的解释它的运行状况，因为正常情况下它运行很快，这时我开始怀疑系统是否负荷过载。这个提示我检查一下我的变化跟踪系统（我使用其中一个在常规基楚上），看看是否有重要的变化。毕竟，昨天系统还是运行良好的。什么变化了呢？当我调查监测系统，它立即报告其中一个512M内存条坏了。我通过使用Unix OS命令行很快地确定这个信息，并且真的系统不再注册RAM为1G了，而是512M。这解释了为什么"示范机运行缓慢"。那个下午，我们的MIS部门用一个新的内存条把那个坏的换了下来，准备着再给用户介绍产品。
我使用什么样的变化跟踪来诊断和解决这个问题呢？答案是：Quest Central Performance Analysis，一个全面的变化跟踪和历史的分析工具，用于帮助解决性能和与性能相关变化的问题。
使用性能分析跟踪变化
Quest Central's Performance Analysis提供一套全面的变化跟踪工具，它能自动地跟踪和报告发生在Oracle和Microsoft SQLServer数据库环境中的变化。变化跟踪工具与Performance Analysis监测工具集成在一起，提供以下功能：
定期地跟踪环境，配置和数据库对象的变化；这些变化可能影响系统和数据库性能
使用户能够把变化的出现和数据库活动关联一起，用于识别影响系统性能的变化
包括选择常见输出格式的报表，计划和变化种类过滤器，变化种类过滤器能使用户能够重新定义在任一个给定时间周期中显示一系列的变化。
IT是怎样工作的
Performance Analysis Change Tacking没有试图审计系统变化，而是集中于那些以后可能影响系统性能的变化。例如，如果在日常变化跟踪断点之间创建和删除索引，表或数据库对象，这时这些对象的变化将记录在日常变化跟踪报表中。因此从日常的观点看它们对于性能将没有什么影响，只有间隔几天去看才能看出影响。但如果在开始变化跟踪时存在索引，并且在下个变化跟踪事件发生之前被删除了，那么索引删除将被记录在变化跟踪系统中，因为它以后可能影响性能。
事例1－Microsoft SQL Server数据库上的Index Drop
在下面的例子中，由于不小心把索引从数据库系统中删除了。让我们回顾一下Performance Analysis将如何发现，诊断问题，并且是如何使DBA采取措施解决这些问题的。
但首先让我们快速地看看Performance Analysis监测产品，这样能帮助你更好地理解例子中用到的截图。如果你已经熟悉Quest Central Performance Analysis，那可以跳过下面的例子。
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变化跟踪使公司能够跟踪发生在它们系统中的重要任务和项目。
文章来源于领测软件测试网 https://www.ltesting.net/
