转载

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这个文件是基础的配置，里面核心的配置就是这些了。

修改数据的归档压缩属性，可以使用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;
还有以下几点需要注意：