Oracle12c DataGuard-FarSync and Whats New

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 with 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

2014 Pythian 2

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

Global Reach & Scalability:

24/7/365 global remote support for DBA and consulting, systems administration, special projects or emergency response

Why Companies Trust Pythian

3 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

2014 Pythian 4

Whats new in 12c Data Guard?

1. Fast Sync

2. Far Sync

3. Real-time Cascade standby database

4. SYSDG role

5. Online standby data file movement

6. Recover standby database using primary service

7. DBMS_ROLLING

2014 Pythian 5

1. Protection modes & Fast Sync

2014 Pythian 6

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/AFFIRM-

NOAFFIRM)

- Maximum protection in maximum Availability

MAX_PERFORMANCE MAX_PROTECTION MAX_AVAILABILITY

ASYNC SYNC SYNC

NOAFFIRM AFFIRM AFFIRM/NOAFFIRM

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 7


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 8

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 9

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

2014 Pythian 10

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.

2014 Pythian 11

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

2014 Pythian 12

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.

2014 Pythian 13

Far Sync Implementation: Prerequisites

2014 Pythian 14

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)

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.

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

2014 Pythian 15

DATABASE_ROLE

DB_UNIQUE_NAME Oracle Net

Primary CANADA CANADA

Far Sync CANFAR CANFAR

Standby INDIA INDIA

Far Sync Implementation

2014 Pythian 16

The new values of parameters from all destinations are

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

2014 Pythian 17

Far Sync - Validation

2014 Pythian 18

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.

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.

2014 Pythian 19

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.

2014 Pythian 20

ASYNC

SYNC

Switch

over Switch

over

Distance ?

SYNC ASYNC

Far Sync Add second far instance

2014 Pythian 21

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


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 22

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.

2014 Pythian 23


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 24

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

2014 Pythian 25


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 26

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 27


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 28

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

2014 Pythian 29


1. Fast Sync

2. Far Sync


4. SYSDG role



7. DBMS_ROLLING

2014 Pythian 30

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)

2014 Pythian 31

DATABASE_ROLE

DB_UNIQUE_NAME Group

Primary CANADA Tail Group (TG)

Standby 1 INDIA Tail Group (TG)

Standby 2 USA Leading Group (LG)

Thank you and Q&A

[email protected]

@nassyambasha

www.oracle-ckpt.com

2014 Pythian 32

Documents

Oracle12c DataGuard-FarSync and Whats New