SQL Server vu par Christian Robert

SQL Server : Ai-je des données corrompus dans ma base de données (msdb.dbo.suspect_pages) ?

Depuis SQL Server 2005 une mécanique plus poussée a été mise en place pour la détection des problèmes de corruption logique et physique.

Historiquement un mécanisme appelé « Torn Page Detection », existe dans SQL Server et est actif par défaut sur les versions d'avant 2005. Il permet d'écrire des bits particuliers dans l'en tête de chaque page (en fait de chaque bloc de 512 octets dans les pages, assimilé aux secteurs). On inverse ces bits à chaque écriture ce qui permet de vérifier que celle-ci s'est bien déroulée. Ce système à faible coût en termes de processeur, permet de détecter certains problèmes de corruption physique, mais pas de loin pas tous.

ALTER DATABASE test SET TORN_PAGE_DETECTION ON

-- ou --

ALTER DATABASE test SET PAGE_VERIFY TORN_PAGE_DETECTION

Depuis SQL Server 2005 s'est ajouté à cette fonction le « Page CheckSum » qui n'est autre qu'une somme de contrôle de toute la page, sauf l'entête. De fait la moindre modification d'un octet dans la page est reflétée lors de la vérification du CheckSum. Cette fonctionnalité est active par défaut, elle consomme légèrement plus de ressource processeur que le « Torn Page Detection », mais détecte un bien plus vaste de domaine de corruption.

ALTER DATABASE test SET PAGE_VERIFY TORN_PAGE_DETECTION CHECKSUM

En effet, à la fois les corruptions physiques, mais aussi les corruptions logiques peuvent être détectées. La corruption physique ayant lieu généralement lors des phases de lecture et d'écriture disques. Côté corruption logique celle-ci arrive plus généralement lors du traitement de la page en mémoire, cela peut être un processus qui écrit dans la zone de mémoire de SQL Server ou carrément un bug.

Ces deux système, renvoie tous deux les erreurs 823 ou 824 en cas de détection de l'une des 2 types de corruption. Le premier concerne la corruption physique (problème de lecture), le second une corruption logique (inconsistance du checksum). En complément l'erreur 832 peut aussi être levée lors de modification ultérieure en mémoire (je vous laisse lire le spécialiste du sujet : http://www.sqlskills.com/BLOGS/PAUL/post/Dont-confuse-error-823-and-error-832.aspx).

Ce qui est intéressant, c'est indépendamment du fait que vous traciez ou non les erreurs survenant sur votre serveur (ce que je ne saurais que trop vous recommander), celles-ci sont stockées dans la base de données système msdb, dans une table appelée msdb.dbo.suspect_pages.

SELECT * FROM msdb.dbo.suspect_pages

Bref, si le moindre enregistrement apparaît dans cette table, intéressez vous à la fiabilité de votre système disque.

En complément, il est possible de supprimer les vérifications de pages, en passant la commande :

ALTER DATABASE test SET PAGE_VERIFY NONE

Mais soyez vraiment sûr de votre système disque avant cela. Si vous réactivez la vérification par CheckSum, sachez de plus que les CheckSum ne seront recrées pour les pages que lorsqu'elles seront écrites ultérieurement sur le disque.

Bonne récupération…