Data Guard Architecture & Setup

Nov. 16, 2011

More Related Content


Data Guard Architecture & Setup

  1. Oracle Data Guard Presented by Satishbabu Gunukula 12+ Years of Experience in Oracle, SQLServer Database Technologies Oracle Certified Professional Oracle 8i,9i,10g Oracle Certified Expert Oracle 10g RAC 
  2. Agenda  Data Guard and its benefits?  Data Guard Architecture  Types of Data guards and Benefits  Advantages with different types of Data guards  Processes and Services  Data Guard Protection Modes  Data Guard Role Transitions  Data Guard Broker Architecture  Data Guard features across versions  Data Guard Setup
  3. Why undertake Disaster Recovery?  Disaster can strike at any time  Unprepared organizations can loose all the critical data.  Even prepared companies can suffer financial loss during system down time.  Disasters can be natural calamities or man-made problems
  4. Origin …  Impact of Disasters  Customers across the globe will be effected  High Availability Challenges  Down time -- unplanned or planned  Setup and Maintenance cost.  Identifying the Disaster Recovery Site (DR Site)
  5. Why Data Guard ? Prior to Data Guard:  Standby database What is Standby database? A standby database is a database replica created from a backup of a primary database. By applying archived redo logs from the primary database to the standby database, you can keep the two databases synchronized Used for :  Disaster protection  Protection against data corruption  Supplemental reporting Data guard is one of the most effective solutions available today in terms of High Availability. Why?
  6. Before Data guard… Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. 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.”
  7. Pre-requisites:  Same Oracle Enterprise Edition must be installed.  primary database must run in ARCHIVELOG mode.  Hardware and Operating System architecture must be same.  Primary and Standby must have its own control file  Can be configured on the same or different systems.  Turn on FORCE LOGGING at the primary.  SYSDBA privileges to user accounts.
  8. Data Guard Benefits  Disaster recovery, data protection, and high availability  Complete data protection  Efficient use of system resources  Flexibility in data protection to balance availability against performance requirements  Automatic gap detection and resolution  Centralized and simple management  Integration with Oracle Database (no separate installation)  Automatic role transitions
  9. Processes Involved in the Architecture Below are the main processes in DG configuration: 1) Logwriter (LGWr) Process 2) Archiver (ARCH) Process 3) Logwriter Network Server (LNS) 4) Fetch Archive Logs (FAL) for Client –Server mechanism 5) Remote File Server (RFS) 6) Managed Recovery Process (MRP) for Physical standby 7) Logical Standby Process (LSP) for Logical Standby If Data Guard Broker is enabled : 8) Data Guard Broker Monitor (DMON) process
  10. DataGuard Architecture
  11. Redo log Data flow Flow of Redo Data from Primary to Standby Database
  12. Apply Services At High Level  Data Guard comprises of two parts  Redo Apply – For physical standby  SQL Apply - for logical standby  The Physical and logical standby databases utilize the same redo transport and role management services, only apply process is different.  Either can be used to offload query and reporting from the primary database. Either can be used to execute a rolling database upgrade  All standby databases are first created as physical standby databases during the standby database instantiation process. Several additional steps are required to convert a physical standby database to a logical standby database.
  13. Redo Apply A physical standby database applies redo data received from the primary using Oracle media recovery.  The Redo Apply uses a specialized process, called the Managed Recovery Process.  As the RFS process is writing redo data to Standby Redo Logs (SRLs), MRP reads the redo data and applies it to the physical standby database.  MRP is started on the physical standby database by mounting the database and using the following command:  SQL> alter database recover managed standby database using current logfile disconnect from session;
  14. Redo Apply MRP may also transparently switch to reading from a standby archived log if the SRL is archived before MRP can complete reading of the.
  15. SQL Apply SQL Apply uses a collection of background processes that perform the task of applying changes from the primary database to the logical standby database.
  16. Types of Dataguards: Physical Standby  Physical standby Provides a physically identical copy of the primary database, Identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. Synchronized with the primary database, through Redo Apply.
  17. Data guard :Physical Standby Benefits Benefits:  Disaster recovery and high availability Enables a robust and efficient disaster recovery and high availability solution  Data protection Ensures no data loss, even in the face of unforeseen disasters. Supports all data types, and all DDL and DML operations  Reduction in primary database workload  Oracle Recovery Manager (RMAN) can use to off-load backups from the primary database saving valuable CPU and I/O cycles.  Performance  The Redo Apply technology applies changes using low-level recovery mechanisms and is most efficient method for applying high volumes of redo.
  18. Types of Dataguard :Logical Standby  Logical standby Contains same logical information physical organization and structure of the data can be different Synchronized with the primary database, through SQL Apply Can be used for queries and reporting at any time.
  19. Logical Standby benefits  Benefits:  Along with disaster recovery, high availability, and data protection;  Efficient use of standby hardware resources  Additional indexes and materialized views can be created to improve query performance and suit specific business requirements.  Reduction in primary database workload
  20. Services Involved: •Log Transport Services Transmit redo data from the primary system to the standby systems in the configuration Enforce the database protection modes •Log Apply Services Automatically apply archived redo logs on the standby database Maintains transactional synchronization with the primary database Allows transitionally consistent read-only access to the data.  Redo Apply for Physical standby. SQL Apply for Logical stand by. •Role Management Services An Oracle database operates in one of two roles: primary or standby Achieved by Switch over and Fail over operations.
  21. Maximum Availability Architecture
  22. Protection Modes There are Three protection modes  Maximum Availability  Maximize Protection  Maximize Performance There are 3 ways of shipping redo data to a physical standby:  LGWR SYNC  LGWR ASYNC  ARCH
  23. Maximum Protection Mode  This mode ensures that zero data loss occurs if a primary fails. The default is Maximum Performance.  In case if standby unavailable then processing stops at primary. This the highest level of protection  Maximum protection configuration - LGWR SYNC, SRLs SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
  24. Maximum Availability Mode  This mode provides highest level of data protection with out compromising the availability of primary database  If last standby is unavailable, processing continues at primary. As long as network stys up - Zero Data Loss  Maximum availability configuration - LGWR SYNC, do not need SRLs SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY
  25. Maximum Performance Mode  This mode provides the highest level of data protection that is possible without affection the performance of a primary database Highest level of performance  This mode has least impact on system and protects from failure of any single component  Maximum performance configuration - LGWR ASYNC, or ARCH SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;
  26. Role Transitions:  A database operates in one of the following mutually exclusive roles: primary or standby.  Data Guard enables you to change these roles dynamically by issuing the SQL statements , or by using either of the Data Guard broker's interfaces.  Oracle Data Guard supports the following role transitions:  Switch over  Failover
  27. Switchover  Allows the primary database to switch roles with one of its standby databases.  There is no data loss during a switchover.  After a switchover, each database continues to participate in the Data Guard configuration with its new role.
  28. DataGuard Config Before Switchover
  29. DataGuard Config AfterSwitchover
  30. Failover  A failover is typically used only when the primary database becomes unavailable, and there is no possibility of restoring it to service within a reasonable period of time.  The specific actions performed during a failover vary based on whether a logical or a physical standby database is involved in the failover, the state of the Data Guard configuration at the time of the failover, and on the specific SQL statements used to initiate the failover
  31. Failover to a Standby Database
  32. Data guard Broker:  The Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations  Can be administered either from Oracle Enterprise Manager or Broker’s CLI (DGMGRL)  List of operations that Broker automates :  Creating and Enabling DG configurations – both Primary and Physical/Logical  Managing DG configuration from any site.  Implementing Switchover and Failover operations
  33. DG Broker Architecture:
  34. Some Data Guard Features across versions 9i,10g and 11g
  35. DG features in Oracle 9.1: 9i : (9.1)  Oracle 8i Standby renamed as Oracle 9i Data Guard  Oracle9i Data Guard broker  No data loss  Database Switch over  Archive gaps automatically detected  Background managed recovery mode.  Standby redo logs.
  36. Enhancements in 9.2: 9i : (9.2)  Logical Standby Database  Data protection modes (Max Protection/Availability/Performance)  Cascading Redo Log Destinations  Data Guard Broker  Supports up to 9 Physical and Logical Standby databases  For Failover and Switchover operations  New Key words for REMOTE_ARCHIVE_ENABLE (Send/Receive)
  37. Data guard Enhancements in 10g :  Fast –start Failover  Logical standby  LGWR ASYNC Redo Transport Enhancement  Real Time Apply  Rolling Upgrade
  38. Dataguard Enhancements in 11g :  Improved Data Protection  High Availability  Manageability  Increased ROI
  39. Improved Data Protection  Faster redo transport  Advanced Compression log_archive_dest= ‘service=dbname ASYNC COMPRESSION= ENABLE’  Redo Compression edit the broker property Redo Compression=Enable  Lost–Write Protection
  40. Higher Availability:  Faster Redo apply and SQL apply  Faster failover and switch over  Enhanced Fast -start failover  Transient logical standby  NEW GC HA console
  41. Manageability:  SQL Apply –more automation  Better RMAN integration  Better Security  Mixed Windows/linux  Enhanced DG Broker
  42. Increased ROI  snapshot standby  Active Data guard  Enhanced Rolling upgrade  Real –time query  Fast incremental backup
  43. Snapshot Standby:
  44. Active Data guard  Offload readonly queries to physical standby  Offload increamental backups to physical standby
  45. Rolling Database Upgrades  The Rolling upgrade process involves upgrading the logical standby database to the next release  The patch set upgrade can be performed with near zero database downtime.
  46. Setup Overview : Step 1: Prepare the Primary for Standby Step 2: Configure Primary parameters Step 3: Configure Primary listener and tnsnames Step 4: Copy the necessary files and create Standby controlfile Step 5: Configure the Standby Parameters Step 6: Configure Standby listener and tnsnames Step 7: Startup the Standby Site and Apply redo
  47. Primary Database Req for DataGuard FORCE LOGGING must be enabled: SQL> Select name, database_role from v$database; SQL> select force_logging from v$database; SQL> alter database force logging; Database must be in ARCHIVELOG mode and automatic archiving must be enabled: SQL> archive log list
  48. Configure Primary parameters control_files='/oradata/orclDB/control01.ctl, ‘/oradata/orclDB/control02.ctl' ' log_archive_config='DG_CONFIG=(orclDB,orclstd)' scope=both; log_archive_dest_1='LOCATION=/oradata/orclDB/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)‘ log_archive_dest_2='SERVICE=orclstd VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR ASYNC REOPEN=10'
  49. Configure Primary parameters control_files='/oradata/orclDB/control01.ctl, ‘/oradata/orclDB/control02.ctl' ' log_archive_config='DG_CONFIG=(orclDB,orclstd)' scope=both; log_archive_dest_1='LOCATION=/oradata/orclDB/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)‘ log_archive_dest_2='SERVICE=orclstd VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR ASYNC REOPEN=10'
  50. Configure Primary Listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = (ORACLE_HOME = /oracle/v10204) (SID_NAME = orclDB) ) )
  51. Configure Primary tnsnames.ora orclDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) ) orclstd = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) )
  52. Create Standby Controlfile Shutdown the Primary database and copy the necessary files to standby site SQL> STATUP MOUNT SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/oradata/orclDB/stdby01.ctl'; Copy the standby control file to standby site
  53. Configure Standby parameters control_files='/oradata/orclDB/stdby01.ctl, /oradata/orclDB/stdby02.ctl' log_archive_config='DG_CONFIG=(orclstd,orclDB)‘ log_archive_dest_1='LOCATION=/oradata/orclDBt/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)’ log_archive_dest_2='SERVICE=orclDB VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR ASYNC REOPEN=10'
  54. Configure Standby parameters log_archive_dest_state_1='enable' log_archive_dest_state_2='enable' FAL_CLIENT='orclstd' FAL_SERVER='orclDB' standby_archive_dest='/oradata/orclDB/arch' standby_file_management='auto' remote_login_passwordfile='EXCLUSIVE'
  55. Configure Standby Listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = (ORACLE_HOME = /oracle/v10204) (SID_NAME = orclDB) ) )
  56. Configure Standby tnsnames.ora orclDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) ) orclstd = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = )
  57. Standby tnsnames.ora orclDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) ) orclstd = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = )
  58. Mount Standby Database and Apply redo Keep the database in Standby mode SQL>STARTUP MOUNT; Start Redo Apply SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; The DISCONNECT FROM SESSION option used to run background session to apply Redo
  60. Thank you.