目录结构

注：提前言明 本文借鉴了以下博主、书籍或网站的内容，其列表如下：

1、参考书籍：《Oracle Database SQL Language Reference》
2、参考书籍：《PostgreSQL中文手册》
3、EDB Postgres Advanced Server User Guides，点击前往
4、PostgreSQL数据库仓库链接，点击前往
5、PostgreSQL中文社区，点击前往
6、Oracle Real Application Testing 官网首页，点击前往
7、Oracle 21C RAT Testing Guide，点击前往
8、Oracle Database 19c:Real Application Testing Overview，点击前往
9、数据库回放白皮书 11g，点击前往

---

1、本文内容全部来源于开源社区 GitHub和以上博主的贡献，本文也免费开源（可能会存在问题，评论区等待大佬们的指正）
2、本文目的：开源共享 抛砖引玉 一起学习
3、本文不提供任何资源 不存在任何交易 与任何组织和机构无关
4、大家可以根据需要自行 复制粘贴以及作为其他个人用途，但是不允许转载 不允许商用 （写作不易，还请见谅 💖）

---

---

---

文章快速说明索引

学习目标：

目的：接下来这段时间我想做一些兼容Oracle数据库Real Application Testing (即：RAT)上的一些功能开发，本专栏这里主要是学习以及介绍Oracle数据库功能的使用场景、原理说明和注意事项等，基于PostgreSQL数据库的功能开发等之后 由新博客进行介绍和分享！

---

学习内容：（详见目录）

1、Oracle数据库Real Application Testing之真实应用测试概述白皮书

---

学习时间：

2023年05月11日 02:50:59

---

学习产出：

1、Oracle数据库Real Application Testing之真实应用测试概述白皮书
2、CSDN 技术博客 1篇

---

注：下面我们所有的学习环境是Centos7+PostgreSQL15.0+Oracle19c+MySQL5.7

postgres=# select version();
                                   version                                   
-----------------------------------------------------------------------------
 PostgreSQL 15.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.1.0, 64-bit
(1 row)

postgres=#

#-----------------------------------------------------------------------------#

SQL> select * from v$version; 

BANNER									    BANNER_FULL 								BANNER_LEGACY									CON_ID
--------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production	    Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production	Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production		     0
									    Version 19.3.0.0.0


SQL>
#-----------------------------------------------------------------------------#

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.19    |
+-----------+
1 row in set (0.06 sec)

mysql>

---

真实应用测试概述

Introduction

Oracle 数据库是市场领导者，是全球数十万家企业以及应用程序开发人员和数据库管理员的首选数据库。多年来，企业已经开始依赖 Oracle 数据库来提供无与伦比的性能和可靠性。Oracle 通过对整合的广泛支持继续提高 Oracle Database 19c 的标准。Oracle Database 19c 专为快速发展和变化以满足业务需求的数据中心环境而设计，使企业能够快速采用新技术，同时最大限度地降低风险。

Real Application Testing

如今，企业必须在硬件和软件方面进行大量投资才能推出基础架构变更。例如，数据中心可能会主动将数据库迁移到低成本计算平台，例如 Oracle Enterprise Linux。传统上，这将需要企业为整个应用程序堆栈（包括 Web 服务器、应用程序服务器和数据库）投资重复硬件，以测试其生产应用程序。因此，组织发现评估和实施对其数据中心基础设施的更改非常昂贵。此外，尽管客户进行了广泛的测试，但当最终在生产系统中进行更改时，仍经常会遇到意想不到的问题。这是因为测试工作负载通常是模拟的，并不是真实生产工作负载的准确或完整表示。因此，数据中心经理不愿意采用新技术并使他们的业务适应快速变化的竞争压力。Oracle Database 19c Real Application Testing 选项通过 SQL Performance Analyzer 和 Database Replay 这两个互补的解决方案正面解决了这些问题。

---

SQL Performance Analyzer

影响 SQL 执行计划的更改会严重影响应用程序性能和可用性。因此，DBA 花费大量时间来识别和修复由于系统更改而退化的 SQL 语句。SQL Performance Analyzer (SPA) 可以预测和预防环境变化导致的 SQL 执行性能问题。SQL Performance Analyzer 通过在更改前后连续运行 SQL 语句，提供环境更改对 SQL 执行计划和统计信息影响的粒度视图。生成的 SQL Performance Analyzer 报告概述了由于系统更改以及回归的 SQL 语句集而对工作负载带来的净收益。对于回归的 SQL 语句，提供了适当的执行计划详细信息以及调整它们的建议。

SQL Performance Analyzer 与现有的 SQL Tuning Set (STS)、SQL Tuning Advisor 和 SQL Plan Management 功能很好地集成在一起。SQL Performance Analyzer 完全自动化并简化了评估更改对超大 SQL 工作负载（数千条 SQL 语句）的影响的手动且耗时的过程。DBA 可以使用 SQL Tuning Advisor 修复测试环境中退化的 SQL 语句并生成新的计划。然后将这些计划播种到 SQL 计划管理基线并导出回生产环境。因此，使用 SQL Performance Analyzer，企业可以高度自信地验证对生产环境的系统更改实际上会以显着降低的成本带来净积极的改进。可以使用 SQL 性能分析器的常见系统更改示例包括：

• 数据库升级、补丁、初始化参数变更
• 操作系统、硬件或数据库的配置更改
• 架构更改，例如添加新索引、分区或物化视图
• 收集优化器统计信息
• SQL 调整操作，例如，创建 SQL 配置文件
• 使用 Oracle 可插拔数据库或模式整合方法进行数据库整合测试

使用 SQL Performance Analyzer 涉及以下 5 个主要步骤：

1. 捕获要使用 SPA 分析的 SQL 工作负载。Oracle 数据库提供了从多个来源（例如游标缓存和自动工作负载存储库）将 SQL 工作负载捕获到 SQL 调优集 (STS) 的方法。这通常在生产系统上完成，然后将 STS 传输到将进行 SPA 分析的测试系统
2. 通过在 STS 上执行 SPA，在更改之前测量工作负载的性能。非常短的运行查询被多次执行，它们的统计数据被平均以消除由于缓冲区缓存状态和其他噪声因素引起的变化
3. 进行更改，例如数据库升级或优化器统计信息刷新
4. 通过再次在 STS 上执行 SPA 来测量更改后工作负载的性能，如步骤 2 中所示
5. 比较 SQL 调优集的两次执行的性能，以确定已经退化、改进或未更改的 SQL 语句

图1中的SPA比较报告显示，在建议的系统更改之后，总体SQL工作负载有了显著的性能改进，但有一些执行计划的倒退。SQL Performance Analyzer在测量SQL语句的影响时，会考虑SQL语句的执行次数。在几秒钟内完成但经常执行的SQL语句可能比只执行一次的长时间运行语句对系统的影响更大。SPA在预测整体性能改进和回归时考虑了这些因素。如果遇到任何回归，SPA允许用户使用SQL调优顾问或SQL计划基线(Oracle Database 11g中引入的计划稳定性特性)来修复它们。

SPA支持许多其他有助于评估系统更改的功能，下面简要介绍：

1. SPA 有助于估计通过迁移到 Exadata 服务器可以实现的 IO 减少，但实际上不需要您配置硬件。这可用于识别适合 Exadata 迁移的潜在工作负载/系统
2. SPA 支持比较两个相似工作负载或 STS 的性能——当您拥有负载测试脚本或 Oracle Application Testing Suite 等可用于测试系统更改的机制时，此功能很有用。通过将工作负载捕获到两个不同的 STS（用于更改运行之前和之后），可以使用 SPA 来评估系统更改的影响
3. 借助 Oracle Enterprise Manager Cloud Control 13c，可以使用一键式one-clickSTS 传输机制来简化在生产和测试数据库之间移动 STS 工作负载和调整工件（例如 SQL 配置文件或计划基线）的过程
4. SPA 支持测试通过 Oracle 可插拔数据库或模式整合技术整合的数据库

---

Database Replay

数据库重放为 DBA 和系统管理员提供了在测试环境中忠实、准确和真实地重新运行实际生产工作负载（包括在线用户和批处理工作负载）的能力。通过从生产系统捕获完整的数据库工作负载，包括所有并发性、依赖性和时间，数据库重放使您能够通过在测试系统上重新创建生产工作负载来真实地测试系统更改——这是依赖模拟的传统测试工具永远无法复制的。通过数据库重放，DBA 和系统管理员可以测试：

• 数据库升级、补丁、参数、架构更改等
• 配置变更，如从单实例到RAC、ASM等的转换
• 存储、网络、互连变化
• 操作系统、硬件迁移、补丁、升级、参数更改
• 使用 Oracle 可插拔数据库和模式整合的数据库整合测试项目
• 工作负载扩展和自定义负载测试场景

Lower test infrastructure cost

DBA 现在可以使用测试基础设施来测试他们的更改，而无需复制整个应用程序基础设施的开销。数据库重放不需要重新创建中间层或 Web 服务器层的设置开销。

因此，DBA 和系统管理员可以满怀信心地快速测试和升级数据中心基础设施组件，因为他们知道这些更改确实已经使用生产场景进行了测试和验证。

Faster deployment

数据库重放的另一个主要优点是它不需要 DBA 花费数月时间来了解应用程序的功能知识和开发测试脚本。只需点击几下，DBA 就可以轻松获得完整的生产工作负载，以测试和推出任何更改。这将测试周期从数月缩短至数天或数周，从而为企业带来显着的成本节约。

数据库重放由四个主要步骤组成，如图 2 所示，如下所述：

1. 工作负载捕获

   启用工作负载捕获后，所有指向 Oracle 数据库的外部客户端请求都将被跟踪并存储在数据库服务器主机文件系统上的二进制文件（称为捕获文件）中。Oracle 建议在捕获负载之前对整个数据库进行备份。用户指定捕获文件的位置以及工作负载捕获的开始和结束时间。在此过程中，与外部数据库调用有关的所有信息都将写入捕获文件

2. 工作负载处理

   捕获工作负载后，必须处理捕获文件中的信息。此处理将捕获的数据转换为重放文件，并创建重放工作负载所需的所有必要元数据。捕获文件通常会被复制到另一个系统进行处理。在重放之前，必须为每个捕获的工作负载执行一次此操作。捕获的工作负载处理后，可以在重放系统上重复重放。由于工作负载处理可能非常耗时且资源密集，因此通常建议在将重放工作负载的测试系统上执行此步骤

3. 工作负载回放

   在处理了捕获的工作负载之后，现在可以进行回放了。然后，一个名为Replay client的客户端程序处理重放文件，并以与捕获系统完全相同的时间和并发性向数据库提交调用。根据捕获的工作负载，您可能需要一个或多个重放客户端来正确重放工作负载。提供了一种校准工具来帮助确定工作负载所需的重放客户端的数量。需要注意的是，由于整个工作负载都是重放的，包括DML和SQL查询，因此重放系统中的数据与捕获其工作负载的生产系统中的相同是很重要的，以便能够进行可靠的分析以进行报告

4. 分析和报告

   提供了广泛的报告，以便对捕获和重放进行详细分析。报告重放期间遇到的任何错误。显示 DML 或查询返回的行中的任何差异。提供了捕获和回放之间的基本性能比较。对于高级分析，回放比较周期和其他 AWR 报告可用于详细比较捕获和回放之间的各种统计数据

工作负载捕获和重放过程都支持过滤功能，该功能对于定位感兴趣的工作负载很有用，例如按服务、操作、模块等等。Oracle Enterprise Manager Cloud Control 13c 通过支持端到端的数据库重放自动化显着提高了真正应用测试的价值。这简化了将工作负载捕获和性能数据保存和传输到测试系统、正确设置测试系统和重放客户端以及通过云控制界面编排整个重放的过程。

---

Consolidate Database Replay

Oracle Database 12c 中的新功能 Database Replay 支持在单个统一数据库上同时执行多个数据库捕获。统一数据库可以是带有 Oracle 可插拔数据库的容器数据库，也可以是使用模式整合方法整合的传统数据库。针对统一数据库重放多个工作负载可确保目标平台能够支持该工作负载。数据库重放支持从所有受支持的 Oracle 数据库版本进行捕获。数据库重放可以在 Oracle 数据库 11 及更高版本上执行。Consolidated Database Replay 可以在 Oracle 数据库 11.2.0.2 及更高版本上执行。数据库重放的捕获与平台无关，可以在任何支持的操作系统上重放。此外，Consolidated Database Replay 支持对各个重放进行调度，从而可以调查各种工作负载场景。图3显示了两个工作负载的Consolidated Replay的结果：

Database Replay Workload Scale-up

Database Replay 还支持基于现有捕获的工作负载创建新的工作负载。新工作负载可用于容量规划和各种假设工作负载场景的验证。可与数据库重放一起使用以验证整合的三种技术包括工作负载折叠、时移和模式重新映射。

这些技术中的第一个是工作负载折叠。工作负载子集可用于组合新的工作负载。通过指定捕获持续时间内的时间点，将现有捕获的工作负载分割成子集，可以将现有捕获分成两个或更多较小的工作负载。然后，您可以通过沿此指定时间点折叠工作负载来增加工作负载。这是通过在目标数据库上提交子集工作负载的同时重放来完成的。这有效地增加了工作量，而无需使用脚本或提供绑定。此技术适用于各个交易大多彼此独立的应用程序。

另一种放大技术是时移。您可以安排多个数据库重放，以便它们的峰值数据库利用率保持一致。这使您可以查看目标整合系统是否可以处理当前生产系统的最大生产工作负载。

数据库重放还支持使用模式复制进行测试。您可以复制目标模式并运行同一工作负载的多次重放。在运行这些多个重放之前，您重新映射用户，以便每个重放都针对其单独的模式，避免工作负载冲突。模式复制允许您测试当前工作负载的多个规模，维护准确的工作负载配置文件和并发性。这在模式即服务 (SaaS) 或每个业务线都有自己的模式等场景中很有用。

Which testing solution

选择正确的测试解决方案有助于 DBA 有效地吸收和管理变更。SPA 帮助 DBA 改进 SQL 响应时间。SPA 是 SQL 单元测试，用于验证您的所有单个 SQL 语句是否都以最佳方式执行，并且应该在几乎每个测试环境中首先使用。

数据库重放旨在测试和提高整体系统性能。在 SPA 验证了单个 SQL 性能后，应使用数据库重放来确保全系统负载下的性能。

Consolidated Database Replay 能够确保数据库整合项目所需的数据库性能，无论是整合到 Oracle Exadata 机器、Oracle 数据库机、Oracle 可插拔数据库还是其他整合的基础架构。数据库工作负载扩展和自定义工作负载创建功能使您能够在各种假设工作负载场景下测试系统，从而使您的环境面向未来。Real Application Testing 使数据库管理员可以轻松地管理和执行对业务至关重要的更改，并以较低的成本完成所有工作。

Conclusion

在当今快速发展的 IT 环境中，变化是无情的。但这对数据中心经理和管理员来说并不难。得益于 Oracle Database 18c 中的真正应用测试功能，数据库管理员可以轻松适应变化，同时消除任何不良副作用。许多客户已经部署了 Real Application Testing，并从大大减少了计划外停机时间的目标环境测试成本和工作量中受益。Forrester 的一项研究确定，已部署 Real Application Testing 的客户在三年时间范围内的风险调整投资回报率为 224%，投资回收期为 5.9 个月。Real Application Testing 通过为 DBA 和系统管理员提供易于部署的解决方案来测试和推出数据中心变更，同时减少硬件和软件投资，从而帮助组织降低测试成本。

Orcle Real Application Testing 的使用帮助 CSX 简化了升级过程，并使其完成数据库升级所需的时间不到公司之前数据库升级所需时间的一半，后者涉及的数据库占用空间减少了 30%。Oracle Real Application Testing 提供了重要的洞察力，使 CSX 能够在将变更部署到生产环境之前全面评估基础架构变更的影响并在测试环境中微调查询。

---

数据库回放白皮书

灵活的企业希望能够快速采用新技术，无论是操作系统、服务器还是软件，以帮助他们在竞争中保持领先地位。

然而，变化通常会给关键任务 IT 系统带来一段时间的不稳定。真实应用测试——使用 Oracle 数据库 11g 企业版——允许企业快速采用新技术，同时消除与变更相关的风险。Real Application Testing 将工作负载捕获和重放功能与 SQL 性能分析器相结合，帮助您测试针对实际工作负载的更改，然后帮助您在将它们投入生产之前对其进行微调。

INTRODUCTION

硬件/软件升级、补丁应用等系统更改对于企业保持合规性/安全性竞争优势至关重要。在将系统更改引入生产系统之前，企业会花费大量时间和精力在测试环境中评估和测试系统更改。

然而，尽管进行了此类测试，使用各种脚本和模拟工具，许多问题往往在生产部署之前未被发现，并对系统性能和可用性产生负面影响。测试成功率低的主要原因是现有工具无法使用实际生产工作负载进行测试。

Database Replay 是 Oracle Real Application Testing 选件中的解决方案之一，它通过在测试系统上重新创建生产负载同时保持负载的独特特性来支持对系统更改进行逼真的测试。它通过捕获生产系统上的实时工作负载并使用原始工作负载的准确时间、并发性和事务属性在测试系统上重放它来实现。这种具有成本效益的解决方案不需要生成和维护任何测试脚本。因此，以前需要几个月努力的复杂应用程序的测试周期现在可以在几天内完成。

DATABASE REPLAY WORKFLOW

数据库重放工作流，数据库重放的工作流程由四个主要步骤组成：

• 工作负载捕获

  当在生产系统上启用负载捕获时，所有指向 Oracle 数据库的外部客户端请求都将被跟踪并存储在文件系统上的二进制文件中，称为捕获文件。用户指定捕获文件的位置以及捕获的持续时间。这些文件包含重放所需的所有相关信息，例如 SQL 文本、绑定值、挂钟时间、系统更改编号 scn等。捕获是数据库范围的并且是 RAC 感知的，因此它只需要在一个实例上启动。您可以通过企业管理器查看捕获进度和系统活动。Oracle 建议在负载捕获之前制定备份和恢复策略，以便可以使用与捕获开始时相同的数据重新创建测试系统。为了从此功能中获得最大利益，用户应该在他们的峰值工作负载期间启用捕获，因为对于测试目的而言，这是最有趣的时期

• 工作负载处理

  捕获后，必须在重放之前处理工作负载文件。这会创建重放工作负载所需的必要元数据。在与 Replay 系统相同的数据库版本上进行一次处理很重要。处理后，捕获的工作负载可以在同一版本上重复重放。通常建议在将重放工作负载的测试系统上执行此步骤

• 工作负载重放

  处理完工作负载后，它就可以进行重放了。测试系统应该应用更改并且数据库应该反映与捕获开始时相同的应用程序数据状态。提供了一个称为 Replay Client 的特殊客户端，以将工作负载发送到数据库服务器，其具有与捕获系统中相同的时间和并发特征。提供了一种校准工具来帮助确定重放客户端的数量，因为可能需要多个客户端来驱动工作负载。工作负载文件必须可供数据库服务器以及所有重放客户端使用

• 分析和报告

  提供了广泛的报告，以便对捕获和重放进行详细分析。报告在回放期间遇到的任何数据错误或差异。强烈建议使用应用程序级别验证脚本来评估重放后应用程序数据的状态。使用 AWR 数据的报告也可用于详细的性能分析。AWR 数据在回放后自动导出到工作负载目录中，允许在回放之间进行比较

Oracle 的企业管理器为上述工作流中的所有步骤提供了完整的支持。下面显示的是企业管理器中启动上述任何步骤的页面：

COMMON USAGE SCENARIOS

常见使用场景，数据库重放可用于测试数据库级别或数据库级别以下的任何系统更改。这包括配置和硬件更改。下面列出了数据库重放的一些常见使用场景：

• 数据库升级，包括补丁部署
• 配置更改，例如从单实例到RAC 的转换、ASM 的使用
• 试验负载平衡技术和RAC 服务
• 更改数据库配置参数，例如：大小调整参数
• 操作系统和硬件平台迁移
• 存储、网络、互连变化

本文的其余部分更详细地解释了各个步骤以及 Oracle 推荐的最佳实践。

CAPTURE

所有指向 Oracle 数据库的外部客户端请求都被跟踪并存储在指定为输入的目录中的二进制文件中。不捕获背景和系统活动。工作负载捕获基础设施支持本地和共享文件系统。捕获文件的大小还取决于工作负载，并与需要捕获的数据成正比。请注意，捕获数据的格式与平台无关；这允许您测试硬件平台之间的迁移。

随着时间的推移，工作负载目录将包含工作负载文件、回放所需的元数据以及捕获的 AWR 快照和所有后续回放（以便进行比较）。建议在捕获和每次重放后将此工作负载目录移动到单独的位置。每次回放都会向目录中添加更多内容，因此继续使用同一组文件来保存回放历史和比较非常重要。

我们目前支持 Oracle 数据库版本 10.2.0.4 及更高版本上的负载捕获。有关不支持的功能列表，请参阅限制部分。

Setting up Capture

在开始捕获之前，需要创建一个目录对象。确保底层目录是空的并且有足够的存储空间。如果系统空间不足，捕获将自动停止，而不会影响用户工作负载。

工作负载捕获可以按需运行或安排在特定时间运行，并且持续时间应涵盖应用程序的有趣时期，例如高峰时间和维护窗口 AWR 快照将在捕获期间自动拍摄，用于分析和报告。用户应在捕获结束时将快照导出到包含工作负载文件的目录。

Enterprise Manager 为这些操作提供全面支持。

Specifying Filters

捕获基础架构提供了根据工作负载属性包括或排除特定工作负载的能力：用户、程序、模块、操作、服务和会话 ID。由于许多应用程序可能共享同一个数据库，过滤器可用于仅测试需要升级的某些特定应用程序而不是整个系统。过滤器还可以用于过滤掉 DBA 在捕获期间可能想要执行的管理工作负载。

Capture Monitoring and Report

Enterprise Manager 提供了广泛的系统监控功能。您可以以图形方式查看与整个数据库工作负载相关的正在捕获的工作负载量。您还可以随时获取捕获状态的报告。AWR 快照在捕获期间自动生成，AWR 中的性能数据用于提供更详细的捕获报告。

建议导出 AWR 以进行进一步分析并与回放进行比较。除了性能数据之外，该报告还描述了已捕获的工作负载、未捕获的数量以及将无法重放的数量。

Overhead

工作负载捕获过程经过了高度优化，以确保即使在繁忙的系统中也能产生微不足道的开销。开销主要取决于工作负载，并且与需要捕获的数据成比例。例如，如果工作负载主要由长时间运行的查询调用组成，那么开销将是最小的，因为每个时间单位捕获的数据很小：对于执行该查询的每个调用，每个会话只有一次复杂查询的文本。相反，如果工作负载是插入密集型的，则开销会更高。例如，我们观察到，在运行高度并发的TPCC工作负载的系统上，吞吐量下降了4.5%。

---

TEST SYSTEM SETUP AND WORKLOAD PROCESSING

一旦捕获了工作负载，下一步就是设置测试系统并应用用户想要测试的更改，例如数据库升级或系统配置更改。测试系统应该将数据库恢复到捕获开始之前的时间点，以反映相同的应用程序数据状态，否则数据库可能会在重放期间遇到数据分歧。

可以使用 RMAN、快照备用、导入/导出工具等来完成应用程序数据的复制或恢复。可以从捕获报告中检索捕获周期的起始 SCN。（见图 4）。例如，如果正在测试数据库升级，您可以使用 RMAN 将测试系统上的数据库恢复到特定的 SCN 或时间点，然后执行升级。

在测试系统上处理之前，需要将捕获文件传输并合并到一个目录中。处理工作负载捕获会导致创建重放工作负载所需的必要元数据。处理需要在与 Replay 系统相同的数据库版本上完成一次。处理后，捕获的工作负载可以在同一版本上重复重放。

REPLAY

一旦捕获的工作负载得到处理，它现在就可以在测试系统上重放了。假定测试系统已正确设置。一个称为“重放客户端”的特殊客户端从已处理的文件中重放工作负载。重放客户端以与捕获系统中完全相同的时间和并发性提交对数据库的调用，并在系统上施加与生产环境中完全相同的负载。这允许识别由更改引起的任何不稳定性，并在将更改引入生产之前在测试环境中进行后续补救。

重要的是要注意重放不需要中间层和应用层。只需要数据库和重放客户端即可忠实地再现生产工作负载并测试系统更改。

Replay Client

重放客户端是重放捕获文件的多线程OCI客户端。每个重放客户端线程读取一个捕获文件，并将记录的调用解释为提交给数据库的OCI调用序列。重放客户端使用捕获处理输出来知道何时开始重放捕获文件。一旦开始回放文件，回放客户端线程就会根据记录的时间发出调用：它会遵守两个连续调用之间记录的思考时间。实际上，这意味着客户端上不同的重放线程之间没有协调。所有的同步（如果启用）都是在服务器端完成的，这产生了一个非常可扩展的体系结构，在这个体系结构中，我们可以根据需要拥有尽可能多的重放客户端，而不会有任何开销。

尽管重放客户端是一个多线程应用程序，可以同时重放多个会话，但由于每个进程的线程数、打开的文件描述符等原因，存在实际限制。建议重放客户端自己重放的并发会话不应超过50个。如果记录的工作负载有更多的并发会话，则应启动多个重放客户端，以便进行忠实的重放。我们提供了一个用于估计这些数字的校准实用程序（有关更多信息，请参阅“设置Replay客户端”一节），名为wrc的重放客户端二进制文件是Oracle客户端和Oracle即时客户端的一部分。

---

Replay Technology

Synchronization

其中一项关键突破是能够在保持原始并发和事务特性的同时重放工作负载。我们将此称为 同步化 synchornization。如果在回放期间启用同步（默认行为），服务器将遵循提交顺序以保留事务特性。

我们将捕获期间的调用分为提交操作和非提交操作。这种区别基于这样一个事实，即提交操作会更改数据库状态并使新状态对所有后续操作可见。

由于任何调用的结果都取决于数据库状态，重放必须确保每个调用都遵循适当的提交操作，以满足结果一致性并最终满足数据库最终状态的一致性。为了强制执行该要求，过早early到达服务器而无法重放的重放调用会等待以下等待事件，直到重放适当的提交操作：

• WCR：重放锁定顺序 replay lock order。如果会话在捕获期间与提交操作尚未重放的事务发生一些锁争用，则会话将在重放期间等待此事件
• WCR：重放时钟 replay clock。这是一个空闲事件。如果会话需要查看的数据库状态取决于尚未重放的提交操作，则会话将在重放期间等待此事件

图 5 显示了一个简单的同步示例。在捕获期间，非提交操作 T3 在提交操作 S2 之后执行。因此，S2 对数据库状态所做的更改对 T3 是可见的。现在，我们可以想象，在重放期间，S2 比捕获期间更慢并且需要更多时间才能完成。

即使重放客户端在捕获期间发出的同时发出了 T3，但在 S2 完成之前，数据库不应该重放它，否则它会错过 S2 的更改。因此，它将被置于 WCR：重放时钟等待事件，直到 S2 完成。

如果禁用同步，我们不会在调用之间强制执行任何逻辑依赖性，在这种情况下，调用仅根据捕获的时间重放。

Data Remapping

即使我们强制执行逻辑数据依赖性，在某些情况下，重放调用也不会执行与捕获期间相同的工作。当调用包含在回放系统中无效的系统相关数据时，就会发生这种情况。Oracle 数据库中此类数据的示例包括行标识符 (rowid)、大对象定位器 (lob 定位器) 和结果引用 (ref 游标)。如果它们是绑定值的一部分，重放客户端会将它们重新映射到运行时正确的值。

以下示例说明了运行时重新映射（图 7）。作为选择列表的一部分返回给客户端的 rowid 被捕获 (1)。然后捕获相同的 rowid 作为绑定 (2)。 在重放期间，捕获的与 select 语句 (3) 关联的 rowid 使重放客户端期望 rowid 的重放时间值。此时，已在捕获的 rowid 和重放期间看到的 rowid 之间建立关联。重放更新时 (4) 使用重放时间 rowid。这将使更新成功并更新员工行。

还需要对服务器内生成的标识符进行重新映射，例如序列值。当重放调用使用序列值时，重放基础结构会在捕获阶段查找工作负载使用的相应序列值。然后重放的调用会提供与捕获期间完全相同的值。如果序列代码在重放期间未更改，重放调用很可能会使用与捕获期间使用的序列值不同的序列值，从而导致数据分歧。

Causes of Data Divergence

重放的呼叫被认为是分歧的，如果：

• 它在回放期间影响的行数与在捕获期间影响的行数不同；
• 它在重放期间发现错误，而在捕获期间没有错误代码或错误代码不同。

由于捕获的数据不包含任何结果，我们无法知道重放期间的调用是否实际上具有与捕获期间相同的结果。但出于重放的目的，行计数和错误值足以表明重放调用的执行是否与其捕获的计数器部分类似。

虽然 Replay 技术足够先进，可以处理同步和数据重新映射，但结果一致性并不总是可能的。确实存在一些极端情况，并且在我们试验的所有工作负载中，这些情况只出现在一小部分调用中，并没有使重放作为测试工具的价值无效。分歧的一些示例原因如下：

• PLSQL 脚本中的多次提交 Multiple commits within PLSQL scripts：在这种情况下，我们将整个 PLSQL 块视为单个提交操作，并且不强制执行 PLSQL 块内的语句与来自其他会话的调用之间的提交顺序
• 重放期间未同步的用户操作 User actions that are not synchronized during replay：这包括，例如，调用 dbms_pipe、用户锁、dbms_lock.sleep，…
• 使用不可重复函数 Use of non-repeatable functions：此类函数的示例是 PLSQL 的 RANDOM() 和 SYSDATE
• 捕获开始时进行中的会话 In-flight sessions at the time capture starts：这些会话可能包含对捕获开始前未提交的数据进行操作的调用。这些呼叫将发生分歧，因为不会重放飞行中会话的缺失部分
• 对外部实体的引用 Reference to external entities：当捕获的调用使用指向远程数据库的数据库链接等设施时，如果远程链接不存在，它将在重放期间失败
• 与预定作业的交互 Interaction with scheduled jobs：如果在测试系统中执行的预定作业与某些重放会话的相同用户数据交互，则可能会出现分歧，因为我们没有在调度程序作业中对提交进行排序

在大多数实际情况下，Replay 力求最小化 replay divergence。由于它是一种测试工具，我们假设可以容忍由于极端情况导致的一些差异。这也强调了使用应用程序级别验证脚本来评估回放质量的必要性。

---

Replay Options

Server Options

默认情况下，重放以完全同步的模式完成。它与捕获的工作负载具有相同的事务提交顺序、相同的并发性和相同的时间。每个重放线程在捕获时启动的同时启动（相对于捕获/重放的开始），并且同一会话中任何两个连续调用之间的捕获期间记录的思考时间也在重放期间得到尊重。此模式通过设计确保最小的数据差异。

但是，它可能会增加一些开销（主要是由于提交顺序），在某些情况下可能会使性能测试无效。因此，我们提供选项来调整适合每个测试用例的重放行为。提交顺序可以打开或关闭。在回放期间可以容忍一些数据差异的情况下，忽略提交顺序可能是合适的。如果您的应用程序在会话之间的依赖性最小，那么此模式不会产生明显的数据差异并且可能很有用。它还可以用于压力和负载测试。

剩下的三个重放选项（连接时间刻度、思考时间刻度和自动速率）调整重放的请求速率。默认情况下，连接时间范围和思考时间范围设置为100%，这是请求速率一致性所必需的。它们可以根据情况进行调整。例如，当尝试在4节点RAC系统上重放单个实例捕获时，与单个实例设置相比，该系统可以处理高达4倍的请求率，可以将思考时间范围设置为25%，从而使重放客户端发出的工作负载的请求率翻四番。

默认情况下，自动速率处于启用状态，在这种情况下，重放线程将尝试通过适当减少思考时间来保持捕获的请求速率。如果关闭了自动速率，则捕获的思考时间不会减少，以补偿更长的执行调用。

Connection Remapping

在捕获时，记录的会话用于连接到数据库的连接字符串被记录下来。但是，用于重放的数据库通常不是捕获期间使用的数据库。因此，这些连接字符串需要在开始重放之前由用户重新映射。一些可能的重映射情况是：

• 一对一：简单的实例到实例的重新映射。还可以将单个连接字符串重新映射到负载平衡侦听器，以便测试从单个实例到 RAC 系统的升级
• 多对一：将多个连接字符串重新映射到测试系统中的单个服务（例如负载平衡侦听器）

Setting Up the Replay Clients

重放期间使用的重放客户端数量可由用户配置。但是，建议用户针对已处理的捕获工作负载以校准模式（wrc mode = calibrate）运行 WRC 重放客户端。校准报告提供了有关要使用的重放客户端数量以及所需 CPU 数量的建议。它还提供了有关捕获会话数和捕获期间看到的最大并发性的一些信息。强烈建议至少使用校准报告建议的重放客户端和 CPU 数量。如果不这样做可能会导致不忠实的重放和/或重放客户端错误。

此外，用户必须确保所有重放客户端都可以连接到重放数据库，并且他们可以访问包含已处理捕获文件的目录。这可以通过将目录复制到客户端计算机或使用共享文件系统来完成。如果采用前一种方法，则客户端计算机上目录的内容不应在重放后复制回原始目录。这将导致覆盖重要的重放数据。

---

REPLAY ANALYSIS AND REPORTING

回放完成后，用户可以通过与工作负载捕获相比较来评估回放的质量。回答的典型问题包括：

• 一般重放信息是什么，例如开始时间、结束时间、重放选项、使用的重放客户端数量等？
• 重放是否已完成？ 它被取消了吗？
• 与捕获相比或与之前的重放相比，重放有多快或多慢？
• 回放是否实际运行了预期的工作负载？
• 回放期间出现了什么错误和数据差异？
• 重放的性能特征是什么？

数据库回放功能提供回放报告以帮助用户分析回放。为了进一步调查，可以使用其他性能报告（AWR、Compare Period、ASH……）和性能顾问 (ADDM)。

Replay Report and Monitoring

用户可以使用企业管理器监控回放的进度和系统活动，并在回放期间或结束时生成报告。重放报告包括重放信息、重放统计信息、工作负载概况和重放差异，例如重放期间遇到的错误以及 DML 或 SQL 查询返回的行中的数据差异。上图是回放报告的例子。

限于篇幅，我们仅展示“回放信息”的概要和详细信息。 以下部分概述了如何解读报告的各个部分。

Session Failure

用户会话的重放可能会失败，会话中剩余呼叫的重放将被跳过。它在回放报告中显示为会话失败。会话失败可能是由于系统配置不当造成的。（例如：最大进程限制）。它也可能是由影子进程或重放线程的崩溃引起的，在这种情况下，应该在客户端或服务器日志目录中找到事件。

Error Divergence

如果特定调用的重放返回新错误或不同错误，则会报告错误分歧。有以下三种情况：

• 未找到：捕获期间遇到的错误在回放期间未看到
• 新错误：重放期间遇到的错误在捕获期间未出现
• 突变：回放中产生的错误与捕获期间产生的错误不同

Data Divergence

在捕获和重放期间，记录每个查询 (SELECT) 或 DML（INSERT、UPDATE）的行数。行数的差异被报告为分歧。用户不要单独依赖这些数据，这一点非常重要。

User-Supplied Data Validation Scripts

用户提供的数据验证脚本：由于工作负载重放的复杂性，用户可能很容易迷失在所提供的详细差异分析中。强烈建议使用特定于应用程序的验证脚本来评估回放质量。有两种方法可以开发验证脚本。首先，用户可以在工作负载中注入自定义设计的脚本来验证数据的关键方面。为这些脚本配备适当的module name/module name action属性允许报告基础设施生成关于它们的详细重放特定报告。前提是，如果此类定制设计的脚本没有发生分歧，那么重放就可以很好地再现捕获的工作负载。

另一种方法是开发一个脚本来评估重放的整体成功率。例如，如果在工作负载捕获期间处理了 10,000 个订单，您应该验证在回放期间也处理了类似数量的订单。请注意，在这种情况下，验证脚本不是工作负载捕获的一部分。

Performance Comparison

只有对回放的数据质量进行了令人满意的评估后，才能进行性能分析。捕获和重放报告可用于进行简单的性能比较。例如，用户可以比较持续时间、等待类/事件时间等。除非回放以非同步模式运行，否则重大错误或数据差异表明回放没有适当地运行数据库。

由于同步的性质，可能无法进行精确的数据库时间比较（如果同步已打开）。这是因为同步会导致等待“wcr: replay clock”空闲等待事件。另请注意，同步将消除捕获期间发生的某些事件；这些包括行锁等待，以及一些缓冲区忙和全局缓存忙等待事件。在捕获期间归因于这些等待事件的时间大部分将出现在“wcr：replay lock order：”重放等待事件下。

对于重放的深入非重放特定性能研究，现有工具可用于监视和测量性能。其中包括 AWR、ASH 和 AWR 比较周期报告。

Restrictions

数据库重放可以捕获和重放所有与 SQL 相关的和 PLSQL 调用，包括 PLSQL RPC。但是，当前数据库版本 (11.1) 不支持以下功能：

• SQL Loader直接路径加载，导入/导出
• 基于 OCI 的对象导航 (ADT) 和 REF 绑定
• 流，非基于 PLSQL 的 AQ
• 分布式事务、远程描述/提交操作
• 闪回查询
• 共享服务器

---

BEST PRACTICES

本节总结了用户应考虑有效使用数据库重放功能的实践列表。

Capture Planning

• 存储开销：所需的存储大小主要取决于工作负载。用户需要为工作负载捕获文件提供足够的磁盘空间。Oracle 建议根据短时间运行捕获来估算大小
• 捕获期：捕获期应包含有趣的工作负载，例如高峰时间
• 重新启动数据库：重新启动数据库是可选的，但是如果在捕获开始期间有正在进行的会话，则在捕获开始之前这些会话更改的数据可能会导致重放期间出现分歧。建议尽可能重新启动数据库，以尽量减少数据差异
• RAC 的文件系统：如果可能，建议使用共享文件系统
• AWR 数据导出：导出 AWR 提供了启用深入回放性能分析所需的统计数据。用户在导出 AWR 之前应考虑对生产系统的影响

Test System Setup and Workload Capture Processing

• 数据设置 Data Setup：应用程序数据需要与生产系统相同，以尽量减少回放差异。建议制定计划以确保相同的复制
• 处理 Processing：处理应该在测试系统而不是生产系统上完成，因为处理有性能开销并且可能需要很长时间

Replay Planning

• 隔离测试系统：测试系统应该与生产系统隔离，这样测试就不会干扰生产。数据库重放基础设施为此目的提供了灵活的目录对象创建和连接重新映射
• 系统时钟：如果应用程序逻辑涉及SYSDATE 使用，用户应考虑在重放开始时将系统时钟重置为捕获开始时的时间

---

PLSQL PACKAGES

虽然数据库重放的主要界面是 Oracle 企业管理器，但通过一些 PLSQL 包和 DBA 视图提供了一个命令行界面。请注意，需要 DBA 角色才能使用这些命令。

用于控制工作负载捕获的 PLSQL 包是 dbms_workload_capture。以下是进行捕获需要输入的主要命令。有关详细信息，请参阅文档。

• create directory “CAPTURE_DIR” as ‘/captures/cap1’;
• dbms_workload_capture.start_capture(name => ‘capture1’, dir => ‘CAPTURE_DIR’, duration => NULL);
• dbms_workload_capture.finish_capture;

用于控制工作负载重放的 PLSQL 包是 dbms_workload_replay。为了处理和重放捕获的工作负载，需要以下命令：

• dbms_workload_replay.process_capture(‘CAPTURE_DIR’);
• dbms_workload_replay.initialize_replay(replay_name => ‘replay1’, replay_dir => ‘CAPTURE_DIR’);
• dbms_workload_replay.remap_connection
• dbms_workload_replay.prepare_replay(synchronization => TRUE, connect_time_scale => 100, think_time_scale => 100, think_time_auto_correct => TRUE);
• dbms_workload_replay.start_replay;

在客户端，用户必须使用 wrc 二进制文件来获取有关捕获的工作负载的校准报告（以便了解需要多少重放客户端）并启动重放客户端：

• %> wrc mode=calibrate replaydir=/captures/cap1
• %> wrc user/passwd@inst replaydir=/captures/cap1

DBA Views

可以查询以下视图以获取有关目标数据库中捕获和重放的所有信息：

• dba_workload_captures
• dba_workload_replays
• dba_workload_replay_divergence
• v$_workload_replay_thread

有关这些视图的详细说明，请参阅文档。

---

CONCLUSION

在当今快速发展的 IT 环境中，变化是无情的，但对于数据中心经理和管理员来说，变化并不一定是困难的。得益于 Oracle 数据库 11g 中真实应用测试功能中的新数据库重放特性，数据库管理员可以轻松适应变化，同时将不良影响降至最低。这种独特技术所实现的功能是市场上任何测试工具所无法比拟的，它允许 DBA 捕获实时生产工作负载并在测试系统上重放相同的负载，同时保持原始工作负载的时间、并发性和事务属性。回放系统不需要 DBA 设置整个应用程序堆栈，从而进一步为组织节省时间和金钱。可以高度自信地快速评估变更，并且可以在业务用户受到变更的负面影响之前采取纠正措施。DBA 终于可以“无风险地改变”。