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

2. Topic Coverage Concepts and Basics 10g/11g Snapshot standby
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.
Redo change vectors A change vector describing a single change to a single data block.
Redo record A collection or group of change vectors that describe an atomic change. The term atomic means that this group of changed blocks is either all successful or all unsuccessful during recovery.
Standby Redo Logs are only supported for the Physical Standby Database in Oracle 9i and as well for Logical Standby Databases in 10g.
The great Advantage of Standby Redo Logs is that every Entry written into the Online RedoLogs of the Primary Database is transfered to the Standby Site and written into the Standby Redo Logs at the same time; Therefore, you reduce the probability of Data Loss on the Standby Database.
In case you do not have Standby Redo Logs, an Archived Redo Log is created by the RFS process and when it has completed, this Archived Redo Log is applied to the Standby Database by the MRP (Managed Recovery Process). An open (not fully written) ArchiveLog file cannot be applied on the Standby Database and will not be used in a Failover situation. This causes a certain data loss.
Limitations: 1.) should be of same size as ORL otherwise RFS doesn’t attach the SRLs with ORLs 2.) LGWR has to be the transmitter on primary (9i). 10g onwards even ARCH process can write to SRLs

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.
Usage, Benefits and Limitations of Standby Redo Logs (SRL) [ID ]

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. VALID_FOR=(redo_log_type,database_role)
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)
The VALID_FOR attribute is used to specify when redo transport services transmits redo data to a redo transport destination. Oracle recommends that the VALID_FOR attribute be specified for each redo transport destination at every site in a Data Guard configuration so that redo transport services will continue to send redo data to all standby databases after a role transition, regardless of which standby database assumes the primary role.
The REOPEN attribute is used to specify the minimum number of seconds between automatic reconnect attempts to a redo transport destination that
is inactive because of a previous error.
The COMPRESSION attribute is used to specify that redo data is transmitted to a redo transport destination in compressed form. Redo transport compression can significantly improve redo transport performance on network links with low bandwidth and high latency.

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. Modes Max Protection ORL SRL COMMIT Primary Standby Max Protection
provides the highest protection mode that guarantees no data loss if primary database fails.
To achieve this, the redo data needed to recover each transaction must be written to both the local (online) redo log and to a standby redo log on at least one standby database before the transaction can be committed.
In order to guarantee no loss of data, the primary database will shut down if a fault prevents it from writing its redo data to at least one remote standby redo log.

15. Max Availability ORL SRL COMMIT Primary Standby Max Availability
provides the highest level of data protection that is possible without affecting the availability of the primary database.
Similar to maximum protection but unlike maximum protection mode, the primary database will not shut down if a fault prevents it from writing its redo data to a remote standby redo log.
Instead, the primary database will operate in maximum performance mode until the fault is corrected and all log gaps have been resolved. After all log gaps have been resolved, the primary database automatically resumes operating in maximum availability mode.
Max Availability
Max Performance
Fault preventing rdo to be written to standby
fault corrected and archive gaps resolved

16. Max Performance ORL SRL COMMIT Primary Standby
Is the default protection mode
Provides the highest level of data protection that is possible without affecting the performance or availability of the primary database.
With this protection mode, a transaction is committed as soon as the redo data needed to recover the transaction is written to the local (online) redo log.
Can be achieved by configuring the LOG_ARCHIVE_DEST_n for standby destination to use either LGWR / ASYNC or ARCH as log transport service.
Using this configuration, the primary database writes its redo stream to the standby database asynchronously with respect to the commitment of the transactions that create the redo data. When the nodes are connected with sufficient bandwidth, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database 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
Chapter 3 – Larry Carpenter
When redo is received by an RFS on the standby system, the RFS process writes the redo data to archived redo logs or optionally to the SRL. Since Oracle Database 10g, with RTA, which requires SRL, the Redo Apply will automatically apply redo directly from the SRL.
The following command is used to enable the real-time apply feature in physical standby databases. This command is issued on the standby site:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Keep in mind that if SRLs are not defined when enabling real-time apply, the user will receive an ORA error message.
To determine whether real-time apply is enabled, query the RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view. If the recovery mode indicates MANAGED REAL TIME APPLY, then real-time apply is enabled.
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2; RECOVERY_MODE MANAGED REAL-TIME APPLY
In some cases, the redo rate becomes too high and the apply process is unable to keep up with real-time apply. In these scenarios, the MRP (or LSP) automatically performs the redo apply using the archive redo log files. When the redo rate has subsided, the apply will again resume real-time apply using the SRL.
Advantage
With the advent of real-time apply, Data Guard now provides faster switchover, instant data access, and reporting for read-only (Active Data Guard) physical standby databases.
Real-time apply is particularly important for Active Data Guard and logical standby databases as it enables real-time reporting

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)
LNS Runs on primary database. It reads the redo information directly from redo log buffer in SGA and ships it to standby databases with the help of Oracle Net Services

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
When a password file is used for redo transport authentication, the password of the user account used for redo transport authentication is compared between the database initiating a redo transport session and the target database. The password must be the same at both databases to create a redo transport session.
Your presentation title goes here

23. Snapshot standby

24. Snapshot standby Differences Features: Fully updateable standby
Provides disaster recovery and data protection
Requires Flashback database
Simplified Single command in 11g
Differences
11g Using Snapshot Standby Database. [ID ]
1.) Allows the  use of a physical standby database in read write mode for a short period of time hence we can say it is A fully update-able standby database that is created by converting a physical standby database into a snapshot standby database.
2.) A snapshot Standby is open in the read-write mode and hence it is possible to process transactions independently of the primary database. At the same time, it maintains protection by continuing to receive data from the production database, archiving it for later use.
3.) You should enable the flashback database to use this feature. We will see in a short time WHY?
4.) Using a single command, changes made while read-write mode can be discarded and quickly resynchronize the standby with the primary database.
1.) Snapshot standby database receives and archives, but does not apply the redo data. Redo data received from the primary database is applied automatically once it is converted back into a physical standby database. 
2.) Data from the primary database is always protected as the archives are being received and stored in place.
3.) All local updates will be discarded when snapshot database is converted back to physical standby database. 
4.) If the primary database moves to new database branch (for example, because of a Flashback Database or an OPEN RESETLOGS), the snapshot standby database will continue accepting redo from new database branch. 
5.) Snapshot standby database cannot be the target of a switchover or failover. A snapshot standby database must first be converted back into a physical standby database before performing a role transition to it. 
6.) After a switchover or failover between the primary database and one of the physical or logical standby databases in a configuration, the snapshot standby database can receive redo data from the new primary database after the role transition. 
7.) Snapshot standby database cannot be the only standby database in a Maximum Protection Data Guard configuration. f

25. Preparing physical standby - Setting up flashback if not already set
Preparing primary  alter system archive log current; alter system set log_archive_dest_2=DEFER; Alter system switch logfile
Creating guaranteed restore point  Cancelling recovery mode, create restore point before_open_standby guarantee flashback database;
Converting physical to primary  alter database activate standby database; startup mount force;
Flashback to restore point and convert standby back to physical standby  STARTUP MOUNT FORCE; FLASHBACK DATABASE TO RESTORE POINT before_open_standby; ALTER DATABASE CONVERT TO PHYSICAL STANDBY; STARTUP MOUNT FORCE;

26. Execute ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;.
Execute ALTER DATABASE CONVERT TO PHYSICAL STANDBY;.

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
An implicit guaranteed restore point is created SNAPSHOT_STANDBY_REQUIRED_MM/DD/YYYY HH:MM:SS when a physical standby database is converted into a snapshot standby database and this restore point is used to flashback a snapshot standby to its original state when it is converted back into a physical standby database.
Once a snapshot standby database has been converted back into a physical standby database and restarted, Redo Apply can be started and all redo received by the snapshot standby database will be applied 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 24*7 book Suresh slide
section 5.4.1
Oracle Active Data Guard option

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'
Alert.log file extract
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: 0x b3ebf seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x
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
Any corrupt data block encountered when a primary database is accessed is automatically replaced with an uncorrupted copy of that block from a physical standby database operating in real-time query mode and vice-a-versa

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_REMOTE('KING')
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

39. SQL> select database_role from v$database;
PHYSICAL STANDBY
SQL> select open_mode from v$database;
OPEN_MODE
READ ONLY WITH APPLY
SQL> INSERT INTO --remote database
VALUES (50,'I.T','HOUSTON');
1 row created.
SQL> commit;
Commit complete.
SQL> UPDATE -- remote database
SET LOC='DALLAS‘
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
NONE = queries will be executed regardless of the apply lag on that database.
Non-zero = queries will be executed only if the apply lag is less than or equal to STANDBY_MAX_DATA_DELAY.
• If delay setting exceeded an error is returned
– Application then decides what to do.
Zero = queries guaranteed to return the exact same result as if the query were issued on the primary database
otherwise the ORA is returned
– Requires Maximum Availability and Real-Time Apply
The new STANDBY_MAX_DATA_DELAY session parameter can be used to specify a session-specific apply lag tolerance, measured in seconds, for queries issued by non-administrative users to a physical standby database that is in real-time query mode.

42. Guaranteed SLA’s for read-only users…cont
ALTER SESSION SYNC WITH PRIMARY

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”