Another reason why you should use the Data Guard Broker for your #Oracle Standby

The Data Guard Broker is recommended for various reasons, this one is less obvious: It prevents a Split-Brain problem that may otherwise occur in certain situations. Let me show you:

[oracle@uhesse ~]$ dgmgrl sys/oracle@prima
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.
DGMGRL> show configuration;

Configuration - myconf

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

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 18 seconds ago)

This is my setup with 12c, but the demonstrated behavior is the same with 11g already. I will cause a crash of the primary database now, without damaging any files – like a power outage on the primary site:

[oracle@uhesse ~]$ ps -ef | grep smon
oracle    6279     1  0 08:30 ?        00:00:00 ora_smon_prima
oracle    6786     1  0 08:32 ?        00:00:00 ora_smon_physt
oracle    7168  3489  0 08:43 pts/0    00:00:00 grep --color=auto smon
[oracle@uhesse ~]$ kill -9 6279

Don’t do that at home 🙂 Now the primary is gone, but of course I can failover to the standby:

[oracle@uhesse ~]$ dgmgrl sys/oracle@physt
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.
DGMGRL> failover to physt;
Performing failover NOW, please wait...
Failover succeeded, new primary is "physt"

So far so good, my end users can continue to work now on the new primary. But what happens when the power outage is over and the ex-primary comes back up again?

[oracle@uhesse ~]$ sqlplus sys/oracle@prima as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Wed May 18 08:47:30 2016

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

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1258291200 bytes
Fixed Size		    2923920 bytes
Variable Size		  452985456 bytes
Database Buffers	  788529152 bytes
Redo Buffers		   13852672 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from
being opened

The DMON background process of the new primary communicates with the DMON on the ex-primary, telling it that there cannot be two primary databases within the same Data Guard Broker configuration! Try the same scenario without the broker and you will observe the ex-primary coming up until status OPEN. Just wanted to let you know 🙂

  1. #1 by Mathias Zarick on May 18, 2016 - 10:29

    Hi Uwe,

    I want to add that this only works if there is a network connection between new and former primary. If the former primary starts up and cannot reach the new primary the former will still open. Only if you add observer and enable FSFO it gets better for that scenario.
    Cheers Mathias

  2. #2 by Jatin on May 19, 2016 - 23:38

    In case of non-Broker, first of all why would any DBA after power on ExPrimary would do a “startup” unless its active dataguard. Also there should not be any auto start of the DG settings.
    Not sure if this test validates that.

  3. #3 by Uwe Hesse on May 20, 2016 - 08:25

    Mathias, correct – if there is no network communication between primary and standby, the old primary will not be prevented to reach status OPEN

  4. #4 by Uwe Hesse on May 20, 2016 - 08:34

    Jatin, it is plain to see what this test validates, isn’t it? I did not say that it is a good idea to startup the old primary or why anyone may want to do that. Actually, it could come up automatically if the server has been configured that way. It is just something to be aware of. “there should not be any auto start of the DG settings” Yes, and there should not be any politicians lying 🙂

  5. #5 by rajesh on January 14, 2017 - 08:58

    Nice article 🙂 I am looking for a document “Physical standby from ASM primary to Non Asm”. (Switch over and Fail over disabled ). Flow is only from primary to standby

  1. Another reason why you should use the Data Guard Broker for your #Oracle Standby — The Oracle Instructor | OracleDock

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: