在数据库的迁移和升级场景中,我们经常会遇到一个问题:在做压力测试时,如何模拟真实的业务压力,解决这个问题的方法有很多,比如:应用方开发模拟程序或者使用压力测试工具模拟,如load runner,但是,如果要说哪种方法能最大限度地模拟真实业务压力,我认为还是Oracle的Database Replay(数据库重放)功能,Database Replay功能是Real Application Testing的一部分,它的基本原理图如下:
简单说,Database Replay可以在生产数据库上“捕获”负载(workload capture),保存成一定格式的二进制文件。将保存的负载文件复制到测试环境,经过一定的处理后,就可以在测试环境“重放”负载(workload replay),从而达到模拟真实压力,进行压力测试的目的。
Database Replay是11g才有的特性,但是,负载的捕获,支持10.2.0.4之后的数据库,这一点也正好符合国内很多客户的需求,因为国内还有相当一部分客户,因为稳妥起见,系统还都一直运行在10gR2版本的Oracle数据库上,都有升级的需求。
Consolidated Database Replay 是11.2.0.2之后才出现的功能,字面意思是整合的数据库重放,它可以将不同系统“捕获”的负载,整合到一起重放,适用于数据库整合测试和Scale-Up测试。
后面我们用实验来详细介绍一下Database Replay的相关功能,实验采用10.2.0.5作为负载的捕获端,用12.1.0.2作为负载的重放端。
首先要根据文档 Mandatory Patches for Database Testing Functionality for Current and Earlier Releases (Doc ID 560977.1),检查该打的补丁是否打过了。捕获端和重放端都要打。
捕获端是一个安装在OL5.9上的10.2.0.5,数据库SID是test1.
在OS创建目录并创建相应的数据库目录对象,用于保存负载数据:
$ cd /u01/app/oracle
$ mkdir wrc_dir1
SQL>CREATE OR REPLACE DIRECTORY wrc_dir1 AS '/u01/app/oracle/wrc_dir1/';
虽然Database Replay支持10.2.0.4以上的版本进行负载“捕获”,但是10gR2的数据库要想正常使用这个功能,需要对数据库设置一个初始化参数,联机文档上讲需要运行脚本$ORACLE_HOME/rdbms/admin/wrrenbl.sql,其实这个脚本只做一件事,就是设置初始化参数PRE_11G_ENABLE_CAPTURE=true。
[oracle@test10g ~]$ sqlplus "/ as sysdba"
SQL*Plus: Release 10.2.0.5.0 - Production on Fri Dec 23 10:57:26 2016
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> @?/rdbms/admin/wrrenbl.sql
SQL> SET FEEDBACK 1
SQL> SET NUMWIDTH 10
SQL> SET LINESIZE 80
SQL> SET TRIMSPOOL ON
SQL> SET TAB OFF
SQL> SET PAGESIZE 100
SQL> alter system set PRE_11G_ENABLE_CAPTURE=true sid='*';
System altered.
修改后需要重启数据库,不仅仅为了让参数生效,也是为了让所有会话都重新连接。
创建数据库用户app1,并在app1 schema中创建表test_table1:
SQL>create table test_table1 (col1 number, col2 varchar2(20));
使用sys用户执行:
BEGIN
DBMS_WORKLOAD_CAPTURE.start_capture (name => 'test1_cap',
dir => 'WRC_DIR1',
duration => NULL);
END;
/
使用app1 用户登录数据库,执行:
begin
for i in 1..10000 loop
insert into test_table1 values(i,'test1:'||i);
end loop;
commit;
end;
/
在test_table1表中插入10000条记录。
然后断开会话。
SQL>exec dbms_workload_capture.finish_capture;
重放端是一个安装在OL7.1上的12.1.0.2数据库,数据库SID是test3。
创建目录及数据库对象:
$ mkdir –p /u01/app/oracle/con_dir/wrc_dir1
SQL>CREATE OR REPLACE DIRECTORY wrc_dir1 AS '/u01/app/oracle/con_dir/wrc_dir1/';
复制捕获的负载文件到/u01/app/oracle/con_dir/wrc_dir1下。
在重放端创建app1用户,并创建和捕获端相同结构的表test_table1。
用SYS用户执行:
BEGIN
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE (capture_dir => 'WRC_DIR1', parallel_level=>1);
END;
/
BEGIN
DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => 'replay1',
replay_dir => 'WRC_DIR1');
END;
/
exec dbms_workload_replay.prepare_replay ;
WRC客户端是负责读取负载文件,重放负载的程序主体。重放除了在SQL环境中发出指令,还需要WRC客户端的配合。启动WRC客户端的命令:
$ wrc system/welcome1 mode=replay replaydir=./wrc_dir1
SQL> exec dbms_workload_replay.start_replay;
WRC客户端退出才标志重放完成,下面是实际执行的输出:
[oracle@ol71vm1 con_dir]$ wrc system/welcome1 mode=replay replaydir=./wrc_dir1
Workload Replay Client: Release 12.1.0.2.0 - Production on Sun Jan 1 20:46:15 2017
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
Wait for the replay to start (20:46:15)
Replay client 1 started (20:46:45)
Replay client 1 finished (20:50:27)
这时我们能够看到重放端app1用户test_table1表中被插入了10000条记录,说明负载被正确地重放了。
另外,完成后可以查看重放报告,取得报告的命令:
SQL>set pagesize 0 long 30000000 longchunksize 2000 linesize 155
SQL>select DBMS_WORKLOAD_REPLAY.REPORT(replay_id => 71, format => 'HTML') from dual;
当然,要想做更详细的分析,还是看相应时间段的AWR报告比较好。
比如有两个APP,分别运行在不同的数据库上,客户希望将两个应用整合到一个数据库上,但是不知道新数据库是否能承受住压力。那么就可以用Consolidated Database Replay来模拟测试一下。
前面的例子我们做的捕获是从数据库test1上做的,我们再创建另一个10.2.0.5的数据库叫test2,在test2上也捕获一份负载。
$ cd /u01/app/oracle
$ mkdir wrc_dir2
在test2数据库中执行:
SQL>CREATE OR REPLACE DIRECTORY wrc_dir2 AS '/u01/app/oracle/wrc_dir2/';
创建数据库用户app2,并在app2 schema中创建表test_table2:
SQL>create table test_table2 (col1 number, col2 varchar2(20));
修改初始化参数,重启test2数据库。
用户SYS用户执行:
BEGIN
DBMS_WORKLOAD_CAPTURE.start_capture (name => 'test2_cap',
dir => 'WRC_DIR2',
duration => NULL);
END;
/
用app2用户登录数据库test2,执行下面的脚本模拟压力:
begin
for i in 1..10000 loop
insert into test_table2 values(i,'test2:'||i);
end loop;
commit;
end;
/
然后断开连接。
SQL>exec dbms_workload_capture.finish_capture;
我们还是使用前面实验用过的OL7.1上的12.1.0.2的这个环境,使用test3这个数据库。
创建Consolidated database replay目录:
SQL>CREATE OR REPLACE DIRECTORY con_dir AS '/u01/app/oracle/con_dir/';
创建存放test2负载的目录wrc_dir2。(wrc_dir1在前面的实验里已经创建过了。)
$ cd /u01/app/oracle/con_dir
$ mkdir wrc_dir2
SQL>CREATE OR REPLACE DIRECTORY wrc_dir2 AS '/u01/app/oracle/con_dir/wrc_dir2/';
WRC_DIR1和WRC_DIR2都是CON_DIR的子目录。
在数据库test3上创建app2用户,并创建和捕获端相同结构的表test_table2。
(app1用户和test_table1已经在上个实验中创建在数据库test3上了)
使用SYS用户执行:
SQL>exec dbms_workload_replay.set_replay_directory('CON_DIR');
SQL>exec dbms_workload_replay.begin_replay_schedule('S1'); -- S1是给时间表起的名字
SQL>select dbms_workload_replay.add_capture('WRC_DIR1') from dual;
SQL>select dbms_workload_replay.add_capture('WRC_DIR2') from dual;
SQL>exec dbms_workload_replay.end_replay_schedule; -- 保存重放时间表
SQL>exec dbms_workload_replay.initialize_consolidated_replay('CR1','S1');
SQL>exec dbms_workload_replay.prepare_consolidated_replay (synchronization => 'OBJECT_ID');
-- 参数synchronization决定replay重放负载的方式,OBJECT_ID代表replay重放负载时,对象上的操作顺序,在对象及被引用的对象范围内,保证和捕获时的顺序一致。
因为是2个不同的负载,所以需要启动至少2个WRC客户端
$ wrc system/welcome1 mode=replay replaydir=/u01/app/oracle/con_dir &
$ wrc system/welcome1 mode=replay replaydir=/u01/app/oracle/con_dir &
用SYS用户执行:
SQL>exec dbms_workload_replay.start_consolidated_replay;
完成重放后,我们可以看到,在数据库test3中app1和app2两个用户下的test_table1和test_table2表中都被插入了10000条记录,证明负载被正确地重放了。
有的时候,我们想知道未来业务量增长了,数据库是否能承受的了,比如模拟测试未来业务增加一倍的情况,也可以使用Consolidated Database Replay。这样使用的最简单方式就是一份捕获,复制多份,同时replay。
比如上面的实验,从test1库上捕获的负载,我们可以复制2份,分别放在WRC_DIR1和WRC_DIR2中,其他步骤完全一样,当我们重放时,就是执行了双份的test1上捕获的负载。
实际效果就是,app1用户下的test_table1表中被插入了20000条记录。
当然,Scale-Up并不只是这么简单,相应的还有Time Shifting,就是通过调整时间,让多个负载的高峰重合到一起,还有Workload Folding,就是将一个负载,分成不同的时间段,然后将不同时间段的负载并行执行。篇幅有限,留待大家自己研究了。
如果出现没有任何报错,但是重放端不重放负载的情况,可能是WRC客户端有问题,可以尝试在重放端,重新编译WRC客户端:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk iwrc