Oracle 11g数据库数据库重放Word下载.docx

Oracle 11g数据库数据库重放Word下载.docx

《Oracle 11g数据库数据库重放Word下载.docx》由会员分享，可在线阅读，更多相关《Oracle 11g数据库数据库重放Word下载.docx（40页珍藏版）》请在冰豆网上搜索。

任何应用程序运行时执行的每一条SQL语句，不管它仅仅是一个简单的查询语句依旧包括大量DML语句的批处理作业，都必须捕捉。

那个挑战目前变得更加尖锐，因为当前的应用程序负载大差不多上跨多个技术产生的：

N层应用程序服务器、webfarms、甚至传统的客户端/服务器模式应用程序。

况且，当某个应用程序执行速度慢下来时，要跟踪追捕检查性能下降的全然缘故几乎不可能的。

它可能是因不正确的网络配置、不正确的应用程序服务器配置、甚至可能是因为应用程序客户端环境变量设置不正确引起的。

目前实现那个艰巨的目标唯独的选择是〝捕捉/重放〞应用程序负载产品套件，这类应用程序是专门设计用于捕捉当前生产环境数据库差不多执行过的完整负载〔p+0〕，然后重放该负载〔p+1〕。

然而，以我多年的体会看来，这意味着公司要尽早购买第三方较昂贵的解决方案〔如HP的LoadRunner工具〕。

软件的许可成本和服务器的配置成本需要集中精力考虑，专门是人力资源配置的考虑，可能在捕捉/重放负载开始之前专门容易就会达到六位数美金的投入了。

这确实是什么缘故许多IT机构舍弃了那个方法，因为测试应用程序性能倒退的成本因素使其变得不太可能。

性能倒退之外的因素

我之前写的关于Oracle11g新的SQL语句性能调试特性：

SQL性能分析器〔SPA〕和SQL打算治理器〔SPM〕差不多讨论过Oracle11g是如何让DBA定位因应用程序环境改变引起的性能提升、保持原样、性能倒退的SQL语句的，所有捕捉/重放工具都必须要能捕捉并能比较源〔p+0〕和以后〔p+1〕系统、应用程序、数据库性能统计，专门是当前性能较低的SQL语句。

但那个地点我还要提出另外两个需要标记的回来类型：

错误回来：

在重放捕捉的负载时，常常会遇到错误，事实上那个错误几乎确实是一个想要的结果，例如：

我想校验一个预期中的专门，如违抗引用完整性〔如主键、外键、唯独键、CHECK、NOT 

NULL约束〕显现时能被正确地捕捉，同时，我还期望有违抗重要的事务规那么的情形显现能被捕捉到，如在检查职职员资单时发觉差不多工资与总工资扣除所有费用后不平稳的情形，我期望这种专门能被当作错误一样被捕捉到。

因此，任何强大的捕捉/重放工具都必须能够监视下面三种类型的错误回来：

所有预期的错误都发生了吗？

有不是预期的错误状态显现吗？

专门明显，这说明严格的因系统或应用程序改变的错误回来是可能的。

预期的错误有没有显现的吗？

这种情形更复杂了，因为这说明在系统或应用程序内某些不祥的情况差不多发送变化了，也可能是重要的事务规那么被滥用或没有应用到所有事务上。

数据回来：

所有捕捉/重放工具在重放完成后，假如数据本身显现了差异还必须发出提醒信号，例如，在测试一个关键任务的金融系统时，我必须确保相同的金融业务安装合理的顺序完成，在p+1环境所有帐户总和都应该象p+0环境中达到平稳，假如结果不一样，我必须考虑在我的应用程序、数据库或环境中是什么改变导致了重放不精确的情形显现。

捕捉和重放套件的另一个关键特性是：

在p+1环境上重放捕捉的负载前，必须确保负载捕捉启动时P+0环境被复位，否那么可能会误诊为数据回来，而实际上应用程序，数据库和环境都没有发送任何改变。

从属的事务需要捕捉并重放，这好比钢琴家演奏完一段曲子后，磁带记录不仅记录了记录信息，还记录了每个按键被按下的频率信息，本质上，它给听众提供了一份艺术大师演奏风格的精确复本，包括所有复杂的演奏停顿〔关于小于25岁的年轻读者而言，可能没有看到过钢琴演奏磁带，能够用mp3或wav文件替换，或询问一下年长的同事当年听磁带的情况。

〕

数据库重放：

功能摘要

感谢Oracle11g新的数据库重放〔DBR〕套件为我们提供了所有讨论到的功能，DBR承诺承诺DBA：

捕捉在生产系统上产生的负载，这包括跨多个会话同时收集所有依靠的事务时捕捉并行执行的相同SQL语句的能力。

捕捉的数据在测试系统上执行前先要做一些处理，这承诺DBA调整负载重放的频率，以及重新映射到不同用户会话，不同服务的连接，或--在Oracle11gRAC测试系统中重放时，是一个或多个数据库实例。

在测试系统上重放捕捉的通过处理过的负载，测试系统的配置符合p+1配置的要求，因此DBA能够准确地判定任何系统改变〔包括应用程序改变，软件补丁，甚至硬件升级〕对负载的阻碍，测试系统能够是测试或QA数据库环境，也能够是一个快照备用数据库〔关于备用数据库后面的文章有更多的说明〕。

执行回来分析突出p+0和p+1模拟负载之间的差异，DBR会自动识别和分析错误回来，数据回来和SQL语句回来的向量。

数据库重放的精妙之处是它排除了创建执行回来分析的模拟负载的必要性，相反，DBA能够准确地执行记录下来的SQL语句，因此这倾向于提供更准确的系统回来实况录像，因为其他外部因素〔如网络等待时刻〕减少了或没有了，所有记录下来的SQL语句组成了重放的负载，实际上看起来几乎可不能显现无用的或专门少执行的代码，这些代码可能会被忽略，假如应用程序是在一个RAC集群数据库环境中的话这是专门关键的。

本文接下来的4小节提供了数据库重放功能的高级入门指南，实现它们的通用目标：

在从p+0到p+1迁移一个生产系统时准确判定需要回来到什么程度，本系列后面的文章中，我会介绍如何利用数据库重放功能捕捉、预处理、重放和分析重放结果。

第一步：

录制负载

Oracle11g企业治理数据库操纵台提供了一个专门直观的治理数据库重放功能的接口，如启用负载捕捉，预处理，回来分析等，每一步它都提供了良好的状态反馈信息，图1显示了初始的数据库重放操纵台界面：

〔点击查看大图〕图1：

数据库重放操纵台主界面

这一步看到的全部负载确实是对生产数据库捕捉和录制的内容，DBA只需要保证在生产系统上有足够的负载，DBR做了其他所有情况〔捕捉所有外部客户端发起执行的SQL语句〕，这包括：

SQL查询，DML语句和DDL语句。

PL/SQL块和远程过程调用〔RPCs〕。

对象导航要求和OCI调用。

注意DBS捕捉操作执行过程中，Oracle11g可不能停止任何后台运行中的作业，所有内部客户端也能够连续产生要求。

DBR通过一系列影子进程记录负载，这些影子进程过滤出必要的信息准确地复制系统负载，最后将这些元数据写入一系列XML文件，后面重放时确实是使用的这些XML文件，Oracle11gDBA只需要关怀文件系统上是否有足够的储备空间来重放这些XML文件。

第二步：

〝整理〞负载

当DBR负载录制完毕后，在重放前，总是需要对其进行一些细微的调整。

例如：

重新映射外部客户端的连接，以便在p+1环境中能准确地重放，在这一步中，DBR为它最后重放预备具体的元数据，所有阻碍重放结果的参数也是在这一步进行修改的。

在相同数据库版本上重放时那个预处理过程必须存在，当只要数据库版本匹配，就能够在一个生产、测试或其他数据库系统上执行擦除操作，实际上，Oracle强烈建议在一个非生产服务器上执行那个元数据的〝整理〞操作，以不阻碍生产服务器的性能或健康为宜。

第三步：

重放负载

负载差不多整理好了，能够启动重放操作了，完成元数据擦除后，选定的DBR重放客户端就能够随需重放负载了。

复位测试环境：

在启动重放前，DBA第一必须复位用于测试的目标数据库和主机环境，因为在应用改变前，测试服务器的关键部位需要与生产服务器匹配，否那么，可能引发非预期的回来，幸运的是，随Oracle10g数据库显现的闪回数据库〔FLASHBACKDATABASE〕特性关心我们简单完成那个任务，其他可选的包括通过RMAN复原到一个时刻点，或使用数据泵导出导入，一旦测试环境正确地复位完毕，接下来，DBA应用所有的改变到测试服务器上的生产系统，使其现在的状态变为p+1，然后传送前面捕捉的负载给那个p+1服务器。

通过重放驱动重放负载：

当在p+1服务器上最后一次重放前面捕捉的负载时，一个叫做重放驱动的应用程序向目标数据库系统发送要求，因为重放驱动是客户端不可知论的，对Oracle11g而言最初发送要求的客户端类型是没有区别的，重放驱动消灭了录制的负载和向p+1系统发送要求的过程，就象是外部客户端发送的要求一样。

因为它将在所有重放客户端之间分配所有的负载捕捉流，重放驱动可能会考虑网络带宽、cpu和内存容量，重放驱动也可能充分利用重新映射连接字串，使它们建立起一对一〔如单实例到单实例〕或多对一〔如单节点到多个RAC节点〕的关系，意味着连接负载均衡可能需要考虑，同样重要的是，重放驱动会忽略最初由外部客户端产生的活动〔如EM数据库操纵〕，可不能重放这种活动，同时，它还会忽略通过数据库连接连接到外部数据库或访问名目对象的活动记录。

另一个使用数据库重放吸引人的优点是：

能够同步模式或异步模式重放捕捉的负载。

在同步模式下，每一个事务都按照录制时的顺序准确地重放，然而，DBR也能够异步重放负载，如不考虑事务的同步性，因此能够产生比录制时更大的负载，这在试图执行一个〝测试到破坏〞新的或修改过的数据库环境时专门有用。

DBR负载重放的范畴：

Oracle11gR1数据库重放功能能够准确地评估下面几类对数据库环境的改变。

数据库升级

数据库打补丁

改变数据库模式

改变初始化参数

修改一个或多个RAC节点及其内连配置

操作系统平台的概念，包括从32位转移到64位

改变服务器内存或cpu配置

改变数据库的储备配置，包括在文件系统〔如ext3,ntfs〕、ASM储备、和/或RAW储备之间迁移数据库文件

DBR负载重放限制：

数据库重放模拟能力有一些显着的〔且合理的〕限制：

SQL*Loader直截了当路径装入不能重放，常规路径SQL*Loader操作能够重放

导入导出操作，不管是通过传统的方式依旧数据泵的方式，都不能重放

Oracle共享服务器会话不能跟踪

闪回数据库复原和Flashback查询操作不能重放

Oracle数据流，包括非基于PL/SQL的高级查询，不能重放

分布式事务处理，包括远程COMMIT操作，只能当作本地事务重放

基于Oracle调用接口〔OCI〕对象导航不能重放

关于大多数部分，这些限制有意义，例如：

闪回数据库本质上是一个不完全的数据库复原操作，因此它不是正常事务处理的范畴，我也可不能考虑它是否会使性能倒退，尽管限制关于共享服务器会话有意义，但仍旧有一些数据库是使用共享服务器作为连接池的，因此这是一个小小的遗憾。

第四步：

回来分析

负载重放完毕后，数据库重放将提供多个有关在p+1环境和p+0环境下负载性能不同的分析，正如我在本文最前面提到的，任何好的回来测试套件都有能力捕捉和分析性能回来、数据回来和错误回来，DBR在这些方面没有让我们败兴。

DBR能够通过它的一套捕捉重放报告赶忙检测到任何性能差异，通过这些报告，能够下钻到储备在ADDM〔自动数据库诊断监视器〕、AWR〔自动负载仓库〕和活动会话历史〔ASH〕报告中更详细的分析。

不管问题出自哪里，DBR都能识别并处理以下两种类型的问题：

联机