ORA-16700: The standby database has diverged from the primary database.

 https://subhanuddinkhadri.blogspot.com/2015/10/flashback-standby-after-resetlogs-on.html

http://anuj-singh.blogspot.com/2018/06/oracle-flashback-for-standby-database.html

Error code: ORA-16700
Description: the standby database has diverged from the primary database
Cause: The primary database may have been flashed back or restored from a backup set and then reopened with the RESETLOGS option.
Action: Re-create the standby database from the primary database or flash back the standby database to the same point the primary database had been flashed back to.

The primary database may has been flashed back or restored from a backup set and then re-opened with the RESETLOGS option.

This happened because when due to an incomplete recovery in primary database, it has to be opened using resetlogs option and incarnation of primary and standby becomes different due to resetlogs option.

This error will appear in the alertlog and DGMGRL> show database  mtproddr

How to deal with ORA-16700:

Reinstantiate the standby database from the primary database.

Flashback the Standby database

We do not have to rebuild our standby, just move standby database using flashback to a previous SCN value when the incarnation of primary and standby was same. Start the MRP manually or bounce the configuration in DG broker.

Monitoring and Tuning an Oracle Database - What's your strategy on database monitoring?

How to Manage the Oracle Listener - 11G R2 Cluster: AVOID Using Sqlplus & Lsnrctl For Oracle

AVOID Using Sqlplus & Lsnrctl For Oracle Database & listener restart - Use srvctl  

In the Cluster World of today's Oracle databases, it is not advisable to use sqlplus and lsnrctl utilities to manage (start/stop) databases and listeners. This is absolutely wrong starting from 10g and the 11gR2 Cluster world

Just before explaining why it is a bad idea I would like to mention the right way of doing things. The following commands are just few examples on how you should start/stop Oracle processes:

1 2 3 4

srvctl start instance -d BTDB -n Lt02 -o open srvctl stop instance -d BTDB -n Lt02 -o immediate srvctl stop scan_listener -i 3 srvctl stop listener

The good news is that you do not need to remember the syntax. Just type “srvctl” and hit Enter. You will see a good overview of the commands available. To get an extensive help you add “-h” at the end. For example if you would like to see what mandatory parameters and additional options available for Oracle instance starting process just enter the following command:

1	srvctl start instance -h

Let’s get back to the topic of why it is bad to use sqlplus or lsnrctl commands in 11gR2 Clusters configuration. There are several reasons why you should avoid using the “old” way of managing Oracle processes:
– A – Listeners configuration in 11gR2 is dynamic and managed by cluster. There is no need to manage/edit listener.ora file directly anymore. In fact if you do so you will end up with a mess. Oracle Cluster (agents) manages the listeners configuration dynamically adding and dropping different configuration items from/to relative listener.ora file. If you try to start an Oracle listener using lsnrctl utility in one possible scenario you will still be able to start a listener however it may be using default 1521 on all IPs available on the host and it may be in conflict with Listeners configured and managed via cluster.
– B – In 11gR2 Cluster configuration all listeners are running under Infrastructure home and separate (by default) OS user (typically grid user). I have seen it many times when Oracle DBAs start listeners under oracle unix user (DB oracle home). This is wrong again. There are no correct listeners’ configuration files under DB oracle directory. Starting Listener under different OS user may conflict with already running listeners and confuse Oracle Cluster.
– C – In talking about staring database (instances) using sqlplus, the problem is that Oracle Cluster starts/stops an Oracle instance using pre-configured non-default SPFILE location. You can see the location of the SPFILE Cluster uses to start/stop database’s instances using the following command:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/export/home/oragrid>srvctl config database -d BTDB Database unique name: BTDB Database name: BTDB Oracle home: /u01/db/mage/11.2.0.1 Oracle user: oracle Spfile: +DATAG1/BTDB /spfileBTDB.ora Domain: WORLD Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: BTDB Database instances: BTDB1,BTDB2 Disk Groups: DATAG1,FRA Services: BTDB_10g… Database is administrator managed /export/home/oragrid>

As you can easily can figure out if you start Oracle instances using sqlplus Oracle tries to use the default spfile location ($ORACLE_HOME/dbs). If you have a pfile or spfile located there this way of starting the Oracle instance will lead to totally different results than starting it using srvctl Cluster utility.

The main message of this blog post to any Oracle DBA is:
– If you are working in Oracle Cluster environment starting from 10g, start using the srvctl utility. Otherwise you will end up in a messy and unmanageable configuration.