Data Guard Log Management Tips Oracle Database Tips by Donald BurlesonDecember 9, 2015

Oracle Data GuardChapter 10 - Oracle 10g:  New Features of Data Guard

Introduction

With the introduction of the grid computing model, Oracle10g brings a whole new concept in database architecture and management. In addition to the dynamic resource allocation feature built into the database server, Oracle10g promises various improvements in other areas such as high availability.

In this chapter, information will be presented on the enhancements specific to the Data Guard technology. Most of the improvements are in the creation and management of logical standby databases. From information in previous chapters, it was not difficult to conclude that the limitations of the logical standby database did not make it a very useful option in Oracle9i. Oracle Corporation has worked to lift some of these restrictions in Oracle10g to make it more attractive to the administrators and system architects.

Moreover, the Data Guard architecture has been fine tuned to support the standby redo logs in all protection modes in order to strike a balance between data loss and performance in the Data Guard environment.

Before delving into the details of Data Guard feature improvements in Oracle10g, a quick overview of upgrades to Oracle10g Data Guard from a previous version will be presented.

Oracle10g Data Guard Enhancements

Oracle Data Guard is one of the popular options available to DBAs for setting up disaster recovery of a database or an alternate database for secondary uses. With the dual option of physical standby and logical standby databases, administrators have more choices in setting up near-real time synchronized secondary databases.

Oracle10g goes further in enhancing the Data Guard database environment. In this section the new features that expand data guard capabilities and improve ease of use will be presented.

SGA Buffer Size for an Asynchronous Redo Transfer

In order to transmit redo data asynchronously, buffer blocks within SGA should be allocated to keep the redo data in memory during the transmission to remote archival destinations. In Oracle10g, the upper limit of network buffer blocks has been raised to 102,400 blocks of 512-bytes. This alleviates the performance issue in asynchronous redo transmission on very high transaction intensive databases. The following snippet from the init.ora parameter file shows an asynchronous transfer using the largest network buffer size:

LOG_ARCHIVE_DEST_3='SERVICE=stdby2 LGWR ASYNC=102400'

Data Guard Performance Improvement

Standby databases in a Data Guard environment can be configured to operate in MAXIMUM PERFORMANCE mode. This setup is common in systems where performance is of the utmost importance, and a small amount of data loss is acceptable in case of disaster and complete loss of the primary database. In such an environment, the primary database uses the ARCn process as the archiving agent.

In Oracle9i Data Guard, the archiver process, ARCn, is triggered on a log switch.  It simultaneously initiates the archiving to local and remote archival destinations. The redo log group on the primary database will not be marked for reuse until archiving to all destinations is complete. As a consequence, a Data Guard configuration containing a Oracle instance connected over a wide area network may suffer a significant impact on performance, and negate the meaning of term MAXIMUM PERFORMANCE.

Data Guard Performance Improvement

Oracle10g addresses this issue by splitting local archiving from remote archiving when configured in MAXIMUM PERFORMANCE mode. The default behavior is to archive the online redo log file to local destinations and then start archiving to remote destinations. Archival to a remote destination will not begin until the online redo log file is written completely to at least one local destination.

At this point, the redo log group is marked for reuse with the result of minimizing impact on the primary database performance. The benefit of this feature is obvious in transaction intensive databases, in which a few hundred megabytes of redo is generated every minute.

This new behavior of log transport service is controlled by the log_archive_local_first parameter. It is a boolean parameter and can be set to TRUE or FALSE. The default value is TRUE. Setting it to FALSE will emulate the Oracle9i archiving behavior.