Corruption de données : un cas concret (partie 1)

En effet, il n’y a malheureusement pas une méthode unique à suivre, applicable dans tous les cas. Le DBA devra s’adapter dans chaque situation, en fonction des objets corrompus et des types de corruptions. Je souhaite partager le dernier cas de corruption rencontré en environnement de production, afin d’illustrer l’utilisation des outils que nous utiliserons lorsque nous serons confrontés à cette situation. Le but étant de se familiariser avec ces outils avant d’être confronté au problème, afin d’avoir les bons réflexes, et éviter des actions malheureuses. Je ne balaierai donc pas ici tous les cas de corruptions possibles, et les méthodes à suivre dans chaque cas. Le cas que j’illustre ici concerne une table Heap, sans index cluster donc. La corruption a été détectée grâce à l’option CHECKSUM de la commande de backup. Je vais commencer par brièvement rappeler comment implémenter cette fonctionnalité pour que les backups puissent remonter les cas de corruptions physiques, lié au sous-système disque donc, l’option CHECKSUM ne permettant pas de détecter les corruptions « In memory ». Nous verrons ensuite l’utilisation de la commande DBCC CHECKDB qui vérifie l’intégrité de la base et nous offrira tous les détails concernant notre corruption. Enfin, nous verrons comment réparer la base en limitant au maximum la perte de données.

Configuration de l’option checkum dans la commande de backup

Configuration de la base de données

Il faut que l’option de base de données PAGE_VERIFY soit à CHECKSUM. Dès lors, le moteur calcule un checksum sur chacune des pages, basé sur la totalité du contenu de la page, puis l’écrit dans l’entête de la page juste avant d’écrire la page sur disque. Lorsque le moteur relie la page, il commence par recalculer le checksum puis le compare à celui précédemment stocké dans l’entête. Si les deux checksum sont identiques, la page est saine. Sinon, elle est corrompue. (Attention donc : une fois l’option checksum activée au niveau base, celui-ci ne sera calculé et écrit dans l’entête que lorsque la page sera montée en mémoire, modifiée, puis réécrite sur le disque : activer l’option ne suffit donc pas, il faut en plus que les pages soient réécrites.)

Configuration de la commande de backup

A partir du moment où le moteur enregistre le checksum de chaque page, il est possible de demander à la commande de BACKUP de vérifier les checksum à chaque lecture de page. Il suffit pour cela d’ajouter l’option WITH CHECKSUM à la commande BACKUP DATABASE. Grâce à cette option, le backup vérifiera le checksum à chaque lecture de page. Si un checksum ne correspond pas, le backup remontera une erreur et par défaut, s’arrêtera (comportement que l’on peut changer avec l’option CONTINUE_AFTER_ERROR).