Oracle 12c Data Guard Far Sync and whats new

Author & Presenter: Nassyam Basha

Date: 22-Feb-2014

Nassyam Basha
Post Graduation in computers from University of Madras 7 Years of experience as Oracle DBA and exposure dBase and FoxPro Currently working for The Pythian Group 10g,11g Oracle certified professional Blogger www.oracle-ckpt.com Frequent OTN contributor (CKPT) Co-Author of Oracle 11gR2 Data Guard administration beginners Guide PACKT nassyambasha Nassyam Basha with

2014 Pythian

Why Companies Trust Pythian

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 One of the worlds 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 Golden Gate & Oracle RAC 24/7/365 global remote support for DBA and consulting, systems administration, special projects or emergency response

Expertise:

Global Reach & Scalability:

2014 Pythian

Oracle Data Guard Journey

7.3 -Introduced in this version as standby database 8i - Physical standby database , Managed recovery of standby , Remote archiving of redo logs 9i - Protection modes, Data Guard Broker, Switchover/Failover, Automatic GAP resolution & Synchronization, Logical standby , Cascaded

10g
- Real-Time Apply, More enhancements with Configurations, FSFO, Flashback Database, SRL support on Logical standby database. 11g - Active Data Guard, Snapshot Standby, Heterogeneous platform support, Rolling upgrade, tuning reports. 12c - Fast Sync, Far Sync, Real-Time Cascade standby, DBMS_ROLLING
4 2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
5 2014 Pythian

1. Protection modes & Fast Sync

Maximum Performance: Primary database never waits for any acknowledgment from standby destinations to complete a transaction. The default mode. (ASYNC/NOAFFIRM) Maximum 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 logs. (SYNC/AFFIRM)
Recommended to have minimum two standby database(s)

Maximum Availability(12c): This has the ability to run as a Maximum Protection or Maximum Performance mode depending on the accessibility of standby databases. . (SYNC/AFFIRMNOAFFIRM) - Maximum protection in maximum Availability MAX_PERFORMANCE
ASYNC NOAFFIRM

MAX_PROTECTION
SYNC AFFIRM

MAX_AVAILABILITY
SYNC AFFIRM/NOAFFIRM

2014 Pythian

Performance with Maximum Availability Fast Sync

Maximum availability with SYNC/AFFIRM Traditional Primary performs write operations and waits for acknowledgement until redo has been transmitted synchronously to the standby and written to the disk. SYNC/NOAFFIRM From 12c The primary performs write operations and waits only for acknowledgement that the data has been received on the standby, Chances of data loss in the event of a failure as primary does not check for redo writes to disk on standby.

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
8 2014 Pythian

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),
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 data centre very far distance?

2014 Pythian

Far Sync Road Map (Cascade Standby)

Introduced in 9iR2 Reduces load on primary, whereby a standby database receives its redo data from another standby database Disadvantage: you must have whole database structure (if VLDB) ?

10

2014 Pythian

Far Sync - Introduction

Far Sync introduced in 12c and its an extension of Cascade standby database Far Sync supports both Physical standby and also Logical standby and it requires Oracle Active Data Guard License Far Sync supports either Maximum Availability or Maximum Performance Why? Its a light and Semi database How? - It contains only configuration file (SPFILE), control file and standby redo log files and it cannot be opened because it doesnt contain any data files. - No storage cost and It consumes very less server resources (CPU, Memory) Far Sync supports Data Guard Broker. Far sync instance acts as a redo log repository to remote standby databases. - compression of redo can be enabled with advanced compression license.

11

2014 Pythian

Far Sync Best Practices

Create a far sync instance close to the primary database to overcome/avoid network latency bottlenecks and gain performance benefits while transmitting redo. As soon as Far Sync receives redo data it transmits to standby database(s) asynchronously

12

2014 Pythian

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) You could configure FSFO for failover operations or use manual method.

13

2014 Pythian

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 Standby redo logs. - Creation of SRLs on overall Data Guard configuration including primary will helps us in case of role transition - Avoid multiplexing of SRL (standby redo logs)
14 2014 Pythian

Far Sync Implementation: Know your environment

In this scenario, We have a Primary database and one standby, Now we introducing Far Sync instance to transmit redo information through it.
DATABASE_ROLE
Primary Far Sync

DB_UNIQUE_NAME
CANADA CANFAR

Oracle Net
CANADA CANFAR

Standby

INDIA

INDIA

Create standby redo logs on primary SRLs on Far Sync will be created by the use of LOG_FILE_NAME_CONVERT Now create the control file for Far Sync instance from primary database and mount on Far Sync

15

2014 Pythian

Far Sync Implementation

The new values of parameters from all destinations are

16

2014 Pythian

Far Sync Implementation(critical)

Increase the protection mode to Maximum availability.

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).

17

2014 Pythian

Far Sync - Validation

After the successful configuration of introducing Far Sync, Overall status of the configuration

SRLs are being used?

Parent and child relationship of Data Guard configuration.

18

2014 Pythian

Far Sync: Flexible

There may some possible chance, when 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)';

Redo will be sent asynchronously to alternate destinations when far sync instance is down Once back, Data Guard automatically resynchronizes far sync (canfar) instance.

19

2014 Pythian

Far Sync: High Availability

After role transition (Switchover), 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.
SYNC

Distance ?
Switch over
ASYNC ASYNC

Switch over
SYNC

20

2014 Pythian

Far Sync Add second far instance

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 SRLs are available for maximum availability in case of role transition

21

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
22 2014 Pythian

Real-Time Cascaded Standby Databases

Real-Time cascaded Another notable feature of 12c
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 Standby should be either Physical or Far Sync Standby (if available) - You cannot cascade a physical standby from logical standby
Add DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, LOG_ARCHIVE_DEST_n with VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
Standby Redo Logs(SRLs) Should be created on cascading standby database. FAL_SERVER on terminal standby should set to the cascading standby or primary database. DEST_1 to DEST_10 supports to Real-Time if ASYNC used, if do not specified ASYNC then it works under non-real time. Especially DEST_11 to DEST_31 supports to only real time transport mode.

23

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
24 2014 Pythian

SYSDG Role

So far for any Data Guard operations performed using SYS, From now SYSDG role can granted to user to perform only specific to Data Guard operations. If you want to manage with SYSDG role then do not forget to copy to standby database(s)
SYSDG role contains ALTER SYSTEM,SELECT ANY DICTIONARY, ALTER DATABASE, ALTER SESSION and all DGMGRL commands

25

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
26 2014 Pythian

Online standby data file movement

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.

Online standby data file is feature of 12c and this is applicable either primary or standby but now it is more flexible How?

27

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
28 2014 Pythian

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. 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 Oracle service name should be reachable from standby.

alter database recover logfile '/u01/app/oracle/fast_recovery_area/INDIA/archivelog/2014_02_06/o1_mf_1_159_9h522kw0_.arc' Thu Feb 06 00:25:17 2014 Media Recovery Log /u01/app/oracle/fast_recovery_area/INDIA/archivelog/2014_02_06/o1_mf_1_159_9h522kw0_.arc

29

2014 Pythian

Whats new in 12c Data Guard?

1. 2. 3. 4. 5. 6.

Fast Sync Far Sync Real-time Cascade standby database SYSDG role Online standby data file movement Recover standby database using primary service 7. DBMS_ROLLING
30 2014 Pythian

DBMS_ROLLING
Rolling upgrade is an Active Data Guard feature It is implemented using the new DBMS_ROLLING PL/SQL package Data Guard Broker supported. Upgrade process splits into leading group and trailing group, all other standbys in the leading group can only be physical standbys. LG database upgraded first.

Code
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => USA'); SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN; SQL> EXECUTE DBMS_ROLLING.START_PLAN; SQL> EXECUTE DBMS_ROLLING.SWITCHOVER; Upgrade LG standby and bounce to RW mode from latest version, Perform Switchover. SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN; Mount former primary CANADA using latest version including other standby database(s)

DATABASE_ROLE
Primary Standby 1 Standby 2

DB_UNIQUE_NAME
CANADA INDIA USA

Group
Tail Group (TG) Tail Group (TG) Leading Group (LG)

31

2014 Pythian

Thank you and Q&A

basha@pythian.com

@nassyambasha
www.oracle-ckpt.com

32

2014 Pythian