Log Transport Services

---

At the heart of Data Guard lies log transport services. The very basis of Data Guard is the fact that we are able to effectively ship changes generated on the primary database to a secondary site. Once those changes exist on the secondary site, we are protected from the dreaded disaster. But log transport services does more than simply ship redo from one site to another site. It also gives us the ability to determine the level of data protection for our database. Log transport services configuration can be performed in such a manner as to balance data protection and availability against any performance impact. In this section we will examine how to configure log transport services, as well as discuss items that should be considered when designing your disaster recovery solution.

Defining Log Transport Services Destinations

We define where and how log transport services will transmit redo using the LOG_ARCHIVE_DEST_n initialization parameter. Using this parameter, we can define up to 10 destinations, each of which can send redo to distinct destinations. We use the LOCATION and SERVICE attributes to determine if the redo is to be sent locally on disk or remotely to an off-site location. To send redo data to a remote standby, we must set the SERVICE attribute to an Oracle Net service name that points to the listener running on the remote host.

The example given below will ship redo to the Oracle Net service name using the default for all nonspecified attributes:

alter system set LOG_ARCHIVE_DEST_2='SERVICE=Nashville_hasun1' scope=both;

Once the parameter is set, Data Guard will send a copy of the archivelog to the Net service name at every log switch. To stop the shipment of archivelogs to the remote site, we simply defer the remote destination as in the following:

alter system set LOG_ARCHIVE_DEST_STATE_2=defer scope=both;

While the parameter in even its simplest form is very effective, we have many more attributes that allow us to control how and when data is sent. As covering all attributes in not practical for this chapter, we will describe some of the more frequently used below.

ARC Attribute (Default)

If neither the ARC nor LGWR attributes are specified, or if the ARC attribute is specified, archiving to the local or remote destination will be performed by the ARC process at the log switch boundary. The ARC process can be configured to perform the archiving in two different methods:

1. By default, an ARC process will first archive the online redo log to the local destination. After the ARC process writes the archive to the local destination, a second ARC process will spawn and begin transmitting data from the local archived redo log to the remote destination. Since the online redo logs are archived locally first, there is no chance that remote archiving across a slow network can impact the availability of the primary database, making this the optimal choice if you have a slow network between your primary and standby sites.

2. If the LOG_ARCHIVE_LOCAL_FIRST parameter is set to False, the ARC process follows the same method that was the default in previous versions. When a log switch occurs, the ARC process builds a list of archive destinations that need to be serviced. Once this list is complete, the ARC process will read a 1MB chunk of data from the online log that is to be archived. This 1MB chunk is then sent to the first destination in the list. When the write has completed, the same 1MB chunk is written to the second destination. This continues until all of the data from the online log being archived has been written to all destinations. So, it can be said that archiving is only as fast as the slowest destination. This method is optimal if you have a fast, reliable network between your primary and standby sites.

LGWR Attribute

In contrast to using the ARC attribute, which only transmits redo data to the standby site at log switch time, the LGWR attribute instructs the LGWR process to transmit redo data to the remote destinations at the same time the redo is writing to the online redo logs. The LGWR can transmit redo data to the remote destinations in either synchronous or asynchronous mode, depending on how the attribute is defined in the LOG_ARCHIVE_DEST_n parameter.

By default, the LGWR process will archive remotely in synchronous mode. If you wish to specify this at the parameter level, you would structure the LOG_ARCHIVE_DEST_n as such:

alter system set LOG_ARCHIVE_DEST_2='SERVICE=Nashville_hasun1 LGWR SYNC' scope=both;

The SYNC attribute with the LGWR process specifies that network I/O is to be performed synchronously for the destination, which means that once the I/O is initiated, the archiving process waits for the I/O to complete before continuing. If you specify the SYNC attribute, all network I/O operations are performed synchronously, in conjunction with each write operation to the online redo log. The transaction is not committed on the primary database until the redo data necessary to recover that transaction is received by the destination.

To have the LGWR process archive remotely in the asynchronous mode, you define your LOG_ARCHIVE_DEST_n as such:

alter system set LOG_ARCHIVE_DEST_2='SERVICE=Nashville_hasun1 LGWR ASYNC=20480' scope=both; 

When using LGWR to remotely archive in ASYNC mode, the LGWR process does not wait for each network I/O to complete before proceeding. This behavior is made possible by the use of an intermediate process, known as an LGWR network server process (LNS), which performs the actual network I/O and waits for each network I/O to complete. Each LNS has a user-configurable buffer that is used to accept outbound redo data from the LGWR process. This is configured by specifying the size in 512-byte blocks on the ASYNC attribute in the archivelog destination parameter. For example, ASYNC=20480 indicates a 10MB buffer. The maximum size of the buffer in Oracle Database 10g is 50MB.

AFFIRM Attribute

The AFFIRM attribute ensures that all disk I/O at the standby site is performed synchronously and completed successfully prior to returning control back to the user on the primary.

NET_TIMEOUT Attribute

The NET_TIMEOUT attribute is used only when the LGWR process transmits redo data using a LGWR Network Server (LNS) process. During normal Data Guard operations, the LNS process establishes a network connection to the standby. The primary and standby then use this network connection to send data back and forth. If for some reason the network between the two hosts is lost, or if either side is unable to contact the other host,  the network connection will go through normal TCP processing before determining that the connection no longer exists. In some cases, these TCP retries can take up to two hours. During the time that TCP is attempting to determine if the connection is still valid, the LNS process will be halted. This could affect processing on the primary database. Oracle developed the NET_TIMEOUT attribute so that the user could specify how many seconds the LNS process on the primary is to wait before giving up on a network connection.

REOPEN Attribute

If an archive destination receives an error, the destination will close and will not be retried until the period of time (in seconds) specified by the REOPEN attribute. Once REOPEN has expired, the destination is once again valid and will be attempted at the next log switch.

MAX_FAILURE Attribute

The MAX_FAILURE attribute defines the number of times we will retry a destination that has been closed due to a failure.

VALID_FOR Attribute

Both the primary and standby initialization parameters should be configured to support either the primary or standby role so that role reversals via switchover are seamless. In order to prevent the DBA from having to enable or defer archive destination, depending on when that destination should be utilized, Oracle developed the VALID_FOR attribute. The VALID_FOR attribute is used to specify exactly when an archive destination is to be used and what types of redo logs are to be archived.

The VALID_FOR attribute is comprised of two keywords, archival_source and database_role. The archival_source keywords are as follows:

• ONLINE_LOGFILE  Archive online redo logs only for this destination.

• STANDBY_LOGFILE  Archive standby redo logs only for this destination.

• ALL_LOGFILES  Archive both online and standby redo logs for this destination.

The database_role keywords are as follows:

• PRIMARY_ROLE  Archive to this destination only when in the primary role.

• STANDBY_ROLE  Archive to this destination only when in the standby role.

• ALL_ROLES  Archive to this destination when in either primary or standby role.

Let's consider two examples to see further how the VALID_FOR attribute works. In the previous section, when creating our physical standby, we set the following parameters:

Orlando Database:

LOG_ARCHIVE_DEST_1=  'LOCATION=/database/10gDR/Orlando/arch/   VALID_FOR=(ALL_LOGFILES,ALL_ROLES)   DB_UNIQUE_NAME=Orlando' LOG_ARCHIVE_DEST_2=  'SERVICE=Orlando_hasun1    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)    DB_UNIQUE_NAME=Nashville'

Nashville Database:

LOG_ARCHIVE_DEST_1=  'LOCATION=/database/10gDR/Orlando/arch/   VALID_FOR=(ALL_LOGFILES,ALL_ROLES)   DB_UNIQUE_NAME=Nashville' LOG_ARCHIVE_DEST_2=  'SERVICE=Orlando_hasun1   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)   DB_UNIQUE_NAME=Orlando' 

In the above example, when the Orlando database is in the primary role, we will archive only the online redo logs to destination 1, as the standby redo logs are not active in the primary role. We will also archive the online redo logs to destination 2 while we are in the primary role. In the Nashville database, we will archive the standby redo logs to destination 1, as the online redo logs are not active in the standby role. We will not archive to destination number 2, as the Nashville database is not in the primary role. When a role reversal occurs, no change to the parameters is necessary to achieve the desired effect. The VALID_FOR attribute makes enabling or deferring destinations during role reversals unnecessary.

Log Transport Services and Security

In today's IT environment, security and availability cannot be separated. To ensure availability, we must be able to guarantee that the data is from an authorized agent and that the data is intact and unmodified. In Oracle Database 10g, Data Guard provides a disaster recovery solution that includes authentication and can provide encryption and data integrity checks by integrating Oracle Advanced Security Option.

By default Data Guard provides for authenticated network sessions between the primary and the standby when transferring redo. We do this by comparing the sys password from the password file to both sides to verify that they are the same. Since this authentication is now required, this means that your primary database and all standby databases within a Data Guard configuration must use a password file-and the password stored in the password file for the sys user must be the same for both the primary and standby databases.

---