昨天对Data Guard的归档压缩进行了一个初步的测试，我今天又做了一些补充。
1.昨天测试的是默认50M的redo，如果redo增大，在IO bound的场景中，是否有很大的变化
2.对于归档压缩来说，数据量如果增大，是否会有较大的抖动，昨天测试的是20G的数据量，初始化了50%
3.对于整个数据初始化的过程中，主备的延迟到底有多大，是否有延迟回落的现象。
我们一个一个来做解答。
首先是redo的大小调整，我们需要设置redo大小为200M,备库的standby logfile也是200M。
然后是生成的数据量，我们这次测试时间长一些，测试的过程尽量完整一些，数据量也大一些，所以调整为50G.
最后的主备的延迟，这个我们先不去查看数据字典里的数据，我们手工DIY一下，如果在
高性能MySQL 这本书中，测试主从延迟，是有一种实现方式，采用federated存储引擎，达到Oracle中类似db
link的数据访问。而在Oracle中，实现起来就很简单了。
我们创建一个DB link，然后在主库中创建一个表
create table sysbench_dba.sync_delay(insert_time timestamp);
然后在备库中反问主库的这个表，对比备库的时间戳即可，假设我们指定的DBA账户是sysbench_dba
sqlplus -s / as sysdba <<EOF
set time on
set head off
set feedback off
col pri_timestamp format a35
col std_timestamp format a35
col diff_timestamp format a35
set linesize 150
delete from sync_delay@sync_link;
insert into sysbench_dba.sync_delay@sync_link select systimestamp from dual;
commit;
with pri_timestamp as (select insert_time from sysbench_dba.sync_delay@sync_link)
select
(select insert_time from pri_timestamp)pri_timestamp,systimestamp
std_timestamp,(select insert_time from pri_timestamp)-systimestamp
diff_timestamp from dual;
EOF
运行这个脚本之后，会得到如下的结果。三列分别是主库时间，备库时间，最后是时间差，即延迟。
07-APR-17 10.37.43.330302 AM 07-APR-17 10.37.48.557999 AM +08:00 -000000000 00:00:05.227697这个算出来的会有一些因素的干扰，但是本身也能够说明一些情况。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
接下来我们初始化数据，这次创建50G的数据，预期的数据量大概是100G左右。
# ./oewizard -s -c oewizard.xml -allindexes -ts users -tc 16 -v -cl -scale 50 -create开启归档压缩设置。
edit database sdataguru set property RedoCompression='ENABLE';
edit database dataguru set property RedoCompression='ENABLE';
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
IO wait的对比，左边是压缩归档，右边是不压缩。数据量相同。可以看到几乎没有差别。
网络带宽，这个指标蛮有意思，我来详细解读一下。
左边是压缩归档，右边是为压缩。为什么左边的部分中间有些中断呢，是因为swingbench初始化数据的过程中，前期是插入数据，然后补充约束关系，创建索引。整体来看压缩归档的均值在50M左右,峰值150M，而未压缩归档的均值要高一些，近100M
,峰值300M左右。
而这个数据和之前的redo 50M的对比是怎么样呢，就是下面的4个方框。第一个代表是50M redo开启压缩，第二个代表50M redo不压缩， 第三个代表 200M redo压缩， 第四个代表 200M redo未压缩。
通过这个数据能够看出一个大题的体量。