Thursday, July 31, 2014

ORA-16826: apply service state is inconsistent with the DelayMins property

 ORA-16826: apply service state is inconsistent with the DelayMins property

We will get this Error mostly when we start the standby database redo apply Manually when the db broker is configured .. when the db broker is configured we should use the db broker to stop and start the redo apply
When the error is noted we have to disable and enable the configuration of the db broker to clear the error
In this same practice you can find the details how to stop and start the redo shipping using the db broker
Step 1 check the database status in the dbbroker 
Login to the db broker and check the status of the configuration and check the status of the database

  

Step 2 Disable the configuration and enable it 
Legends
show configuration := the command which is used to show the configuration of the db broker
Disable configuration := Disable the Configuration  the db broker will stop processing
enable  configuration :=  enables the configuration of the db broker
In the Primary  database dbbroker log file we will get the below message
07/31/2014 18:33:04
Data Guard Broker Status Summary:
  Type                        Name                             Severity  Status
  Configuration               OMOICDR                           Warning  ORA-16608
  Primary Database            OMPROD                            Success  ORA-00000
  Physical Standby Database   OMDRDB                            Warning  ORA-16826
07/31/2014 18:33:20
DISABLE CONFIGURATION
Command DISABLE CONFIGURATION completed
07/31/2014 18:33:34
DISABLE CONFIGURATION
Command DISABLE CONFIGURATION completed
07/31/2014 18:33:50
ENABLE CONFIGURATION
07/31/2014 18:34:29
Command ENABLE CONFIGURATION completed

In the Standby database logfile we will get the below details
Redo Apply is running without USING CURRENT LOGFILE option while DelayMins=0
07/31/2014 18:30:17
DMON Deregistering service OMDRDB_DGB with listener(s)
07/31/2014 18:30:50
DMON Registering service OMDRDB_DGB with listener(s)
07/31/2014 18:30:55
Redo Apply is running without USING CURRENT LOGFILE option while DelayMins=0
07/31/2014 18:31:24
Command ENABLE CONFIGURATION completed

Check the configuration of the 'OMDRDB'

STOP REDO SHIPPING USING DB BROKER

To stop the redo shipping by using the db broker we can Use
Edit database <database_name> set state='TRANSPORT-OFF';  then check the configuration of the primary database
if we use this command it will globally stop the redo shipping to all the stand by database we have
If we have three standby database and we need to stop apply for one database then we need to execute the command as
EDIT DATABASE < name pf stadnby database for which we to stop log shipping> SET PROPERTY LogShipping=OFF;


when you stop the redo shipping using the db broker the log_archive_dest_state_2 will be changed to the reset mode.. as we have configured only one destination for the stand by database

SQL> show parameter log_archive_dest_state_2

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      RESET

Check the log file sequence from the Primary
SQL> select RESETLOGS_CHANGE#, THREAD#, min(SEQUENCE#) mins, max(SEQUENCE#) maxs from v$log_history group by RESETLOGS_CHANGE#, THREAD#;

RESETLOGS_CHANGE#    THREAD#       MINS       MAXS
----------------- ---------- ---------- ----------
       2.3900E+10          1       4283       8646
       2.3900E+10          2       3203       6141


Check the log file sequence from the Stand by
SQL> select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
  2  from (select thread# thrd, max(sequence#) almax
  3  from v$archived_log
  4  where resetlogs_change#=(select resetlogs_change# from v$database)
  5  group by thread#) al,
  6  (select thread# thrd, max(sequence#) lhmax
  7  from v$log_history
  8  where resetlogs_change#=(select resetlogs_change# from v$database)
  9  group by thread#) lh
 10  where al.thrd = lh.thrd;

    Thread Last Seq Received Last Seq Applied
---------- ----------------- ----------------
         1              8644             8644
         2              6140             6139

SQL>
Now you can clearly find the difference between the two log sequecne as the redo shipping had been stooped if you want to enable the redo shipping then again change the transport on property

START REDO SHIPPING USING THE DB BROKER

To start the redo shipping again we need to edit the parameter of the database in the db broker and change to  EDIT DATABASE '<primary database name>' SET STATE='TRANSPORT-ON';
 SQL> show parameter log_archive_dest_state_2

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2             string      ENABLE
Once you enable the transport-on in the db broker then the parameter state is turned to enable 

Check the log sequence from the Primary


SQL> select RESETLOGS_CHANGE#, THREAD#, min(SEQUENCE#) mins, max(SEQUENCE#) maxs from v$log_history group by RESETLOGS_CHANGE#, THREAD#;

RESETLOGS_CHANGE#    THREAD#       MINS       MAXS
----------------- ---------- ---------- ----------
       2.3900E+10          1       4287       8648
       2.3900E+10          2       3204       6144

SQL>
Check the log sequence from the stand by

SQL> select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
  2  from (select thread# thrd, max(sequence#) almax
  3  from v$archived_log
  4  where resetlogs_change#=(select resetlogs_change# from v$database)
  5  group by thread#) al,
  6  (select thread# thrd, max(sequence#) lhmax
  7  from v$log_history
  8  where resetlogs_change#=(select resetlogs_change# from v$database)
  9  group by thread#) lh
 10  where al.thrd = lh.thrd;

    Thread Last Seq Received Last Seq Applied
---------- ----------------- ----------------
         1              8648             8648
         2              6144             6143

Now both Primary and standby are sync again


No comments:

Post a Comment