Oracle Data Guard Architecture

Oracle Data Guard ensures high availability, data protection, and disaster recovery by maintaining standby databases as replicas of the primary database. To manage this, several background processes work behind the scenes to handle the real-time synchronization between primary and standby databases. Let’s explore the core components:

• LNS (Log writer Network Server) Process: – The LNS process captures redo data generated by the primary database. The LNS process sends redo data packets to the RFS process on the standby

Note :- When transactions are generating redo data at a very high rate, the LNS process may struggle to capture all the redo information directly from the redo log buffer; in such cases, the LNS process can read redo data directly from the online redo log files

• RFS (Remote File Server): – The RFS process is responsible for receiving redo data packets sent by the LNS (Log writer Network Server). Once it receives the redo data, it temporarily stores it in the standby database’s redo logs. This ensures that the standby database can stay up to date with any changes made on the primary.

• MRP (Managed Recovery Process): – MRP works closely with the RFS process, which is responsible for receiving redo data from the LNS process on the primary database. Once the RFS stores the redo data, it signals MRP to apply that data.

• LSP (Logical Standby Process): – The LSP works closely with the RFS (Remote File Server) process, which receives redo data from the primary database. After RFS stores the redo data in the standby’s redo logs, the LSP processes this data. The LSP reads the redo records and converts them into SQL statements that can be executed on the logical standby database.

• FAL (Fetch Archive Log): – FAL (Fetch Archive Log) is a mechanism used to manage the retrieval of archived redo logs between the primary database and standby databases.

FAL process is divided into two components: FAL Client and FAL Server

When the standby database detects that it is missing some archived redo logs, the FAL Client sends a request to the FAL Server on the primary.

The FAL Server processes the request and sends the necessary archived logs back to the FAL Client, which then stores them and applies them to the standby database. This interaction is vital for maintaining the integrity and consistency of data between the primary and standby databases.