第三阶段：重放负载

　　现在我的RAC数据库已经准备好可以接受执行重放先前捕获的负载了，如前面的文章谈到的那样，使用Oracle 11g EM进行重放时必须按照严格的顺序执行，调用存储过程DBMS_WORKLOAD_REPLAY执行重放时这些步骤也必须按步骤执行，重新映射所有的连接，调整所有自定义重放频率设置，收集重放性能，回归统计报表收集。

　　启动数据库负载重放：为了启动数据库重放，我将使用存储过程DBMS_WORKLOAD_REPLAY.INITIATE_REPLAY，它将吧RACDB数据库置为INIT FOR REPLAY状态，是通过存储过程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY将数据库置为PREPARE状态的必要前提条件。

　　重新映射连接字符串：为了保证将所有参与在DB10G数据库上生成负载的会话重新映射到RACDB上对应的TESTLBA负载均衡连接上，我将使用存储过程DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION。

　　参考Listing 3.7（见附件）中关于如何调用这两个存储过程以及如何查看重新映射连接的结果的例子。

　　自定义负载重放选项：正如我在数据库重放入门那篇文章中谈到的那样，Oracle 11g允许DBA自己精细控制重放的频率，负载重放客户端可以提供存储过程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY设置多个额外的参数被牢牢控制：　

表3.1重放客户端选项
重放选项	描述
SYNchrONIZATION	定义生产负载时是否使用SYNchrONIZATION：
	l   TRUE：这是默认值，在重放过程中捕获的负载中将被保留的COMMIT的顺序，所有重放动作只有当所有依赖的COMMIT动作执行完毕后才能执行。
	l   FALSE：原始的COMMIT顺序不会得到遵从，这样很可能会返回大量的数据分歧，但它在载入或压力测试时非常有用。
THINK_TIME_SCALE	定义同一会话两个连续用户调用之间说花费的时间，因此由它驱动重放的速度：
	l   默认值是100，或原始负载产生速度的100%。
	l   如果设置为0，连续发送到重放数据库的速度会是尽可能地快。
	l   如果设置的值大于100%，那速度就响应减低了。
THINK_TIME_AUTO_CORRECT	基于指定的百分比纠正用户调用之间的THINK_TIME_SCALE，将这个参数设置为TRUE，重放客户端将被强制缩短调用之间的“思考时间”，以便让重放说花费的时间与最初收集的时间相匹配。

　　注意数据库重放负载捕获时间与负载重放时间之间的区别：

　　捕获负载过程中，所花费的时间是通过用户时间（中的用户调用时间）和用户思考时间（在发出另一个调用是用户等待的时间）组成的。

　　然而，在负载重放过程中，所花费的时间是由用户时间，用户思考时间和同步时间组成的。

　　正如在前面的文章中提到的，我只需要接收默认的选项，通过调用Listing 3.8存储过程DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY。
启动负载重放客户端：现在可以启动负载重放客户端（WRC）重放前面捕获的负载了，我将通过打开一个终端会话启动重放会话，在我集群数据库中的节点RACNODE2上调用WRC客户端：

$>  wrc replaydir=/home/oracle/DBRControl Workload Replay Client: Release 11.1.0.6.0 – Production on Mon Jun 23 21:27:47 2008 Wait for the replay to start (21:27:48)

 
　　当WRC在RACNODE2节点上启动后，我需要告诉Oracle 11g它可以控制所有活动的数据库重放操作了，如Listing 3.9显示的，我通过调用存储过程DBMS_WORKLOAD_REPLAY.START_REPLAY来完成这件事，这个存储过程执行成功的状态会在WRC终端会话输出中反应出来：　

Wait for the replay to start (21:27:48) 　　Replay started (21:28:16)

 
　　监视活动的重放操作：Listing 3.10显示了一个简单的对视图DBA_WORKLOAD_REPLAY的查询，它产生一个简单的关于当前DBR负载重放状态的报告，Report 3.2显示了不不同重放阶段执行这个查询的结果（它也反应在WRC的终端输出中了）：

　　

Wait for the replay to start (21:27:48) Replay started (21:28:16) Replay finished (21:48:40)

　　实例的警告日志中：
　　

>>> From RACDB1’s alert log:…Tue Jun 24 21:28:01 2008DBMS_WORKLOAD_REPLAY.START_REPLAY(): Starting databasereplay at 06/24/2008 21:28Tue Jun 24 21:31:04 2008Thread 1 advanced to log sequence 92Current log# 2 seq# 92 mem# 0: +DATA/racdb/onlinelog/group_2.262.649041349Current log# 2 seq# 92 mem# 1: +FRA/racdb/onlinelog/group_2.259.649041351Tue Jun 24 21:48:39 2008DBMS_WORKLOAD_REPLAY: Database replay ran to completion at 06/24/2008 21:48:40 …>>> From RACDB2’s alert log: … Tue Jun 24 21:28:01 2008 DBMS_WORKLOAD_REPLAY.START_REPLAY(): Starting database replay at 06/24/2008 21:28 Tue Jun 24 21:48:39 2008 DBMS_WORKLOAD_REPLAY: Database replay ran to completion at 06/24/2008 21:48:40