Après une récente panne de courant sur notre site de reprise après sinistre, j'ai découvert qu'une veille avait cessé d'appliquer les journaux. Apparemment, dans les journaux redo archivés, il y avait une transaction qui augmentait un fichier de données, mais le disque du site de secours n'avait pas assez d'espace disque pour permettre à cette transaction de se terminer. Ainsi, la récupération gérée de secours a terminé, comme il se doit.
Nous conservons normalement les redo logs archivés pendant 7 jours. Malheureusement, au moment où j'ai découvert cette situation, 15 jours s'étaient écoulés et les journaux redo archivés étaient "manquants". En l'absence de journaux redo archivés à appliquer, la seule solution consistait à reconstruire la base de données à partir de zéro. Cette base de données a une taille d'environ 7 To, donc reconstruire à partir de zéro n'est pas une mince affaire.
Le principal est une base de données RAC 11.2.0.2 à 3 nœuds fonctionnant sous Linux. La veille est une base de données RAC à deux nœuds, évidemment les mêmes versions d'Oracle et de système d'exploitation.
Voici comment nous avons réussi à reconstruire la veille :
- Nous avons mis le serveur principal en mode de sauvegarde à chaud et pris un instantané de la base de données sur disque.
- L'instantané a été copié sur un support externe. Remarque :L'expédition sur le WAN prenait trop de temps.
- Le support externe a été transporté en main propre sur le site DR.
- Le LOG_ARCHIVE_DEST_STATE_n pour la veille a été défini sur DEFER.
- La base de données de secours a été supprimée de la configuration de DG Broker : REMOVE DATABASE standby PRESERVE DESTINATIONS ;
- Les points de montage de la base de données de secours ont été effacés. Après tout, la base de données était essentiellement inutile à ce stade.
- De nouveaux points de montage ont été créés et l'instantané a été écrit sur le disque du site DR.
- Une fois les transferts de fichiers terminés (environ 5 jours), nous avons demandé à notre espace de stockage de mettre à jour l'instantané sur le site DR avec un instantané plus récent. Cela a été effectué sur le WAN puisque seules les modifications ont été envoyées, ce qui était beaucoup, beaucoup plus petit que la base de données.
- Un fichier de contrôle de secours a été créé : ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/dir/path' ;
- Pour simplifier les choses, nous voulions utiliser une instance de secours unique jusqu'à ce qu'elle soit opérationnelle. Nous avons donc créé un PFILE à partir du SPFILE RAC de secours, puis utilisé un éditeur de texte pour modifier le fichier de paramètres afin de supprimer tous les paramètres compatibles RAC. Nous avons supprimé CLUSTER_DATABASE, défini un paramètre UNDO_TABLESPACE spécifique à l'instance à utiliser pour toutes les instances "*.", supprimé les paramètres THREAD, etc. Notre base de données de secours normale a deux instances, STANDBY1 et STANDBY2. Dans le nœud 1, nous avons placé le pfile dans $ORACLE_HOME/dbs/initstandby.ora au lieu de initstandby1.ora afin que la base de données à instance unique puisse trouver son fichier de paramètres. Nous avons fait quelque chose de similaire pour le fichier de mots de passe.
- Nous avons copié le fichier de contrôle de secours de l'étape 9 sur les fichiers de contrôle de l'instantané de la base de données.
- Avec les fichiers pfile et pswd en place pour une seule instance de base de données, nous avons effectué STARTUP MOUNT.
- Nous avons créé tous les journaux redo de secours dont nous aurions besoin. Dans notre cas, le primaire dispose également de redo logs de secours pour faciliter les opérations de basculement et les redo logs de secours du primaire ne faisaient pas partie de l'instantané. Nous avons donc dû retirer les SRL qui n'avaient pas fait le voyage.
- Dans le primaire, définissez LOG_ARCHIVE_DEST_STATE_n sur ENABLE.
- Dans les instances principales, effectué ALTER SYSTEM SWITCH LOGFILE ;
- Vérifié dans les journaux d'alertes du serveur principal et du serveur de secours que le serveur de secours recevait les journaux, c'est-à-dire vérifié que le transport des journaux fonctionnait.
- Activation de la veille gérée :ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION ;
- Vérifié dans le journal des alertes de veille que les journaux étaient appliqués, c'est-à-dire que l'application vérifiée fonctionnait désormais.
À ce stade, nous avions une base de données de secours en cours d'exécution. Nous avons créé une table simple dans le primaire et y avons inséré une ligne de données, effectué à nouveau les changements de journal, puis ouvert la veille en mode LECTURE SEULE pour vérifier que la transaction a été rejouée dans la veille comme il se doit. Une fois que nous avons été convaincus que la base de données de secours fonctionnait, nous devons en faire une base de données RAC. Eh bien, tout est déjà en place pour qu'il s'agisse d'une base de données RAC, car elle l'était autrefois. Pour terminer le travail, nous avons simplement arrêté la base de données de secours à instance unique (SHUTDOWN ABORT) dans SQL*Plus, puis utilisé srvctl pour démarrer la base de données de secours en tant que base de données RAC :
srvctl start database -d standby -o mount
La seule chose qui restait à ce stade était d'ajouter la veille à la configuration DG Broker (dans DGMGRL) : ADD DATABASE standby
Lorsque cela s'est produit pour la première fois, j'étais nerveux de savoir comment cela se passerait avec une si grande base de données. Aucune des opérations ci-dessus ne dépend de la taille autre que la copie des fichiers vers et depuis le support. Mais tout s'est bien passé.
Pour nous assurer que nous ne rencontrons pas cette situation à l'avenir, nous avons ajouté des alertes à notre Oracle Enterprise Manager Grid Control. Je vais maintenant recevoir une alerte AVERTISSEMENT lorsque l'envoi de journaux ou l'application de journaux a 12 heures de retard et une alerte CRITIQUE lorsqu'il y a 24 heures de retard. Cela devrait nous donner suffisamment de temps pour résoudre les problèmes avant que les journaux redo archivés ne soient automatiquement supprimés après 7 jours, ou à tout le moins, modifier le processus pour conserver plus de jours de redo logs archivés jusqu'à ce que nous corrigions la situation.
