Oracle 11g New 数据库重放

• 确定使用数据库重放的优点

• 列出数据库重放所涉及的步骤

• 使用Enterprise Manager 记录和重放工作量

• 为什么使用数据库重放

• 系统更改（如硬件和软件升级）是不可避免的。

• 客户需要在实施更改前确定更改的全面影响。

• 大量的测试和验证可能会花费很多的时间和资金。

• 测试除了成本昂贵之外，成功率还很低：

– 许多问题未被检测到。

– 更改可能会对系统的可用性和性能产生负面影响。

• 成功率低的原因：

– 无法使用实际的生产工作量进行正确的测试，有许多问题未被 检测到。

• 数据库重放功能使你可以执行与实际情况相符合的测试。

为什么使用数据库重放？

大型业务关键应用程序不但复杂，而且负载模式和使用模式也相当多。与此同时，这些业 务系统要在响应时间、吞吐量、运行时间和可用性方面提供特定服务级别的保证。对系统 的任何更改（如升级数据库或修改配置）通常都需要进行全面的测试和验证，然后才能在 生产系统中实施这些更改。在移到生产系统之前为了保证安全，数据库管理员(DBA) 需 要让测试系统承受与生产环境中的工作量很近似的工作量。DBA 使用一种有效的方式分 析系统级更改对整体SQL 性能的影响也很有益处，因为这样便可以在生产之前对更改执 行任何必要的优化。

• 数据库重放

• 在测试环境中重新创建实际的生产数据库工作量。

• 在生产中实施更改之前，确定和分析潜在的不稳定性。

• 捕获生产中的工作量：

– 捕获带有实际负载和并发度的完整生产工作量

– 将捕获的工作量移到测试系统

• 在测试中重放工作量：

– 在测试系统中进行所需的更改

– 重放带有生产负载和并发度的工作量

– 采用提交顺序

• 分析和报告：

– 错误

– 数据差异

– 性能差异

数据库重放

针对之前列出的挑战，Oracle Database 11 g 提供了具体的解决方案。

通过数据库重放，在将实际的工作量放到生产系统之前，可以在测试系统上重放实际工作 量，从而测试系统更改的影响。记录数据库服务器在一段有代表性的时段（例如高峰期 间）内的生产工作量（包括事务处理并发度和相关性）。此记录数据用于在经过适当配置 的测试系统上重放工作量。通过在测试系统中使数据库服务器承受与生产工作量几乎相同 的工作量，可以在数据库更改获得整体成功方面获得高度的信心。

• 系统体系结构：捕获

系统体系结构：捕获

图中展示了一个正在进行记录的系统。应始终记录生产系统中某个“你所关注的”期 间内的工作量。一般情况下，可通过重放记录来确定升级到新版本的RDBMS  服务器是否 安全。在系统中运行生产工作量时，内置到RDBMS  中的一种特殊记录基础结构可以记录 有关所有外部客户机请求的数据。外部请求包括所有SQL 查询、PL/SQL  块、PL/SQL  远 程过程调用、DML 语句、DDL 语句、对象导航请求或Oracle Call Interface (OCI) 调用。 在记录过程中，后台作业以及通常情况下的所有内部客户机将继续工作，不会被记录。最 终结果是一份工作量记录，其中包含重放工作量所必需的全部信息；RDBMS  可通过外部 请求来查看这些信息。

记录基础结构只会对记录系统造成最低的性能开销（额外的CPU 、内存和输出/ 输出）。

但是，应计划配备额外的磁盘空间用于记录实际工作量。

RAC 说明：RAC 环境中的实例可以访问公用数据库文件。但是，它们不需要共享公用的

通用文件系统。在这样的环境中，工作量记录会在记录过程中写入各个实例的文件系统。

为了进行处理和重放，需要将工作量记录的所有部分手动复制到单个目录中。

• 系统体系结构：处理工作量

系统体系结构：处理工作量

处理工作量捕获数据，创建特定于新工作量重放的元数据文件，这是重放指定工作量捕获 所必需的。仅创建新文件，而不对工作量捕获过程中创建的任何文件进行修改。因此，可 以对相同的捕获目录多次运行预处理（例如，过程遇到意外错误或被取消时）。

在此阶段中，将重新映射外部客户机连接。可以修改会影响重放结果的所有重放参数。

注：因为处理工作量捕获的成本可能相对较高，所以最好的做法是在生产数据库系统以外 的某个系统中执行该操作。

• 系统体系结构：重放

系统体系结构：重放

在重放系统中重放工作量之前，务必执行以下操作：

1. 在测试系统中还原重放数据库，以便与工作量捕获开始时的捕获数据库匹配。

2. 根据需要更改测试系统（如执行升级等）。

3. 将工作量复制到测试系统。

一个名为“重放驱动程序”的特殊应用程序将使用工作量记录，向在其中重放工作量的 RDBMS  发送请求。该 RDBMS  通常是一个测试系统。假定重放系统的数据库适合于重放 已记录的工作量。不会重放内部RDBMS  客户机。重放驱动程序是一种特殊客户机，它使 用工作量记录并向测试系统发送相应的请求，其行为与记录工作量过程中使用的客户机在 发送外部请求时的行为相同（参见前面的示例）。使用其行为与RDBMS  的唯一外部客户 机相同的特殊驱动程序，可以记录和重放客户机不可知的基础结构。

重放驱动程序包含一个或多个连接到重放系统的客户机，并且可以根据工作量捕获发送请 求。重放驱动程序可以根据网络带宽、CPU 和内存容量，在所有重放客户机之间均匀分 配工作量捕获流。

• 更改前生产系统

更改前生产系统

数据库重放侧重于记录和重放RDBMS  所承受的工作量。因此，记录工作量的操作是在 图中所示的位置完成的。在软件堆栈中的RDBMS  上进行记录可实现此级别以下的所

有项目交换，并可使用记录和重放功能测试新的设置。

在重放工作量时，RDBMS  将执行记录过程中发现的操作。也就是说，RDBMS  代码在重 放阶段的行为方式与记录阶段的行为方式非常相似。这是通过重新创建所有外部客户机对 RDBMS  的请求实现的。外部客户机请求包括了 RDBMS  的所有可能的外部客户机发出的 请求。

• 支持的工作量

• 支持的工作量：

– 包含几乎所有类型的绑定的所有SQL（DML、DDL、 PL/SQL）

– 完整的LOB 功能（基于游标和直接OCI）

– 本地事务处理

– 登录和注销

– 会话切换

– 有限的PL/SQL RPC 

• 限制：

– 直接路径加载、导入/导出

– 基于OCI 的对象导航(ADT)  和REF 绑定

– 流、非基于PL/SQL  的AQ 

– 分布式事务处理、远程描述/提交操作

– 闪回（数据库和查询）

– 共享服务器

支持的工作量

以上显示了支持的和不支持的数据库操作。

注：也会捕获基于 SQL 的XML 操作。系统仅捕获显式的SQL 语句（客户机发布的SQL  语句）。不会捕获数据库本身生成的隐式调用。例如，审计是隐式的，类似后台进程活动 是隐式的。

• 捕获注意事项

计划：

• 为捕获的工作量（二进制文件）留出足够的磁盘空间

• 数据库重新启动：

– 确保重放与实际情况相符的唯一方式

— 启动限制

— 捕获将取消限制

– 可能不是必需的（取决于工作量）

• 还原数据库以进行重放的一种方式：

– 物理还原（提供顺序/时间）

– 逻辑还原应用程序数据

– 闪回/ 快照备用

• 可以指定过滤器来捕获部分工作量

• SYSDBA 或SYSOPER权限和相应的OS 权限

开销：

• TPCC 的性能开销为4.5% 

• 内存开销：每个会话64 KB 

• 磁盘空间

捕获注意事项

在工作量记录的计划阶段要执行以下任务：

• 检查数据库备份策略，确保在记录开始时数据库可被还原为StartSCN 。

• 计划捕获期间：根据应用情况和峰值期间选择捕获期间。可以使用现有的可管理性功 能，如自动工作量资料档案库(AWR) 和活动会话历史记录(ASH) ，根据工作量历史 记录选择一个恰当的期间。应谨慎计划捕获的开始时间，因为建议的操作是在捕获开 始前关闭并重新启动数据库。

• 指定工作量捕获数据的位置。必须设置用于存储工作量捕获数据的目录。应提供充足 的磁盘空间，因为磁盘空间不足时记录会停止。但是，在停止之前捕获的所有内容仍 可用于重放。

• 定义捕获过滤器，过滤掉不捕获的用户会话。可以指定记录过滤器以跳过不应捕获的 会话。

• 数据库重放功能没有引入任何新的权限或用户角色。记录用户和重放用户必须具有 SYSDBA 权限或SYSOPER权限。这是因为仅具备SYSOPER权限或SYSDBA 权限的 用户才可以启动或关闭开始记录的数据库。还应分配正确的操作系统(OS) 权限，以 便用户能够访问记录、重放目录以及操作这些目录下的文件。

• 重放注意事项

• 预处理捕获的工作量：

– 一次性的操作

– 在与重放时使用版本相同的 DB 版本上

– 如果版本匹配，可在任何位置（生产系统、测试系统或

其它系统）执行

• 还原数据库，然后执行更改：

– 升级

– 方案更改

– OS 更改

– 硬件更改

– 添加实例

重放注意事项

预处理阶段是必需的针对指定数据库版本的一次性操作。创建了必需的元数据以后，可以 按需要多次重放工作量。

必须还原重放数据库，以便与工作量捕获开始时的捕获数据库匹配。成功的重放取决于应 用程序事务处理，该事务处理要访问与捕获系统上的数据相同的应用程序数据。可以选择 使用时间点恢复、闪回和导入/ 导出来还原应用程序数据。

• 重放注意事项