Oracle Data Guard压缩归档效果对比(r12笔记第26天)

   Oracle Data Guard对归档的传输提供了很多辅助的选项，这个可 以通过log_archive_dest_x看到。

   一般说这类的优化，如果有大批量的归档需要传输，对于网络带宽还真是一个不小的冲击，有一种改进方法，就是打包压缩归档，然后传输到备库，然后解压应用，整个过程有几个地方需要注意，整个过程肯定会有延迟，而且还不小，在压缩和解压的过程对系统资源会有一个持续的耗用。而好处也相对明显很多，就是对于带宽的占用会有一定的压缩。所以一句话总结，如果压缩备份，对系统会有额外的资源消耗，节约流量，会有一定的延迟。

    在这个地方上，其实很多Oracle DBA都知道这么个过程，而且设置起来就是一个参数属性的修改，没什么难的，而对于这个属性的设置带来的优劣和比重却很少有人去探究，我们来做一个简单的测试。

    首先要保证持续的插入数据，测试分为两组，一组是压缩归档，一组是不压缩归档，插入的数据量一致，在这个过程中监控CPU,IO,网络带宽的使用情况。

    按照这种需求我们就可以很自然的使用swingbench和zabbix来做。通过swingbench来初始化数据，通过zabbix监控资源使用情况。

   为了尽可能造成一种瓶颈的情况，我保留了redo的默认值50M.让它尽可能频繁的切换。

   初步的测试50G的数据，大概要切换1700多次，因为还包括索引的开销。

   使用swingbench初始化我采用命令行方式初始化

# ./oewizard  -s -c oewizard.xml -allindexes  -ts users -tc 16 -v -cl -scale 20 -create

oewizard.xml这个文件是基础的配置，里面核心的配置就是这些了。

<DefaultParameters>
      <Parameter Key="datatablespacesexists" Value="true"/>
      <Parameter Key="password" Value="soe"/>
      <Parameter Key="username" Value="soe"/>
      <Parameter Key="datafile" Value=""/>
      <Parameter Key="userexists" Value="true"/>
      <Parameter Key="connectionstring" Value="10.127.2.32:1521:dataguru"/>
      <Parameter Key="connectiontype" Value="thin"/>
      <Parameter Key="onlydropuser" Value="false"/>
      <Parameter Key="operation" Value="create"/>
      <Parameter Key="tablespace" Value="USERS"/>
      <Parameter Key="dbausername" Value="sysbench_dba"/>
      <Parameter Key="dbapassword" Value="oracle"/>
      <Parameter Key="output" Value="Verbose"/>
   </DefaultParameters>

修改数据的归档压缩属性，可以使用DG Broker来完成，轻轻松松。

假设DG Broker的配置如下：

DGMGRL> show configuration;
Configuration - dg_dataguru
  Protection Mode: MaxPerformance
  Databases:
    sdataguru - Primary database
    dataguru  - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS修改归档压缩参数的设置，可以采用如下的方式:

edit database sdataguru set property RedoCompression='ENABLE';
edit database dataguru set property RedoCompression='ENABLE';这个过程，会自动生成SQL语句，比如：

ALTER SYSTEM SET log_archive_dest_2='service="dataguru"','LGWR ASYNC NOAFFIRM delay=0 optional compression=enable max_failure=0 max_connections=1 reopen=300 db_unique_name="dataguru" net_timeout=30','valid_for=(all_logfiles,primary_role)' SCOPE=BOTH;
还有以下几点需要注意：

1. 创建足够空间的数据文件

2. 闪回区设置的满足数据量需求

测试的结果如何呢，我们来看几个图。

主库的CPU情况如下，可以看到红色的部分差别很小。整体来看压缩归档对于主库的CPU负载压力还是很低的，至少比预期低很多。

而备库的CPU使用情况如下，可以看到第二第三个红框中的CPU差异也很小，而左边的这个是什么呢，是之前压力测试的时候，备库集中式的应用归档的CPU利用情况。

下面的图是备库集中传输归档，开启压碎归档，为开启压缩归档的差别图。可以看到如果备库集中传输归档，流量就会非常大，接近1G的样子，而如果使用swingbench加压的过程中，产生的归档大概不到100M，而不开启压缩归档后的流量大概是原来的1倍，大概是150~180M左右

而备库端的情况，和主库几乎是一致的，看起来抖动和主库都是吻合的，所以结论和上面的一样。开启压缩归档网卡流量大大降低。

整个测试的情况就是这样，我们后续会持续收集数据，做一些更有针对性的对比测试。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2136783/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-2136783/