Je suis en train de remplacer le matériel d'un cluster RAC à 3 nœuds existant. Ce système est également le principal d'une base de données de secours RAC à 2 nœuds. Pour remplacer le matériel, mon plan est d'étendre temporairement le cluster dans une configuration à 6 nœuds, 3 anciens serveurs et 3 nouveaux serveurs. Une fois que les instances s'exécutent sur le nouveau matériel et que mes applications se connectent aux nouvelles instances, je supprime les anciennes instances et retire les anciens serveurs, pour revenir à une configuration à 3 nœuds.
Après avoir étendu le cluster aux six nœuds, le week-end dernier, j'ai démarré les nouvelles instances sur les nouveaux nœuds. Pour me faciliter la vie, je viens de tirer parti de la DBCA pour ce travail. Après avoir lancé le DBCA, j'ai choisi de travailler sur une base de données RAC, puis j'ai choisi Instance Management, puis Add New Instance. En parcourant l'assistant, je laisse la DBCA s'occuper de tous les détails pour moi. Cela semble simple.
Ce matin, j'ai reçu mon rapport de décalage d'archivage habituel. Il ressemble à ce qui suit :
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Je l'envoie dans ma boîte de réception deux fois par jour. Un coup d'œil rapide m'aide à déterminer si mon standby reçoit et applique des transactions du primaire. J'ai défini toutes mes bases de données de secours sur un délai d'application de quatre heures. Et mon principal a ARCHIVE_LAG_TARGET défini sur une heure. Cela signifie que le délai d'application sera d'au moins 4 heures mais ne devrait pas dépasser 5 heures. Comme nous pouvons le voir ci-dessus, nous avons deux bases de données de secours qui ont largement dépassé le délai d'application maximal de 5 heures. Au dessus, j'ai le standby avec un décalage d'application de 1 jour 21 heures ! J'ai donc tout de suite su que quelque chose n'allait pas. Et il n'a pas fallu être un génie pour savoir que l'ajout de la nouvelle instance à la principale a probablement contribué au problème.
Comme je l'ai dit au début de cet article, j'ai un système de secours RAC à 2 nœuds. Une instance est "l'instance d'application" et l'autre instance reste relativement inactive. Dans mon journal d'alerte d'instance d'application, j'ai vu les messages d'erreur suivants :
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Étant donné que ma base de données de secours est définie sur STANDBY_FILE_MANAGEMENT=AUTO, la première partie des messages a du sens. Lorsque vous ajoutez une nouvelle instance à une base de données RAC, vous devez fournir un tablespace d'annulation uniquement pour cette instance et vous devez également fournir des groupes de journaux redo en ligne dédiés au thread de cette instance. La DBCA m'a spécifiquement posé des questions concernant les structures de fichiers d'annulation et de rétablissement. Dans le contenu du journal des alertes ci-dessus, nous pouvons voir que le standby a ajouté avec succès le fichier de données 342, qui est mon tablespace Undo. Mais le serveur de secours n'a pas pu ajouter les journaux redo en ligne. Si vous souhaitez que le standby puisse ajouter automatiquement les redo logs en ligne, vous devez spécifier les paramètres OMF, ce que j'hésite à faire. Étant donné que l'ajout du fichier de journalisation en ligne a entraîné une erreur, le serveur de secours a arrêté la récupération du support. La veille reçoit toujours des journaux.
Je n'ai pas trouvé grand-chose sur Metalink ou en faisant des recherches Google sur la façon de résoudre ce problème, mais voici les étapes que j'ai suivies pour remettre Media Recovery en marche. Sur la base de données de secours (j'ai fait cela sur l'instance d'application, mais cela devrait être viable sur n'importe quelle instance de la base de données de secours du RAC) :
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Cela ne devrait pas être un choc car nous savons que la récupération gérée a été interrompue. Mais pour être complet, j'ai inclus cette étape. Si vous devez ajouter des journaux redo à un standby qui applique actuellement des transactions, vous aurez besoin de cette étape.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
Ce qui précède est exactement ce qui a été exécuté sur le primaire. Besoin d'ajouter le journal redo sur le standby exactement comme fait sur le primaire. Répétez l'opération pour chaque groupe de fichiers de journalisation ajouté sur le principal. Depuis que j'ai ajouté 3 instances à ma base de données RAC principale, je dois ajouter trois threads ici.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Démarrez la récupération gérée. Tout devrait être bon maintenant et nous pouvons vérifier dans le journal des alertes de l'instance d'application :
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Nous pouvons également vérifier que le délai d'application est de plus en plus court. En veille, émettez ce qui suit :
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
Pour obtenir des informations générales sur la gestion des journaux redo en ligne pour votre base de données de secours physique, consultez la note Metalink 740675.1 Online Redo Logs in a Standby.
