Same Sequence# with different applied value in v$archived_log

Question

Hi everyone,
I have an issue with one of the dataguard servers here.
Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
my query to check this is:
SELECT sequence# from v$archived_log where applied = 'NO';result:
SEQUENCE#
    40154
    40546with a different query I found an interesting result
select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE#      RECID      STAMP S APP
    40154       8093  777156019 D NO
    40154       8095  777156053 D YES
    40546       8486  777673729 D NO
    40546       8487  777673734 D YESAt the time I ran this query, the v$managed_standby are as follow:
select process, status, sequence# from v$managed_standby;result:
PROCESS   STATUS        SEQUENCE#
ARCH      CLOSING           40562
ARCH      CLOSING           40557
MRP0      APPLYING_LOG      40563
RFS       IDLE                  0
RFS       IDLE              40563A simple solution to get those un-applied archived log to be applied is to restart the standby database instance.
Another finding from the production database:
select recid, stamp, sequence#, creator, registrar, standby_dest from v$archived_log where sequence# in (40154, 40546);result:
RECID      STAMP  SEQUENCE# CREATOR REGISTR STA
45446  777156011      40154 ARCH    ARCH    NO
45447  777156017      40154 LGWR    LGWR    YES
45450  777156051      40154 ARCH    ARCH    YES
46231  777673709      40546 ARCH    ARCH    NO
46232  777673728      40546 LGWR    LGWR    YES
46233  777673733      40546 ARCH    ARCH    YESThe question is of course, why is this happening?
Can this be prevented?
Thank you,
Adhika

Answer 1

CKPT wrote:
I have an issue with one of the dataguard servers here.
Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
my query to check this is:
SELECT sequence# from v$archived_log where applied = 'NO';result:
SEQUENCE#
40154
40546
Even if old archives applied or not, it will keep transfer the archivelogs from primary. Please confirm that you been executed above query in standby.. is it?Yes I ran it from the standby database
CKPT wrote:
with a different query I found an interesting result
select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE#      RECID      STAMP S APP
40154       8093  777156019 D NO
40154       8095  777156053 D YES
40546       8486  777673729 D NO
40546       8487  777673734 D YES
How many remote/standby destinations you have in your DR setup?
Might this query you have executed in primary, You should always use DEST_ID when executing from primary (or) do check in standby database, Because the applied column you have to check in standby , If you see above the same sequence showing applied in one destination & not applied on other instance, so please do select for dest_2 or in standby.I have only 1 standby destination.
The query above was executed in the standby database server as well as to show that the same sequence# has different result in the applied column.
CKPT wrote:
The question is of course, why is this happening?
Can this be prevented?What is your Online redo log file size (or) how much average archive log file size?
This issue happens when Network glitch while transferring archives from primary to standby RFS , So when is big enough in such conditions it will be in status can be WAIT_FOR_LOG.
BTW, which redo transport you are using? -- recommended to use LGWR
Is there any network problem?
check for exact problem either from primary alert log file or from below query,
SQL> select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status;
SQL> select sequence#, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') from v$archived_log where sequence# in (40154, 40546);
HTH.The redolog file size is 100MB and so does the archive log file size.
I'm using LGWR ASYNC
these are the result of the query which I modified slightly:
query:
select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status where message like '%40154%' or message like '%40546%';result:
SEVERITY ERROR_CODE MESSAGE                                                                                              TIMESTAMP
Warning           0 LNS: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2    11-MAR-2012 20:28:44
Warning           0 ARC1: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2   11-MAR-2012 20:28:49The message for the 40154 must have been purged.
It appeared to me that sequence 40546 has been sent twice, by LNS and ARC1.
query:
select sequence#, registrar, creator, standby_dest, dest_id, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') completion_time from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE# REGISTR CREATOR STA    DEST_ID COMPLETION_TIME
    40154 ARCH    ARCH    NO           1 05-MAR-2012 20:40:11
    40154 LGWR    LGWR    YES          2 05-MAR-2012 20:40:17
    40154 ARCH    ARCH    YES          2 05-MAR-2012 20:40:51
    40546 ARCH    ARCH    NO           1 11-MAR-2012 20:28:29
    40546 LGWR    LGWR    YES          2 11-MAR-2012 20:28:48
    40546 ARCH    ARCH    YES          2 11-MAR-2012 20:28:53This query proved that the primary database is actually trying to send twice with a different completion time.
Why does the primary database has to send twice?
Thanks for replying,
Adhika