Redo Transport Compression in a Data Guard Environment (文檔 ID 729551.1)

Redo Transport Compression in a Data Guard Environment (文檔 ID 729551.1)

轉(zhuǎn)到底部

In this Document

Oracle Database - Enterprise Edition - Version 11.1.0.6 to 11.2.0.3 [Release 11.1 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 16-Jul-2014*** 

Oracle Database 11g has the ability to compress redo as it is transmitted over a network by Data Guard Redo Transport Services.

In certain environments, redo compression can:

·         Improve data protection by reducing redo transport lag

·         Reduce network utilization

·         Provide faster redo gap resolution

·         Reduce redo transfer time

Redo transport compression is a feature of the Oracle Advanced Compression option. You must purchase a license for this option before using the redo transport compression feature.  Compression of redo transport for versions prior to Oracle Database 11g Release 1 can be accomplished using third party WAN accelerators, such as those available from Cisco, Riverbed, F5, and other vendors.

Compression is most beneficial in achieving recovery point objectives (RPO) when used over low bandwidth networks. As a general statement, as network bandwidth increases, the RPO benefit is reduced. Compressing redo in a Data Guard environment is particularly beneficial if:

• The database redo rate is higher than the available network bandwidth.
• Sufficient CPU resources are available for the compression processing.

CPU consumption will increase in higher network bandwidth environments since potentially a larger percentage of time is spent compressing redo compared to transmitting redo. For example, gap resolution testing showed that with OC1 (51.8 Mbits/sec) and T3 (44.7 Mbits/sec) networks, 50% of one CPU was consumed per ARCH process during the compression operation, while with a 100Mbits network an entire CPU was consumed per ARCH process.

If reducing RPO in the case of disaster is a priority then compression is not recommended for network bandwidths above100 Mbits/sec, since the process of compression can actually increase overall redo transfer time. If reduced network utilization is a priority over RPO, evaluate compression even with high network bandwidths. Oracle recommends testing to determine the degree of benefit that will be realized.

From Oracle Database 11g Release 2 onward, setting the COMPRESSION attribute of the redo transport destination will compress redo transmitted by all Data Guard transport methods (SYNC, ASYNC, ARCH), including redo transmitted to resolve archive log gaps, and all Data Guard protection modes (Maximum Protection, Maximum Availability, and Maximum Performance).

In Oracle Database 11g Release 1, setting the COMPRESSION attribute of the redo transport destination will only compress redo transmitted to resolve an archive log gap. Oracle also supports compression of ASYNC and ARCH redo transport (Maximum Performance) by using a hidden parameter in conjunction with enabling the COMPRESSION attribute as documented below.

Enabling Data Guard Redo Transport Compression

To enable compression, set the COMPRESSION attribute of the redo transport destination to ENABLE. For example:

LOG_ARCHIVE_DEST_2='SERVICE=boston COMPRESSION=ENABLE DB_UNIQUE_NAME=boston'

If using Data Guard Broker, specify the following syntax:

DGMGRL> EDIT DATABASE 'boston' SET PROPERTY 'RedoCompression' = ENABLE;

Test Results and Other Guidance

Oracle MAA testing showed that with a redo compression ratio of 35% or more, redo transmission time was reduced by 15-35%.

                                               Network Throughput

Oracle MAA testing showed the following benefits when testing with a low bandwidth network (less than 100Mbits/sec) and high redo generation rate (> 20 MB/sec) where the redo compression ratio was 60%:

• Redo transport lag consistently remained less than 10 seconds even though the database redo rate far exceeded the network throughput. In previous test runs where compression was not enabled, redo transmission could not keep pace with redo generation, and redo transport lag continued to increase linearly over time for the duration of the test making it impossible to achieve recovery point objectives.
• Minimum impact on production workload when sufficient CPU and IO resources are available.

In addition, Oracle MAA testing showed:

• Gap resolution time was reduced by 35-60%
• Network latency did not impact network throughput
• Using the MAX_CONNECTIONS attribute to transmit redo in multiple network sessions showed no benefit.

Enabling Data Guard Redo Transport Compression for ASYNC when using Oracle Database 11g Release 1

To enable compression when using ASYNC or ARCH redo transport mode and Oracle Database 11g Release 1, set the COMPRESSION attribute of the redo transport destination to ENABLE, and set the initialization parameter _REDO_TRANSPORT_COMPRESS_ALL to TRUE (this initialization parameter is not needed from Oracle Database 11g Release 2 onward). For example:

LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC COMPRESSION=ENABLE DB_UNIQUE_NAME=boston'

_REDO_TRANSPORT_COMPRESS_ALL=TRUE

If using Data Guard Broker, then you must set the _REDO_TRANSPORT_COMPRESS_ALL=TRUE parameter in the database parameter file as stated above.  To enable the COMPRESSION attribute on the LOG_ARCHIVE_DEST parameter you must edit the database property within DGMGRL as specified below:

DGMGRL> EDIT DATABASE 'boston' SET PROPERTY 'RedoCompression' = ENABLE;

How to estimate the compression ratio that can be achieved:

Data Guard redo transport compression uses the same zlib compression engine at level 1 as gzip -1. To estimate the compression ratio you can achieve using Data Guard redo transport compression, first compress an archived redo log file with gzip:

$ gzip -1 .arc

Then use the gzip --list option to explicitly display the compression ratio:

$ gzip --list .gz

Note: Use gzip version 1.3.3 or later. Refer to www.gzip.org for the latest information on gzip.

For more details please check also