Exception
when others then
dbms_output.put_line(substr(SQLERRM, 1, 1000)); End P_GG_PERFORDATA;
（4）数据统计脚本
每秒统计142、146上端口性能表中已提交的数据量和差值。 CREATE OR REPLACE PROCEDURE P_GG_TESTLOG( /*
* COMPARE THE ROWS COUNTS BETWEEN 146 AND 142 FOR TESTING GOLDENGATE SYNC; * IT SHOULD BE CALLED BEFORE WHEN THE P_GG_PERFORDATA WILL BE CALLED * AUTHOR ZHOUJIONG 2011-04-07 */
p_marks in varchar2 default null --for marking which tests the records belong to ) AS
v_timestamp timestamp; v_rows_146 number:=0; v_rows_142 number:=0; begin
for i in 1..1200 loop
v_timestamp:=systimestamp;
select (select count(*) from per_test) num1,
(select count(*) from per_test@DB142.REGRESS.RDBMS.DEV.US.ORACLE.COM) num2
into v_rows_146,v_rows_142 from dual;
insert into GG_PERFORMANCE_TESTLOG(RECORD_DATE,COUNTS_142,COUNTS_146,DIFFERENCE,MARKS) values (v_timestamp, v_rows_142, v_rows_146,
v_rows_146-v_rows_142, p_marks); commit;
dbms_lock.sleep(1); end loop;
Exception
when others then
dbms_output.put_line(substr(SQLERRM, 1, 1000)); end P_GG_TESTLOG;
36
6.2.2 GoldenGate配置
为统计生成的trail文件量，首先将两端的mgr.rpm中的PURGEOLDEXTRACTS C参数注释掉，并重启mgr进程。
（1）146上extract进程配置 ext3.prm /***
extract ext3 SETENV (ORACLE_SID = ORCL)
userid COSS360,password COSS360 exttrail C:\\ggoracle\\dirdat\\e3
dynamicresolution gettruncates
TABLE COSS360.per_test, keycols (sampletime, objectid); ***/
pump3.prm /***
extract pump3
userid COSS360,password COSS360 rmthost 192.168.0.142, mgrport 7801 rmttrail D:\\ggoracle\\dirdat\\trail146\\e3 NOPASSTHRU gettruncates
table COSS360.res_p_s_*; ***/
（2）142上应用进程配置 rep146e3.prm /***
REPLICAT rep146e3
USERID coss3,PASSWORD coss3
--SOURCEDEFS d:\\ggoracle\\dirdef\\ext146\\ext3.ref assumetargetdefs
REPERROR default,discard
DISCARDFILE d:\\ggoracle\\log\\rep148e3.dsc,append,megabytes 200 gettruncates
37
HANDLECOLLISIONS
BATCHSQL BATCHESPERQUEUE 200, OPSPERBATCH 2000 MAP coss360.per_test, TARGET coss3.per_test, keycols (sampletime, objectid); ***/
6.3 测试步骤
（1）清空两端测试表
SQL> truncate table per_test;
（2）清空归档和日志
sqlplus sys/broada_plat@orcl142 as sysdba SQL> alter system switch logfile;
SQL> host RMAN target sys/broada_plat@orcl142 RMAN> delete noprompt archivelog all; RMAN> exit
SQL> conn sys/broada_plat@orcl146 as sysdba SQL> alter system switch logfile;
SQL> host RMAN target sys/broada_plat@orcl146 RMAN> delete archivelog all;
这里需要注意的是，extract进程应该在归档清空后开始抓取，即建立extract进程应该在这个时间点之后begin。主要了防止日志大小统计的不准确。
（3）开启两端GoldenGate进程，记录初始trail file大小 146：2K 142：2K
（4）执行测试脚本
分别在两个命令行窗口中执行2个脚本，其中p_gg_testlog提前于P_GG_PERFORDATA执行，以记录完整的测试信息：
SQL> exec p_gg_testlog(p_marks => 'one')
SQL> exec P_GG_PERFORDATA(p_looptime => 10000000); --实际执行时间约1882秒
（5）测试数据生成结束、会话未关闭时（即10分钟停顿时间内）数据监控 查看相应SESSION
146 user commit: 10000000次 142 user commit: 10082次
备注：在应用端配置了每1000条事务进行一次批量提交
38
会话REDO生成情况统计：
select s.sid, n.name, round(s.value / 1024 / 1024) \ from v$sesstat s, v$statname n where s.statistic# = n.STATISTIC# and n.name like '%redo size%' order by 3 desc; 统计结果：
142上会话redo量（SID 288） ------------------------------------- 1 288 redo size 1679M
146上会话redo量（SID 211） ------------------------------------- 1 211 redo size 10037M
金山卫士流量监控中记录142总下载流量为3.1G。
GoldenGate应用端控制台中，查看lag信息，基本在3秒以内。
（6）统计表大小
SQL> analyze table per_test compute statistics; --190s左右
SQL> select s.segment_name,(s.bytes/1024)||'K' bytes from s.segment_name=UPPER('per_test');
146上
---------------------------------------------------------------- 1 PER_TEST 770048K
142上
---------------------------------------------------------------- 1 PER_TEST 770048K
两端的rows均为1000万行，传输中无数据丢失。
（7）检查trail文件大小 测试后trail文件大小：（e3*） 146：3,326,940,923 142：3,326,956,814
（8）检查生成的归档文件大小
sqlplus sys/broada_plat@orcl142 as sysdba SQL> alter system switch logfile;
sqlplus sys/broada_plat@orcl146 as sysdba SQL> alter system switch logfile;
39
user_segments s where 146：12,413,898,752 142：1,826,665,472
备注：146上的归档还包含一部分因日志表数据插入造成的归档数据。但在前面redo统计中则不包含，因为2个脚本分别运行，在不同的会话下。
（9）查看146上日志表
通过以下语句查看这次测试的日志表数据：
select * from gg_performance_testlog t where regexp_like(marks,'one') order by 1
日志表记录了同步过程中，两端同步表已提交数据的数量和差值，每秒记录一次。可以通过日志表的数据，计算出每秒事务量，并估算出同步效率。如果差值大，表明网络延迟较大；如果差值不断增大，表明应用端同步效率较低，无法满足源端的事务量。
另一文档《性能测试日志表数据》中记录了这次测试的日志表数据。
6.4 性能测试结果
6.4.1 测试数据计算
测试日志表中，记录了测试数据生成时间是从9:58:34到10:31:06，约32分32秒，生成1000万条测试记录，每生成一条记录提交一次，所以： 每秒事务量=10,000,000/1952=5123 次/秒
根据测试日志表记录，统计差值情况：
select avg(difference) avg,max(difference) max from gg_performance_testlog t where regexp_like(marks,'one') and difference>0; avg max
------------------------------------------ 17895.8988970588 51260
即同步时两端记录平均差值约17896行，最大差值为51260行。差值并不随着时间增大，表明应用进程的应用效率能满足抓取的每秒事务量。
146端在10:31:06完成所有事务，相应的，142端10:31:11完成所有应用，最终同步lag约5秒。 生成的trail文件大小3,326,956,814字节，约3172.8M或3.1G，与前面记录的网络传输流量3.1G基本一致，所以： 每秒网络传输流量=3172.8/1952=1.6M/s 源端1000万条记录，相应生成的redo为10037M，约9.80G；应用端同步生成的redo
40