|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : avril 2008 Messages : 5 ![]() |
Bonjour,
Je m'excuse d'avance si les questions vous semblent un peu bébète, mais je suis spécialisé DB2 et mon collègue qui s'occupe d'Oracle est en vacances. Le soucis est le suivant : Il y a un ecart entre le MAX(SEQUENCE#) from v$archived_log de la base primaire et le MAX(SEQUENCE#) from v$archived_log where applied = 'YES' et en grattant un peu je m'apercois que le SEQUENCE# = NN present sur la primaire est absent de la stand by et que c'est à partir de ce numero de sequence que les logs ne sont plus appliquées. Est ce grave ? comment faire pour que l'application des logs redemarre sur la standby ? Merci |
|
|
00
|
|
|
#2 |
|
Membre chevronné
![]() Inscription : septembre 2007 Messages : 519 ![]() |
Si je comprends bien tu as un log qui n'est pas passé de l'autre côté. Généralement cela vient du fait qu'il y a des outils externes de purge/archive des logs qui passent avant même que Oracle ait pu transférer ses petits.
Afin de résoudre ce trou (Appelé communément GAP) soit tu remets à disposition le fichier log manquant côté serveur et celui-ci va se charger de le transférer, soit tu le transfères toi même et tu le mets à disposition. Oracle reprendra là où il en était une fois le fichier visible. Au cas où poste ici les 100 dernières lignes de tes fichiers ALERT_LOG (primaire & standby). On ne sait jamais. |
|
|
00
|
|
|
#3 |
|
Membre confirmé
![]() Inscription : novembre 2007 Messages : 426 ![]() |
Bonjour,
tu peux voir : select max(sequence#) from v$log_history Cordialement, |
|
|
00
|
|
|
#4 |
|
Invité de passage
![]() Inscription : avril 2008 Messages : 5 ![]() |
Merci de vos reponses
Le probleme a ete identifié vendredi matin, et à cette heure oracle n'a toujours pas retabli la situation. Je vais donc transferer le fichier de log et on verra bien. Un ftp en mode binaire suffit il ? Pour le select max(sequence#) from v$log_history sur la primaire : 78461 sur la stand by : 77888 et c'est la sequence 77889 qui manque sur la stand by Voici les logs à partir de la sequence 77888 sur la primaire : Current log# 1 seq# 77887 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo01.log Fri Apr 25 02:00:02 2008 Thread 1 advanced to log sequence 77888 Current log# 3 seq# 77888 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo03.log Fri Apr 25 02:06:00 2008 Thread 1 advanced to log sequence 77889 Current log# 2 seq# 77889 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo02.log Thread 1 advanced to log sequence 77890 Current log# 1 seq# 77890 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo01.log Thread 1 cannot allocate new log, sequence 77891 Checkpoint not complete Current log# 1 seq# 77890 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo01.log Fri Apr 25 02:06:11 2008 Thread 1 advanced to log sequence 77891 Current log# 3 seq# 77891 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo03.log Fri Apr 25 02:06:50 2008 Thread 1 advanced to log sequence 77892 Current log# 2 seq# 77892 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo02.log Fri Apr 25 02:08:03 2008 Thread 1 cannot allocate new log, sequence 77893 Checkpoint not complete Current log# 2 seq# 77892 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo02.log Thread 1 advanced to log sequence 77893 Current log# 1 seq# 77893 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo01.log Fri Apr 25 02:08:27 2008 Thread 1 advanced to log sequence 77894 Current log# 3 seq# 77894 mem# 0: /data/oracle/oracle/product/10.2.0/db_1/oradata/nf2prod/redo03.log Fri Apr 25 02:09:17 2008 Thread 1 cannot allocate new log, sequence 77895 Voici les logs sur la stand by : Fri Apr 25 01:50:37 2008 Media Recovery Log /data/backup/archivelog/nf2prod/1_77886_604777431.dbf Media Recovery Waiting for thread 1 sequence 77887 (in transit) Fri Apr 25 01:53:40 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77887_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created Fri Apr 25 01:53:44 2008 Media Recovery Log /data/backup/archivelog/nf2prod/1_77887_604777431.dbf Media Recovery Waiting for thread 1 sequence 77888 (in transit) Fri Apr 25 01:59:44 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77888_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created Fri Apr 25 01:59:48 2008 Media Recovery Log /data/backup/archivelog/nf2prod/1_77888_604777431.dbf Media Recovery Waiting for thread 1 sequence 77889 Fetching gap sequence in thread 1, gap sequence 77889-77889 Fri Apr 25 01:59:56 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77890_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created Fri Apr 25 02:00:29 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77891_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created Fri Apr 25 02:01:45 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77892_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created Fri Apr 25 02:02:08 2008 RFS[1]: Archived Log: '/data/backup/archivelog/nf2prod/1_77893_604777431.dbf' Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: No standby redo logfiles created |
|
|
00
|
|
|
#5 | |
|
Membre confirmé
![]() Inscription : novembre 2007 Messages : 426 ![]() |
Citation:
|
|
|
|
00
|
|
|
#6 |
|
Membre confirmé
![]() Inscription : novembre 2007 Messages : 426 ![]() |
Vu le nomre important d'archive à jouer à votre place je vais plutôt reconstruire la standby ... enfain je ne connais pas votre contexte.
Cordialement, |
|
|
00
|
|
|
#7 |
|
Invité de passage
![]() Inscription : avril 2008 Messages : 5 ![]() |
Pour ma culture generale, qu'elles sont les operation à faire pour relancer l'application des logs ?
|
|
|
00
|
|
|
#8 | |
|
Membre Expert
![]() Inscription : juin 2007 Messages : 1 497 ![]() |
Citation:
Code :
ALTER DATABASE REGISTER LOGFILE '/chemin/log_XXX.arch'
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/ |
|
|
|
00
|
|
|
#9 |
|
Invité de passage
![]() Inscription : avril 2008 Messages : 5 ![]() |
Merci pour vos contributions ! La STANDBY est a nouveau active et en bon etat !
Merci |
|
|
00
|
|
|
#10 |
|
Membre confirmé
![]() Inscription : novembre 2007 Messages : 426 ![]() |
Bonjour,
Qd tu as +ieurs archives à jouer: set autorecovery ON recover standby database until cancel; @+ Cordialement, |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com