|Oracle9i Data Guard Concepts and Administration
Release 1 (9.0.1)
Part Number A88808-01
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.
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
n initialization parameters.
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
nn is the arbitrary server number. For example,
ora_lns5_prmy is background network server process number 5 for the database whose SID is
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
n initialization parameter. The network buffer resides in the private memory of the network server process. See Chapter 8 for information on the
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:
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.