Je ne sais pas si vous avez remarqué… Tous les DBA savent mettre en place une sauvegarde mais dès qu’il s’agit de restaurer un environnement critique parce qu’un « Qsxg@34Bbv~ », heureusement d’une autre équipe, a mis le SAN en compote et que le-dit environnement est « highly critical », il n’y a plus que deux ou trois personnes pour se retrousser les manches. Bizarrement, même quand le problème commence à minuit, je me retrouve dans l’histoire. Heureusement que j’ai des copains en Australie… Merci les kangourous!

Ce message s’adresse donc aux « Qsxg@34Bbv~ » et leurs responsables, aux DBA qui mettent en place des sauvegardes et sont bizarrement absents quand un problème arrive et aussi à VOUS et MOI, parce qu’on peut apprendre autant des erreurs des autres que des siennes…

Principes Fondamentaux

Comme dirait un bon copain : « C’est évident mais ça va mieux en le disant! ».
Les consultants vous le diront: « Une sauvegarde fait partie d’une stratégie de sécurisation »
J’ai tendance à penser: « Une sauvegarde est une tactique qui s’inscrit dans un contexte! »

Mettre en place une sauvegarde inclut de tester qu’on peut la restaurer sur un AUTRE serveur : ça vous permettra de vous assurez que vous n’oubliez pas un fichier dans l’histoire et de vous assurer aussi que vous n’avez besoin de personne pour restaurer votre base de données. C’est particulièrement vrai avec les Media Managers dont les agents pour RMAN sont très intelligents; s’il ne sont pas correctement paramétrés ou/et que vous ne leur envoyez pas les bonnes informations, ils offrent une sécurité à toute épreuve : vous ne pourrez pas accéder aux sauvegardes. Soyez attentifs également si vous faites des sauvegardes depuis plusieurs noeuds d’un cluster. Si vous faites des sauvegardes incrémentales toute la semaine, faites vos tests un vendredi et pas un lundi; faites vos tests après au moins 10 jours et pas juste après une installation. Mais vous savez tout ça, alors faites-le! Plus tard ça sera trop tard!

J’entends déjà mes responsables, mes collègues ou mes clients se plaindre du prix d’un test. Et si vous avez 500 bases de données? Industrialiser/standardiser n’interdit pas de tester! Préférez-vous découvrirez tous vos problèmes le mauvais jour? Ca pourrait vous coutez bien plus cher, jusqu’à sonner le glas de votre entreprise. Si votre base est corrompue et que vous n’avez pas de sauvegardes valides, vous pourrez toujours appeler une superstar du support d’Oracle mais, même lui, pourrait ne pas avoir que des bonnes nouvelles pour vous! Et ça ne lui fera pas plus plaisir qu’à vous…

Autre évidence, mettre en place une sauvegarde, c’est aussi mettre en place sa supervision. Et par supervision, je N’entends PAS « valider que les scripts sont exécutés et ne retournent pas d’erreurs ». J’entends s’assurer chaque jour que vous avez tout ce qu’il faut pour restaurer votre environnement. J’entends connaitre le temps qu’il vous faudra pour restaurer votre environnement pour chaque cas de panne. J’entends, valider que c’est conforme à vos engagements, votre SLA. J’entends évaluer les risques (et pas en % mais bien en € ou en $). Bien sur ce n’est pas facile! Mais (1) les professionnels le font et nous sommes des professionnels, (2) certains outils, en particulier Recovery Manager avec les commandes crosscheck, validate ou report vous aident et (3) c’est quand même plus intéressant que d’expliquer a posteriori pourquoi vous ou un autre s’est planté; surtout après s’être défoncé pendant 10 heures pour tout remettre d’équerre.

Enfin, on est tous, un jour, un « Qsxg@34Bbv~ » ou le responsables d’un « Qsxg@34Bbv~ » mais on peu essayer de l’être le moins souvent possible, au moins au travail. Il existe d’ailleurs des moyens de minimiser nos chances d’en être. Par exemple, aux US, par les temps qui courent, les « Qsxg@34Bbv~ » et les responsables de « Qsxg@34Bbv~ » ont une espérance de vie dans l’entreprise de l’ordre du LIO… Bien inférieure donc au temps qu’il m’a fallut pour revenir à la situation initiale. Inutile d’entrer dans le détail de la fin de l’histoire; j’ai ma médaille ça me suffit!

Principes Techniques

Ceci dit, il n’y a pas que des enseignements généraux que l’on peut tirer d’une situation comme celle-ci… Voici quelques considérations techniques:

• Utilisez à dessein la commande RMAN « delete expired« .

Imaginez le cas suivant: vous faites vos sauvegardes sur disque, dans une baies de stockage ou un filer séparé de votre production. Si pour une raison quelconque, y compris une maintenance planifiée pour appliquer un Firmware, vos fichiers de sauvegardes ne sont plus accessibles pendant que vous lancez une sauvegarde ou un script « cleanup », et vous faites, « crosscheck ...; delete expired ...;« , vous supprimez toutes les références des fichiers dans le catalogue ou le fichier de contrôle. Lorsque les sauvegardes sont de nouveaux disponibles, ça risque d’être très compliqué de retrouver vos petits (*). D’autre part les fichiers étant supprimés du catalogue, si vous vous appuyez sur la policy RMAN pour supprimer vos fichiers, delete obsolete ne supprimera pas le fichier que restera « éternellement » sur votre disque.

Autrement dit, la commande crosscheck sert à détecter des problèmes dans les sauvegardes et la commande delete expired sert à supprimer des références dans le catalogue une fois qu’on a expliqué le problème. A moins que vous utilisiez une politique de rétention extérieure à RMAN, n’utilisez pas delete expired dans vos scripts.

(*) En fait sur disque la commande catalog start with ... de 10g vous rendra la tache facile mais retrouver les handler des fichiers dans le Media Manager pour les re-cataloguer avec la commande catalog device type 'SBT_TAPE' backuppiece 'Qsxg@34Bbv~'; pourrait bien devenir un petit cauchemar.

• Par défaut un backup incrémental RMAN est différentiel… pas cumulatif!

C’est une idée faussement répandue… pour que votre incrémental soit cumulatif il faut en fait que vous utilisiez explicitement le mot clé cumulative. Autrement dit, si vous faite un incrémental « level 1 » tous les jours et un « level 0 » le dimanche, pour restaurer vendredi, vous devez appliquer 6 sauvegardes, non pas 2… A moins que vous n’utilisiez le mot clé cumulative.

Ceci amène une autre question qui est: « Comment déterminer le premier SCN d’un backup incrémental? ». La meilleure réponse que j’ai trouvée pour l’instant est la colonne incremental_change# de la vue v$backup_datafile que vous pouvez comparer au checkpoint_change# de v$datafile_header; je vous laisse construire la requête! Si vous trouvez une commande RMAN pour afficher la même information, laissez un commentaire.

• Attention aux fichiers offline!

Selon la manière dont un crash arrive, il se peut que certains fichiers passent offline avant que vos instances crashes. Il vous faudra donc les repasser online avant ou après avoir redémarrer votre base de données si, comme moi, vous repartez sur un current controlfile.

Dans le flot des erreurs, ce n’est pas toujours évident d’y pensez alors « Pensez-y! »

En outre, si le fichier fait partie du tablespace SYSTEM ou d’un UNDO, il est très probable
que votre base refuse de démarrer. Si c’est votre cas, l’erreur n’est pas forcément très explicite; voici un exemple de message d’erreur lorsque vous essayez de redémarrer une base avec 1 fichier undo offline:

ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '+DATA/redx/datafile/undotbs3.17.68234245'
Error 704 happened during db open, shutting down database
USER (ospid: 7081): terminating the instance due to error 704

Ce qui peut vouloir dire « datafile 5 offline » ou pas…

• Comment supprimer le membre d’un redo CURRENT ?

Si vous utilisez ASM et perdez le disk group qui contient un membre d’un redo log courant, vous ne pourrez pas copier un autre membre pour le remplacer, à moins que vous ne nommiez vos fichiers de redo logs avec des alias. En effet : vous ne pouvez pas copier un fichier et forcer son nom si ce nom est conforme à un format OMF. Vous vous retrouvez donc dans une situation ou vous n’avez pas tous les membres du redo log courant et dans l’impossibilité de supprimer le membre avec alter database drop logfile member ..., ni de changer de log courant avec alter system switch logfile;.

Et bien ce n’est pas grave! votre base de données pourra être ouverte sans tous les membres des redolog courant. En fait vous verrez des messages comme ci-dessous dans votre fichier alert.log et les membres seront automatiquement supprimés:

ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '+DATA/redx/onlinelog/group_2.72.665161291'
ORA-17503: ksfdopn:2 Failed to open file +DATA/redx/onlinelog/group_2.72.665161291
ORA-15012: ASM file '+DATA/redx/onlinelog/group_2.72.665161291' does not exist

Une fois la base réouverte, il vous suffira de changer de redo log courant et d’ajouter le membre supprimé comme ci-dessous:

alter database add logfile member '+DATA' group 2;

• Autre remarque

Les fichiers « temporaires » sont recréés automatiquement lors du redemarrage de la base de données. Je pensais que ce n’était que dans le cas d’un open resetlogs, ce que je n’ai pas fait(?). C’est peut-être parce que les fichiers sont OMF, ou une nouveauté de 11g… ou une fausse idée de ma part! Il faudrait bien que je teste ou que je cherche dans la documentation, un jour.

Conclusion

Si quelqu’un vous propose de gérer un ticket à minuit, demander lui pourquoi? Si vous voulez apprendre des trucs, prenez le ticket, sinon laissez-le à quelqu’un d’autre.