Uploaded byMario Redón Luz
High Availability And Oracle Data Guard 11g R2
This document discusses high availability and Oracle Data Guard 11g R2, emphasizing the importance of disaster readiness for organizations. It covers key concepts such as availability, types of standby databases, protection modes, and the management of primary and standby databases, as well as real-world examples and features of Data Guard. The document also outlines the steps necessary to configure Data Guard for optimal performance and reliability.
More Related Content
![Oracle RAC 12c Practical Performance Management and Tuning OOW13 [CON8825]](https://cdn.slidesharecdn.com/ss_thumbnails/oraclerac12cpracticalperformancemanagementandtuningoow13con8825-131001011452-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to High Availability And Oracle Data Guard 11g R2
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
High Availability And Oracle Data Guard 11g R2
- 1.
- 2. High Availability andOracle Data Guard 11g R2 Mario Redón Luz Student
- 3. Agenda Introduction toHigh Availability Data Guard Concepts Real examples Demo References <Insert Picture Here>
- 4. “ … IT operations professionals are crossing their fingers and hoping a disaster won’t hit, while business executives have no idea how vulnerable they really are to significant losses . . .” “ Six Years After 9/11, Most Firms Are Not Ready For Another Disaster”, Sep 11, 2007 What Forrester Research Is Saying
- 5. Even Companies WhoImplement DR . . .using Traditional DR Technologies Are saddled with expensive, redundant systems Under-utilize their standby resources Have no immediate ROI until a disaster occurs Lack confidence that it will work when needed
- 6. Introduction to HighAvailability Definition and characteristics Availability is the degree to which an application or service is accessible on demand. It is measured by the perception of an application's end user Characteristics of a highly available solution: Reliability Recoverability Timely error detection Continuous operation
- 7. Introduction to HighAvailability Related concepts SLA : agreement between two parties which specifies levels of availability, performance or operation. Each area of service scope should have its level of service defined. In some cases, penalties may be agreed in case of non-compliance RTO : maximum amount of time that an IT-based business process can be down before the organization starts suffering unacceptable consequences (financial losses, customer dissatisfaction, reputation, etc.) RPO : maximum amount of data that an IT-based business process may lose without harm to the organization
- 8. Introduction to HighAvailability Causes of downtime Site failure Clusterwide failure Computer failure Storage failure Data corruption Human error Hang or slowdown System and database changes Data changes Application changes Unplanned Planned
- 9. Introduction to HighAvailability Some data… Source: IOUG Survey on High Availability Trends
- 10. Introduction to HighAvailability Oracle HA Technologies
- 11. Data Guard ConceptsOracle 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 database 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 user interface provided with Oracle Enterprise Manager Grid Control
- 12. Data Guard ConceptsPrimary and Standby Databases Primary : accesed by most applications, can be single-instance or RAC database Standby: transactionally consistent copy of the primary database. Maintained automatically using redo data. Can be a single-instance or RAC database
- 13. Data Guard ConceptsTypes of Standby Databases: Physical Standby Provides a physically identical copy of the primary database Synchronized through Redo Apply Benefits:
- 14. Data Guard ConceptsTypes of Standby Databases: Physical Standby Provides a physically identical copy of the primary database Synchronized through Redo Apply Benefits:
- 15. Data Guard ConceptsTypes of Standby Databases: Logical Standby Contains the same logical information as the production database although the physical organization and structure of the data can be different Synchronized through SQL Apply Auxiliar structures can be created to optimize the reporting workload Some restrictions on datatypes, types of tables, and types of DDL and DML operations Benefits: 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
- 16. Physical Standby vsLogical Standby
- 17. Data Guard ConceptsTypes of Standby Databases: Snapshot Standby It’s a physical standby database that is temporarily converted into an updatable standby database Receives and archives redo data from the primary database but it does not apply redo data from the primary database while the standby is open for read/write access Typically diverges from the primary database over time Redo data from the primary database is not applied until you convert the snapshot standby database Benefits: Development and testing purposes
- 18. Data Guard ConceptsReader farms - RAC
- 19. Data Guard ConceptsReader farms – Single Instance
- 20. Data Guard ConceptsRole transitions Operation used to change from primary to standby and viceversa. Switchover : ensures no data loss. Used when performing planned maintenance of the primary system. The primary database transitions to a standby role, and the standby database transitions to the primary role Failover : is when the primary database is unavailable. Failover is performed only in the event of a failure of the primary database and the failover results in a transition of a standby database to the primary role
- 21. Data Guard ConceptsProtection modes Maximum availabilility : t ransactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. Ensures zero data loss except in the case of certain double faults Maximum performance : default protection mode. Transactions are allowed to commit as soon as all redo data generated by those transactions has been written to the online log. Offers less data protection than maximum availability mode Maximum protection : redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. Ensures zero data loss
- 22. Data Guard ConceptsNew features in 11 g releases Heterogeneus Data Guard Configuration Real-Time Query Capability of Physical Standby Database User Configurable Conditions to Initiate Fast-Start Failover Added Snapshot Standby Transport of Redo Data using SSL Support TDE with Data Guard SQL Apply Compressed Table Support in Logical Standby Databases Integrated Support for Application Failover Support Up to 30 Standby Databases 11 g R1 11 g R2
- 23. How redo istransported...
- 24.
- 25. What Data Guardcan be used for?
- 26. <Insert Picture Here>Real examples
- 27. Amazon.com experience Data-GuardFast-Start Failover
- 28. Benchmarks Not usingData Guard
- 29.
- 30. Benchmarks Using DataGuard + RAC
- 31. Volkswagen AG OracleStreams and Data Guard
- 32.
- 33. Initial environment… OracleVM Manager 2.1.5 Oracle VM Server 2.1.5 Oracle Enterprise Linux 5.3 Oracle Database 10g XE Oracle Grid Control 10.2.0.5 Oracle Database 11.1.0.7 – emrep Oracle Database 11.1.0.7 – standby A ll this with a laptop… moreover, limitations using Data Guard 1 GB 2 GB 800 MB 800 MB
- 34. ... and afterthinking Oracle Enterprise Linux 5.3 Oracle Database 11.2 - orcl Oracle Database 11.2 - orclstby 800 MB 800 MB 1 GB No resources problems
- 35. Setup Enable forcelogging SQL> ALTER DATABASE FORCE LOGGING Configure database to receive redo data (x4) SQL> ALTER DATABASE ADD STANDBY LOGFILE Configure database initialization parameters SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=‘dg_config=(orcl,orclstby)’ SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=‘service= orclstby ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=orclstby’ Put the primary database in ARCHIVELOG mode SQL> ALTER DATABASE ARCHIVELOG
- 36. Creating the physicalstandby database Create an Oracle Net service name for the physical standby database in tnsnames.ora ORCLSTBY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mredon-es.us.oracle.com)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orclstby) ) )
- 37. Creating the physicalstandby database Configure an entry for the standby database in listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = orclstby) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = orclstby) ) )
- 38. Creating the physicalstandby database Create the standby database $> lsnrctl reload Navigate to $ORACLE_HOME/dbs and copy the remote login password file ( orapworcl) from the primary database system to the standby database system, renaming it to orapworclstby . Go to $ORACLE_HOME/dbs and create initorclstby.ora with a single line containing DB_NAME=orclstby Go to /u01/app/oracle/admin and create orclstby directory, get into it and create adump folder. Create a directory named orclstby in $ ORACLE_BASE/oradata and in $ORACLE_BASE/flash_recovery_area
- 39. Creating the physicalstandby database On the standby system: Set ORACLE_SID=orclstby Login into SQL*Plus and execute: SQL> startup nomount pfile=$ORACLE_HOME/dbs/initorclstby.ora On the primary system: Ensure $ORACLE_SID is set to the one of the primary database ( orcl ) RMAN> CONNECT TARGET sys RMAN> CONNECT AUXILIARY sys@orclstby Now, we are able to execute the script of the following slide
- 40. Creating the physicalstandby database run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile parameter_value_convert 'orcl','orclstby' set db_unique_name='orclstby' set db_file_name_convert='/orcl/','/orclstby/' set log_file_name_convert='/orcl/','/orclstby/' set log_archive_max_processes='5' set fal_client='orclstby' set fal_server='orcl' set standby_file_management='AUTO' set log_archive_config='dg_config=(orcl,orclstby)' set log_archive_dest_1='service=orcl ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=orcl‘ ; }
- 41. Verify the standbydatabase is performing correctly On the standby database: SQL> SELECT sequence#, first_time, next_time FROM v$archived_log ORDER BY sequence#; On the primary database: SQL> ALTER SYSTEM SWITCH LOGFILE On the standby database, issue this SQL statement to verify the redo data was received and archived on the standby database SQL> SELECT sequence#, first_time, next_time, applied FROM v$archived_log ORDER BY sequence#;
- 42. Creating a DGBroker Configuration Set the DG_BROKER_START initialization parameter to TRUE for your primary database and physical standby database SQL > ALTER SYSTEM SET dg_broker_start=TRUE Create the services for the listener and reload it (SID_DESC = (GLOBAL_DBNAME = orclstby_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = orclstby) ) (SID_DESC = (GLOBAL_DBNAME = orcl_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = orcl) )
- 43. Creating a DGBroker Configuration Invoke DGMGRL and connect to your primary database DGMRL> connect sys Create the broker configuration including a profile for the primary database DGMGRL> create configuration ‘DGConfig1’ as primary database is ‘orcl’ connect identifier is orcl; Add your physical standby database to the broker configuration. DGMGRL> add database ‘orclstby’ as connect identifier is orclstby; Enable the entire configuration. This may take some time to complete DGMGRL> enable configuration Verify that the configuration was successfully enabled DGMGRL> show configuration
- 44. Reading data fromthe standby database Using Active Data Guard option In the standby database, set up Active Data Guard mode: DGMGRL> edit database ‘orclstby’ set state=‘apply-off’; SQL> ALTER DATABASE OPEN READ ONLY DGMGRL> edit database ‘orclstby’ set state=‘apply-on’; Query the HR.REGIONS table in the standby database Insert a row in the HR.REGIONS table in the primary database and commit the transaction Query the HR.REGIONS table in the standby database and check a new row has appeared
- 45. Enabling Fast StartFailover Enable flashback on primary database: SQL> ALTER DATABASE FLASHBACK ON Enable flashback on standby database: DGMGRL> edit database ‘orclstby’ set state=‘apply-off’; SQL> ALTER DATABASE FLASHBACK ON DGMGRL> edit database ‘orclstby’ set state=‘apply-on’; Enable Fast Start Failover: DGMGRL> enable fast_start failover Check configuration DGMGRL> show fast_start failover DGMGRL> show database orcl DGMGRL> show database orclstby
- 46. Performing a switchoverInitiate the switchover to the standby database DGMGRL> switchover to orclstby Check changes in the configuration DGMGRL> show configuration SQL> SELECT database_role FROM v$database; Switchover to the original situation DGMGRL> switchover to orcl Check the new roles DGMGRL> show configuration SQL> SELECT database_role FROM v$database;
- 47. References ENISA - Risk Assessment Methods CCN Cert Oracle Database High Availability Overview 11 g Release 2 Oracle Open World MAA Presentations Oracle Data Guard Concepts and Administration 11 g Release 1 Oracle Data Guard Concepts and Administration 11 g Release 2 Oracle By Example Series: Data Guard Oracle Online Demos: 11g R2 Data Guard Series
- 48. <Insert Picture Here>Any questions? Thanks for your time!
- 49.
- 50.
Editor's Notes
- #7 Reliability implies hardware and software (database, web servers and applications) Recoverability how the system recovers from various types of errores e.g. : db problems (Oracle solutions like Data Guard) Timely error detection time needed to determine the cause of failure Continous operation continuous access to data, certain operations shouldn’t affect users working on the system
- #8 SLA (service-level-agreement) : t he SLA records a common understanding about services, priorities, responsibilities, guarantees, and warranties. It can also be specified as target and minimum, which allows customers to be informed what to expect (the minimum), whilst providing a measurable (average) target value that shows the level of organization performance. RTO (recovery time objectives) : determined by a business impact analysis using a methodology like CRAMM, OCTAVE or Magerit (developed by CCN). The RTO requirements are driven by the mission-critical nature of the business and an organization is likely to have varying RTO requirements across its various business processes. RPO (recovery point objectives) : RPO indicates the data-loss tolerance of a business process or an organization in general. This data loss is often measured in terms of time, for example, 5 hours or 2 days of data loss. As the RTO, it is also calculated performing a business impact analysis.
- #9 11gR1: Heterogeneus Data Guard Configuration primary and standby databases in a data guard configuration can be linux or windows versions Real-Time Query Capability of Physical Standby Database Active Data Guard User Configurable Conditions to Initiate Fast-Start Failover corrupted controlfile, inaccesible logfile, ORA errors Added Snapshot Standby new type of standby database Transport of Redo Data using SSL Support TDE with Data Guard SQL Apply Transparent Data Encription 11gR2: Compressed Table Support in Logical Standby Databases Integrated Support for Application Failover Applications connected to a primary database can transparently failover to the new primary database upon an Oracle Data Guard role transition. Integration with Fast Application Notification (FAN) provides fast failover for integrated clients Support Up to 30 Standby Databases in 11gR1 9 standby databases were supported
- #14 Redo Apply: recovers the redo data received from the primary database and applies the redo to the physical standby database . More efficient way of keeping a database updated, avoids SQL code layers. Applications, backups, reports run on production only
- #15 Offload read-only queries to an up-to-date physical standby. Perform fast incremental backups on a physical standby . Deploy on low cost servers and storage, no special network components. Thousands of production customers Data Guard 11g Recovery (redo apply) must be stopped to open a standby read-only. Same functionality as previous Data Guard releases. Not possible to guarantee read consistency while redo apply is active Data Guard 11 g with the Active Data Guard Option Physical Standby is open read-only while redo apply is active. Read consistency is guaranteed. Redo apply is not adversely affected by read-only workload
- #16 SQL Apply: transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database. Auxiliar structures could be including structures that could have a prohibitive effect on the primary database
- #18 Redo data is applied when you convert a snapshot standby database into a physical standby database. In this moment, changes made to the snapshot standby state are discarded and Redo Apply automatically resynchronizes the physical standby database with the primary database using the redo data that was archived
- #19 Creating a reader farm of physical standby databases provides the following benefits: Fault isolation High performance with physical standby databases and Redo Apply Seamless support for all DDL and data types using Redo Apply All reader databases are kept up-to-date with changes made to the primary database Automatic, zero or minimal data loss failover capability Management as a unified configuration through Grid Control Scale-out using single writer database and n reader databases Rolling upgrade capabilities
- #21 Failover: - dbms_dg.initiate_fs_failover Allows an application to trigger a fast-start failover - shutdown abort Crashing primary instance
- #22 Maximum availabilility: 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 protection mode ensures zero data loss except in the case of certain double faults, such as failure of a primary database after failure of the standby database. Maximum performance: 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. Maximum protection: 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.
- #23 11gR1: Heterogeneus Data Guard Configuration primary and standby databases in a data guard configuration can be linux or windows versions Real-Time Query Capability of Physical Standby Database Active Data Guard User Configurable Conditions to Initiate Fast-Start Failover corrupted controlfile, inaccesible logfile, ORA errors Added Snapshot Standby new type of standby database Transport of Redo Data using SSL Support TDE with Data Guard SQL Apply Transparent Data Encription 11gR2: Compressed Table Support in Logical Standby Databases Integrated Support for Application Failover Applications connected to a primary database can transparently failover to the new primary database upon an Oracle Data Guard role transition. Integration with Fast Application Notification (FAN) provides fast failover for integrated clients Support Up to 30 Standby Databases in 11gR1 9 standby databases were supported
- #24 Synchronous The synchronous redo transport mode transmits redo data synchronously with respect to transaction commitment. A transaction cannot commit until all redo generated by that transaction has been successfully sent to every enabled redo transport destination that uses the synchronous redo transport mode. This transport mode is used by the Maximum Protection and Maximum Availability data protection modes. Asynchronous The asynchronous redo transport mode transmits redo data asynchronously with respect to transaction commitment. A transaction can commit without waiting for the redo generated by that transaction to be successfully sent to any redo transport destination that uses the asynchronous redo transport mode. This transport mode is used by the Maximum Performance data protection mode.
- #29 tps: transactions per second number of commits (successful SQL) and rollbacks (aborted SQL) per second. In sum, SQL statements per second.
- #31 High transactions per second eBay, Amazon 1,000 - 10,000 TPS Medium transactions per second International web application 100 - 1,000 TPS Low transactions per second Small internal OLTP 10 - 100 TPS
- #32 Choose Oracle Streams if: • Concurrent updates on the same data in multiple sites • For more than simple, one-way replication architectures (bi-directional replication), • Support heterogeneous platforms and different charactersets
- #36 Force logging: this option makes statements that specicify the NOLOGGING option will still generate log information in order to properly maintain the Data Guard standby databases. Configure the primary database to receive redo data, by adding the standby logfiles to the primary. It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs. SID of standby database must not exceed 8 characters. In order to put the primary database in ARCHIVELOG mode it has to be just mounted.
- #37 Two first steps can be done with netmgr
- #38 Two first steps can be done with netmgr
- #39 Two first steps can be done with netmgr
- #40 In this example, standby system and primary system is the same, these steps should be performed in two separate tabs of the console. Temp filesystem should have a size two times or larger than the memory_target_parameter
- #42 ALTER SYSTEM SWITCH LOGFILE force a log switch and archive the current online redo log file group.
- #46 Fast-start failover enables the creation of a fault-tolerant standby database environment by providing the ability to totally automate the failover of database processing from the production to standby database, without any human intervention. This greatly reduces the length of an outage. The Observer, which monitors the Data Guard environment, automatically triggers and completes the failover when required. Fast Start Failover has not been enabled on this demo due to a resource problem (it needs setting up an observer) -Conditions Datafile Offline Data file offline due to a write error. Corrupted Controlfile Corrupted controlfile. Corrupted Dictionary Dictionary corruption of a critical database object. Inaccessible Logfile LGWR is unable to write to any member of a log group due to an I/O error. Stuck Archiver Archiver is unable to archive a redo log because device is full or unavailable. ORA errors Application Initiated Fast-Start Failover Use the DBMS_DG PL/SQL package to enable an application to initiate a fast-start failover when it encounters specific conditions. The primary database will notify the observer of this and the observer will immediately initiate a fast-start failover, assuming the standby is in a valid fast-start failover state (observed and either synchronized or within lag limits) to accept a failover.If the configuration is not failable, the DBMS_DG.INITIATE_FS_FAILOVER procedure will return an ORA error number (not signal an exception) informing the caller that a fast-start could not be performed.