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:
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.
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.)
Because ARCn archiver processing is the default archival behavior, specifying the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter is optional.
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.
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).
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.
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:
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:
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.
the primary role LOG_ARCHIVE_DEST_n
parameters that configure the LGWR process for asynchronous network
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.
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/，如需转载，请注明出处，否则将追究法律责任。