> Tech > Pour aller plus Loin

Pour aller plus Loin

Tech - Par iTPro - Publié le 05 mars 2015
email

DBCC IND

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.

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.

Téléchargez gratuitement cette ressource

Aborder la Blockchain, comprendre et démarrer

Aborder la Blockchain, comprendre et démarrer

Une véritable révolution se prépare progressivement... les entreprises doivent veiller à ne pas rester à l’écart et se faire prendre de vitesse. Tout comme la mobilité ou encore le cloud, la blockchain est une composante essentielle de la transformation numérique. Découvrez, dans ce dossier, comment aborder, comprendre et démarrer la Blockchain

Tech - Par iTPro - Publié le 05 mars 2015