Data Guard Performance Tuning Tips Oracle Database Tips by Donald BurlesonDecember 9, 2015

Oracle Data Guard- Performance Tuning of Data Guard Configuration

Introduction

Standby databases and a Data Guard environment can be very useful for the disaster recovery policy of any enterprise. On the other hand, if the Data Guard environment is not set up correctly, it can significantly impact the performance of the primary database.

The first six chapters of this book concentrated on creating and managing standby databases in a Data Guard environment. This chapter will provide guidelines on the performance tuning of Data Guard components such as Log Transport and Log Apply services.  The overall goal is to minimize the impact on database services provided by the primary database.

Understanding Tuning Requirements

Before undertaking performance tuning, it is important to understand the objective of performance tuning. In absence of any clearly defined goals, it will be difficult to evaluate the success of any tuning efforts. The end goal should be quantitative and not qualitative.

In other words, it is not the best practice to start the performance-tuning task with the thought; "I have to make it faster". The DBA that thinks that way will soon get lost in the process and will never be able to measure the success of the tuning exercise. The other issue will be determining when to stop tuning.

Performance Tuning of Data Guard Configuration

Understanding Tuning Requirements

For the tuning of the Data Guard environment, the DBA can setup a clearly defined quantitative objective. The bottom line is, "data in all the standby databases in the Data Guard environment should be identical to the primary database". How will this be quantified? A Data Guard configuration involves log transfer and log apply services on individual sites to manage the standby database. Log transfer and log apply services on all the sites should be performing well enough that a redo log file should be archived and applied to the Oracle instance in near real-time.

For example, assume that the primary database is an insert/update intensive database. This high rate of redo generation is resulting in an archive redo log file every five minutes during the peak activity period. In this case, the log management service should transfer and apply the redo logs onto standby databases within five minutes. Failing to do so will result in a backlog of archived redo log files on standby sites that will slow down the role transfer process.

Moreover, if a logical Oracle instance is being used to serve reporting requirements, any extra delay in log management will impact the service. For this example, the goal should be to tune the entire Data Guard environment such that it will be able to finish the end-to-end log management process within five minutes.

The DBA needs to understand the redo generation rate of the primary database before the tuning objective can be quantified. Oracle alert log file and dynamic performance views can assist in the calculation of the redo generation rate in the environment. Later in this chapter, the techniques on calculating the peak redo generation rate will be presented.

Tuning Data Guard Log Transfer