High Availability And Oracle Data Guard 11g R2

Editor's Notes

1. 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
2. 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.
3. 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
4. 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
5. 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
6. 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
7. 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
8. 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
9. Failover: - dbms_dg.initiate_fs_failover  Allows an application to trigger a fast-start failover - shutdown abort  Crashing primary instance
10. 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.
11. 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
12. 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.
13. tps: transactions per second  number of commits (successful SQL) and rollbacks (aborted SQL) per second.  In sum, SQL statements per second. 
14. 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
15. 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
16. 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.
17. Two first steps can be done with netmgr
18. Two first steps can be done with netmgr
19. Two first steps can be done with netmgr
20. 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
21. ALTER SYSTEM SWITCH LOGFILE  force a log switch and archive the current online redo log file group.
22. 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.