Discussion :

[karimarien]

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 ???

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.

[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?

[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 ..)

[orafrance]

Merci d'éditer les messages et ajouter les balises CODE ou QUOTE

[remi4444]

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....

[karimarien]

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 :

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 ID11.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 ID19.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 ID10.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 ?

[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

[remi4444]

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

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

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.