Redo Transport Services之When and How to send redo data

                Oracle DataGuard Instructor 

                                   之 Redo Transport Services（上）  王清清

How to Send Redo Data 

On the primary database, Oracle Data Guard uses archiver processes (ARCn) or the log writer process (LGWR) to collect transaction redo data and transmit it to standby destinations. Although you cannot use both the archiver and log writer processes to send redo data to the same destination, you can choose to use the log writer process for some destinations, while archiver processes send redo data to other destinations.This section contains the following topics:

•         Using Archiver Processes (ARCn) to Archive Redo Data
•         Using the Log Writer Process (LGWR) to Archive Redo Data
•         Providing for Secure Redo Data Transmission
• 
  

Data Guard also uses the fetch archive log (FAL) client and server to send archived redo log files to standby destinations following a network outage, for automatic gap resolution, and resynchronization. The FAL process and gap resolution are discussed in Section 5.8.

1  Using Archiver Processes (ARCn) to Archive Redo Data

By default, redo transport services use ARCn processes to archive the online redo log files on the primary database. ARCn archival processing supports only the maximum performance level of data protection in Data Guard configurations. You must use the LGWR process to transmit redo data to standby locations that operate in other data protection modes. (See Section 5.6 for more information about the Data Guard data protection modes.)

• Initialization Parameters That Control ARCn Archival Behavior
• ARCn Archival Processing

1.1   Initialization Parameters That Control ARCn Archival Behavior

LOG_ARCHIVE_DEST_n:

Because ARCn archiver processing is the default archival behavior, specifying the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter is optional.

LOG_ARCHIVE_MAX_PROCESSES:

you need to have at least 2 ARCn processes to separate local archival from remote archival. the LOG_ARCHIVE_MAX_PROCESSES default value is 2.

1.2   When standby archiving happen?

Figure 5-3 shows an example of archival processing in a Data Guard configuration, with a primary database located in Chicago and one physical standby database located in Boston.

Archiving happens when a log switch occurs on the primary database:

On the primary database, after the ARC0 process successfully archives the local online redo log to the local destination (LOG_ARCHIVE_DEST_1), the ARC1 process transmits redo from the local archived redo log files (instead of the online redo log files) to the remote standby destination (LOG_ARCHIVE_DEST_2).

1.3   How to transmit archived data to standby AND how to receive archived data from primary database?

On the remote destination, the remote file server process (RFS) will, in turn, write the redo data to an archived redo log file from a standby redo log file. Log apply services use Redo Apply (MRP processFoot 1 ) or SQL Apply (LSP processFoot 2 ) to apply the redo to the standby database.

Because the online redo log files are archived locally first, the LGWR process reuses the online redo log files much earlier than would be possible if the ARCnprocesses archived to the standby database concurrently with the local destination.

 

2  Using the Log Writer Process (LGWR) to Archive Redo Data

You can optionally enable redo transport services to use the LGWR process to transmit redo data to remote destinations.

Using the LGWR process differs from ARCn processing (described in Section 5.3.1), because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once, the LGWR process selects a standby redo log file at the standby site that reflects the log sequence number (and size) of the current online redo log file of the primary database. Then, as redo is generated at the primary database, it is also transmitted to the remote destination. The transmission to the remote destination will either be synchronous or asynchronous, based on whether the SYNC or the ASYNC attribute is set on the LOG_ARCHIVE_DEST_n parameter. Synchronous LGWR processing is required for the maximum protection and maximum availability modes of data protection in Data Guard configurations. (See Section 5.6 for information about the Data Guard data protection modes.)This section contains the following topics:

•         LOG_ARCHIVE_DEST_n Attributes for LGWR Archival Processing
•         LGWR SYNC Archival Processing
•         LGWR ASYNC Archival Processing

2.1  LGWR SYNC Archival Processing

点击(此处)折叠或打开

1. LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
   
2. LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
   
3. LOG_ARCHIVE_DEST_STATE_1=ENABLE
   
4. LOG_ARCHIVE_DEST_STATE_2=ENABLE

Specifying the SYNC attribute on the LOG_ARCHIVE_DEST_n parameter is optional, because this is the default for LGWR archival processing. The NET_TIMEOUT attribute is recommended, because it controls the amount of time that the LGWR process waits for status from the network server process before terminating the network connection. If there is no reply within NET_TIMEOUT seconds, then the LGWR process returns an error message.

 

Figure 5-4 shows a Data Guard configuration that uses the LGWR process to synchronously transmit redo data to the standby system at the same time it is writing redo data to the online redo log file on the primary database:

•         On the primary database, the LGWR process submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in parallel to multiple remote destinations. Transactions are not committed on the primary database until the redo data necessary to recover the transaction is received by all LGWR SYNC destinations.
•         On the standby system, the remote file server (RFS) receives redo data over the network from the LGWR process and writes the redo data to the standby redo log files.

2.1.1 When standby archiving happen?

A log switch on the primary database triggers a log switch on the standby database, causing ARCn processes on the standby database to archive the standby redo log files to archived redo log files on the standby database. Then, Redo Apply (MRP process) or SQL Apply (LSP process) applies the redo data to the standby database. If real-time apply is enabled, Data Guard recovers redo data directly from the current standby redo log file as it is being filled up by the RFS process.

2.2  LGWR ASYNC Archival Processing

the primary role LOG_ARCHIVE_DEST_n parameters that configure the LGWR process for asynchronous network transmission.

点击(此处)折叠或打开

1. LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
   
2. LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
   
3. LOG_ARCHIVE_DEST_STATE_1=ENABLE
   
4. LOG_ARCHIVE_DEST_STATE_2=ENABLE

Figure 5-5 shows the LNSn process collecting redo data from the online redo log files and transmitting it over Oracle Net to the RFS process on the standby database.

 

When the LGWR and ASYNC attributes are specified, the log writer process writes to the local online redo log file, while the network server (LNSn) processes (one for each destination) asynchronously transmit the redo to remote destinations. The LGWR process continues processing the next request without waiting for the LNS network I/O to complete.

 

_______________________________________________________________________________________________________________________________________

Note:

Beginning with Oracle Database 10g Release 10.2, it is unnecessary to specify the NET_TIMEOUT attribute on the LOG_ARCHIVE_DEST_n destinations configured with both the LGWR and ASYNC attributes. This is because the log writer process never waits for the LNSn for any reason in release 10.2. Thus, specifying the NET_TIMEOUT attribute is not required.

________________________________________________________________________________________________________________________________________

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29249734/viewspace-1814844/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29249734/viewspace-1814844/