C
Log Writer Asynchronous Network I/O

This appendix describes the Data Guard algorithms for asynchronous network I/O when you use the log writer process (LGWR) to transmit primary database online redo log modifications to standby databases. This information is provided to help database administrators and support analysts know how asynchronous I/O is achieved, and how to diagnose and interpret asynchronous I/O-related network issues.

Figure C-1 shows the various processes involved in the asynchronous network I/O operation.

Figure C-1 Asynchronous Network I/O Processes

Text description of the illustration rapid_prot.gif

Data Guard achieves asynchronous network I/O using transparent network server processes. These network server processes are deployed by the LGWR process when the ASYNC attribute is specified for the LOG_ARCHIVE_DEST_n initialization parameter.

Note: LGWR network server processes are different from LGWR I/O slave processes. However, both types of background processes are compatible with each other.

The network server processes are transparent because the remote file server (RFS) processes on the standby database do not know that network server processes are initiating the network I/O operations on the primary database. The network server processes mimic the same network I/O operations that occur when the LGWR process is set up for synchronous I/O operations. The network server process name is ora_lnsnn_SID where nn is the arbitrary server number. For example, ora_lns5_prmy is background network server process number 5 for the database whose SID is prmy.

There is one network server process for each LGWR network connection to an asynchronous standby database. A network server process is created when the network connection to the standby database is established. A network server process remains active as long as the network connection to the standby database remains active. The abnormal termination of a network server process does not lead to instance shutdown. For example, if the system monitor (SMON) background process is unable to function, the Oracle instance ceases operation and fails. However, if one of the network server processes is terminated, the process monitor (PMON) background process wakes up and cleans up the resources that were being occupied by that network server process, and the Oracle instance continues to function. The PMON activity in cleaning up the resources is recorded in the corresponding alert log and trace files.

However, if a network server process terminates abnormally, the LGWR process discards the network connection for the remainder of the processing of the current online redo log. The network connection is reestablished, if possible, on the next log switch operation. Each network server process manages an internal network buffer, whose size is specified by the ASYNC attribute of the LOG_ARCHIVE_DEST_n initialization parameter. The network buffer resides in the private memory of the network server process. See Chapter 12 for information on the LOG_ARCHIVE_DEST_n initialization parameter.

The LGWR process sends the online redo modifications to the network server and the network server caches the online redo log modifications in the network buffer, if possible. If the online redo log modifications can be cached, the LGWR process continues operating as if the network I/O operation was successfully performed, when, in fact, it was not.

Because the network buffer resides on the primary database, the contents of this cache are susceptible to loss due to primary database system failure. To minimize this risk, the network server processes attempt to transmit the data to the standby database as long as the network does not become saturated.

Several events can also cause the network buffer to be transmitted to the standby database by the network server. These events are:

• If the LGWR request size exceeds the currently available buffer space, the existing network buffer is transmitted to the standby database. The LGWR process stalls until sufficient buffer space can be reclaimed, but this seldom occurs.
• A primary database online log switch forces the network buffer to be transmitted to the standby database.
• The primary database is shut down normally.

  Note: An immediate shutdown of the primary database results in the network buffer contents being discarded because the network server process is shut down. A standby database shutdown also causes the network buffer contents to be discarded.

• The primary database has no online redo log activity for a period of time. The duration of database inactivity cannot be controlled by the user.
• If the rate of redo generation exceeds the runtime network latency, the LGWR request is buffered if sufficient space is available. Otherwise, the existing buffer is transmitted to the standby database. The LGWR process stalls until sufficient buffer space can be reclaimed, but this seldom occurs.

The network server process always performs synchronous network I/O; however, the LGWR process interprets this as asynchronous network I/O, because it is not blocked by the actual network I/O operation.