High Availability And Oracle Data Guard 11g R2

35,594 views
35,347 views

Published on

Second presentation as student in Oracle.

Content:

- Introduction to High Availability
- Data Guard Concepts
- Real examples
- Demo
- References

Published in: Technology
25 Comments
80 Likes
Statistics
Notes
No Downloads
Views
Total views
35,594
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
0
Comments
25
Likes
80
Embeds 0
No embeds

No notes for slide
  • 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
  • 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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Failover: - dbms_dg.initiate_fs_failover  Allows an application to trigger a fast-start failover - shutdown abort  Crashing primary instance
  • 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.
  • 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
  • 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.
  • tps: transactions per second  number of commits (successful SQL) and rollbacks (aborted SQL) per second.  In sum, SQL statements per second. 
  • 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
  • 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
  • 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.
  • Two first steps can be done with netmgr
  • Two first steps can be done with netmgr
  • Two first steps can be done with netmgr
  • 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
  • ALTER SYSTEM SWITCH LOGFILE  force a log switch and archive the current online redo log file group.
  • 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.
  • High Availability And Oracle Data Guard 11g R2

    1. 2. High Availability and Oracle Data Guard 11g R2 Mario Redón Luz Student
    2. 3. Agenda <ul><li>Introduction to High Availability </li></ul><ul><li>Data Guard Concepts </li></ul><ul><li>Real examples </li></ul><ul><li>Demo </li></ul><ul><li>References </li></ul><Insert Picture Here>
    3. 4. <ul><li>“ … 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 . . .” </li></ul><ul><li>“ Six Years After 9/11, Most Firms Are Not Ready For Another Disaster”, Sep 11, 2007 </li></ul>What Forrester Research Is Saying
    4. 5. Even Companies Who Implement DR . . .using Traditional DR Technologies <ul><li>Are saddled with expensive, redundant systems </li></ul><ul><li>Under-utilize their standby resources </li></ul><ul><li>Have no immediate ROI until a disaster occurs </li></ul><ul><li>Lack confidence that it will work when needed </li></ul>
    5. 6. Introduction to High Availability Definition and characteristics <ul><li>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 </li></ul><ul><li>Characteristics of a highly available solution: </li></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Recoverability </li></ul></ul><ul><ul><li>Timely error detection </li></ul></ul><ul><ul><li>Continuous operation </li></ul></ul>
    6. 7. Introduction to High Availability Related concepts <ul><li>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 </li></ul><ul><li>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.) </li></ul><ul><li>RPO : maximum amount of data that an IT-based business process may lose without harm to the organization </li></ul>
    7. 8. Introduction to High Availability Causes of downtime <ul><li>Site failure </li></ul><ul><li>Clusterwide failure </li></ul><ul><li>Computer failure </li></ul><ul><li>Storage failure </li></ul><ul><li>Data corruption </li></ul><ul><li>Human error </li></ul><ul><li>Hang or slowdown </li></ul><ul><li>System and database changes </li></ul><ul><li>Data changes </li></ul><ul><li>Application changes </li></ul>Unplanned Planned
    8. 9. Introduction to High Availability Some data… <ul><li>Source: IOUG Survey on High Availability Trends </li></ul>
    9. 10. Introduction to High Availability Oracle HA Technologies
    10. 11. Data Guard Concepts <ul><li>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 </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>
    11. 12. Data Guard Concepts Primary and Standby Databases <ul><li>Primary : accesed by most applications, can be single-instance or RAC database </li></ul><ul><li>Standby: transactionally consistent copy of the primary database. Maintained automatically using redo data. Can be a single-instance or RAC database </li></ul>
    12. 13. Data Guard Concepts Types of Standby Databases: Physical Standby <ul><li>Provides a physically identical copy of the primary database </li></ul><ul><li>Synchronized through Redo Apply </li></ul><ul><li>Benefits: </li></ul>
    13. 14. Data Guard Concepts Types of Standby Databases: Physical Standby <ul><li>Provides a physically identical copy of the primary database </li></ul><ul><li>Synchronized through Redo Apply </li></ul><ul><li>Benefits: </li></ul>
    14. 15. Data Guard Concepts Types of Standby Databases: Logical Standby <ul><li>Contains the same logical information as the production database although the physical organization and structure of the data can be different </li></ul><ul><li>Synchronized through SQL Apply </li></ul><ul><li>Auxiliar structures can be created to optimize the reporting workload </li></ul><ul><li>Some restrictions on datatypes, types of tables, and types of DDL and DML operations </li></ul><ul><li>Benefits: </li></ul><ul><ul><li>Switchover and failover </li></ul></ul><ul><ul><li>Reduce the amount of queries performed on the primary database </li></ul></ul><ul><ul><li>Can be used to upgrade Oracle Database software and patch sets with almost no downtime </li></ul></ul>
    15. 16. Physical Standby vs Logical Standby
    16. 17. Data Guard Concepts Types of Standby Databases: Snapshot Standby <ul><li>It’s a physical standby database that is temporarily converted into an updatable standby database </li></ul><ul><li>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 </li></ul><ul><li>Typically diverges from the primary database over time </li></ul><ul><li>Redo data from the primary database is not applied until you convert the snapshot standby database </li></ul><ul><li>Benefits: </li></ul><ul><ul><li>Development and testing purposes </li></ul></ul>
    17. 18. Data Guard Concepts Reader farms - RAC
    18. 19. Data Guard Concepts Reader farms – Single Instance
    19. 20. Data Guard Concepts Role transitions <ul><li>Operation used to change from primary to standby and viceversa. </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>
    20. 21. Data Guard Concepts Protection modes <ul><li>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 </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>
    21. 22. Data Guard Concepts New features in 11 g releases <ul><li>Heterogeneus Data Guard Configuration </li></ul><ul><li>Real-Time Query Capability of Physical Standby Database </li></ul><ul><li>User Configurable Conditions to Initiate Fast-Start Failover </li></ul><ul><li>Added Snapshot Standby </li></ul><ul><li>Transport of Redo Data using SSL </li></ul><ul><li>Support TDE with Data Guard SQL Apply </li></ul><ul><li>Compressed Table Support in Logical Standby Databases </li></ul><ul><li>Integrated Support for Application Failover </li></ul><ul><li>Support Up to 30 Standby Databases </li></ul>11 g R1 11 g R2
    22. 23. How redo is transported...
    23. 24. ... and applied
    24. 25. What Data Guard can be used for?
    25. 26. <Insert Picture Here> Real examples
    26. 27. Amazon.com experience Data-Guard Fast-Start Failover
    27. 28. Benchmarks Not using Data Guard
    28. 29. Benchmarks Using Data Guard
    29. 30. Benchmarks Using Data Guard + RAC
    30. 31. Volkswagen AG Oracle Streams and Data Guard
    31. 32. <Insert Picture Here> Demo
    32. 33. Initial environment… Oracle VM 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
    33. 34. ... and after thinking Oracle Enterprise Linux 5.3 Oracle Database 11.2 - orcl Oracle Database 11.2 - orclstby 800 MB 800 MB 1 GB No resources problems
    34. 35. Setup <ul><li>Enable force logging </li></ul><ul><ul><li>SQL> ALTER DATABASE FORCE LOGGING </li></ul></ul><ul><li>Configure database to receive redo data (x4) </li></ul><ul><ul><li>SQL> ALTER DATABASE ADD STANDBY LOGFILE </li></ul></ul><ul><li>Configure database initialization parameters </li></ul><ul><ul><li>SQL> ALTER SYSTEM SET </li></ul></ul><ul><ul><li>LOG_ARCHIVE_CONFIG=‘dg_config=(orcl,orclstby)’ </li></ul></ul><ul><ul><li>SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=‘service= orclstby ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=orclstby’ </li></ul></ul><ul><li>Put the primary database in ARCHIVELOG mode </li></ul><ul><ul><li>SQL> ALTER DATABASE ARCHIVELOG </li></ul></ul>
    35. 36. Creating the physical standby database <ul><li>Create an Oracle Net service name for the physical standby database in tnsnames.ora </li></ul><ul><ul><li>ORCLSTBY = </li></ul></ul><ul><ul><li>(DESCRIPTION = </li></ul></ul><ul><ul><li>(ADDRESS_LIST = </li></ul></ul><ul><ul><li>(ADDRESS = (PROTOCOL = TCP)(HOST = mredon-es.us.oracle.com)(PORT = 1521)) </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>(CONNECT_DATA = </li></ul></ul><ul><ul><li> (SERVER = DEDICATED) </li></ul></ul><ul><ul><li>(SERVICE_NAME = orclstby) </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>) </li></ul></ul>
    36. 37. Creating the physical standby database <ul><li>Configure an entry for the standby database in listener.ora </li></ul><ul><ul><li>SID_LIST_LISTENER = </li></ul></ul><ul><ul><li>(SID_LIST = </li></ul></ul><ul><ul><li>(SID_DESC = </li></ul></ul><ul><ul><li>(GLOBAL_DBNAME = orclstby) </li></ul></ul><ul><ul><li>(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) </li></ul></ul><ul><ul><li>(SID_NAME = orclstby) </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>) </li></ul></ul>
    37. 38. Creating the physical standby database <ul><li>Create the standby database </li></ul><ul><ul><li>$> lsnrctl reload </li></ul></ul><ul><ul><li>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 . </li></ul></ul><ul><ul><li>Go to $ORACLE_HOME/dbs and create initorclstby.ora with a single line containing DB_NAME=orclstby </li></ul></ul><ul><ul><li>Go to /u01/app/oracle/admin and create orclstby directory, get into it and create adump folder. </li></ul></ul><ul><ul><li>Create a directory named orclstby in $ ORACLE_BASE/oradata and in $ORACLE_BASE/flash_recovery_area </li></ul></ul>
    38. 39. Creating the physical standby database <ul><li>On the standby system: </li></ul><ul><ul><li>Set ORACLE_SID=orclstby </li></ul></ul><ul><ul><li>Login into SQL*Plus and execute: </li></ul></ul><ul><ul><li>SQL> startup nomount pfile=$ORACLE_HOME/dbs/initorclstby.ora </li></ul></ul><ul><li>On the primary system: </li></ul><ul><ul><li>Ensure $ORACLE_SID is set to the one of the primary database ( orcl ) </li></ul></ul><ul><ul><li>RMAN> CONNECT TARGET sys </li></ul></ul><ul><ul><li>RMAN> CONNECT AUXILIARY sys@orclstby </li></ul></ul><ul><li>Now, we are able to execute the script of the following slide </li></ul>
    39. 40. Creating the physical standby database <ul><li>run { </li></ul><ul><li>allocate channel prmy1 type disk; </li></ul><ul><li>allocate channel prmy2 type disk; </li></ul><ul><li>allocate channel prmy3 type disk; </li></ul><ul><li>allocate channel prmy4 type disk; </li></ul><ul><li>allocate auxiliary channel stby type disk; </li></ul><ul><li>duplicate target database for standby from active database </li></ul><ul><li>spfile </li></ul><ul><li>parameter_value_convert 'orcl','orclstby' </li></ul><ul><li>set db_unique_name='orclstby' </li></ul><ul><li>set db_file_name_convert='/orcl/','/orclstby/' </li></ul><ul><li>set log_file_name_convert='/orcl/','/orclstby/' </li></ul><ul><li>set log_archive_max_processes='5' </li></ul><ul><li>set fal_client='orclstby' </li></ul><ul><li>set fal_server='orcl' </li></ul><ul><li>set standby_file_management='AUTO' </li></ul><ul><li>set log_archive_config='dg_config=(orcl,orclstby)' </li></ul><ul><li>set log_archive_dest_1='service=orcl ASYNC </li></ul><ul><li>valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=orcl‘ </li></ul><ul><li>; </li></ul><ul><li>} </li></ul>
    40. 41. Verify the standby database is performing correctly <ul><li>On the standby database: </li></ul><ul><ul><li>SQL> SELECT sequence#, first_time, next_time </li></ul></ul><ul><ul><li>FROM v$archived_log </li></ul></ul><ul><ul><li>ORDER BY sequence#; </li></ul></ul><ul><li>On the primary database: </li></ul><ul><ul><li>SQL> ALTER SYSTEM SWITCH LOGFILE </li></ul></ul><ul><li>On the standby database, issue this SQL statement to verify the redo data was received and archived on the standby database </li></ul><ul><ul><li>SQL> SELECT sequence#, first_time, next_time, applied </li></ul></ul><ul><ul><li>FROM v$archived_log </li></ul></ul><ul><ul><li>ORDER BY sequence#; </li></ul></ul>
    41. 42. Creating a DG Broker Configuration <ul><li>Set the DG_BROKER_START initialization parameter to TRUE for your primary database and physical standby database </li></ul><ul><ul><li>SQL > ALTER SYSTEM SET dg_broker_start=TRUE </li></ul></ul><ul><li>Create the services for the listener and reload it </li></ul><ul><ul><li>(SID_DESC = </li></ul></ul><ul><ul><li>(GLOBAL_DBNAME = orclstby_DGMGRL) </li></ul></ul><ul><ul><li>(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) </li></ul></ul><ul><ul><li>(SID_NAME = orclstby) </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>(SID_DESC = </li></ul></ul><ul><ul><li>(GLOBAL_DBNAME = orcl_DGMGRL) </li></ul></ul><ul><ul><li>(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) </li></ul></ul><ul><ul><li>(SID_NAME = orcl) </li></ul></ul><ul><ul><li>) </li></ul></ul>
    42. 43. Creating a DG Broker Configuration <ul><li>Invoke DGMGRL and connect to your primary database </li></ul><ul><ul><li>DGMRL> connect sys </li></ul></ul><ul><li>Create the broker configuration including a profile for the primary database </li></ul><ul><ul><li>DGMGRL> create configuration ‘DGConfig1’ as </li></ul></ul><ul><ul><li>primary database is ‘orcl’ </li></ul></ul><ul><ul><li>connect identifier is orcl; </li></ul></ul><ul><li>Add your physical standby database to the broker configuration. </li></ul><ul><ul><li>DGMGRL> add database ‘orclstby’ as </li></ul></ul><ul><ul><li>connect identifier is orclstby; </li></ul></ul><ul><li>Enable the entire configuration. This may take some time to complete </li></ul><ul><ul><li>DGMGRL> enable configuration </li></ul></ul><ul><li>Verify that the configuration was successfully enabled </li></ul><ul><ul><li>DGMGRL> show configuration </li></ul></ul>
    43. 44. Reading data from the standby database Using Active Data Guard option <ul><li>In the standby database, set up Active Data Guard mode: </li></ul><ul><ul><li>DGMGRL> edit database ‘orclstby’ set state=‘apply-off’; </li></ul></ul><ul><ul><li>SQL> ALTER DATABASE OPEN READ ONLY </li></ul></ul><ul><ul><li>DGMGRL> edit database ‘orclstby’ set state=‘apply-on’; </li></ul></ul><ul><li>Query the HR.REGIONS table in the standby database </li></ul><ul><li>Insert a row in the HR.REGIONS table in the primary database and commit the transaction </li></ul><ul><li>Query the HR.REGIONS table in the standby database and check a new row has appeared </li></ul>
    44. 45. Enabling Fast Start Failover <ul><li>Enable flashback on primary database: </li></ul><ul><ul><li>SQL> ALTER DATABASE FLASHBACK ON </li></ul></ul><ul><li>Enable flashback on standby database: </li></ul><ul><ul><li>DGMGRL> edit database ‘orclstby’ set state=‘apply-off’; </li></ul></ul><ul><ul><li>SQL> ALTER DATABASE FLASHBACK ON </li></ul></ul><ul><ul><li>DGMGRL> edit database ‘orclstby’ set state=‘apply-on’; </li></ul></ul><ul><li>Enable Fast Start Failover: </li></ul><ul><ul><li>DGMGRL> enable fast_start failover </li></ul></ul><ul><li>Check configuration </li></ul><ul><ul><li>DGMGRL> show fast_start failover </li></ul></ul><ul><ul><li>DGMGRL> show database orcl </li></ul></ul><ul><ul><li>DGMGRL> show database orclstby </li></ul></ul>
    45. 46. Performing a switchover <ul><li>Initiate the switchover to the standby database </li></ul><ul><ul><li>DGMGRL> switchover to orclstby </li></ul></ul><ul><li>Check changes in the configuration </li></ul><ul><ul><li>DGMGRL> show configuration </li></ul></ul><ul><ul><li>SQL> SELECT database_role FROM v$database; </li></ul></ul><ul><li>Switchover to the original situation </li></ul><ul><ul><li>DGMGRL> switchover to orcl </li></ul></ul><ul><li>Check the new roles </li></ul><ul><ul><li>DGMGRL> show configuration </li></ul></ul><ul><ul><li>SQL> SELECT database_role FROM v$database; </li></ul></ul>
    46. 47. References <ul><li>ENISA - Risk Assessment Methods </li></ul><ul><li>CCN Cert </li></ul><ul><li>Oracle Database High Availability Overview 11 g Release 2 </li></ul><ul><li>Oracle Open World MAA Presentations </li></ul><ul><li>Oracle Data Guard Concepts and Administration 11 g Release 1 </li></ul><ul><li>Oracle Data Guard Concepts and Administration 11 g Release 2 </li></ul><ul><li>Oracle By Example Series: Data Guard </li></ul><ul><li>Oracle Online Demos: 11g R2 Data Guard Series </li></ul>
    47. 48. <Insert Picture Here> Any questions? Thanks for your time!

    ×