Lorsque je travaillais récemment sur une base de données de secours, je suis allé voir DG Broker pour vérifier l'état et j'ai reçu ceci :
DGMGRL> afficher la configuration Configuration - resp_ress_config Mode de protection :MaxPerformanceDatabases : resp - Base de données principale - Base de données de secours physiqueErreur :ORA-16766 :Redo Apply est arrêté
Hmm… ma veille n'applique pas de refaire. Lorsque j'ai tenté de démarrer la récupération gérée, j'ai reçu ce qui suit dans le journal des alertes de veille :
Tue Dec 31 09:52:10 2013Managed Standby Recovery start Real Time ApplyTue Dec 31 09:52:10 2013MRP0 :Background Media Recovery terminé avec l'erreur 38868Errors in file /u01/app/oracle/diag/rdbms/ress/ress2 /trace/ress2_pr00_13905.trc:ORA-38868 :avertissement :le fichier de contrôle peut avoir une structure de fichier de données incorrecte. ress2/trace/ress2_pr00_13905.trc:ORA-38868 : avertissement :le fichier de contrôle peut avoir une structure de fichier de données incorrecte.Donc, l'ORA-38868 me dit que j'ai une mauvaise structure de répertoires. Ma première pensée a été que cela était lié au travail sur lequel j'ai blogué hier. Mais ce travail était du côté primaire. J'ai regardé le journal des alertes de veille et j'ai trouvé la première occurrence de cette erreur il y a environ 2,5 mois. S'il s'agissait d'un système de production, je pourrais avoir beaucoup de mal à laisser ce problème passer inaperçu pendant cette période. Mais j'ai mis en place des mesures pour m'alerter si ma veille de production est en retard par rapport à la primaire pendant une période de temps inacceptable. Ce n'est qu'un système de test que je peux souffler et recommencer à zéro si j'en ai besoin. Mais en quoi serait-ce amusant ? Voyons si nous pouvons résoudre le problème.
Mon premier arrêt était Metalink. Mais je n'ai eu aucun résultat pour l'erreur ORA-38868. Lors d'une recherche sur le Web, j'ai obtenu un résultat pertinent qui offrait une solution consistant simplement à redémarrer l'instance et à redémarrer l'application de rétablissement. J'étais sceptique, mais j'ai essayé la solution facile. Il n'est pas surprenant qu'un simple redémarrage de l'instance n'ait pas résolu le problème. L'erreur me dit que mon fichier de contrôle est corrompu. Le redémarrage de l'instance ne résoudra pas la corruption du fichier de contrôle. Puisque Metalink et Internet ne sont d'aucune utilité, je suppose que c'est à moi de résoudre ce problème. Si tout le reste échoue, je vais simplement supprimer la veille et la recréer.
Ma solution initiale est de revenir au primaire et de créer un fichier de contrôle de secours. Démarrez ensuite le standby avec le fichier de contrôle du standby. J'ai confiance qu'un nouveau fichier de contrôle du primaire résoudra le problème. Cependant, je dois appliquer 2,5 mois de refaire dont je n'ai plus de disponible.
J'ai essayé d'étudier l'utilisation de RMAN pour faire avancer une veille via une sauvegarde incrémentielle. Mais cela semble tomber bas dans ma liste prioritaire de choses à faire. J'ai un projet à venir où j'aurai besoin de savoir comment faire cela et ce projet est maintenant dans moins d'un mois. Cela semble donc être le moment idéal pour pratiquer cette technique pour mon prochain projet et pour résoudre mon problème actuel. Les étapes pour ce faire sont dans :
Metalink Note 836986.1 Étapes à suivre pour restaurer une base de données de secours à l'aide de sauvegardes incrémentielles RMANLes étapes décrites dans ce document ont non seulement avancé ma veille, mais ont également recréé les fichiers de contrôle, résolvant ainsi mon problème.
