DBCC PAGE, Pour aller plus Loin

Retrouvez la partie 1 de cet article ici.

Nous aurions également pu constater la corruption, en listant les pages associées à notre table par la commande DBCC IND : voir figure 3. Effectivement la pageID 6195 pointe vers la page 6196 (colonne NextPagePID) qui n’existe pas. De même la page 6197 à un reverse pointer qui pointe vers l’ID 6196 (colonne PrevPagePID). On voit clairement que l’ID de la page 6196 a été « remplacé » par une valeur aberrante 3276845. De même le FileID 55 n’existe pas dans la base, ce qui renforce le fait que la page est belle et bien corrompue.

DBCC PAGE, Mais notre page corrompue existe toujours !

Après avoir corrigé la base, un DBCC PAGE sur la page corrompue 6196 renvoie toujours la même erreur. Nous avons donc toujours une page corrompue présente dans notre base. Nous pouvons vérifier son statut d’allocation, en allant jeter un œil dans la page PFS correspondante. Facile dans notre exemple : une base de donnée comporte une page pfs toutes les 8088 pages. Notre page corrompue portant l’ID 6196, elle sera adressée par la première page PFS de la base (ID=1).

llons voir donc ce qu’il y a dans la page PageID=1 : voir figure 3.

Nous pouvons constater que la page est marquée comme NOT ALLOCATED. Aucun problème donc, si effectivement il est impossible pour le moment de faire un DBCC PAGE dessus, notre page étant marqué comme NOT ALLOCATED, elle est parfaitement réutilisable.

Et le problème de chainage constaté  via DBCC IND ? Le REPAIR_ALLOW_DATA_LOSS a-t-il corrigé le chaînage ? Vérifions : voir figure 4. La PageID 6196 n’apparait pas : normal, elle n’est pas allouée. Par contre, les pointeurs avant et après des pages suivantes et précédentes ne sont pas corrigés car ils adressent toujours le PID 6196. Et pourtant, un select  * de la table ne renvoie aucune erreur. En effet, la corruption s’est produite sur un Heap. Le parcours de la table se fait via les pages IAM et non pas en suivant les pointeurs de pages qui sont donc inutiles. La correction n’aurait donc servie à rien. Pour les puristes, il suffit de faire un rebuild de la table pour retrouver une structure cohérente. Cela n’aurait bien sur pas été le cas sur un index, qui utilise systématiquement le chainage pour ces parcours.

(((IMG7464)))

Conclusion:

Voila un bon exemple d’utilisation des commandes de détection (BACKUP WITH CHEKSUM, CHECKDB) et d’identification (commandes DBCC CHECKDB, PAGE, IND) d’une corruption de page de données. En présence d’une telle situation, il faut bien comprendre dans quel état se trouve la base avant d’entreprendre les actions correctrices, afin de minimaliser d’une part la perte de données (pas toujours évitable malheureusement) et d’autre part l’indisponibilité de la base. En parallèle, notre exemple nous permet d’illustrer combien la politique de backup est importante, car nous aurons parfois besoin de restaurer un backup en cas de corruption, et également l’utilité d’activer les checksum. Mais cela ne suffit pas, le checksum ne contrôlant que les corruptions physiques. Il est donc indispensable de le compléter par des DBCC CHECKDB régulier. Enfin, j’ajouterai qu’une fois le service rétablis, il est bien sur nécessaire de rechercher l’origine de la corruption, afin d’éviter qu’elle ne se reproduise…  Remerciement à Michel Degremont pour sa précieuse relecture.

Retrouvez la partie 1 de cet article ici.