Oracle 11g -Snapshot Standby and Active Data Guard

1. Oracle 11g -Snapshot Standby and Active Data Guard

2. Topic Coverage • Concepts and Basics • Redo logs, archive logs and standby redo logs • Attributes of log_archive_dest for standby • Standby Protection modes • Redo transport services, Redo apply services, Gap resolution • 10g/11g Snapshot standby • 11g Active data guard

3. Concepts and Basics

4. History of Standby database

5. Online Redo Log files, Archive log files and Standby Redo Logfiles Online redo log file (ORL) - Contains persistently stored changed redo records. - Redo records in the log files are stored in SCN sequential order—that is, the order in which redo was written. - When ORL are full, they become archived to the archive redo logs. Archived redo log file - Archived versions of online redo logs. - These files are archived by the archive processes to one or more defined log archive destinations. Standby redo log file (SRL) • are used to store redo data received from another database. • are structurally identical to redo logs, and are created and managed using the same SQL statements used to create and manage redo logs. • Less data loss in failover situations than without Standby Redo Logs. • Are only used if you have the LGWR activated for archival to the Remote Standby Database. Hence are necessary for Real time log apply.

6. Standby redo log file (SRL)… cont Assume Primary database - two redo log groups with one member each. Logfile size 500 MB Then in this case, Standby Database - at least 3 standby redo log groups to satisfy the requirement that a standby redo log must have at least one more redo log group than the redo log groups at the primary database.

7. Redo Transport Modes Synchronous Asynchronous (default) • 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. • Used by the Maximum Protection and Maximum Availability modes • 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. • Used by the Maximum Performance mode

8. Synchronous Redo Transport Mode • The user commits a transaction creating a redo record. The LGWR reads the redo record from the log buffer, writes it to the online redo log file, and waits for confirmation from the LNS. • The LNS reads the same redo record from the log buffer and transmits it to the standby database using Oracle Net Services. The RFS receives the redo at the standby database and writes it to a standby redo log file. • When the RFS receives a write-complete from the disk, it transmits an acknowledgment back to the LNS process on the primary database, which in turn notifies the LGWR that transmission is complete. The LGWR then sends a commit acknowledgment to the user.

9. Myth Buster: LGWR Transmits Redo to Standby Databases A common misconception is that the LGWR is the process that transmits data to a standby database. This is not the case. The LNS process manages all synchronous and asynchronous redo transmissions. Eliminating this perception is the reason why the Data Guard 11g documentation simply refers to the redo transport methods as SYNC or ASYNC, rather than LGWR SYNC or LGWR ASYNC as was done in previous releases. LNS The LogWriter Network Service (LNS) reads the redo being flushed from the redo buffers by the LGWR and performs a network send of the redo to the standby site. The main purpose of the LNS process is to alleviate the LGWR process from performing the redo transport role.

10. Asynchronous Redo Transport Mode • LGWR does not wait for acknowledgment from the LNS i.e. LGWR will continue to acknowledge commit success even if the redo of previous transactions is delayed/not sent (due to some reasons) to the standby database immediately . • If the LNS is unable to keep pace and the log buffer is recycled before the redo can be transmitted to the standby, the LNS automatically transitions to reading and sending from the ORL (Data Guard 11g onward). Once the LNS has caught up, it automatically transitions back to reading/sending directly from the log buffer.

11. Few attributes of log_archive_dest_n attributes • AFFIRM and NOAFFIRM: AFFIRM - specifies that a redo transport destination acknowledges received redo data after writing it to the standby redo log. NOAFFIRM - specifies that a redo transport destination acknowledges received redo data before writing it to the standby redo log. • VALID_FOR VALID_FOR=(redo_log_type,database_role) redo_log_type keyword can assume following values: • ONLINE_LOGFILE—This destination is valid only when archiving ORL files. • STANDBY_LOGFILE—This destination is valid only when archiving SRL files. • ALL_LOGFILES— This destination is valid when archiving either online redo log files or standby redo log files. database_role keyword identifies the role in which this destination is valid for archiving: • PRIMARY_ROLE—This destination is valid only when the database is running in the primary role. • STANDBY_ROLE—This destination is valid only when the database is running in the standby role. • ALL_ROLES—This destination is valid when the database is running in either the primary or the standby role. Default: (ALL_LOGFILE,ALL_ROLES)

12. Few attributes of log_archive_dest_n attributes… cont • REOPEN Specifies the minimum number of seconds before redo transport services should try to reopen a failed destination. • COMPRESSION Specifies whether redo data is transmitted to a redo transport destination in compressed form or uncompressed form when resolving redo data gaps. NOTE: Redo transport compression is a feature of the Oracle Advanced Compression option. You must purchase a license for this option before using the redo transport compression feature. • SYNC and ASYNC

13. Why Isn’t ARCH Redo Transport mentioned in the Data Guard 11g Documentation? Three redo transport methods were documented prior to Data Guard 11g: SYNC, ASYNC, and ARCH. ARCH refers to traditional archive log shipping, in which Data Guard would wait for an ORL to be archived before the contents of the resulting archive log file where shipped by an ARCH process. Data Guard 11g ASYNC performance enhancements have led Oracle to deprecate ARCH as a documented redo transport method. Though deprecated, the functionally still exists to use ARCH for redo transport and provide backward compatibility for previous customer installations. The ARCH transport infrastructure also continues to be used transparently by Data Guard 11g when automatically resolving archive log gaps between primary and standby databases. Your presentation title goes here

14. Primary Standby ORL SRL COMMIT Modes • Max Protection

15. Standby Primary ORL SRL Fault preventing rdo to be written to standby COMMIT Max Availability Max Performance fault corrected and archive gaps resolved • Max Availability

16. Standby Primary ORL SRL COMMIT • Max Performance Command to put standby database in one of the protection modes:

17. The protection modes in the order from highest (most data protection) to the lowest (least data protection):     Yes

18. Redo apply services at standby Real time redo apply services

19. Automatic Gap resolution Your presentation title goes here

20. Automatic Gap resolution • ARCH process on primary continuously pings the standby during outage to determine its status. • When communication with the standby is restored, the ARCH ping process queries the standby control file (via its RFS process) to determine the last complete log file that the standby received from the primary database. • It determines which log files are required to resynchronize the standby database and immediately begins transmitting them using additional ARCH processes. Simultaneously, at the very next log switch, the LNS will attempt and succeed in making a connection to the standby database and will begin transmitting current redo while the ARCH processes resolve the gap in the background. • Once the standby apply process is able to catch up to current redo records, the apply process automatically transitions out of reading from archived redo logs, and into reading from the current SRL (assuming the user has configured Data Guard real-time apply). • Beginning with Data Guard 10g, one ARCH process at the primary database is always dedicated to local archival to ensure that remote archival during gap resolution does not impact the ability of the primary to recycle its ORLs.

21. Dataguard components (Recap)

22. Redo transport Security Enhancements in 11g • Redo Transport Authentication Using a Password File • By default password of SYS is used to authenticate redo transport sessions • 11g onwards, we can also specify a user other than SYS for redo transport authentication using REDO_TRANSPORT_USER init parameter • This user should have SYSOPER privileges • Requires password for this user to be the same at primary and all standbys • REDO_TRANSPORT_USER parameter be set to the same value on both primary and all standbys Your presentation title goes here

23. Snapshot standby

24. Snapshot standby Features: • Fully updateable standby • Provides disaster recovery and data protection • Requires Flashback database • Simplified Single command in 11g Differences f

27. Steps to convert Physical Standby Database to the Snapshot Standby Database

28. Steps to convert the Snapshot Standby Database to the Physical Standby Database Limitations Flashback Database is used to convert a snapshot standby database back into a physical standby database. Any operation that cannot be reversed using Flashback Database technology will prevent a snapshot standby from being converted back to a physical standby.

29. Using Grid control

30. Benefits • Reduced database licensing costs Since we can now easily transform a physical standby database from its disaster recovery mode into application testing mode, this translates into one less Oracle 11g database that needs to be licensed. • Reduced hardware costs One less Oracle database also means one less database server • Real Application Testing A snapshot standby database is a perfect complement to Oracle 11g’s new Real Application Testing suite because it’s an excellent platform on which to replay a previously-recorded workload.

31. Active standby database

32. Difference: 11g Active and Snapshot standby Active Standby • Read Only - redo from primary received and applied Snapshot Standby • Read Write - redo from primary received but not applied • Redo applied when snapshot standby database is converted back to physical standby Note: Both Active Data Guard and Snapshot standby require a physical standby database in place

33. What is Active Data Guard? • Introduced in 11g Release 1 • Available in the database server Enterprise Edition as an additional license option • Real time replica of a production database which is open in read only mode while changes transmitted from the primary database are being simultaneously applied to it. • Applies to physical and not logical standby database • Can offload reporting, queries and fast incremental backups from the primary site to the standby site improving the performance. • Performs its primary Data Guard objective of preventing data loss and downtime due to data corruptions, database and site failures, human error, or natural disaster. • Automatically repair block corruptions online from Primary and for Primary

34. Active data guard

35. Block corruption error SQL> select * from monitor.emp; select * from monitor.emp * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 5, block # 188) ORA-01110: data file 5: '/u02/oradata/apex/monitor_data01.dbf' Corrupt block relative dba: 0x018005da (file 5, block 188) Fractured block found during user buffer read Data in bad block: type: 6 format: 2 rdba: 0x018005da last change scn: 0x0000.001b3ebf seq: 0x2 flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x00000000 check value in block header: 0x1b14 computed block checksum: 0xb2a8 Reading datafile '/u01/oracle/testdr01.dbf' for corruption at rdba: 0x018005da (file 5, block 188) Reread (file 5, block 188) found same corrupt data Requesting Auto BMR for (file# 5, block# 188) Waiting Auto BMR response for (file# 5, block# 188) Auto BMR successful Alert.log file extract

36. Active Data Guard Usage • Offload Read-Only Queries and Reporting • Read-only queries and reports can be offloaded from the primary to the standby database, reducing I/O and CPU consumption and improving quality of service for read-write transactions on primary • Should the primary database fail, data is protected at the standby and failover is immediate because the standby database is completely up-to-date. • Offload Backups • Includes ability to use RMAN block change tracking and perform fast, online, incremental backups of your physical standby database. • Because backups taken on a physical standby can be used to restore either the primary or standby databases, it is no longer necessary to perform backups on the primary, freeing system resources to process critical transactions. (assuming same storage structure) Your presentation title goes here

37. Active Data guard – Operations Permitted We can do • Issue SELECT statements • Issue complex queries such as grouping SET queries and WITH clause queries • Call stored procedures • Use database links to write to remote databases • Use stored procedures to call remote procedures via dblinks Active Data guard – Operations Permitted We cannot do • Any DML excluding SELECT • Any DDL • So no additional indexes allowed • AWR tool not supported for Active DG standby Your presentation title goes here

38. ON ACTIVE STANDBY SQL> select getsal('KING') from dual; GETSAL('KING') ---------------- 5000 SQL> select getsal_remote ('KING') from dual; -- getsal_remote is synonym for getsal@dblink GETSAL_REMOTE('KING') --------------------- 5000 SQL> create table mytab 2 (col_a number); create table mytab * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-16000: database open for read-only access SQL> delete from scott.emp; delete from scott.emp * ERROR at line 1: ORA-16000: database open for read-only access

39. SQL> select database_role from v$database; DATABASE_ROLE -------------------------- PHYSICAL STANDBY SQL> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY WITH APPLY SQL> INSERT INTO dept@mylink --remote database 2 VALUES (50,'I.T','HOUSTON'); 1 row created. SQL> commit; Commit complete. SQL> UPDATE dept@mylink -- remote database 2 SET LOC='DALLAS‘ 3 WHERE LOC='HOUSTON'; 1 row updated.

40. Enabling Active data guard If the standby database is not running (note in 11g, STARTUP command will start standby in read-only mode) If standby database is running and managed recovery in operation

41. Guaranteed SLA’s for read-only users • New with Data Guard 11g Release 2 • Active Data Guard service level agreements (SLA) can be implemented using the session parameter, STANDBY_MAX_DATA_DELAY (NONE, NON-ZERO, ZERO) • Specifies a limit for the amount of time (in seconds) allowed to elapse between when changes are committed on the primary and when they can be queried on an active standby database • The active standby will return an ORA-3172 error code if the limit is exceeded. • Applications can handle this error and redirect queries to the primary database

42. Guaranteed SLA’s for read-only users…cont

43. Guaranteed SLA’s for read-only users…cont Your presentation title goes here

44. Guaranteed SLA’s for read-only users…cont Your presentation title goes here

45. Monitoring Active Data Guard • Query SCN on Standby is equivalent to CURRENT SCN on primary • View V$DATAGUARD_STATS to monitor “apply lag” as well as “transport lag”