jump to navigation

ORA-16765 + ORA-16826: apply service state is inconsistent with the DelayMins property with Dataguard Broker 28 October 2010

Posted by David Alejo Marcos in Dataguard Broker, Oracle 11.2, Standby.
Tags: , ,
trackback

Last Saturday I had to start-up our DR Database as the server went down 3 days before due to maintenance.

It should have been an easy task as the DR database was lagging “only” 400 files behind and all archivelogs were on the primary database.

The problem:

I had the following errors on the Dataguard Broker:

ORA-16765: Redo Apply is running

and

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

I first thought it was related to how much time we allow the standby database to be behind the primary, but it is not the case.

The solution:

I did copy all necessary archivelogs from the primary server to the standby server using SCP.

Once I had the necessary archivelogs, I registered using the following script:


spool /tmp/register.sql
begin
for i in 38010 .. 38060 loop
dbms_output.put_line ('alter database register logfile ''/u01/oradata/dbname/arch/1_'||i||'_697561259.arc'';');
end loop;
end;
/
@/tmp/register.sql

where:
1.- 38010 is the first archivelog file the standby was waiting for.
2.- 38060 is the last archivelog being generated by the primary database.

Once archivelogs were registered, the database started to apply them.

With only two logfiles behind, I decided to enable dataguard broker but the same error happened.

The only way I could get around was:

1.- To remove the standby database from the configuration:
DGMGRL> remove database 'dr_database';
Removed database "dr_database" from the configuration

2.- Add the database back to the configuration:
DGMGRL> add database 'dr_database' as connect identifier is 'dr_database';
Database "dr_database" added

3.- And then enable it again:
DGMGRL> enable database 'dr_database';
Enabled.

And voila, it started to work again.

As always, comments are welcome.

Comments

1. Jan Benjamins - 28 October 2010

I have seen this message on several occasions:
ORA-16826: apply service state is inconsistent with the DelayMins property

just the following would solve it:
edit database ‘standby’ set property DelayMins=’0′;

bug?

2. clirun - 2 November 2010

I fix this ORA- by reseting DGMGRL properties/parameters without copying archive log files.

#—-check db setup in verbose mode
DGMGRL> show database verbose ;

#—-got the property from previous output.
DGMGRL> show database InconsistentProperties;
DGMGRL> show database ;

#—–after compare to v$parameter setting, edit it
DGMGRL> edit database set property DelayMins=1;

DGMGRL> enable database ;

David Alejo Marcos - 6 November 2010

Afternoon,

first of all, thank you for your comments.

Lets see what Oracle says regarding this parameter:

“The DelayMins configurable database property specifies the number of minutes log
apply services will delay applying the archived redo log data on the standby database.
When the DelayMins property is set to the default value of 0 minutes, log apply
services apply redo data as soon as possible.”

Our configuration is as follows:

DGMGRL> show database verbose xxxxx

Database – xxxxx

Enterprise Manager Name: xxxxx
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
XXXX

Properties:
DGConnectIdentifier = ‘xxxxx’
ObserverConnectIdentifier = ”
LogXptMode = ‘ASYNC’
DelayMins = ‘0’
Binding = ‘optional’
MaxFailure = ‘0’
MaxConnections = ‘1’
ReopenSecs = ‘300’
NetTimeout = ’30’
RedoCompression = ‘DISABLE’
LogShipping = ‘ON’
PreferredApplyInstance = ”
ApplyInstanceTimeout = ‘0’
ApplyParallel = ‘AUTO’
StandbyFileManagement = ‘AUTO’
ArchiveLagTarget = ‘0’

Oracle should have started applying archivelogs automatically, (MaxFailure = 0 indicates that an unlimited number of failures are allowed), but it was not the case.

After your comments, I believe a change on the configuration is necessary, either changing the value of DelayMins (probably any parameter will do), or by the solution I provided.

Thank you,

David Alejo-Marcos.


Sorry comments are closed for this entry