Logs are shipped to the physical standby database but NOT applied.

Version imprimable

20/06/2013, 17h40
whisper

Logs are shipped to the physical standby database but NOT applied.

Bonjour,

Les groupes redolog de la base de secour sont en état UNASSIGNED.
Le mécanisme qui permet d'appliquée les séquences au niveau de la base de secour ne démarre pas.

En regardant la log de la base de secour:

Media Recovery Waiting for thread 1 sequence 97730
Thu Jun 20 14:13:37 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 14:35:03 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'
Thu Jun 20 14:37:21 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 14:56:09 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:04:57 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'
Thu Jun 20 15:15:23 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:34:01 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:34:50 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'
Thu Jun 20 15:49:54 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:55:47 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:56:58 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 15:57:02 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'
Thu Jun 20 16:12:53 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 16:14:00 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 16:14:02 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'
Thu Jun 20 16:27:35 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 16:39:47 2013
RFS[1]: Successfully opened standby log 7: '+DATA_PROD/STBY/onlinelog/group_7.279.791301897'
Thu Jun 20 16:43:56 2013
RFS[2]: Successfully opened standby log 11: '+DATA_PROD/STBY/onlinelog/group_11.275.791301953'

Quant je lance la commande "shutdown immediate" au niveau de la base de secour cette dérnière reste figé , même constat pour la commande "ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL "

Lorsque je relance la base de secour, l'application des archivelog recç par la base de secour se déclenche de nouveau mais il s'arrête au cours de la journée même et je suis obligé de faire un A/R a chaque fois de la base de secours puor que les séquence soit appliqués.

Merci pour votre aide.
21/06/2013, 23h39
Heaven93

bonsoir,

est-ce que la séquence 97730 est arrivée sur la standby?
interrogez la vue V$ARCHIVE_GAP sur la standby.

Code:

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

si des archivelogs manquent les envoyer sur la standby (si oracle n'y arrive pas tout seul).
une petite requête qui peut être utile :

Code:

select * from v$managed_standby;

pour le pb des standbylogs non assigned, quel est le mode de recover? using current logfile? si oui, alors la taille est-elle la même que sur la primary pour ces standbylogs?

La séquence 97730 est bien présente au niveau de la STBY, par contre ( en vérifiant au niveau v$archived_log ) elle n'est pas appliquée.

Le mode de recovery est realtime apply ( effectivement using current logfile).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
###primaire:
 
SQL> select GROUP#, BYTES from v$log;
 
    GROUP#      BYTES
---------- ----------
         1 1073741824
         2 1073741824
         3 1073741824
         4 1073741824
         5 1073741824
         6 1073741824

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
###STBY :
 
SQL> select GROUP#, BYTES from V$STANDBY_LOG;
 
    GROUP#      BYTES
---------- ----------
         7 1073741824
         8 1073741824
         9 1073741824
        10 1073741824
        11 1073741824
        12 1073741824
        13 1073741824
        14 1073741824

Je pense que j'ai deux goup de plus au niveau de la STBY mais la taille des group reste identique.

27/06/2013, 22h20
Heaven93

ça ne donne pas le resultat de la dernière requête (sur la standby)
28/06/2013, 12h23
whisper

support oracle "thank you for these tests. They show the log transport, registration and log apply are working fine. Just the MRP will not informed about new log files. Therefore I recommend to recreate the standby controlfiles, because in the controlfiles there are all information about new archived log files"

personellement, je ne suis pas convaincu car un A/R du process MRP corrige le problème.