文章
SQL 和 PL/SQL
 | Oracle Database 11g： 作者：Arup Nanda |
数据库重放
了解如何使用数据库重放（Oracle Database 11g 中一个闪亮登场的全新工具）来捕获完整的数据库负载，以便您可以随意进行“重放”。
参见系列目录
需要在数据库中进行更改时 — 无论是进行微小的改动（如变更初始化参数和数据库属性）还是进行不可避免的较大改动（如应用补丁集），您最关心什么？对于到 Oracle Database 11g 的升级，您最关心的是什么？
对我而言，我最关心的是更改是否会带来“破坏性”风险。即使微小的改动也有可能引发多米诺骨牌效应，最终导致严重后果。
为了将这种风险降至最低，许多厂商在类似于生产环境的控制环境中进行更改，应用类似于生产系统的负载并观察随之产生的影响。复制生产系统非常简单（至少从技术层面上讲），但再现负载却是另一回事。说起来容易做起来难。
多数机构会采用一些可自动运行以模拟真实用户活动的第三方负载生成工具进行尝试。大多数情况下，这种方法是可行的，但始终无法真正忠实地再现生产数据库负载。这些第三方工具只是通过不同参数执行预编写的查询若干次；您必须向这些工具提供查询并给定其可以随机使用的参数范围。这并不能代表您的生产系统负载，而仅仅是运行了一小部分执行了若干次的生产负载，因此，这只是对 1% 的应用程序代码进行了测试。最糟糕的是，这些工具要求您自己提供所有来自生产负载的查询，对于小型应用程序而言，这可能需要数周或数月，对于复杂些的应用程序，则可能需要多达一年的时间。
如果可以，在数据库本身内记录所有数据库操作（与 DML 相关的操作及其他操作），而后按这些操作出现的真实顺序进行重放，难道不是一种更好的方法吗？
数据库重放概述
Oracle Database 11g 将为您带来诸多好处。新的数据库重放工具好似数据库内的 DVR。使用这个独特的方法，可以如实地以二进制文件格式捕获 SQL 级以下的所有数据库活动，然后在同一数据库或不同数据库内进行重放（这正是在进行数据库更改之前您希望做的）。您还可以自定义捕获流程，以包括或排除某些特定类型的活动。
数据库重放与另一个工具 SQL Performance Analyzer 共同构成了 Oracle Database 11g 的 Real Application Testing 选件。这两个工具之间的主要不同在于涉及的范围：数据库重放适用于捕获和重放数据库内的所有（符合某些过滤条件）活动，而 SQL Performance Analyzer 可用于捕获特定的 SQL 语句并对其进行重放。（在数据库重放中，您无法查看或访问捕获到的特定 SQL，而在 SQL Performance Analyzer 中则可以）。后者的一个显著优势是 SQL 调优，因为您可以调整由应用程序执行的 SQL 语句并评估其影响。（本系列即将推出有关 SQL Performance Analyzer 介绍的文章。）
理论上，数据库重放的工作顺序如下图所示。
启动一个记录数据库活动的捕获流程。
- 该流程将活动写入名为“capture files”的特殊文件，该文件位于 /capture directory/ 目录中。
- 稍后，停止捕获流程，将这些捕获文件移至 /replay directory/ 目录中的测试系统。
- 启动一个重放流程和若干重放客户端，以重放这些捕获文件。
- 这些捕获文件将在测试数据库上应用。
那么，数据库重放可以提供哪些第三方工具不能提供的优势？一些工具仅重放若干您提供的复合语句。而数据库重放不需要您提供 SQL 语句。由于它将捕获 SQL 之下的所有活动，因此您不会遗漏任何可能导致性能问题的关键操作。此外，您可以有选择地（针对特定用户、程序等）进行捕获，还可在捕获负载时指定时间期限，可以重放导致问题的特定负载，而不是整个数据库。
例如，您注意到月末利息计算程序导致问题出现，并猜想更改参数将简化流程。您必须做的是捕获月末程序运行期间内的负载，在测试系统上对参数进行更改，然后在该测试系统上重放捕获文件。如果性能有所提升，则表明此解决方案可行。如果性能没有提升，这也仅仅是个测试系统而已。您不会妨碍到生产数据库的运行。
在我看来，单为了使用该工具，也值得升级到 Oracle Database 11g。下面将介绍该工具的工作原理。
捕获
第一个任务是捕获数据库中的负载。所有任务都可通过命令行或 Oracle Enterprise Manager Database Control 完成，但本文将使用后者。
- 捕获到的负载存储在系统中的文件上，这些文件是名副其实的“摄像机”内的“磁带”。该目录应当为空。因此，第一个任务是创建目录（如果还没有此目录）。对于本例，创建的目录名为 /home/oracle/dbcapture。
$ cd /home/oracle
$ mkdir dbcapture - 在数据库中为该目录创建一个目录对象：
SQL> create directory dbcapture as '/home/oracle/dbcapture'; Directory created. - 现在，可以开始捕获了。为了演示真实场景，将创建一个简单的测试工具，该工具将生成许多 INSERT 语句并插入到一个名为 TRANS 的表中。
create table trans ( trans_id number, cust_name varchar2(20), trans_dt date, trans_amt number(8,2), store_id number(2) ) /
下面是一个可完成此任务的小的 PL/SQL 代码片断。该代码片断将生成 1,000 条插入语句并进行执行。（注意，此代码片段将生成 1,000 条不同的插入语句，而不是在同样的语句或程序中执行 1,000 次插入操作。）declare l_stmt varchar2(2000); begin for ctr in 1..1000 loop l_stmt := 'insert into trans values ('|| trans_id_seq.nextval||','|| ''''||dbms_random.string('U',20)||''','|| 'sysdate - '|| round(dbms_random.value(1,365))||','|| round(dbms_random.value(1,99999999),2)||','|| round(dbms_random.value(1,99))||')'; dbms_output.put_line(l_stmt); execute immediate l_stmt; commit; end loop; end; - 只创建包含以上内容的文件；不要运行。将该文件命名为 add_trans.sql。（以上所有步骤仅对于此课程都是必要的。如果没有目录对象，则在生产环境中执行操作时无需这些步骤。）
- 在现实情况中，您可能会在不同的数据库上运行重放。但是，在此处，针对我们的目的，您将只是闪回同一数据库并重放那里的活动。您可以通过创建名为 GOLD 的恢复点来标记该场所。
SQL> create restore point gold;
现在，准备开始捕获。导航到 Oracle Enterprise Manager Database Control 中的 Database Replay 主页面。在该主页中，选择 Software and Support（如下图所示，标记为“1”）
- 单击 Database Replay（在 Real Application Testing 下面）启动 Database Replay 页面（如下所示）。
- 在左侧窗格中，您将看到一系列活动。选择第一个活动 (Step 1:Capture Workload)，方式是单击它旁边的 Go to Task 图标。
- 下一个屏幕将显示三个您应在启动捕获流程之前仔细检查并确认的假设：
- 当前数据库可以在重放系统上恢复到负载捕获开始时的 SCN
- 有足够的磁盘空间来保存捕获的负载
- 在负载捕获开始之前已准备好重启数据库（如果您选择这样做）
- 选中所有复选框进行确认。
- 单击 Next。
- 下一个屏幕有两个不同的操作项。在屏幕的上半部分，您将看到两个单选按钮，您可通过这两个按钮来选择是否希望在捕获流程前重启数据库。
启动捕获流程后，可能会有一些正处于运行中的事务，其中并非所有都可进行捕获。重启数据库将使这些正处于运行中的事务无效。重启数据库可清除这些“干扰”。而且，重启数据库可以为您提供一个干净备份在测试系统上进行恢复，从而确保您在与生产系统的 SCN 号相同的系统上重放活动。
出于上述原因，特别是第一个，Oracle 建议在捕获之前重启数据库（该选项为默认设置）。但这不是必须的。如果不希望重启，请选择另一个单选按钮。
- 屏幕底部显示的内容如下所示。
现在，您将记录捕获流程在捕获活动时将考虑的筛选器。默认有两个筛选器：排除所有来自 Oracle Management Server 的活动和来自 Oracle Management Agent 的活动。
您也可以添加其他筛选器。例如，要添加排除所有 Perl 程序的筛选器，可单击 Add Another Row 并在域“Filter Name”和“Value”中分别输入“perl”和“%perl%”。同样，纠正默认参数中的小错误 — Oracle Management Agent 筛选器的值应为“%emagent%”，而不是“emagent%”。或者，假设您希望排除所有 SYS 用户操作。那么，您需要从 Session Attribute 下拉框中选择 USER，并在“Value”列中输入 SYS。
- 单击 Next。这将显示一个类似如下所示的屏幕：
- 在该屏幕中，从下拉框中选择将在其中存储捕获文件的目录名。本例中已使用了目录 DBCAPTURE。如果您没有在以上步骤中创建该目录，还可通过单击 Create Directory Object 进行创建。然后单击 Next。
- 在下一个屏幕中，您将看到 Job Details（作业细节），如作业执行时间等。选择单选按钮 Immediate 立即执行作业。
- 在该页面上填写其他详细信息，如 OS 用户名、SYS 口令等，并单击 Next。
- 下一个屏幕标为“Step 5 of 5”，其中将显示您输入的所有信息，如作业名和排除筛选器。如果所有内容都符合您的要求，则单击 Submit。否则，可返回进行修改。
- 一旦单击了 Submit，负载捕获就将开始。您将看到一个确认屏幕，如下所示。
注意 Status，其显示为“In Progress”。 - 现在，该工具正在捕获负载，从 SQL*Plus 提示符运行您的模拟负载。当然，在实际的系统中，无需运行任何模拟；只需让捕获流程运行一段时间以捕获所有负载。
SQL> connect arup/arup SQL> @ins_trans
这将在表 TRANS 中执行 1,000 条插入语句。在负载完成后，单击 Stop Capture 按钮，如以上屏幕中所示。将要求您确认。 - Oracle 在捕获负载前后自动获取自动负载信息库 (AWR) 快照。在下一个屏幕中，将询问您是否要导出 AWR 数据。如果您在其他系统上重放并且希望将 AWR 数据从当前数据库导出到目标数据库（如以下屏幕中所示），这步操作很重要。单击 Yes。
- 这将创建一个导出 AWR 的调度程序作业。单击作业名称并刷新状态屏幕，直至您看到作业从 Running 选项卡中消失。
您已将捕获的负载存储到 /home/oracle/dbcapture 目录中的文件里。
预处理
现在，负载已捕获，可进行重放了。通常，您希望在单独的测试系统中进行重放，因此需要将目录 /home/oracle/dbcapture 中的文件复制到一个新的主机。请确保在将文件复制到该目录时，该目录为空。出于教学目的，您将使用同一个数据库进行重放。
在同一数据库中进行重放并不常见，但有可能出现。例如，您可能希望在主系统中重放事务，测试完成后闪回至起始点。您可能会中断一个时段，以在期间测试参数更改（您将在同一数据库中进行此更改）的效果。
您需要在播放捕获的负载之前对其进行预处理。预处理可使这些捕获的文件为重放做好准备。
转至 Database Replay 主页面。
选择 Step 2:Preprocess Workload。
从下拉列表框中选择目录对象。这将显示捕获的负载。在本例中，该目录对象是 DBCAPTURE。如果您还没有创建目录对象，单击相应的按钮即可轻松创建目录。
单击 Preprocess Workload。
在下一个页面中，将要求您提供作业名和相关详细信息，如主机用户名和口令。如果不想指定作业名，则接受默认值。选择立即运行该作业。主机用户 ID 和口令应已填充。如果还没有，输入相应的值，单击 Submit。
在下一个页面中，您将看到确认信息和一个可用于查看作业状态的链接。单击该链接。
刷新该屏幕，直至您看到状态为“Succeeded”。
现在，负载已经过预处理，可用于重放了。
重放
捕获负载并进行预处理后，就可在测试数据库中进行重放了。出于教学目的，您在同一数据库中预处理了负载，并将使用同一数据库重放这些活动。为此，您必须将数据库重置回起始点。您可以通过将其闪回到在捕获流程期间创建的还原点 GOLD 来轻松实现此目的。
SQL> shutdown immediate;
... database shuts down ...
SQL> startup mount
... instance starts and mounts the database ...
SQL> flashback database to restore point gold;
... database will be flashed back ...
SQL> alter database open resetlogs;
... database is opened ...
现在，您处于负载启动之前的一个点，可以重放之前捕获的负载了。按照以下步骤对其进行重放。
- 从 Database 主页转至 Database Replay 主屏幕，如“Capturing”部分中所示。
- 从菜单中选择 Step 3:Replay Workload。这将带您进入 Replay 主屏幕。
- 您将看到一个用于选择目录的下拉框。选择重放文件所在的目录。这是目录对象；不是实际的 UNIX 目录。在之前的示例中，您使用了目录对象 DBCAPTURE，因此将其选中。如果您还没有创建目录，可单击 Create Directory 创建一个目录对象。
- 单击右上角的 Setup Replay。
- 下一个屏幕将显示即将发生的事情的信息列表。以下为每条信息项的相关说明。
- Restore Database（还原数据库）— 重放之前捕获的负载时，可能需要在测试系统上执行此操作。您如何构建测试系统？您可能将生产数据库还原到测试系统并对其进行还原。最大的可能是，在此活动中，生产数据库没有关闭，因此您的恢复可能并不完全。在这种情况下，确认恢复操作已执行至捕获和预处理阶段指定的 SCN 号。
本例中，您将数据库闪回至该 SCN 号。因此，您遵循了规定。 Perform System Changes（执行系统更改）— 这是为什么要首先执行重放的原因：测试系统更改，如参数更改或设置更改。当然，您需要在重放之前进行更改。
- Resolve References to External Systems（解决对外部系统的引用）— 假设您已经在生产数据库中有了一个指向 /home/appman/myfiles 的目录对象，而测试系统上不存在该目录。在重放时，对该目录的引用将失败。同样，源系统中的所有数据库链接也将在测试系统中失败（如果它们不存在）。因此，您需要通过创建或更改目录来解决这些问题。可以利用下一个屏幕对其进行更改。
- Set Up Replay Clients（设置重放客户端）— 了解如何在后续步骤中执行该操作。
- 单击 Continue，这将显示如下所示的屏幕：
可以通过单击页面上显示的链接更改所有非引用参数。请注意，单击任何一个链接都将离开 Database Replay 页面。因此，最好在 SQL*Plus 中对这些链接进行单独更改。单击 Continue。 - 输入 Replay Name 或接受默认值。
- 下一个屏幕将显示一些由于未解决的对数据库链接、目录等的引用而可能导致的问题。
如果愿意，可以在屏幕右侧更改重放系统。在本例中，由于在同一数据库上运行，因此本步骤并非必需。 - 单击 Next。这将显示如下所示的屏幕：
该屏幕将显示重放流程正在等待重放客户端。重放客户端的执行并不在 Database Control 屏幕内进行。这些客户端程序读取捕获的负载并对其进行重放。程序名为 wrc（在 UNIX 和 Windows 系统上均是该名称）。要启动重放客户端，您需要转至 UNIX 提示符并执行以下命令行：$ wrc userid=system password=* replaydir=/home/oracle/dbcapture - 当然，您需要提供正确的 SYSTEM 口令。如果捕获文件存储在另一个地方，则需更改目录名。应返回以下消息：
Workload Replay Client: Release 11.1.0.6.0 - Production on Tue Sep 4 19:50:44 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved. Wait for the replay to start (19:50:44) - 此时，重放客户端仅仅是等待重放管理程序 (Database Control) 告知其启动。您可以决定是否启动多个客户端来并行处理负载。
- 立即转至 Database Control 屏幕。您应当看到该屏幕已更改，其中显示已连接重放客户端。该屏幕将显示客户端连接的主机名、操作系统进程 ID 等。
- 单击 Next，然后单击 Submit 启动重放流程。如果现在转至 UNIX 会话，您会看到另一条消息：“Replay started (01:49:56)”。该屏幕将通过进度条来显示目前已处理的数据量。
- 一段时间之后，UNIX 会话将显示“Replay finished (01:50:35)”。此时，如果查看 Database Control 屏幕，您将看到该屏幕类似如下所示：
- 其中显示了重放作业的详细状态。左上角的关键域“Status”显示为“Completed”，指示作业已完成。
- 现在可以进行运行分析了。该屏幕在下半部分（标题“Comparison”下）显示了一些指标。在本例中，完成重放所用的时间是捕获时间的 39.08%。这是个好消息吗？您实施的更改有效吗？
未必。查看下一个指标 — Database Time — 是捕获时间的 180%。要查看更多信息，可单击选项卡 Report，这将显示如下屏幕：
- 该屏幕显示报告的各种选项。从最简单的 Workload Report 开始。该报告没有比较性能，而是向您显示“差异”— 重放中有多少数据不同。例如，如果您有一条 ID 为 3 的记录，对该记录进行了更新，之后又将其删除。在重放期间，假定先将其删除然后再更新；这就属于差异。差异越少，回放越精确。
- 但请勿就此停下。要进行明确分析，可检查如下所示的 AWR 比较时段报告，看看众多其他指标（如栓锁争用、锁定、重做产生、一致获取等）之间的差异，以使您更好、更清晰地了解更改所带来的影响。
该报告显示捕获和重放负载之间的差异。在重放期间，与捕获期间相比，物理读取和写入分别增加为 367% 和 111%。其他参数（如排序和逻辑读取）也呈增长趋势，虽然增长的不是那么明显。因此，您可以得出结论：无论进行何种更改，都会损害性能，而非有助于性能。
第 2 版新增特性：
在第 2 版中，将一些新的信息类型捕获到 AWR 信息库中。这些新数据源作为视图公开，视图名称中包含 DBA_HIST。
DBA_HIST_DISPATCHER
DBA_HIST_DYN_REMASTER_STATS
DBA_HIST_IOSTAT_DETAIL
DBA_HIST_SHARED_SERVER_SUMMARY
DBA_HIST_SQLCOMMAND_NAME
DBA_HIST_TOPLEVELCALL_NAME
这里要介绍一个特别重要的视图。DBA_HIST_IOSTAT_DETAIL 显示按文件类型和功能（组件）组合所收集的 I/O 统计信息。该视图包含 V$IOSTAT_FILE 和 V$IOSTAT_FUNCTION 的快照。以下是内容的快照：
SNAP_ID DBID INSTANCE_NUMBER FUNCTION_ID FUNCTION_NAME
---------- ---------- --------------- ----------- ------------------------------
FILETYPE_ID FILETYPE_NAME SMALL_READ_MEGABYTES
----------- ------------------------------ --------------------
SMALL_WRITE_MEGABYTES LARGE_READ_MEGABYTES LARGE_WRITE_MEGABYTES SMALL_READ_REQS
--------------------- -------------------- --------------------- ---------------
SMALL_WRITE_REQS LARGE_READ_REQS LARGE_WRITE_REQS NUMBER_OF_WAITS WAIT_TIME
---------------- --------------- ---------------- --------------- ----------
1099 1883196973 1 2 LGWR
1 Control File 4
4 0 0 279
286 0 0 279 985
1099 1883196973 1 2 LGWR
3 Log File 0
586 0 494 52
165586 0 1438 104 457
1099 1883196973 1 5 Streams AQ
1 Control File 13
4 0 0 861
246 0 0 861 1471
1099 1883196973 1 5 Streams AQ
2 Data File 5
0 0 210 569
82 0 210 610 19582
1099 1883196973 1 8 Buffer Cache Reads
2 Data File 664
0 346 0 62272
0 779 0 50136 396220
1099 1883196973 1 9 Direct Reads
2 Data File 62
0 1139 0 761
4 2340 1 0 0
1099 1883196973 1 10 Direct Writes
2 Data File 0
4 0 6 0
316 0 24 0 0
该输出清楚地显示了不同类型文件（如数据文件、控制文件、重做日志文件和 Data Pump 文件）上的组件（DBWR、LGWR、Streams、Data Pump 等）发出的不同类型的 IO 调用（少量或大量读取等）。
此外，在 Oracle Database 11g 第 2 版中，数据库重放有一个被称作扩展倍增器 (scale up multiplier) 的新特性，相比于捕获期间的负载，该特性在负载重放期间可数倍增加数据库上的负载。
我们通过一个示例来了解如何使用该特性。我们将从目录 u01/ratcapture 中捕获的负载开始。我们还在该 UNIX 目录上定义了一个名为 RATCAPTURE 的目录对象。通过该信息，我们可以重放捕获的文件。我通过数据库负载捕获 API（而非 Enterprise Manager）来演示该操作。（截至本文撰写时，Enterprise Manager 尚未放入所需特殊参数的供应方式，因此，无论如何 API 都是唯一选择。）
以下是具体操作步骤。此时，已经捕获了负载并且准备在目标系统中处理。
首先，我们将预处理捕获的文件。
begin dbms_workload_replay.process_capture (capture_dir => 'RATCAPTURE'); end; /
我们将需要为重放初始化数据库。我们必须为重放提供一个名称；我们选择 REPLAY1。
begin
dbms_workload_replay.initialize_replay (
replay_name => 'REPLAY1',
replay_dir => 'RATCAPTURE'
);
end;
/
然后，我们将为重放准备数据库。这就是我们将使用特殊参数来进行扩展的地方。该参数（恰当的名称为 scale_up_multiplier）设置为 10 时，可将负载重放提高到 10 倍于捕获期间的原始负载。
begin
dbms_workload_replay.prepare_replay (
synchronization => 'SCN',
connect_time_scale => 100,
think_time_scale => 100,
think_time_auto_correct => TRUE,
scale_up_multiplier => 10
);
end;
/
在一个单独的 Unix 会话上，我们将需要启动 wrc 客户端。这将等待实际重放启动。
# wrc system/oracle REPLAYDIR=/u01/ratcapture Workload Replay Client: Release 11.2.0.1.0 - Production on Thu Aug 12 17:24:30 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Wait for the replay to start (17:24:30)
在第一个 SQL*Plus 会话上，我们将启动重放。
begin dbms_workload_replay.start_replay; end; /
当重放启动后，wrc 客户端也将开始处理。它将显示重放已启动以及启动时间。
Replay started (17:27:04)
在重放了全部捕获负载后，将显示重放完成以及完成时间，然后返回 unix 提示符。
Replay finished (17:29:51)
现在该分析重放期间所发生的事情了，也就是查看重放报告。为此，我们需要找到本次重放的 ID：
SQL> select id, name, scale_up_multiplier
2* from dba_workload_replays;
ID NAME SCALE_UP_MULTIPLIER
---------- ------------------------------ -------------------
4 REPLAY-D112D2-20100812170729 1
6 REPLAY1 10
我们可以看到有两次重放。一次的 ID 为 4，本次重放未使用任何扩展。另一次就是我们刚刚运行的那次，扩展了 10 倍。
然后，我们将获取 ID 为 6 的重放的报告。可以通过从程序包 dbms_workload_replay 中执行函数 REPORT 来获取该报告。该函数的输出是 CLOB 数据类型的报告。在进行选择之前，您需要先设置 LONGSIZE，否则默认情况下，它仅显示前 80 个字节。
SQL> set longsize 999999 SQL> select dbms_workload_replay.report ( 2> replay_id => 6, 3> format => 'TEXT' 4> ) 5> from dual;输出如下：
DB Replay Report for REPLAY1
------------------------------------------------------------------------
-------------------------------------------------------------------------
| DB Name | DB Id | Release | RAC | Replay Name | Replay Status |
-------------------------------------------------------------------------
| D112D2 | 1883196973 | 11.2.0.1.0 | NO | REPLAY1 | COMPLETED |
-------------------------------------------------------------------------
Replay Information
------------------------------------------------------------------------
| Information | Replay | Capture |
------------------------------------------------------------------------
| Name | REPLAY1 | CAPTURE-D112D2-20100812162527 |
------------------------------------------------------------------------
| Status | COMPLETED | COMPLETED |
------------------------------------------------------------------------
| Database Name | D112D2 | D112D2 |
------------------------------------------------------------------------
| Database Version | 11.2.0.1.0 | 11.2.0.1.0 |
------------------------------------------------------------------------
| Start Time | 12-08-10 21:27:04 | 12-08-10 20:28:47 |
------------------------------------------------------------------------
| End Time | 12-08-10 21:27:10 | 12-08-10 20:28:59 |
------------------------------------------------------------------------
| Duration | 6 seconds | 12 seconds |
------------------------------------------------------------------------
| Directory Object | RATCAPTURE | RATCAPTURE |
------------------------------------------------------------------------
| Directory Path | /u01/ratcapture | /u01/ratcapture |
------------------------------------------------------------------------
Replay Options
---------------------------------------------------------
| Option Name | Value |
---------------------------------------------------------
| Synchronization | SCN |
---------------------------------------------------------
| Connect Time | 100% |
---------------------------------------------------------
| Think Time | 100% |
---------------------------------------------------------
| Think Time Auto Correct | TRUE |
---------------------------------------------------------
| Number of WRC Clients | 1 (1 Completed, 0 Running ) |
---------------------------------------------------------
Replay Statistics
------------------------------------------------------------
| Statistic | Replay | Capture |
------------------------------------------------------------
| DB Time | 5.047 seconds | 0.407 seconds |
------------------------------------------------------------
| Average Active Sessions | .84 | .03 |
------------------------------------------------------------
| User calls | 1120 | 112 |
------------------------------------------------------------
| Network Time | 3.748 seconds | . |
------------------------------------------------------------
| Think Time | 24.591 seconds | . |
------------------------------------------------------------
Replay Divergence Summary
-------------------------------------------------------------------
| Divergence Type | Count | % Total |
-------------------------------------------------------------------
| Session Failures During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| Errors No Longer Seen During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| New Errors Seen During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| Errors Mutated During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| DMLs with Different Number of Rows Modified | 0 | 0.00 |
-------------------------------------------------------------------
| SELECTs with Different Number of Rows Fetched | 0 | 0.00 |
-------------------------------------------------------------------
现在将此报告与扩展倍增器保留为默认值 1 的报告进行比较。下面是 ID 为 4 的重放的报告（来自之前显示的 DBA_WORKLOAD_REPLAYS 视图的输出）。
DB Replay Report for REPLAY-D112D2-20100812170729
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
| DB Name | DB Id | Release | RAC | Replay Name | Replay Status |
------------------------------------------------------------------------------------------
| D112D2 | 1883196973 | 11.2.0.1.0 | NO | REPLAY-D112D2-20100812170729 | COMPLETED |
------------------------------------------------------------------------------------------
Replay Information
-----------------------------------------------------------------------------------
| Information | Replay | Capture |
-----------------------------------------------------------------------------------
| Name | REPLAY-D112D2-20100812170729 | CAPTURE-D112D2-20100812162527 |
-----------------------------------------------------------------------------------
| Status | COMPLETED | COMPLETED |
-----------------------------------------------------------------------------------
| Database Name | D112D2 | D112D2 |
-----------------------------------------------------------------------------------
| Database Version | 11.2.0.1.0 | 11.2.0.1.0 |
-----------------------------------------------------------------------------------
| Start Time | 12-08-10 21:13:17 | 12-08-10 20:28:47 |
-----------------------------------------------------------------------------------
| End Time | 12-08-10 21:13:22 | 12-08-10 20:28:59 |
-----------------------------------------------------------------------------------
| Duration | 5 seconds | 12 seconds |
-----------------------------------------------------------------------------------
| Directory Object | RATCAPTURE | RATCAPTURE |
-----------------------------------------------------------------------------------
| Directory Path | /u01/ratcapture | /u01/ratcapture |
-----------------------------------------------------------------------------------
Replay Options
---------------------------------------------------------
| Option Name | Value |
---------------------------------------------------------
| Synchronization | SCN |
---------------------------------------------------------
| Connect Time | 100% |
---------------------------------------------------------
| Think Time | 100% |
---------------------------------------------------------
| Think Time Auto Correct | TRUE |
---------------------------------------------------------
| Number of WRC Clients | 1 (1 Completed, 0 Running ) |
---------------------------------------------------------
Replay Statistics
-----------------------------------------------------------
| Statistic | Replay | Capture |
-----------------------------------------------------------
| DB Time | 1.458 seconds | 0.407 seconds |
-----------------------------------------------------------
| Average Active Sessions | .29 | .03 |
-----------------------------------------------------------
| User calls | 112 | 112 |
-----------------------------------------------------------
| Network Time | 0.087 seconds | . |
-----------------------------------------------------------
| Think Time | 2.786 seconds | . |
-----------------------------------------------------------
Replay Divergence Summary
-------------------------------------------------------------------
| Divergence Type | Count | % Total |
-------------------------------------------------------------------
| Session Failures During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| Errors No Longer Seen During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| New Errors Seen During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| Errors Mutated During Replay | 0 | 0.00 |
-------------------------------------------------------------------
| DMLs with Different Number of Rows Modified | 0 | 0.00 |
-------------------------------------------------------------------
| SELECTs with Different Number of Rows Fetched | 0 | 0.00 |
-------------------------------------------------------------------
您是否注意到一些重要差异？
- 在使用了扩展的情况下，重放持续时间为 6 秒，与之相比，非扩展情况下为 5 秒
- DB 时间为 5.047，非扩展情况下为 1.458 秒
- 平均活动会话数和用户调用数分别为 0.84 和 1120，而这些数字在非扩展情况下为 0.29 和 112。顺便说一下，在捕获期间，用户调用数也是 112，与非扩展情况相同。因为扩展系数为 10，因此用户调用的数量增加到 10 倍。
您可以清楚地看到，扩展倍增器按照倍增系数增加了用户会话的数量。该测试不仅如实地重放了生产环境中捕获的活动，而且还增加了这些活动的数量以检查系统是否能够处理该测试。
您应牢记一些重要事情：捕获的负载只是一个 SELECT 查询。如果已有 DML，那么仅一组重放发出了这些语句，而其他仅重放 SELECT。5 个不同的重放客户端运行同一条删除语句将不会造成 5 次删除，而 5 条插入语句可能会由于主键违规导致四个故障。
此外，还请考虑以下情况：假设从生产系统中捕获了所有负载，并在测试系统中重放了这些负载。经过几轮测试和调优后，将测试系统升级为生产系统。假设某个应用程序仍需要进一步的模式更改（如附加索引或不同分区），您当然希望确保这些更改会增强性能，更重要的是，不会导致其他问题。在模式更改后再次重放负载是确认您所考虑的问题的最有效方法。
如何确保仅重放特定用户（例如 SH）的活动？一种方法是从生产环境中重新捕获负载，具体来说就添加一个仅捕获 SH 的活动的筛选器，然后在测试系统上重放新捕获的负载。但是，该方法可能由于以下多种原因而不可行：
截至某个时段（不同于测试系统中的时段）已经捕获了新负载，从而导致重放效率极低。
由于旧生产环境不再工作，而新生产环境（旧测试环境）没有与 SH 模式相关的任何活动，甚至可能导致无法捕获新负载。
即使可以再次捕获负载，但是为了避免影响生产性能的风险，您可能也不希望这样做
其他逻辑方面的挑战（如变更控制限制）
可以做些什么呢？
在 Oracle Database 11g 第 2 版中，有一个简单选择：在重放阶段只重放选择的负载。这样，不仅可以在捕获期间应用筛选器，还可以在重放期间应用筛选器。我们来了解一下其工作原理。
在重放期间，您可以创建并使用筛选器。我们来创建一个筛选器以便仅使用 SH 用户：
begin dbms_workload_replay.add_filter ( fname => 'SH_ONLY', fattribute => 'USER', fvalue => 'SH' ); end; /
您可以对众多用户定义任意数量的筛选器。此外，您还可以对不同属性（不只是用户名）定义筛选器。在参数 FATTRIBUTE 中可以使用以下值，在 FVALUE 参数中可以使用您感兴趣的值。以下是属性的可能值：
USER the usernames of the calling users MODULE the module ACTION the action PROGRAM the program SERVICE service_name of the calling user CONNECTION_STRING the connect string used (like the one you use in tnsnames.ora file)
添加筛选器之后，创建一个筛选器集：
begin
dbms_workload_replay.create_filter_set (
replay_dir => 'RATCATURE',
filter_set => 'SH_ONLY',
default_action => 'INCLUDE'
);
end;
/
注意，参数 default_action 设置为 INCLUDE，这是默认值。它指定筛选器集的默认操作。在本例中，INCLUDE 意味着包含筛选器，即 SH 用户包含在重放的负载中。如果您希望相反的结果，即运行除 SH 以外的所有用户的操作，那么您应使用 EXCLUDE 作为此参数的值。
创建筛选器集之后，就可在重放中使用它了。数据库初始化之后（在重放之前）：
begin
dbms_workload_replay.initialize_replay (
replay_name => 'REPLAY1',
replay_dir => 'RATCATURE'
);
end;
/
您可使用筛选器集：
begin
dbms_workload_replay.use_filter_set (
filter_set => 'SH_ONLY'
);
end;
/
当您执行选择性测试（即针对模式、服务名称等的测试）时，重放负载子集这一功能非常有用。它使您不必多次捕获负载。理想情况下，您只需要一次捕获整个生产负载，然后有选择性地重放，从而单独测试各种组件。
用例
数据库参数更改 — 假如，您要更改参数 db_file_multiblock_read_count 的默认值，那么是从 16 改为 256 还是 128？亦或是将其设为 64 或 32？选择有限，但影响可能无限；更改此值会对优化器带来极大影响，对某个查询有益的更改可能会破坏另外 100 个查询。如何确定该参数的最佳值？
数据库重放可轻松应对这种情况。您可以从生产系统捕获负载，而后将捕获的负载移至不同的测试系统中，并将 db_file_multiblock_read_count 设为 32，然后重放负载。之后，您可以将数据库闪回至初始状态，将该值设为 64，并重放相同的负载。您可以针对该参数所有可能的值重复执行这一过程：闪回、设置值、重放捕获的负载。每次重放时，您可运行重放前后的 AWR 报告并进行比较。然后选择可带来最佳整体结果的参数值。如果没有数据库重放，则根本不可能确定出最佳值。
操作系统升级 — 您计划升级操作系统或只是应用一个小补丁来修复 I/O 问题，但您如何能确保它不会带来任何破坏或带来一些其他问题？很简单：只要捕获负载并在应用补丁的测试系统中对其进行重放。该方法同样也适用于内核参数更改。
应用补丁 — 假设您发现一个错误，并且有相应的补丁可用。但您无法确保其会对现有操作产生何种影响，当然，您也可以和企业中 1000 位其他用户共同找出答案。数据库重放将为您解决这一难题。
调试 — 总是会有一些会带来意外结果的令人讨厌的程序。幸运的是，有了数据库重放，调试变得前所未有的轻松。只需在程序运行期间捕获负载，并移至一个新系统，更改程序逻辑以加入一些调试信息，而后重放负载、分析输出并解决问题。如果第一次并未奏效，不要失去信心。重复该过程（从重放开始；无需再次捕获）直至找到解决方案。
对象更改 — 您希望添加索引或将索引从 b 树转换为位图。这会对 INSERT 语句产生何种影响？会在何处产生影响？不要猜测；只需捕获负载并在测试系统中进行重放即可。
数据库升级 — 这是梦寐以求的更改确保。升级至 Oracle Database 11g 的时代已经到来。最大的问题是：您所有的应用程序都会正常运行甚至是表现更好吗？无需多虑，只要从 Oracle Database 10g 捕获负载并在 Oracle Database 11g 中进行重放即可。您不是在新版本上测试一些复合事务，而是在测试应用程序每天都在使用的 SQL。如果有些事情并未按计划进行，则在新系统中对其进行调整，直至您获得完全满意的结果。
平台更改 — 假设您希望将数据库平台从 Solaris 迁移到 HP-UX（其中没有提供适用于文件系统的异步 I/O）。性能是否还会一样？为什么要猜测？只要捕获 Solaris 中的负载并在 HP-UX 中进行重放即可。
转换到 Oracle Real Application Clusters (RAC) — 这是一个普遍问题：您计划将数据库从单一实例转换为 RAC 实例。应用程序表现是否如初？获取答案的唯一方法是运行实际的负载，对其进行捕获，而后在 RAC 数据库中进行重放。
总结
更改从来都是困难重重，但也不再是无法忍受。您可以通过使用新的数据库重放工具捕获最终用户放入系统中的确切活动，而后在测试系统上进行重放，以精确地衡量更改影响来降低多数风险，而这些都只需几下鼠标点击和键盘敲击即可实现。请记住，您还可以测试应用程序的功能，并不仅仅限于性能。
Printer View