pb de bascule primary/Standby !

Version imprimable

06/09/2006, 18h08
karimarien

pb de bascule primary/Standby !

Bonjour,

nous avons deux serveurs Oracle en primary/Standby et des scripts spécifiques pour basculer.

Un sur le primary pour le basculer en standby et inversement sur le standby.

J'avais fait un restore avec les backup control file la veille de la base primaire et quand j'ai voulu basculer j'ai eu les messages suivants :

sur le primary :

LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 opened at log sequence 17
Current log# 2 seq# 17 mem# 0: F:\DATABASEV5\REDO\REDO02.LOG
Successful open of redo thread 1
Wed Sep 06 13:29:40 2006
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Sep 06 13:29:40 2006
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Sep 06 13:29:40 2006
Database Characterset is WE8MSWIN1252
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Wed Sep 06 13:29:46 2006
ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;
Wed Sep 06 13:29:46 2006
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
Wed Sep 06 13:29:46 2006
SMON: disabling tx recovery
SMON: disabling cache recovery
Wed Sep 06 13:29:46 2006
Shutting down archive processes
Archiving is disabled
Wed Sep 06 13:29:46 2006
ARCH shutting down
ARC1: Archival stopped
Wed Sep 06 13:29:46 2006
Thread 1 closed at log sequence 17
Successful close of redo thread 1
Wed Sep 06 13:29:46 2006
ARCH: noswitch archival of thread 1, sequence 17
ARCH: End-Of-Redo archival of thread 1 sequence 17
ARCH: Evaluating archive log 2 thread 1 sequence 17
ARCH: Beginning to archive log 2 thread 1 sequence 17
Creating archive destination LOG_ARCHIVE_DEST_2: 'NP1205_REM.SCPROLOG.COM'
ARCH: Error 16069 Creating archive log file to 'NP1205_REM.SCPROLOG.COM'
Wed Sep 06 13:29:46 2006
Errors in file f:\databasev5\log\np1205_ora_280.trc:
ORA-16069: Archive Log standby database activation identifier mismatch

Creating archive destination LOG_ARCHIVE_DEST_1: 'O:\ARCHIVEV5\ARC001.00017'
ARCH: Failed to archive log 2 thread 1 sequence 17
ORA-16038 signalled during: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL ST...
Wed Sep 06 13:29:47 2006
ARCH shutting down
Wed Sep 06 13:29:47 2006
ARC0: Archival stopped

sur le standby(c'est cela qui est le plus grave, je pense..) :

*** 2006-09-06 13:13:19.828
Activation ID mismatch: found ed75f631 expected ed6757df
*** 2006-09-06 13:13:19.937
RFS: Possible network disconnect with primary database (c'est faux évidemment c'est vérifié qu'il n'y a pas de pb réseau.

keske ça veut dire ???8O

Cela vous parle t'il d'une part et si oui quelles seraient les étapes à faire pour résoudre le pb ?Si vous pouvez me filer un coup de main ce serait super cool !! Attention ne me parlez pas en oracle chinois je suis un DBA très junior...

Merci par avance pour vos indications.

NB : SVP ne me dites pas que je dois reconstruire la standby !!!

@ +
Karimarien.
06/09/2006, 18h39
aline

Bonjour,

Juste une petite question.
As tu vu ta standby 'tourner' avant de la passer en primary.
Pourrais tu nous envoyer les traces de ton fichier d'alerte avant ton erreur sur la standby?
06/09/2006, 18h53
karimarien

ok, j'enverrais cela mais ça a commencé à planter au moment de la restore de la base primaire (voir les dernières lignes):

Mon Sep 04 15:46:12 2006
Full restore complete of datafile 3 to datafile copy F:\DATABASEV5\DATA\TOOLS01.DBF
checkpoint is 16509353
Full restore complete of datafile 9 to datafile copy F:\DATABASEV5\DATA\NP_INDEX_MEDIUM.DBF
checkpoint is 16509353
Full restore complete of datafile 4 to datafile copy F:\DATABASEV5\DATA\NP_DATA_SMALL.DBF
checkpoint is 16509353
Full restore complete of datafile 8 to datafile copy F:\DATABASEV5\DATA\NP_INDEX_SMALL.DBF
checkpoint is 16509353
Full restore complete of datafile 5 to datafile copy F:\DATABASEV5\DATA\NP_DATA_MEDIUM.DBF
checkpoint is 16509353
Mon Sep 04 15:46:48 2006
Full restore complete of datafile 1 to datafile copy F:\DATABASEV5\DATA\SYSTEM01.DBF
checkpoint is 16509353
Mon Sep 04 15:48:59 2006
Full restore complete of datafile 2 to datafile copy F:\DATABASEV5\DATA\RBS01.DBF
checkpoint is 16509353
Full restore complete of datafile 7 to datafile copy F:\DATABASEV5\DATA\NP_TEMP.DBF
checkpoint is 16509353
Mon Sep 04 15:50:20 2006
Full restore complete of datafile 10 to datafile copy F:\DATABASEV5\DATA\NP_INDEX_LARGE.DBF
checkpoint is 16509353
Mon Sep 04 15:51:11 2006
Full restore complete of datafile 6 to datafile copy F:\DATABASEV5\DATA\NP_DATA_LARGE.DBF
checkpoint is 16509353
Mon Sep 04 15:51:13 2006
alter database mount
Mon Sep 04 15:51:18 2006
Successful mount of redo thread 1, with mount id 3983930929
Mon Sep 04 15:51:18 2006
Database mounted in Exclusive Mode.
Completed: alter database mount
Mon Sep 04 15:51:23 2006
alter database recover datafile list
clear

Completed: alter database recover datafile list
clear
Mon Sep 04 15:51:23 2006
alter database recover datafile list
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10

Completed: alter database recover datafile list
1 , 2 , 3 ,
Mon Sep 04 15:51:23 2006
alter database recover if needed
start until cancel using backup controlfile

Media Recovery Start
ORA-279 signalled during: alter database recover if needed
start until canc...
Mon Sep 04 15:51:24 2006
alter database recover logfile 'F:\DATABASEV5\REDO\REDO01.LOG'
Mon Sep 04 15:51:24 2006
Media Recovery Log F:\DATABASEV5\REDO\REDO01.LOG
ORA-279 signalled during: alter database recover logfile 'F:\DATABASEV5\REDO...
Mon Sep 04 15:51:24 2006
alter database recover logfile 'F:\DATABASEV5\REDO\REDO03.LOG'
Mon Sep 04 15:51:24 2006
Media Recovery Log F:\DATABASEV5\REDO\REDO03.LOG
ORA-279 signalled during: alter database recover logfile 'F:\DATABASEV5\REDO...
Mon Sep 04 15:51:25 2006
alter database recover cancel
Mon Sep 04 15:51:25 2006
Media Recovery Cancelled
Completed: alter database recover cancel
Mon Sep 04 15:51:26 2006
alter database open resetlogs
RESETLOGS after incomplete recovery UNTIL CHANGE 16509550
Resetting resetlogs activation ID 3982972895 (0xed6757df)

Depuis ce restore les bases ne sont plus synchronisées. Faut il passer quelques commandes sur le recovery catalog ? (question supplémentaire ..)
06/09/2006, 19h13
orafrance

Merci d'éditer les messages et ajouter les balises CODE ou QUOTE :roll:
06/09/2006, 19h53
remi4444

Citation:

Envoyé par karimarien

NB : SVP ne me dites pas que je dois reconstruire la standby !!!

:? :roll:

Je pense que la standby a mal supporté le recover de la primaire (c'est une litote...:aie: )?

Reconstruire une standby physique n'est pas si pénible quand ça a déja été fait une fois car tu n'a pas à te refaire le paramétrage.
06/09/2006, 20h09
remi4444

Citation:

Envoyé par karimarien

Depuis ce restore les bases ne sont plus synchronisées. Faut il passer quelques commandes sur le recovery catalog ? (question supplémentaire ..)

Tu as fait un restore complet de la base primaire, tu est donc reparti de 0, comment veux-tu qu'en "quelques commandes" la standby puisse faire l'équivalent du rechargement total. La standby s'appuie le le recover des archivelog (donc un restore différentiel).
Normalement si tes archives sont encore sur la primaire depuis le dernier restore (sinon il faudra les copier à la main), tu dois pouvoir restorer tes datafiles sur le serveur standby (les meme que ce que tu as rapatrié sur la primaire), puis tu crée un "STANDBY CONTROLFILE " depuis ta primaire que tu copies sur la standby (en le duppliquant aux bons endroits définis dans le fichier init) Puis tu lance ta standby....
07/09/2006, 00h12
karimarien

un peu plus de détail...

hello les dba master,

Je reviens vers vous avec j'espère un peu plus de détails.

J'ai une palanquée de serveurs dont deux serveurs Oracle, et un serveur Networker avec un jukebox et tout ce beau monde sur un même lan. Pour les sauvegardes des bd oracles, on utilise rman.

Lundi j'ai donc fait une restore en premier lieu avec les backup control file et en second lieu avec les online control file pour montrer au client les différences et la restore s'est bien passée. Sauf que j'ai négligé la base standby a priori qui doit rentrer en compte dans la restauration ...

J'ai condensé quelques logs qui sont récurrents après dépouillage des fichiers de logs :

Citation:

Base Standby

Depuis le restore du lundi 4/9 à 15H50 :

Dump file f:\databasev5\log\np1205_rfs_1052.trc
Mon Sep 04 16:20:45 2006
ORACLE V9.2.0.6.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.2 Service Pack 1, CPU type 586
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
Windows 2000 Version 5.2 Service Pack 1, CPU type 586
Instance name: np1205

=> Vous avez la version maintenant.

*** SESSION ID:(11.262) 2006-09-04 16:20:45.234
*** 2006-09-04 16:20:45.234
Activation ID mismatch: found ed75f631 expected ed6757df
*** 2006-09-04 16:20:45.375
RFS: Possible network disconnect with primary database

Base primary

Mon Sep 04 16:20:11 2006

*** SESSION ID:(19.12) 2006-09-04 16:20:11.078
Error 16069 attaching RFS server to standby instance at host 'NP1205_REM.SCPROLOG.COM'
Error 16069 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'NP1205_REM.SCPROLOG.COM'
*** 2006-09-04 16:20:11.078
ARCH: Error 16069 Creating archive log file to 'NP1205_REM.SCPROLOG.COM'
*** 2006-09-04 16:20:11.078
kcrrfail: dest:2 err:16069 force:0
ORA-16069: Archive Log standby database activation identifier mismatch

Wed Sep 06 13:12:45 2006

*** SESSION ID:(10.5) 2006-09-06 13:12:45.812
Switchover archival completed
*** 2006-09-06 13:12:46.125
Using noswitch low SCN 0:16567411 next SCN 0:16590147
Error 16069 attaching RFS server to standby instance at host 'NP1205_REM.SCPROLOG.COM'
Error 16069 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'NP1205_REM.SCPROLOG.COM'
*** 2006-09-06 13:12:46.140
ARCH: Error 16069 Creating archive log file to 'NP1205_REM.SCPROLOG.COM'
*** 2006-09-06 13:12:46.140
kcrrfail: dest:2 err:16069 force:0
ORA-16069: Archive Log standby database activation identifier mismatch
*** 2006-09-06 13:12:46.171
ARCH: Changing kcrfhnxs from 65535:-1 to 0:16590147
*** 2006-09-06 13:12:46.171
ARCH: Setting end-of-redo flag
Switchover archival failed: 16038

Exemple de Tentative de switchover
Message logué qui est tout le temps le même :

Creating archive destination LOG_ARCHIVE_DEST_2: 'NP1205_REM.SCPROLOG.COM'
ARCH: Error 16069 Creating archive log file to 'NP1205_REM.SCPROLOG.COM'
Wed Sep 06 19:13:47 2006
Errors in file f:\databasev5\log\np1205_ora_4384.trc:
ORA-16069: Archive Log standby database activation identifier mismatch

Creating archive destination LOG_ARCHIVE_DEST_1: 'O:\ARCHIVEV5\ARC001.00019'
ARCH: Failed to archive log 1 thread 1 sequence 19
ORA-16038 signalled during: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL ST...
Wed Sep 06 19:13:48 2006
ARCH shutting down
Wed Sep 06 19:13:48 2006
ARC0: Archival stopped

A priori, donc quand je fais une restore de la base primaire, je comprends aisément que je repars à 0 au niveau des redo logs, et que du coup il y a un décalage au niveau des redologs entre la primary et la standby.

Comment éviter cette situation ? y a t'il une manière plus souple de procéder ?

J'imagines qu'il faut suivre la procédure restorer les mêmes fichiers .dbf sur la standby et que je recrées les control file à partir de la base primaire avec le bon fichier init etc ???

Si une bonne ame dévouée a le temps de m'envoyer une procédure déjà faite pour se faire, je ne la remercierais jamais assez ...

Merci par avance pour votre aide et un peu d'indulgence svp si vous trouvez que je poses des questions à la con car un ce n'est pas mon métier et deux l'entraide est un peu le but des forums non ;) ?

Merci encore à tous.
Karim

NB : est il besoin de préciser que c'était pour hier lol ? :mouarf:
07/09/2006, 09h22
Arturius

Voila la doc en ligne pour l'usage de RMAN dans un environnement Dataguard :
(attention doc 10gR2)

http://download-uk.oracle.com/docs/c...n.htm#CHDHAJFD
07/09/2006, 22h27
karimarien

merci pour la doc...

Mais ça ne répond pas à ma question essentielle...

Quand on fait une restauration de la base primaire(avec les backup control file comme avec les online d'ailleurs...), que doit on faire pour ne pas être obligé de reconstruire la standby ?

Pour ma part, j'ai tout réinstallé comme ça c'est fait mais bon ce n'est pas la solution à tous les maux....on croirait que personne n'a jamais fait de restore lol :mouarf: ...

Merci en tout cas.

@ +
Karim
08/09/2006, 00h32
remi4444

Refaire une standby, c'est repartir à "datafiles égaux" donc le restore que tu fais sur la primaire, tu le fais aussi sur la standby, tu fabriques un nouveau controlfile standby, tu lance ta standby et puis voilà.... je trouve pas que ce soit si compliqué que ça de refaire une standby, c'est pénible pour la première construction mais apres ça va (enfin je trouve...)
08/09/2006, 08h43
karimarien

oui effectivement

Quand tu es un dba master, il n'y a po de problème pour recréer une standby...mais quand on te colles sur un truc foireux et c'est pas ton domaine, eh bien tu te sors les doigts et tu fais au mieux...Je pourrais te parler des heures de la configuration des cartes mwam dans les routeurs Cisco que tu me dirais ah oué...tout est relatif ....

Ou sinon, quelles sont les commandes pour redémarrer la base en standby (alter database quelquechose standby database ??) ?
Et comment ça se passe au niveau du recovery manager ? Il faut le taquiner un peu ?

Ce sera mes dernières questions :-) ...

Bon Week-end a tous ...
Karim
08/09/2006, 10h35
Arturius

Si tu fait un reset log tu génères une nouvelle incarnation de ta base de données et le numéro des archive log repart à zéro. Il est normale dans ce cas la de devoir reconstruire tout le site stand by.
09/09/2006, 19h15
remi4444

Bien sur, il faut connaitre un peu les manips pour faire une standby, mais la doc oracle est assez bien faite :
http://download-uk.oracle.com/docs/c...a96653/toc.htm

Je trouve de toutes façons que c'est un travail interressant que d'apprendre à en construire une parce que ça t'amène à bien comprendre l'implémentation physique d'oracle.

Il y a pas de miracle, dans tout les cas, si tu n'as aucune expérience de dba et qu'on te colle des batterie de bases à gérer avec des système de standby etc... ce ne sera pas facile de s'en sortir avec un claquement de doigt. Ce sont des utopies de chefs que de penser que les gens sont interchangeables en quelque jours, si c'était le cas alors ça voudrait dire que notre metier et notre connaissance n'a aucune valeur ajoutée...