Remote File Server (RFS) Process:
The RFS process runs on the standby database and is responsible for communication between the primary and the standby database. For the log transport service, the RFS on the standby database receives the redo records from the archiver or the log writer process of the primary database over Oracle Net and writes to the filesystem on the standby site.
Fetch Archive Log (FAL):
The FAL process has two components: FAL Client and FAL Server. Both processes are used for archive gap resolution. If the Managed Recovery Process (MRP) on the standby database site detects an archive gap sequence, it initiates a fetch request to the FAL client on the standby site. This action, in turn, requests the FAL server process on the primary database to re-transmit the archived log files to resolve the gap sequence. Archive gap sequences will be discussed later in this chapter.
Once the log transport service completes the transmission of redo records to the standby site, the log apply service starts applying the changes to the standby database. The log apply service operates solely on the standby database. The following processes on the standby site facilitate the log apply operations.
Managed Recovery Process (MRP):
The MRP applies the redo entries from the archived redo logs onto the physical standby database.
Logical Standby Process (LSP):
The LSP applies the redo records from archived redo logs to the logical standby database. The Oracle database log miner engine is used by the logical standby process for the SQL apply operations. Using the log miner engine, the LSP process recreates the SQL statements from redo logs that have been executed on the primary database. These statements are then applied to the standby database to keep it current with the primary database.
Data Guard background processes:
In a Data Guard configuration, we can see some Oracle Data Guard specific background processes in both, primary and standby databases. These processes perform the operations of redo transport and apply services. Data Guard broker also has some specific background processes. We can see the description and duties of the most important Data Guard processes as follows:
MRP0 (Managed Standby Recovery Process):
coordinates the read and apply process of redo in a physical standby database.
RFS (Remote File Server):
Is responsible for receiving the redo data, which is sent by the primary database to the standby database.
LSP0 (Logical Standby Coordinator Process):
Coordinates the SQL Apply processes, which are the mining processes and apply processes.
LSP1 (Logical Standby Dictionary Build Process):
Is used on the logical standby databases when a switchover or failover is in action.
LSP2 (Logical Standby Set Guard Process):
Is used to operate Database Guard settings. Database Guard specifies which objects will be protected for modification in a logical standby database.
NSAn (Redo Transport NSA1 Process):
Is used on the primary database to ship redo data to the standby database when ASYNC mode is being used. There may be multiple NSA processes such as NSA1 and NSA2.
NSSn (Redo Transport NSA1 Process):
Is also used on the primary database to ship redo data to the standby database. However, only when the SYNC mode is being used.
DMON (Data Guard Broker Monitor Process):
runs on every instance in a Data Guard broker configuration. It communicates with local database and DMON processes of the remote databases. The broker-related requests and the monitoring information are transferred on this communication channel.
FSFP (Data Guard broker fast-start failover pinger process):
Is used for the management of fast-start failover status.
The RFS process runs on the standby database and is responsible for communication between the primary and the standby database. For the log transport service, the RFS on the standby database receives the redo records from the archiver or the log writer process of the primary database over Oracle Net and writes to the filesystem on the standby site.
Fetch Archive Log (FAL):
The FAL process has two components: FAL Client and FAL Server. Both processes are used for archive gap resolution. If the Managed Recovery Process (MRP) on the standby database site detects an archive gap sequence, it initiates a fetch request to the FAL client on the standby site. This action, in turn, requests the FAL server process on the primary database to re-transmit the archived log files to resolve the gap sequence. Archive gap sequences will be discussed later in this chapter.
Once the log transport service completes the transmission of redo records to the standby site, the log apply service starts applying the changes to the standby database. The log apply service operates solely on the standby database. The following processes on the standby site facilitate the log apply operations.
Managed Recovery Process (MRP):
The MRP applies the redo entries from the archived redo logs onto the physical standby database.
Logical Standby Process (LSP):
The LSP applies the redo records from archived redo logs to the logical standby database. The Oracle database log miner engine is used by the logical standby process for the SQL apply operations. Using the log miner engine, the LSP process recreates the SQL statements from redo logs that have been executed on the primary database. These statements are then applied to the standby database to keep it current with the primary database.
Data Guard background processes:
In a Data Guard configuration, we can see some Oracle Data Guard specific background processes in both, primary and standby databases. These processes perform the operations of redo transport and apply services. Data Guard broker also has some specific background processes. We can see the description and duties of the most important Data Guard processes as follows:
MRP0 (Managed Standby Recovery Process):
coordinates the read and apply process of redo in a physical standby database.
RFS (Remote File Server):
Is responsible for receiving the redo data, which is sent by the primary database to the standby database.
LSP0 (Logical Standby Coordinator Process):
Coordinates the SQL Apply processes, which are the mining processes and apply processes.
LSP1 (Logical Standby Dictionary Build Process):
Is used on the logical standby databases when a switchover or failover is in action.
LSP2 (Logical Standby Set Guard Process):
Is used to operate Database Guard settings. Database Guard specifies which objects will be protected for modification in a logical standby database.
NSAn (Redo Transport NSA1 Process):
Is used on the primary database to ship redo data to the standby database when ASYNC mode is being used. There may be multiple NSA processes such as NSA1 and NSA2.
NSSn (Redo Transport NSA1 Process):
Is also used on the primary database to ship redo data to the standby database. However, only when the SYNC mode is being used.
DMON (Data Guard Broker Monitor Process):
runs on every instance in a Data Guard broker configuration. It communicates with local database and DMON processes of the remote databases. The broker-related requests and the monitoring information are transferred on this communication channel.
FSFP (Data Guard broker fast-start failover pinger process):
Is used for the management of fast-start failover status.
No comments:
Post a Comment
Ask your Questions....