ITPub博客

首页 > 数据库 > Oracle > Oracle Data Guard压缩归档效果对比(r12笔记第26天)

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

原创 Oracle 作者:jeanron100 时间:2017-04-06 23:41:39 0 删除 编辑

   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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14229625