Base SQL Server corrompue : que faire, et que ne pas faire.

Reconnaître une corruption

Les signes les plus courants :

• Erreur 823 : échec d'une lecture ou d'une écriture au niveau du système d'exploitation ou du disque.
• Erreur 824 : incohérence logique détectée dans une page de données.
• Erreur 825 : lecture réussie seulement après plusieurs tentatives. C'est un signal d'alerte, souvent annonciateur d'une panne de stockage.
• Une base en état SUSPECT ou RECOVERY_PENDING, ou qui ne se met plus en ligne.
• Des erreurs rapportées par DBCC CHECKDB, ou des lignes dans la table msdb.dbo.suspect_pages.

Les premiers réflexes

• Arrêter les écritures sur la base si c'est possible.
• Copier les fichiers de données et de journal (.mdf, .ndf, .ldf) avant toute action, si l'espace le permet.
• Noter les messages d'erreur exacts, avec l'heure du premier incident.
• Ne pas redémarrer le service en boucle, ne pas détacher une base suspecte (elle risque de ne plus se rattacher), ne pas supprimer de fichier de journal.
• Faire l'inventaire des sauvegardes disponibles : dernière complète, différentielle, journaux.

Mesurer l'étendue des dégâts

On lance DBCC CHECKDB sans option de réparation, de préférence sur une copie restaurée de la base pour ne pas charger la production. Le résultat indique quelles pages et quels objets sont touchés.

L'importance de la corruption dépend de l'objet atteint : un index non clusterisé endommagé se reconstruit sans perte, alors qu'une page de données de table est un problème plus sérieux.

Choisir la voie de récupération

Par ordre de préférence :

• Restauration depuis sauvegarde : complète, puis différentielle, puis journaux jusqu'à un instant précédant l'incident. C'est la voie la plus sûre.
• Restauration de pages : quand seules quelques pages sont touchées et que le modèle de récupération et les sauvegardes le permettent.
• Reconstruction de l'index : si la corruption ne touche qu'un index non clusterisé.
• Extraction des données lisibles vers une nouvelle base, quand aucune sauvegarde exploitable n'existe.
• REPAIR_ALLOW_DATA_LOSS : dernier recours. L'option supprime les pages endommagées pour rendre la base cohérente. Elle fait perdre des données et peut rompre la cohérence applicative. Elle ne s'utilise qu'après copie des fichiers et jamais en première intention.

Chercher la cause

Une corruption a presque toujours une origine matérielle ou système : disque ou contrôleur défaillant, pilote ou micrologiciel (firmware) en cause, coupure d'alimentation, couche de stockage ou de virtualisation défaillante. Tant que la cause n'est pas trouvée, la corruption peut revenir. Les journaux du système d'exploitation et les alertes du stockage sont à examiner en même temps que la base.

Prévenir

• Planifier DBCC CHECKDB régulièrement sur toutes les bases, sur la production ou sur une copie restaurée.
• Vérifier que l'option PAGE_VERIFY est à CHECKSUM, en particulier sur les bases anciennes.
• Faire les sauvegardes avec l'option CHECKSUM et tester leur restauration.
• Créer des alertes SQL Server Agent sur les erreurs 823, 824 et 825.