What Is Data Guard?

Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as copies of the production database. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

Draw Architecture of Data guard?

Image result for data guard architecture

Explain Physical standby dataguard Architecture?

A physical standby database is a byte for byte exact copy of the primary database. This also means that rowids stay the same in a physical standby database environment.
On the primary database site, the log writer process (LGWR) collects transactions from the log buffer and writes to the online redo logs.  The archiver process (ARCH) creates a copy of the online redo logs, and writes to the local archive destination.  Depending on the configuration, the archiver process or log writer process can also transmit redo logs to standby database.  When using the log writer process, you can specify synchronous or asynchronous network transmission of redo logs to remote destinations.  Data Guard achieves asynchronous network I/O using LGWR network server process (LNS).  These network severs processes are deployed by LOG_ARCHIVE_DEST_n initialization parameter. Data Guard’s asynchronous log transport (i.e. the Maximum Performance mode) is recommended for a configuration in which the network distance is up to thousands of miles, providing continual maximum performance, while minimizing the risks of transaction loss in the event of a disaster.
On the standby database site, the remote file server process (RFS) receives archived redo logs from the primary database.  The primary site launches the RFS process during the first log transfer.  The redo logs information received by the RFS process can be stored as either standby redo logs or archived redo logs.  Data Guard introduces the concept of standby redo logs (separate pool of log file groups).  Standby redo logs must be archived by the ARCH process to the standby archived destination before the managed recovery process (MRP) applies redo log information to the standby database.
The fetch archive log (FAL) client is the MRP process.  The fetch archive log (FAL) server is a foreground process that runs on the primary database and services the fetch archive log requests coming from the FAL client.  A separate FAL server is created for each incoming FAL client.
FAL_SERVER specifies the FAL (fetch archive log) server for a standby database. The value is an Oracle Net service name, which is assumed to be configured properly on the standby database system to point to the desired FAL server.
FAL_CLIENT specifies the FAL (fetch archive log) client name that is used by the FAL service, configured through the FAL_SERVER parameter, to refer to the FAL client. The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client (standby database).
Thanks to the FAL_CLIENT and FAL_SERVER parameters, the managed-recovery process in the physical database will automatically check and resolve gaps at the time redo is applied. This helps in the sense that you don’t need to perform the transfer of those gaps by yourself.
FAL_CLIENT and FAL_SERVER only need to be defined in the initialization parameter file for the standby database(s). It is possible; however, to define these two parameters in the initialization parameter for the primary database server to ease the amount of work that would need to be performed if the primary database were required to transition its role.
Prior to Oracle 11g, Redo Apply only worked with the standby database in the  MOUNT state, preventing queries against the physical standby whilst media recovery was in progress. This has changed in Oracle 11g.
When using Data Guard Broker (DG_BROKER_START = TRUE), the monitor agent process named Data Guard Broker Monitor (DMON) is running on every site (primary and standby) and maintain a two-way communication.

EXPLAIN LOGICAL STANDBY dataguard Architecture?

The major difference between the logical and physical standby database architectures is in its log apply services. On Logical Standby, you can query it while simultaneously applying transactions from the primary. This is ideal for business that requires a near real-time copy of your production DB for reporting.
The key advantage for logical standby databases is that they’re opened read/write, even while they’re in applied mode. That is, they can be used to generate reports and the like. It is indeed a fully functional database. Also, additional indexes, materialized views and so on can be created.
Oracle (or more exactly the log apply services) uses the primary database’s redo log, transforms them into SQL statements and replays them on the logical standby database. SQL Apply uses  LOGMINER technology to reconstruct  DML statements from the redo generated on the primary.
The logical standby process (LSP) is the coordinator process for two groups of parallel execution process (PX) that work concurrently to read, prepare, build, and apply completed SQL transactions from the archived redo logs sent from the primary database.  The first group of PX processes read log files and extract the SQL statements by using LogMiner technology; the second group of PX processes apply these extracted SQL transactions to the logical standby database.  The mining and applying process occurs in parallel.  Logical standby database does not use standby online redo logs.  Logical standby database does not have FAL capabilities in Oracle.  All gaps are resolved by the proactive gap resolution mechanism running on the primary that polls the standby to see if they have a gap.  

What Are The Services Required On The Primary And Standby Database ?

The services required on the primary database are:

Log Writer Process (LGWR) – Collects redo information and updates the online redo logs. It can also create local archived redo logs and transmit online redo to standby databases.
Archiver Process (ARCn) – One or more archiver processes make copies of online redo logs either locally or remotely for standby databases.
Fetch Archive Log (FAL) Server – Services requests for archive redo logs from FAL clients running on multiple standby databases. Multiple FAL servers can be run on a primary database, one for each FAL request. .
The services required on the standby database are:
Fetch Archive Log (FAL) Client – Pulls archived redo log files from the primary site. Initiates transfer of archived redo logs when it detects a gap sequence.
Remote File Server (RFS) – Receives archived and/or standby redo logs from the primary database.
Archiver (ARCn) Processes – Archives the standby redo logs applied by the managed recovery process (MRP).
Managed Recovery Process (MRP) – Applies archive redo log information to the standby database

What Are The Advantages In Using Oracle Data Guard?

  • High Availability.
  • Data Protection.
  • Off loading Backup operation to standby database.
  • Automatic Gap detection and Resolution in standby database.
  • Automatic Role Transition using Data Guard Broker.

What is Switchover event?

Switchover is useful for minimizing downtime during planned maintenance. It is a planned event in which Data Guard reverses the roles of the primary and a standby database.

The primary database runs unaffected while we are making the required changes on our standby database (e.g. patchset upgrades, full Oracle version upgrades, etc).
Once changes are complete, production is switched over to the standby site running at the new release.

This means regardless of how much time is required to perform planned maintenance, the only production database downtime is the time required to execute a switchover, which can be less than 60 seconds
Below operations happens when switchover command is executed:

  1. primary database is notified that a switchover is about to occur.
  2. all users are disconnected from the primary.
  3. a special redo record is generated that signals the End Of Redo (EOR).
  4. primary database is converted into a standby database.
  5. the final EOR record is applied to standby database, this guarantees that no data has been lost, and it converts the standby to the primary role.

What is Failover event?

A failover is when the primary database fails and one of the standby databases is transitioned to take over the primary role. Failover is performed only in the event of a catastrophic failure of the primary database, and there is no possibility of recovering the primary database in a timely manner. Failover may or may not result in data loss depending on the protection mode in effect at the time of the failover.

Whether or not a failover results in data loss depends upon the Data Guard protection mode:

a) Maximum Protection >> No Data Loss

b) Maximum Availability >> No Data Loss (except when there was a previous failure (e.g. a network failure) that had INTERRUPTED REDO TRANSPORT and allowed the primary database to move ahead of standby).

c) Maximum Performance (ASYNC) >> may lose any committed transactions that were not transmitted to the standby database before the primary database failed.

Failover event can be of two types:

1) Manual

Administrator have complete control of primary-standby role transitions. It can lengthen the outage by the amount of time required for the administrator to be notified and manual execution of command.

2) Automatic

It uses Data Guard’s Fast-Start Failover feature which automatically detects the failure, evaluates the status of the Data Guard configuration, and, if appropriate, executes the failover to a previously chosen standby database.

What Are The Protection Modes In Dataguard?

Data Guard Protection Modes

Maximum Availability

This protectionmode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

Maximum Performance

This protectionmode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.

Maximum Protection

This protection mode ensures that zero data loss occurs if a primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

Because this data protection mode prioritizes data protection over primary database availability, Oracle recommends that a minimum of two standby databases be used to protect a primary database that runs in maximum protection mode to prevent a single standby database failure from causing the primary database to shut down.

How To Check What Protection Mode Of Primary Database In Your Oracle Data Guard?

By using following query you can check protection mode of primary database in your Oracle Data Guard setup.

select protection_mode from v$database;

How To Change Protection Mode In Oracle Data Guard Setup?

By using following query your can change the protection mode in your primary database after setting up required value in corresponding LOG_ARCHIVE_DEST_n parameter in primary database for corresponding standby database.
ALTER DATABASE SET STANDBY DATABASE TO MAXIMUM [PROTECTION|PERFORMANCE|AVAILABILITY];

alter database set standby database to MAXIMUM PROTECTION;

What Are The Uses Of Standby Redo Log Files?

The Advantage of having Standby Redo Logs is that every records written into the Online RedoLogs of the Primary Database
is transferred to the Standby database and written into the Standby Redo Logs at the same time.
therefore, you it minimizes the probability of Data Loss on the Standby Database.

For real time apply, it is mandatory to have redolog.

Without Standby Redo Logs, an Archived Redo Log is created by the RFS process and when it has completed,
this Archived Redo Log is applied to the Standby Database by the MRP process . An incomplete ArchiveLog file cannot be applied on the Standby Database and will not be used in a Failover situation. This causes a certain data loss.

If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log ,when there record entered in online redolog and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database. In a Failover situation, you will also have access to the information already written in the Standby Redo Logs, so the information will not be lost.

How Many Standby Databases We Can Create (in 10g/11g/12C)?

Till Oracle 10g, 9 standby databases are supported.

From Oracle 11g R2, we can create 30 standby databases..

How to Find the archive GAP in ORACLE DATA GUARD?

How to check MRP is running or not ?

How to check RFS is receiving archives at standby or not?

How to start or stop MRP process?

How to start MRP in parallel?

What are reason for archive GAP in ORACLE DATA GUARD?

How to resolve small archive gaps in ORACLE DATA GUARD?

How to resolve huge archive gaps in ORACLE DATA GUARD?

Categories:

Tags:

One response

Leave a Reply

Your email address will not be published. Required fields are marked *