FASTSYNC Redo Transport for Data Guard in #Oracle 12c

FASTSYNC is a new LogXptMode for Data Guard in 12c. It enables Maximum Availability protection mode at larger distances with less performance impact than LogXptMode SYNC has had before. The old SYNC behavior looks like this:

LogXptMode=SYNC

LogXptMode=SYNC

The point is that we need to wait for two acknowledgements by RFS (got it & wrote it) before we can write the redo entry locally and get the transaction committed. This may slow down the speed of transactions on the Primary, especially with long distances. Now to the new feature:

LogXptMode=FASTSYNC

LogXptMode=FASTSYNC

Here, we wait only for the first acknowledgement (got it) by RFS before we can write locally. There is still a possible performance impact with large distances here, but it is less than before. This is how it looks implemented:

DGMGRL> show configuration;   

Configuration - myconf

  Protection Mode: MaxAvailability
  Members:
  prima - Primary database
    physt - (*) Physical standby database 

Fast-Start Failover: ENABLED

Configuration Status:
SUCCESS   (status updated 26 seconds ago)

DGMGRL> show database physt logxptmode
  LogXptMode = 'fastsync'
DGMGRL> exit
[oracle@uhesse ~]$ sqlplus sys/oracle@prima as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Sat Aug 1 10:41:27 2015

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> show parameter log_archive_dest_2

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2		     string	 service="physt", SYNC NOAFFIRM
						  delay=0 optional compression=
						 disable max_failure=0 max_conn
						 ections=1 reopen=300 db_unique
						 _name="physt" net_timeout=30,
						 valid_for=(online_logfile,all_
						 roles)

My configuration uses Fast-Start Failover, just to show that this is no restriction. Possible but not required is the usage of FASTSYNC together with Far Sync Instances. You can’t have Maximum Protection with FASTSYNC, though:

DGMGRL> disable fast_start failover;
Disabled.
DGMGRL> edit configuration set protection mode as maxprotection;
Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode

Failed.
DGMGRL> edit database physt set property logxptmode=sync;
Property "logxptmode" updated
DGMGRL> edit configuration set protection mode as maxprotection;
Succeeded.

Addendum: As my dear colleague Joel Goodman pointed out, the name of the process that does the Redo Transport from Primary to Standby has changed from LNS to NSS (for synchronous Redo Transport):

SQL> select name,description from v$bgprocess where paddr<>'00';

NAME  DESCRIPTION
----- ----------------------------------------------------------------
PMON  process cleanup
VKTM  Virtual Keeper of TiMe process
GEN0  generic0
DIAG  diagnosibility process
DBRM  DataBase Resource Manager
VKRM  Virtual sKeduler for Resource Manager
PSP0  process spawner 0
DIA0  diagnosibility process 0
MMAN  Memory Manager
DBW0  db writer process 0
MRP0  Managed Standby Recovery
TMON  Transport Monitor
ARC0  Archival Process 0
ARC1  Archival Process 1
ARC2  Archival Process 2
ARC3  Archival Process 3
ARC4  Archival Process 4
NSS2  Redo transport NSS2
LGWR  Redo etc.
CKPT  checkpoint
RVWR  Recovery Writer
SMON  System Monitor Process
SMCO  Space Manager Process
RECO  distributed recovery
LREG  Listener Registration
CJQ0  Job Queue Coordinator
PXMN  PX Monitor
AQPC  AQ Process Coord
DMON  DG Broker Monitor Process
RSM0  Data Guard Broker Resource Guard Process 0
NSV1  Data Guard Broker NetSlave Process 1
INSV  Data Guard Broker INstance SlaVe Process
FSFP  Data Guard Broker FSFO Pinger
MMON  Manageability Monitor Process
MMNL  Manageability Monitor Process 2

35 rows selected.

I’m not quite sure, but I think that was even in 11gR2 already the case. Just kept the old name in sketches as a habit 🙂

,

  1. #1 by Noons on August 1, 2015 - 15:53

    Still don’t get why max avail has to shutdown the primary if the standby write fails.
    Shutting down an application’s db because a standby write failed?
    That is not max avail in any language…

  2. #2 by Uwe Hesse on August 1, 2015 - 16:06

    And who says that with maximum availability the primary needs to shutdown if the standby fails? For sure I didn’t. Because it’s false. The behavior you describe occurs with maximum protection when only one standby is configured. Which is why two (or more) standby databases are recommended with maximum protection. With maximum availability and just one standby, the primary changes to ASYNC Redo Transport if the one standby doesn’t respond. It does NOT shutdown then – therefore the name of the protection mode, by the way 🙂

  3. #3 by Noons on August 2, 2015 - 01:42

    Hmmm, something is wrong with my setup, then. Will investigate. Thanks for the heads-up.

  4. #4 by Vishal Gupta on August 10, 2015 - 14:34

    LNS change to NSA (Aysnc) or NSS (Sync) from 11.2.0.1 onwards

  5. #5 by Robert Koltai on October 11, 2016 - 09:44

    Hi Uwe!

    set lines 120
    column destination format a25
    column id format 999
    column target format a7
    column seq# format 9999
    column proc format a4
    select dest_id as id, status , target,
    –archiver, destination, log_sequence as seq#, process as proc,
    register, transmit_mode, affirm,
    –valid_type, valid_role, db_unique_name,
    applied_scn
    from v$archive_dest where dest_id SQL> SQL> SQL> SQL> SQL> SQL> 2 3 4 5 6

    ID STATUS TARGET REG TRANSMIT_MOD AFF APPLIED_SCN
    —- ——— ——- — ———— — ———–
    1 VALID PRIMARY YES SYNCHRONOUS NO 0
    2 VALID STANDBY YES PARALLELSYNC YES 1854722

    I have a 12.1.0.2 physical standby setup with the query above run on the primary.
    Can you please shed light on what the difference between PARALLELSYNC and SYNCHRONOUS is. (v$archive_dest.transmit_mode)

    The documentation https://docs.oracle.com/database/121/REFRN/GUID-B70F0435-96AE-4AB4-9329-F035188C413F.htm#REFRN30007 does not give any detail on this.

    Any link, explanation, metalink note id is welcome.

    Thanks,
    Rob

  6. #6 by fouedgray on October 11, 2016 - 20:48

    Thanks for this post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: