The document provides an introduction to Oracle Data Guard and high availability concepts. It discusses how Data Guard maintains standby databases to protect primary database data from failures, disasters, and errors. It describes different types of standby databases, including physical and logical standby databases, and how redo logs are applied from the primary database to keep the standbys synchronized. Real-time apply is also introduced, which allows for more up-to-date synchronization between databases with faster failover times.
2. Aganda Introduction to High Availability Data Guard Concept Data Guard Implementation Data Guard Scenario
3. Introduction to High Availability Availability is the degree to which an application or server is accessible on demand. It is measured by the perception of an applications end user. Characteristics of a high availability Reliability Recoverability Timely error detection Continuous operation
4. Why Data Guard ? UNPLANNED Site Failure Computer Failure Storage Failure Data Corruption Human Error Hang or Slowdown PLANNED System and Database Changes Data Changes Application Changes
5. Why Data Guard ? Data Guard helps you protect your Data. Takes your data and automatically puts it elsewhere Makes it available for Failover in case of failure. The apply process also revalidates the log records to prevent application of any log corruptions Geographically dispersed sites Useful for logical data corruptions if lag behind used Flexible configuration options for protection level Reporting and backups can be diverted to standby Automatic resync for failed primary Switchover for Maintenance
6. What is Standby Data guard ? A copy of a production database that you can use for disaster protection. You can update the standby database with redo logs from the production database in order to keep it current. If a disaster destroys the production database, you can activate the standby database and make it the new production database. You can maintain the standby data in one of the following modes: For physical standby databases Redo Apply For logical standby databases SQL Apply A Standby Database is NOT Data Guard
7. Data Guard Concepts Oracle Data Guard provides the management, monitoring and automation software to create and maintain one or more standby databases to protect oracle data from failures, disasters, human error and data corruptions A data guard configuration consists of one production and one or more standby databases. The databases in a data guard configuration may be dispersed geographically. Managing primary and standby databases can be done using SQL command-line interfaces, Data guard broker interfaces or using a graphical users interface provided with oracle Enterprise Manager Grid Control.
9. Data Guard Concepts Types of Standby Databases : Physical Standby Database A physical standby database provides a physically identical copy of the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The database schemas, including indexes are the same. Synchronized through Redo Apply The Redo Apply technology applies redoes data on the physical standby database using standard Oracle media recovery techniques. Logical Standby Database Contains the same logical information as the production database although the physical organization and structure of the data can be different . Logical standby database does not have to match the schema structure of the source database. Synchronized through SQL apply.
10. Data Guard Concept Benefits of Standby Database Switchover and Failover Reduce the amount of queries performed on the primary database Can be used to upgrade oracle Database software and patch sets with almost no downtime.
12. Data Guard Concept Services required on the primary database : 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 Services required on the standby database : 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
13. Data Guard Concept Redo from primary database RFS ARC0 Standby redo logs Archived redo logs MRP/LSP Standby database
14. Real Time Apply Redo data is applied to the standby database as soon as it is received from the primary database In Oracle9 i Data Guard this apply has to wait till an archivelog is created on the standby database For Redo Apply: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE When real time apply is enabled , RECOVERY_MODE column in V$ARCHIVE_DEST_STATUS displays “ MANAGED REAL TIME APPLY ”
15. SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=tmstby 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 4> DB_UNIQUE_NAME=tmstby'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(tmtst,tmstby)' SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; PROTECTION_MODE PROTECTION_LEVEL --------------------- --------------------- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
17. Real Time Apply Benefits Standby databases now more closely synchronized with the primary More up-to-date, real-time reporting Faster switchover and failover times Reduces planned and unplanned downtime Better Recovery Time Objective (RTO) for DR
18. Data Dictionary V$DATABASE DATABASE_ROLE: LOGICAL STANDBY, PHYSICAL STANDBY or PRIMARY PROTECTION_LEVEL: current protection mode setting. FS_FAILOVER_STATUS: synchronization status V$DATAGUARD_STATS V$DATAGUARD_STATUS V$LOG & V$STANDBY_LOG: Redo log changed. V$MANAGED_STANDBY : Recovery progress