Standby Database and Data Guard

Oracle Dataguard is a High availabity  software solution  designed for  data availability, data protection and disaster recovery solutions on enterprise data. It is only available with database enterprise edition .

The Solution is achieved by Creating a single  Standby database or multiple Standbys databases  for major Database in which enterprise data is handled 

A standby database is Transactional- consistent  copy of the Production or Primary Database 

Whenever a Primary Database becomes unavailable due to planned or unplanned outages ,the application traffic can be switched over to one of Standby to maintain a Business continuity .

Data Guard can be used in combination with other Oracle High Availability (HA) solutions such as Real Application Clusters (RAC), Oracle Flashback and Oracle Recovery Manager (RMAN), to provide a very high level of data protection and data availability

This data guard configuration ban be manged by tools like SQL command-line interfaces (SQLPLUS), Data Guard broker interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise Manager.

Types of Standby databases .

    1. Physical Stnadby 

    2.Logical Standby 

    3.Snapshot Standby 

    4.Active Data Guard 

Data Guard provides two methods to apply this redo data to the standby database and keep it transactional consistent with the primary, and these methods correspond to the two types of standby databases supported by Data Guard.

  • Redo Apply, used for physical standby databases
  • SQL Apply, used for logical standby databases
There are two kinds of role transitions – a switchover and a failover. A switchover is a role reversal between the primary database and one of its standby databases. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role and the standby database transitions to the primary role. The transition occurs without having to re-create either database. A failover is an irreversible transition of a standby database to the primary role. This is only done in the event of a catastrophic failure of the primary database, which is assumed to be lost and to be used again in the Data Guard configuration, it must be re-instantiated as a standby from the new primary.

Physical standby database:

  • Physical standby database is exact copy of primary database which is identical to primary database with block-for-block basis. A physical standby database is kept synchronized with the primary database, through Redo Apply (method used for transferring changes from primary database), which recovers the redo data received from the primary database and applies the redo to the physical standby database.
  • Normally, physical standby databases are not accessible to applications as they are maintained in “MOUNT” mode. 

Logical standby database:

  • Logical standby databases may not be exact copy of primary database, structure of the data can be different.
  • The logical standby database is kept synchronized with the primary database though SQL Apply (method used for transferring changes from primary database), which transforms the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database.
Active Data Guard:
  • Oracle Active Data Guard is the super set of Oracle Data Guard. Oracle Active Data Guard provides the best data protection and availability for Oracle Database.
  • Active Data Guard enables the offloading of read-only operations, backups, and so on, to an up-to-date physical standby database while also providing disaster protection. Active Data Guard uses highly parallelized apply process for best performance and ensuring the same read consistency at the standby as primary database. No other physical or logical replication solution does this.
  • Active Data Guard is licensed option to the Oracle Database Enterprise Edition and enables advanced capabilities that extend the basic Data Guard functionality which includes following:
  • Real-Time Query and DML Offload uses the standby database for queries, reports and occasional updates without impacting protection of the primary.
  • Automatic Block Repair provides an automatic and user-transparent recovery of corrupted database blocks from either the primary or the standby database.
  • Standby Block Change Tracking enables incremental backups on the standby.
  • Far Sync enables zero data loss protection across any distance.
  • Global Data Services load balance connection requests and provide an integrated service management across replicated databases, considering placement of connections depending on read or read/write workload.
  • Application Continuity makes outages transparent to application users.
  • Faster Incremental Backups can be performed on active Data guar database by enable Block change tracking on the ADG database .

SNAPSHOT STANDBY:

  • A snapshot standby database is a fully update-able standby database that is created by converting a physical standby database into a snapshot standby database. During this setup though it will receive logs from primary, those redo won’t be applied to snapshot standby.

  • It provides an exact replica of a production database for development and testing purposes, while maintaining data protection at all times.

  • Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database. 

Data Guard Protection Modes:

In some situations, a business cannot afford to lose data at any cost. In other situations, some applications require maximum database performance and can tolerate a potential loss of data. Data Guard provides three distinct modes of data protection to satisfy these varied requirements:

  • Maximum Protection— This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode ensures no-data-loss.
  • Maximum Availability— This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
  • Maximum Performance— This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database and there is little effect on primary database performance.

Data Guard Broker:

The Oracle Data Guard Broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. All management operations can be performed either through Oracle Enterprise Manager, which uses the Broker, or through the Broker’s specialized command-line interface (DGMGRL).

Real Time Apply:

With this feature, redo data can be applied on the standby database (whether Redo Apply or SQL Apply) as soon as they have written to a Standby Redo Log (SRL). Prior releases of Data Guard require this redo data to be archived at the standby database in the form of archivelogs before they can be applied. 

The Real Time Apply feature allows standby databases to be closely synchronized with the primary database, enabling up-to-date and real-time reporting (especially for Data Guard SQL Apply). This also enables faster switchover and failover times, which in turn reduces planned and unplanned downtime for the business.

The impact of a disaster is often measured in terms of Recovery Point Objective (RPO – i.e. how much data can a business afford to lose in the event of a disaster) and Recovery Time Objective (RTO – i.e. how much time a business can afford to be down in the event of a disaster). With Oracle Data Guard, when Maximum Protection is used in combination with Real Time Apply, businesses get the benefits of both zero data loss as well as minimal downtime in the event of a disaster and this makes Oracle Data Guard the only solution available today with the best RPO and RTO benefits for a business.

  • Standby redolog is mandatory for realtime apply

Transport Services   are the pieces that handle the synchronous and asynchronous transport. These services move the log or transactions to available standby servers and verify that they are being applied to these servers. Synchronous transports validate that transactions have been applied on both primary and standby servers before committing the transactions. The asynchronous transport will validate that transactions have been sent, but transactions will be committed on the primary even if not completed on the standby.

Standby Redologs

Standby Redo Logs (SRL) is similar to Online Redo Log (ORL). Only difference between two is that Standby Redo Log is used to store redo data received from another database (primary database).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.

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.



 .     

Comments

Post a Comment

Popular posts from this blog

Cold Backup Cloning of Database .

 Cold Backup :  A cold backup is done when there is no user activity going on with the system. Also called as offline backup, is taken when the database is not running and no users are logged in. all files of the database are copied and no changes during the copy are made. Cold backup can be preformed when Database is in archive mode as well as Non archive log mode  . Backup Strategy :  Gather all the details of physical files (CRD) files in  database . redo log files are online redo log and archived redo log ones .   Select file_name,tablespace_name from dba_data_files  ; select * from v$controlfile  select member from v$logfile ; select name from v$archived_Log ;  create pfile from spfile  Backup  the contol file manually . alter database backup controlfile to trace as '/tmp/coldbackup_controlfile.sql' ;     Stop all the DB services (Database ,Listener)on source DB Server. Copy all the files(Datafiles,redologfiles,pfile,contol file backup) from source to backup location 
Read more

Find ALert log Location

 The alert log is an XML file that is a the log of messages and errors. Each alert log is specific to its component type, such as database, Oracle ASM, listener, and Oracle Clusterware. For the database, the alert log includes messages about the following:     Critical errors (incidents)     Administrative operations, such as starting up or shutting down the database,         recovering the database, creating or dropping a tablespace, and others.     Errors during automatic refresh of a materialized view     Other database events      Trace files are updated periodically over the life of the process and can contain information on the process environment,  status, activities, and errors. In addition, when a process detects a critical error,  it writes information about the error to its trace file.      Using Find Command    find $ORACLE_BASE -type f -name alert_$ORACLE_SID.log    select value from GV$DIAG_INFO WHERE name='Diag Trace';    find /opt/oracle -name alert*log
Read more

FRA Usage and Administration

Image
 In Oracle database, the Flash Recovery Area or FRA is a location on disk where the database can create and manage several kinds of backup and recovery-related files. Main file types are archivelog, flashback log, backups, as well as mirrors for your control files and redo log files. All files in the FRA are Oracle-managed files. Using a Flash Recovery Area simplifies the administration of your database by automatically retaining them for as long as they are needed for restore and recovery activities, and deleting them when they are no longer needed, because the space is needed for another backup and recovery-related purpose. Checking the current usage  You can check the configuration by looking at two parameters.The parameters are db_receovery_file_dest and second one db_recovery_file_dest_size .  db_receovery_file_dest point to location where the files will be located in Server . FOr normal single Databases this will be any directory for RAC this will be set to a Diskgroup whi
Read more