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

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

Data - Par Olivier Maître - Publié le 07 janvier 2015
email

La corruption de données est la hantise de tous les DBA. Elle peut être lourde de conséquences, et complexe à traiter.

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).

Téléchargez cette ressource

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Data - Par Olivier Maître - Publié le 07 janvier 2015