Oracle的测试评估工具RAT

梁铭图 2019-08-08 20:52:00

作者介绍

梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有Oracle OCM、Togaf企业架构师（鉴定级）、IBM CATE等认证，曾获dbaplus年度MVP以及华为云MVP等荣誉，并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

一、RAT介绍

Oracle Real Application Testing（简称RAT）是11g引入的一个重要的feature，其推出的初衷是为了满足数据中心变更后有很好的方法和工具去衡量这些变更对于生产环境的应用带来的影响，更好的评估诸如硬件升级，软件升级，架构变化等等对于客户应用程序的影响。

Real Application Testing其实有两个解决方法，分别是Database Replay和SPA（SQL Performance Analyzer）。本次主要介绍RAT的使用以及我在使用过程中遇到的问题。

Database Replay，数据库回放顾名思义可以理解为一个录像机，通过在源系统上把实时应用产生的负载录制下来，并拿到变更后的环境进行播放，从而进行一个对比。数据库回放分为四个阶段完成：录制、预处理、回放、结果分析和报告。

二、使用背景

在上个月，客服有一套数据库从11.1.0.7迁移至12.1.0.2，系统运行两天后新数据库运行异常，工程需要回退。

在之前的迁移测试以及应用测试中，都是一些简单的测试，没有试过模拟现网的压力，导致应用连接到新库之后出现了各种未知问题而不能及时处理。同时应用侧不具备模拟现网的测试条件，于是需要使用RAT中的Database Replay，模拟现网的运行。

三、RAT使用

源库版本：11.1.0.7.16，需要one-off-patch补丁：17373277。

目标库版本：12.1.0.2.171017，需要one-off-patch补丁：21117072。

1、录制

1）首先创建一个操作系统目录，用于存放录制的文件（本次使用非共享目录）

mkdir -p /datadump/rat_20180418

ln -s /datadump/rat_20180418 /home/oracle/rat_20180418

2）在数据库内创建一个DIRECTORY

SQL>create directory DBRAT_0418 as '/home/oracle/rat_20180418';

假如是RAC数据库的话，优先使用共享目录，假如没有共享目录的话，可以在其它目录创建存放录制文件的目录，然后通过创建目录及名称一致的软链接指向实际存放的目录。

3）设置捕捉的过滤条件（可不设置）

有时候我们需要限定只捕捉部分的工作负载，可以通过这个设置来达成：

例如只捕捉SCOTT用户的负载：

exec dbms_workload_capture.ADD_FILTER(fname =>'FILTER_SYS',fattribute => 'USER',fvalue => 'SCOTT');

4）开启捕捉

BEGIN

DBMS_WORKLOAD_CAPTURE.start_capture (name => 'DBREPLAY_0418',

dir => 'DBRAT_0418',

duration => 2700);

END;

name是本次捕捉任务的名称；dir是上面创建的directory；duration是捕捉时间，上面设置了2700，也就是捕捉45分钟，该参数可以设置为NULL，就是无时间限制地录制，直到发起停止命令。

BEGIN

DBMS_WORKLOAD_CAPTURE.finish_capture;

END;

5）查看捕捉状态

可用以下命令查看是否录制完成：

select id,name,status,start_time,end_time,connects,user_calls,dir_path from dba_workload_captures;

如有需要可以删掉多余的录制记录：

exec dbms_workload_capture.delete_capture_info(3);

2、预处理

1）创建一个目录的对象指向目标环境的录制后的文件（RAC使用共享目录）

create directory DBRAT_0418 as '/ACFS01/rat_20180418';

2）预处理

exec dbms_workload_replay.process_capture('DBRAT_0418');

遇到过的问题：在最开始的测试中，我们一直卡在这一步，语句一直不完成，一开始以为这个预处理需要很多的时间，于是一直等，几个小时甚至一天都不能完成，从来没有成功过，而且后台日志有如下错误。

后来提交MOS，官方建议在源库以及目标库都打上相应的补丁来修复bug。

目标库：one-off-patch补丁：21117072，打完这个补丁之后，预处理的命令不再是一直等待卡着不动，如果文件有错误则直接退出。

源库：one-off-patch补丁：17373277，修复了上图中出现文件错误的bug。

做完预处理之后，后面的步骤基本没什么难度了，下面就是做重放准备了。

3）初始化播放

exec dbms_workload_replay.initialize_replay('DBREPLAY_0418','DBRAT_0418');

第一个参数是捕捉任务的名称，第二个参数是文件存放的DIRECTORY。

4）连接配置映射

由于播放环境和捕捉环境数据库配置不同，需要进行一个映射的过程。

未映射：

select conn_id,capture_conn from dba_workload_connection_map order by 1;

映射命令：

exec DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (connection_id =>1,replay_connection =>'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.252.223.81)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=GZLZSK)))');

connection_id就是上面语句查询出来的conn_id，有多少就需要改多少，replay_connection这里只需要修改IP、端口和SERVICE_NAME即可。

映射后：

5）Prepare the Replay

exec dbms_workload_replay.prepare_replay(synchronization=>FALSE);

这里是默认的参数，如果需要加大重放的压力，可以适当配置connect_time_scale和think_time_scale这两个参数，这两个参数默认的值是100（百分比），也就是1：1重放，如果把connect_time_scale设置成50%，也就是两个连接的间隔时间缩短到原来的50%（10分钟的话就缩短到5分钟），从而加大数据库的压力。

exec dbms_workload_replay.prepare_replay(synchronization=>FALSE,connect_time_scale=>50,think_time_scale=>50);