1. Oracle 12c Data Guard – Far Sync and what’s new
Author & Presenter: Nassyam Basha
Date: 18-DEC-2014

2. Nassyam Basha Post Graduation in computers from University of Madras
Oracle Database Pythian
Frequent OTN contributor (CKPT) /MOSC certified GURU
Co-Author of Oracle 11gR2 Data Guard administration beginners Guide
Blogger
Author of OTN Articles
11g Oracle Certified Master
Co-Founder of
@nassyambasha
/nassyambasha
© 2014 Pythian

3. Oracle Data Guard Evolution
7.x
Now lets See
Managed standby Database 8i
11g
Read-only Physical standby database
Managed Recovery of standby
Remote archiving of redo log files
ADG, Heterogeneous Platform support
Snapshot Standby , Rolling Upgrade, Tuning Reports 9i
10g
Logical standby database
Integrated zero data loss
Broker, Switchover & Failover
Automatic GAP resolution
Cascade redo log destinations
Real-Time Apply, Simplified Configuration, SRL Support with Logical standby database, FSFO, Flashback database over Data Guard
© 2014 Pythian

4. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

5. Quick look at Protection modes – 12c
Maximum Performance:
Works as independent database
(ASYNC/NOAFFIRM)
Oracle no longer recommends ARCH transport
Maximum Protection:
Highest level of data protection, No data loss
Must recommended to have more than one standby database.
(SYNC/AFFIRM)
Maximum Availability(11g/12c):
Flexibility to run in Maximum Protection and Maximum Performance
(SYNC/AFFIRM) - Maximum protection in maximum Availability
(SYNC/NOAFFIRM) – Maximum performance with maximum Availability
MAX_PERFORMANCE
MAX_PROTECTION
MAX_AVAILABILITY
ASYNC
SYNC
NOAFFIRM
AFFIRM
AFFIRM/NOAFFIRM
Maximum Performance : This mode is the default protection mode and the log transport service must use the ASYNC mode with the LGWR or ARCH attribute. with 11g, ARCH transport is not recommended because it doesn't offer any advantage in terms of performance, and offers less data protection. (ASYNC) Maximum performance doesn’t bother of standby database whether redo is been sent to standby or even received or even applied..
There are not so many changes with protection mode except Maximum availability in 12c.
From 12c Maximum availability supports only AFFIRM earlier, now it supports to NOAFFIRM as well.
Just changing of redo transport attributes doesn’t perform protection level, You have to manually convert protection mode.
What are new changes in 12c? – Max availability
The NET_TIMEOUT parameter allows the LGWR on the primary database to wait for the specified time in the parameter for the RFS on the standby server to send an acknowledgement to the LGWR on the primary database saying that the log has been applied to the standby database and finally commits the ongoing transaction. If the LGWR in primary does not receive the acknowledgement within the NET_TIMEOUT period, then it would go ahead with the commitment and starts behaving in as the Maximum Performance Mode. Once the standby is up, it automatically gets the logs from the online redo logs of the primary database.
The Maximum Availability mode is the data protection mode that has the ability to run as a Maximum Protection or Maximum Performance mode depending on the accessibility of standby databases. It guarantees 100-percent data protection during normal operation in the event that the primary database fails(until unless same time failure at the primary site and power is lost at the standby site) .
No data loss even if primary database fails, to reach the protection level the redo data needed to recover transaction must be written to both the online redo log and to the standby redo log at least one synchronized standby database before the transaction commits
© 2014 Pythian

6. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

7. Protection with Maximum Availability – 11.x
SYNC/AFFIRM – Maximum Availability
Standby
SYNC 3
Primary
LGWR 2
NSS
RFS
11.x
AFFIRM
11.x 5 4
Commit ACK
Commit
LOG1
LOG2
MRP 6
SLOG1
SLOG2 1
-bash-3.2$ ps -ef|grep nss
oracle :06 ? :00:02 ora_nss2_mcdb
oracle :31 pts/ :00:00 grep nss
-bash-3.2$ ps -ef|grep lns
oracle :31 pts/ :00:00 grep lns
-bash-3.2$
© 2014 Pythian

8. Performance with Maximum Availability – 12c FastSync
SYNC/NOAFFIRM – Maximum Availability
Standby
SYNC 3
Primary
LGWR 2
NSS
RFS
12c
12c
Ack Receipt 4 2
NOAFFIRM
Commit ACK
Commit 5
LOG1
LOG2
MRP
SLOG1
SLOG2 1
© 2014 Pythian

9. Performance with Maximum Availability – Fast Sync
Prior to 12c it Maximum availability supports only SYNC/AFFIRM,
SQL> alter system set log_archive_dest_2='service=india sync noaffirm valid_for=(online_logfiles,primary_role) db_unique_name=india' scope=both;
System altered.
SQL> select protection_mode from v$database;
PROTECTION_MODE
MAXIMUM PERFORMANCE
SQL> alter database set standby database to maximize availability;
Database altered.
SQL>
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
NSS(11.2) - Acts as a slave for LGWR when SYNC transport is configured for a remote standby destination
NSS(12.1) - Transfers redo from current online redo logs to remote standby destinations configured for SYNC transport
LNS - primary database LGWR process is writing redo
to its ORL, a separate Data Guard process called the Log Network Server (LNS) is reading from
the redo buffer in SGA and passes redo to Oracle Net Services for transmission to the standby
database
RFS - Redo records transmitted by the LNS are received at the standby database by another Data
Guard process called the Remote File Server (RFS). The RFS receives the redo at the standby
database and writes it to a sequential file called a standby redo log file (SRL).
© 2014 Pythian

10. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

11. Far Sync – Road Map (Topology 1:n)
Multiple standby databases support(dest_n)
Standby database can be Physical or Logical or Snapshot
What is throughput and network traffic from one to many topology?
Is your all of standby sites will have same network speed across global?
© 2014 Pythian

12. Far Sync – Evolution Cascade standby Disadvantages?
At least one standby I able to transmit redo and the other standby(cascade) am not much worried because my data is safe in at least one standby
Avoided network trip between primary to standby databases
But I need huge storage in case of VLDB
© 2014 Pythian

13. Far Sync - Introduction
Light weight Oracle database instance
SPFILE, Password file, Standby Control file , SRL’s and ARL’s
No Datafiles
No Database Open
No storage cost and It consumes very less server resources (CPU, Memory…)
Far Sync supports both Physical standby and also Logical standby.
Far Sync doesn’t require a license but other nodes must required Oracle Active Data Guard License
Far Sync supports either Maximum Availability or Maximum Performance… Why?
Far Sync supports Data Guard Broker.
Compression of redo can be enabled with advanced compression license.
Database = control + data files + redo , Instance = Memory + Back Ground processes, Semi Database – far sync
Far sync instances are part of the Oracle Active Data Guard Far Sync feature, which requires an Oracle Active Data Guard license.
offload the primary database performance obligations/complexity and overcome network latency issues involved while shipping the redo synchronously to its all remote standby databases configured far away, at the same time guarantee zero data loss failover capabilities.
- cannot perform any switchover or either failover operations
Supports up to 29 remote destinations
© 2014 Pythian

14. Far Sync – Best Location to create
Considerations before creating FAR SYNC
Redo write size
Available network bandwidth
Round Trip Network latency
Standby I/O performance
If your redo rate bytes per second , bandwidth is 100 Mbps
© 2014 Pythian

15. Far Sync – Zero Data Loss Protection- How?
As soon as Far Sync receives synchronous redo from primary, it also completes sending committed transactions to the standby destination(s) of Data Guard configuration.
- My data is safe in standby database(s)
Now it lefts to you whether you wish to configure FSFO for failover operations or you prefer to do using manual method.
Standby servers doesn’t mean that failover performed to different location, its just logical representation that we performed failover and now the database is new primary
© 2014 Pythian

16. Far Sync – Implementation: Prerequisites
Change to SPFILE in case of PFILE.
Create Password file on Primary
- Copy password file to Far Sync instance and standby servers
Primary database should be in Archive log mode
Enable FORCE LOGGING on Primary database
Listener configuration on all locations (Primary, Far Sync and Standby)
Network connection
- Primary to Far Sync and vice versa
- Far Sync to remote standby database(s) and vice versa
- Primary to remote database(s), useful in case of switchover and any checks
Create SRL(Standby redo logs) and recommended to have same or more size than ORL(online redo logs) and create same or more number of standby redo log groups(SRL) than online redo log group(ORL)
- Creation of SRL’s on overall Data Guard configuration including primary will helps us in case of role transition
- Avoid multiplexing of SRL(standby redo logs)
© 2014 Pythian

17. Far Sync – Implementation: Know your environment
In this scenario, We have Primary database and one standby, Now we introducing Far Sync instance to transmit redo information through it.
Now create control file for Far Sync instance from primary database
Create SPFILE and copy it to Far Sync server and modify required parameters
Copy Password file to remote servers and rename it as per instance name
Copy control file backup(above location) to the Far Sync server, Either you can restore using RMAN even directly copy to the required location and perform mount.
DATABASE_ROLE
DB_UNIQUE_NAME
Oracle Net
Primary
CANADA
Far Sync
CANFAR
Standby
INDIA
© 2014 Pythian

18. Far Sync – Implementation
The new values of parameters from all destinations are
Why VALID_FOR used STANDBY_LOGFILE,STANDBY_ROLE used from far sync to standby?
The redo_log_type keyword identifies the destination whether valid or not.
© 2014 Pythian

19. Far Sync – Implementation(critical)
Create standby redo logs on primary
Because of LOG_FILE_NAME_CONVERT parameter the standby redo logs will be created automatically on Far Sync if they are created.
Increase protection mode to avail Maximum availability with zero data loss
Black Box
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
Recovery (MRP)
When recovery comes into picture, probably recovery can started from Far Sync? Then you will run into “ORA-01665: control file is not a standby control file”
Moreover there are no data files to update any committed transaction, its any instance which works as broker between primary and standby database, Recovery(MRP) should start only on standby database(s).
For real-time apply, no need to start recovery using “current logfile”, real-time apply is enabled by default.
© 2014 Pythian

20. Far Sync - Validation
After the successful configuration of introducing Far Sync, Overall status of the configuration
SRL’s are being used?
Parent and child relationship of Data Guard configuration.
© 2014 Pythian

21. Far Sync: Flexible Alternate destination
- alter system set log_archive_dest_2='service=canfar SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 DB_UNIQUE_NAME=canfar VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';
- alter system set log_archive_dest_3='service=india ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 DB_UNIQUE_NAME=india VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';
By thus configurations, redo will be sent asynchronously to alternate destinations and when far sync is available Data Guard automatically resynchronizes far sync(canfar) instance and redo will be transmitted towards far sync.
© 2014 Pythian

22. Far Sync: High Availability
After role transition(Switch over), will be the commit response time remains same between new primary and the Far Sync-1(canfar)?
To avail maximum availability for zero data loss establish a new far sync instance near to the primary.
Far Sync-1
SYNC
Distance ?
Standby
Switchover
Switchover
ASYNC
ASYNC
Standby
SYNC
Primary
Far Sync-2
After switchover
© 2014 Pythian

23. Far Sync – Add second far instance
Adding Far Sync instance near to remote destination is easy.
Create SPFILE from new/modified PFILE
Copy Password file
Network connection between all the locations.
Create new Far Sync control file from Primary database and mount.
Ensure SRL’s are available for maximum availability in case of role transition
© 2014 Pythian

24. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

25. Real-Time Cascaded Standby Databases
Cascaded destinations now receives redo in Real-Time
Must have Active Data Guard License
Cascading Standby can be in any Protection Mode
Data Guard Broker now supports cascade standby
First standby should be either Physical or Far Sync Standby but no Logical Standby
© 2014 Pythian

26. Real-Time Cascaded Standby Databases - Setup
Real-Time Cascade, Then transport mode should be ASYNC and it can be any destinations.
For Non Real-Time Cascade, Transport mode should be SYNC and use the destinations from 1 to 10.
Standby Redo Logs(SRLs) must have created already on cascaded standby database.
Primary to Cascading:
SQL> alter system set log_archive_dest_2='SERVICE=INDIA SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=INDIA' scope=both;
Cascading to Cascade:
SQL> alter system set log_archive_dest_2='SERVICE=UK ASYNC VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME=UK' scope=both;
© 2014 Pythian

27. Real-Time Cascade with Broker
From 12c Cascade standby now with Broker support
Configure RedoRoutes
DGMGRL> edit database CANADA set property redoroutes='(LOCAL:INDIA) (INDIA:UK)';
Property "redoroutes" updated
DGMGRL> edit database INDIA set property redoroutes='(CANADA:UK ASYNC)';
DGMGRL>
© 2014 Pythian

28. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

29. Simpler Role Transitions
Simple Switchover with “SQL> alter database switchover to india;”
Simple Failover with “SQL> alter database failover to india;”
Standby can be
© 2014 Pythian

30. Simpler Role Transitions
© 2014 Pythian

31. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

32. 11g Rolling Upgrade Disable Broker
Create Guaranteed restore point on primary & Standby
Convert standby to Transient Logical standby
Create 2nd Guaranteed restore point
Upgrade Transient Logical standby
Switchover to Primary
Flashback Original Primary
Mount Primary from new home and convert to physical standby
Start Switchover on primary
Complete switchover on standby
Restart Old primary as standby
Drop Restore points
© 2014 Pythian

33. DBMS_ROLLING Legacy Rolling Upgrade Vs DBMS_ROLLING
PL/SQL package of ADG Feature
Very useful in case of any maintenance, Patching.
© 2014 Pythian

34. DBMS_ROLLING High Level Steps DBMS_ROLLING.DESTROY_PLAN ();
DBMS_ROLLING.ROLLBACK_PLAN;
© 2014 Pythian

35. DBMS_ROLLING
© 2014 Pythian

36. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

37. Online standby data file movement
Online standby data file is feature of 12c and this is applicable either primary or standby but now it is more flexible… How?
No need to terminate the recovery (MRP)
No need to set STANDBY_FILE_MANAGMENT to MANUAL
If using ADG no need to bounce database to mount either.
© 2014 Pythian

38. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

39. Recover standby database using primary service
From 12c to fill huge archive lags, incremental backups on fly procedure can be performed for faster and simple form of recovery by using service name from standby and no need to have any backup either in primary or standby to do.
Should be in mount status or else
Recovery cannot be performed in open status and data file fall into exclusive enqueue
No need to have backup from primary
Restore Datafile
RMAN> restore datafile 6 from service “canada" ;
© 2014 Pythian

40. What’s new in 12c Data Guard?
Fast Sync
Far Sync
Real-time Cascade standby database
Switchover Preview
DBMS_ROLLING
Online standby data file movement
Restore datafile & Recover standby database using primary service
SYSDG role
© 2014 Pythian

41. SYSDG Role SYSDG administrative privilege specific to Data Guard.
If you want to manage with SYSDG role then ensure you have fresh copy of password file.
ALTER SYSTEM,
ALTER SESSION
ALTER DATABAE,
FLASHBACK DATABASE
DROP RESTORE POINT
SELECT ANY DICTIONARY
All DGMGRL Commands
© 2014 Pythian

42. Finally……
"There is a law written somewhere in the universe that says the day your standby's config diverges from your primary is the day you will need to failover. Better hope such divergence doesn't hurt the end user experience now that they are using the standby." - Brian Peasland
© 2014 Pythian

43. Thank you and Q&A basha@pythian.com @nassyambasha www.oracle-ckpt.com