Data Guard Architecture

Description:
In this blog, we are going to see oracle Data Guard architecture and a clear description of the data guard overall process.

What is Oracle Data Guard:

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.
Data Guard maintains these standby databases as transactionally consistent copies of the production database.
If the production database becomes unavailable, Data Guard can switch any standby database to the production role.

Data Guard configuration pre-system checks:
Hardware :
       Hardware can be different for the standby and primary databases. Like CPU, hard disk capacity.
Operating system :
The operating system should be the same as both the primary and standby databases, if you use Linux on the primary side the same os will be the standby. OS versions can be different but the platform should be the same.
Software :
The same release of oracle database version in primary and standby side.
         Standby database enables archive and force logging method.
          Sysdba privilege required.

ORACLE DATA GUARD ARCHITECTURE:
Primary Database Process:

LGWR(log writer)
            Log writer collects transaction log information and updates to the online redo logs.
      LGWR modes:
            SYNC– in synchronous mode, it sends redo information directly to the RFS(remote file server) process on the standby database its waits for the confirmation before proceeding.
            ASYNC – in asynchronous mode its also sends redo information directly it does not wait before proceeding.
            In ASYNC mode LGWR submits the network I/O request to the network server (LNSn) process for the destination.

Archiver process(ARCn):
            ARCn or a SQL session performing an archival operation, create a copy of online redo logs locally for primary database recovery.
            ARCn also send simultaneously online logs to the RFS(remote file server)
            It’s also responsible for GAP solving in the standby database.

FAL (Fetch Archive Logs):
FAL provides a client/server mechanism for resolving gaps detected in the range of archive logs generated in the primary database and received to the standby database.

Standby Database Process:

RFS (remote file server process):
RFS it receives redo information from the primary database. RFS writes redo to standby redo logs or archived logs
Each primary LSN, ARCn has their own RFS

ARC archiver process;
ARCn process archives all standby redo logs.

Managed Recovery Process(MRP):
            For the physical standby database, only MRP applies archived log information to the physical standby database.
            MRP process commands:
                        Alter database recover managed standby database disconnect no delay.
                        Alter database recover managed standby database disconnect from the session.
                        Alter database recover managed standby database cancel.

Logical standby database:
LSP is controlling the applies of archived redo log information to the logical standby database.

Standby redo log files:
Standby redo log files are used only when the database is in the standby role to store redo data received from the primary database.
Standby redo logs from a separate pool of log filegroup.

********************************************************************************

Thank you for giving your valuable time to read the above information.

If you want to be updated with all our articles send us the Invitation or Follow us:

Ramkumar’s LinkedIn: https://www.linkedin.com/in/ramkumardba/
LinkedIn Group: https://www.linkedin.com/in/ramkumar-m-0061a0204/
Facebook Page: https://www.facebook.com/Oracleagent-344577549964301
Ramkumar’s Twitter: https://twitter.com/ramkuma02877110
Ramkumar’s Telegram: https://t.me/oracleageant
Ramkumar’s Facebook: https://www.facebook.com/ramkumarram8

Data Guard Architecture

Data Guard Architecture

Share this:

Like this: