分类：
2008-10-16 19:57:54
DBA很早就盼望能够在生产环境中捕获应用程序的负载，然后通过在环境中重放捕获的负载来判断数据库或应用程序的改动对数据库性能的影响， 11g数据库新的数据库重放特性使DBA可以捕获，处理负载，然后有选择性地或跨大范围的数据库环境和平台全部重放，本文为在日益不稳定的数据库环境中使用Oracle 11g数据库重放有效地快速预报应用程序的改变对性能的影响提供一个入门。
如果我在IT行业这几年教会了我一切，那它是继墨菲定律（凡事只要有可能出错，那就一定会出错）之后的又一真理了，过去的几年里，我认识到了多个墨菲定律推论的正确性，包括“替代的零件往往不能代用”及特别是“墨菲实际上是一个乐观主义者”的回答，我希望有一天我自己的推论也能通过长期的观察被添加到这些严格的定律中，我的推论就是：“没有东西能够象在环境那样在生产环境中运转”。
Oracle DBA面临一个严峻的挑战：如何准确预报下一组对数据库或应用程序，甚至是硬件配置的改动对整个数据库环境产生的负面影响。这里所说的整个环境字面上的意思是：任何应用程序运行时执行的每一条SQL语句，不管它仅仅是一个简单的查询语句还是包括大量DML语句的批处理作业，都必须捕获。这个挑战目前变得更加尖锐，因为当前的应用程序负载大都是跨多个技术产生的：N层应用程序、web fs、甚至传统的客户端/模式应用程序。况且，当某个应用程序执行速度慢下来时，要跟踪追捕检查性能下降的根本原因几乎不可能的。它可能是因不正确的网络配置、不正确的应用程序服务器配置、甚至可能是因为应用程序客户端环境变量设置不正确引起的。
目前实现这个艰巨的目标唯一的选择是“捕获/重放”应用程序负载产品套件，这类应用程序是专门设计用于捕获当前生产环境数据库已经执行过的完整负载（p+0），然后重放该负载（p+1）。然而，以我多年的经验看来，这意味着公司要尽早购买第三方较昂贵的解决方案（如HP的LoadRunner工具）。软件的许可成本和服务器的配置成本需要集中精力考虑，特别是人力资源配置的考虑，可能在捕获/重放负载开始之前很容易就会达到六位数美金的投入了。这就是为什么许多IT机构放弃了这个想法，因为测试应用程序性能倒退的成本因素使其变得不太可能。
性能倒退之外的因素
我之前写的关于Oracle 11g新的SQL语句性能调试特性：SQL性能分析器（SPA）和SQL计划管理器（SPM）已经讨论过Oracle 11g是如何让DBA定位因应用程序环境改变引起的性能提升、保持原样、性能倒退的SQL语句的，所有捕获/重放工具都必须要能捕获并能比较源（p+0）和未来（p+1）系统、应用程序、数据库性能统计，特别是当前性能较低的SQL语句。但这里我还要提出另外两个需要标记的回归类型：错误回归：在重放捕获的负载时，常常会遇到错误，事实上这个错误几乎就是一个想要的结果，例如：我想校验一个预期中的异常，如违背引用完整性（如主键、外键、唯一键、CHECK、NOT NULL约束）出现时能被正确地捕获，同时，我还希望有违背重要的事务规则的情况出现能被捕获到，如在检查职员工资单时发现基本工资与总工资扣除所有费用后不平衡的情况，我希望这种异常能被当作错误一样被捕获到。
因此，任何强大的捕获/重放工具都必须能够监视下面三种类型的错误回归：
所有预期的错误都发生了吗？
有不是预期的错误状态出现吗？很显然，这表明严格的因系统或应用程序改变的错误回归是可能的。
预期的错误有没有出现的吗？这种情况更复杂了，因为这表明在系统或应用程序内某些不祥的事情已经发送变化了，也可能是重要的事务规则被滥用或没有应用到所有事务上。
数据回归：所有捕获/重放工具在重放完成后，如果数据本身出现了差异还必须发出提醒信号，例如，在测试一个关键任务的金融系统时，我必须确保相同的金融业务安装合理的顺序完成，在p+1环境所有帐户总和都应该象p+0环境中达到平衡，如果结果不一样，我必须考虑在我的应用程序、数据库或环境中是什么改变导致了重放不精确的情况出现。
捕获和重放套件的另一个关键特性是：在p+1环境上重放捕获的负载前，必须确保负载捕获启动时P+0环境被复位，否则可能会误诊为数据回归，而实际上应用程序，数据库和环境都没有发送任何改变。
从属的事务需要捕获并重放，这好比钢琴家演奏完一段曲子后，磁带记录不仅记录了记录信息，还记录了每个按键被按下的频率信息，本质上，它给听众提供了一份艺术大师演奏风格的精确复本，包括所有复杂的演奏停顿（对于小于25岁的年轻读者而言，可能没有看到过钢琴演奏磁带，可以用mp3或wav文件替换，或询问一下年长的同事当年听磁带的事情。）
[1]
