Oracle 12c Data Guard –
Far Sync and what’s new
Author & Presenter: Nassyam Basha
Date: 23-Aug-2014
• Recognized Leader:
– Global industry-leader in remote database administration services and consulting for Oracle, Oracle
Applications, MySQL and SQL Server
– Work with over 150 multinational companies such as Forbes.com, Fox Sports, Nordion and many more to
help manage their complex IT deployments
• Expertise:
– One of the world’s largest concentrations of dedicated, full-time DBA expertise. Employ 7 Oracle ACEs/ACE
Directors
– Hold 7 Specializations under Oracle Platinum Partner program, including Oracle Exadata, Oracle
GoldenGate & Oracle RAC
• Global Reach & Scalability:
– 24/7/365 global remote support for DBA and consulting, systems administration, special projects or
emergency response
Why Companies Trust Pythian
2 © 2013 Pythian
Nassyam Basha • Post Graduation in computers from University of Madras
• 8 Years of experience as Oracle DBA and exposure with dBase and FoxPro
• Co-Author of Oracle 11gR2 Data Guard
administration beginners Guide – PACKT
• Author of OTN Articles
• 11g Oracle certified professional
• Frequent OTN contributor (CKPT) /MOSC certified GURU
• Co-Founder
• Blogger www.oracle-ckpt.com
• nassyambasha Nassyam Basha
© 2013 Pythian 3
Oracle Data Guard Evolution
© 2013 Pythian 4
Read-only Physical standby database
Managed Recovery of standby
Remote archiving of redo log files
8i
Managed standby Database
7.x
Logical standby database
Integrated zero data loss
Broker, Switchover & Failover
Automatic GAP resolution
Cascade redo log destinations
9i
ADG, Heterogeneous Platform support
Snapshot Standby , Rolling Upgrade,
Tuning Reports
11g
Now lets See
12c
Real-Time Apply, Simplified
Configuration, SRL Support with
Logical standby database, FSFO,
Flashback database over Data Guard
10g
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
© 2013 Pythian 5
Quick look on Protection modes – 12c
© 2013 Pythian 6
• Maximum Performance: – Works as independent database – (ASYNC/NOAFFIRM) – Oracle no longer recommends ARCH transport
• Maximum Protection: Highest level of data protection, 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. (SYNC/AFFIRM)
• Maximum Availability(11g/12c): 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) .
– (SYNC/AFFIRM) - Maximum protection in maximum Availability – (SYNC/NOAFFIRM) – Maximum performance with maximum Availability
- Internal swapping of Performance to Availability and vice-versa depends on NET_TIMEOUT ?
MAX_PERFORMANCE MAX_PROTECTION MAX_AVAILABILITY
ASYNC SYNC SYNC
NOAFFIRM AFFIRM AFFIRM/NOAFFIRM
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
© 2013 Pythian 7
Performance with Maximum Availability – Fast Sync • Prior to 12c it Maximum availability supports only SYNC/AFFIRM,
• From 12c comes with SYNC/NOAFFIRM the primary performs write operations and waits only for
acknowledgement that the data has been received on the standby, not that it has been written to
disk.
• In case of extreme situations such as failure of primary and power loss on standby when transport
SYNC/AFFIRM, it has mechanism to check to confirm that data is written to disk on the standby,
there would be no data loss because the data would be available on the standby when the system
is back.
- In the us e of transport SYNC/NOAFFIRM, in which there is no check that data has been
written to disk on the standby, hence expected minimal data loss.
© 2013 Pythian 8
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
© 2013 Pythian 9
Far Sync – Road Map (Topology 1:n) • In legacy configurations, you can have multiple standby databases based on the
destination numbers(LOG_ARCHIVE_DEST_n), Of course you can have mixed
combination of either physical or logical standby.
• What is throughput and network traffic from one to many topology?
• Is your all of standby sites will have same network speed across global?
• What happens if you have only one datacentre very far distance?
© 2013 Pythian 10
Far Sync - Introduction • Light weight Oracle database instance
• Far Sync supports both Physical standby and also Logical standby and it requires Oracle Active
Data Guard License
• 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 either Maximum Availability or Maximum Performance… Why?
• Far Sync supports Data Guard Broker.
• Far Sync should be near to Primary database that can tolerate the impact of network latency on
synchronous transport.
• Compression of redo can be enabled with advanced compression license.
© 2013 Pythian 11
Far Sync – Evolution • Cascade standby
– Disadvantages?
© 2013 Pythian 12
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
© 2013 Pythian 13
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.
© 2013 Pythian 14
Far Sync – Implementation: Prerequisites
© 2013 Pythian 15
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)
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.
© 2013 Pythian 16
DATABASE_ROLE
DB_UNIQUE_NAME Oracle Net
Primary CANADA CANADA
Far Sync CANFAR CANFAR
Standby INDIA INDIA
Far Sync – Implementation
© 2013 Pythian 17
• The new values of parameters from all destinations are
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).
© 2013 Pythian 18
Far Sync - Validation
© 2013 Pythian 19
• 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.
Far Sync: Flexible • There may some possible chance, where your far sync instance may unavailable, so configure
Data Guard in such way to maintain zero data loss.
- 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.
© 2013 Pythian 20
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.
© 2013 Pythian 21
ASYNC
SYNC
Switch
over Switch
over
Distance ?
SYNC ASYNC
Far Sync – Add second far instance
© 2013 Pythian 22
• 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
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
© 2013 Pythian 23
Real-Time Cascaded Standby Databases 12c comes with Real-Time cascaded where in prior releases(Non Real-Time) the transport
will be in terms of archives.
– Must have Active Data Guard License
– Cascading Standby can be in any Protection Mode
– A Cascading Standby Database can serve one or multiple terminal Standby Databases
• Data Guard Broker now supports cascade standby
• First standby should be either Physical or Far Sync Standby(if available)
- You cannot cascade a physical standby from logical standby
Setup
• Add DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, LOG_ARCHIVE_DEST_n with
‘VALID_FOR=(‘STANDBY_LOGFILES’,’STANDBY_ROLE)’
– Log transport method should be ASYNC
– Standby Redo Logs(SRLs) Should be created on cascading standby database.
– Dest_1 to Dest_10 supports to non Real-Time cascading destination and remaining can be used for Real-Time
Cascading
© 2013 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
© 2013 Pythian 25
Simpler Role Transitions
• Simple Failover with “SQL> alter database failover to india;”
© 2013 Pythian 26
© 2013 Pythian 27
Simpler Role Transitions
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
© 2013 Pythian 28
DBMS_ROLLING
• Legacy Rolling Upgrade Vs DBMS_ROLLING
• PL/SQL package of ADG Feature
• Very useful in case of any maintenance, Patching.
© 2013 Pythian 29
© 2013 Pythian 30
DBMS_ROLLING
DBMS_ROLLING • High Level Steps
• DBMS_ROLLING.DESTROY_PLAN ();
• DBMS_ROLLING.ROLLBACK_PLAN;
© 2013 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
© 2013 Pythian 32
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.
© 2013 Pythian 33
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
© 2013 Pythian 34
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" ;
© 2013 Pythian 35
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
© 2013 Pythian 36
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
© 2013 Pythian 37
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
© 2013 Pythian 38