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

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

转到底部

In this Document

APPLIES
TO:

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*** 

PURPOSE

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.

SCOPE

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.

DETAILS

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