Discussion :

[Francky8]

Bonjour,

J'ai l'option Page Verify à CHECKSUM sur mes bases.
J'ai l'option CHECKSUM sur le backup de mes bases.
J'ai un job qui surveille la table suspect_pages (msdb) et qui envoie un email en cas d'alerte.
J'aimerais m'assurer de l'intégrité de mes bases.
Est-ce que l'option CHECKSUM que j'utilise au niveau base et backup est suffisante pour m'assurer d'avoir des bases en "bonne santé" ?
Ou est-ce qu'il faut impérativement mettre en place un job quotidien qui vérifie les bases (je pense notamment à dbcc check) ?
Sachant que cette vérification de base (dbcc checkdb) aura des conséquences au niveau charge en raison de la taille de certaines bases.

Par avance, merci pour votre aide.

Franck

[elsuket]

Bonjour,

Est-ce que l'option CHECKSUM que j'utilise au niveau base et backup est suffisante pour m'assurer d'avoir des bases en "bonne santé" ?

Malheureusement non

L'option de base de données PAGE_VERIFY à CHECKSUM est une bonne chose, mais elle ne recalcule la somme de contrôle que lorsque la page est chargée en RAM à partir des disques, modifiée en RAM, puis écrite sur disque après ce changement.

L'option CHECKSUM de l'instruction BACKUP est aussi une bonne chose, puisqu'alors toutes les pages allouées sont vérifiées par le calcul de cette somme de contrôle lors d'un backup complet de la base. Cette vérification est aussi réalisée lors des sauvegardes différentielles, mais seulement pour les pages qui ont été modifiées depuis la dernière sauvegarde complète.

Ces mécanismes permettent de détecter au plus tôt des pages corrompues, en augmentant la fréquence de calcul de la somme de contrôle. Mais aucun mécanisme ne garantit qu'aucune page n'est corrompue. En effet, même lorsqu'on exécute DBCC CHECKDB, il est tout à fait possible qu'une page soit corrompue juste après l'exécution de cette commande sans détection d'erreur.

Une corruption plus insidieuse pourrait être, par exemple, l'écriture d'une page en RAM avec son checksum, corrompue par une barrette de RAM défectueuse : dans ce cas on a une somme de contrôle correcte, mais une page incorrecte. Le seul moyen de le détecter est d'utiliser DBCC CHECKDB.

Identiquement, on peut mettre en place une session d'événements étendus ou des alertes de l'Agent SQL Server sur génération des erreurs 823 à 825 : c'est un bon mécanisme, mais encore une fois on n'a pas de garantie que d'autres pages ne sont pas corrompues. Ceci est simplement du au fait qu'une base de données vit, que des pages sont échangées entre les disques et la RAM, ...

Ou est-ce qu'il faut impérativement mettre en place un job quotidien qui vérifie les bases (je pense notamment à dbcc check) ?

Vous l'aurez compris, c'est un passage obligé.

Sachant que cette vérification de base (dbcc checkdb) aura des conséquences au niveau charge en raison de la taille de certaines bases.

Pour les plus grosses bases, vous pouvez découper le travail que fait DBCC CHECKDB par les instructions que celle-ci exécute implicitement : DBCC CHECKCATALOG, DBCC CHECKTABLE, DBCC CHECKALLOC. Vous pouvez aussi, si vous avez plusieurs groupes de fichiers, vous en remettre à DBCC CHECKFILEGROUP. Il suffit alors de créer de groupes de tables suivant leur taille, de façon à équilibrer le volume de données à vérifier sur les jours de la semaine par exemple, en exécutant les vérifications sur les tables les plus volumineuses dans les périodes creuses ou plus longues (4h de nuit en semaine, 8h le weekend par exemple).

Notez aussi que depuis le SP2 de SQL Server 2014, les instructions DBCC CHECKDB et DBCC CHECKFILEGROUP sont parallélisables (voir leur option MAXDOP).

@++

[Francky8]

Bonjour elsuket,
Merci beaucoup pour cette réponse claire et précise.
Je vais donc adapter mes vérifications en fonction de tes conseils.

Encore merci

Franck

[Francky8]

Re-bonjour elsuket,

Je me pose une question concernant votre phrase :
"L'option de base de données PAGE_VERIFY à CHECKSUM est une bonne chose, mais elle ne recalcule la somme de contrôle que lorsque la page est chargée en RAM à partir des disques, modifiée en RAM, puis écrite sur disque après ce changement."
Sauf si j'ai mal compris mais vous semblez dire que ce contrôle n'est réalisé que lors des écritures. C'est bien cela ?

Pour ma part, j'avais compris que ce CHECKSUM est calculé et écrit lors d'une opération d'écriture. Ensuite, à chaque lecture, un recalcul (CHECSUM) est réalisé afin de vérifier s'il correspond au CHECSUM réalisé lors de l'opération d'écriture. Ce qui aurait pour conséquence d'avoir un contrôle des pages à chaque opération de lecture. Vous confirmez ou pas ?

En tout cas, merci pour vos précieuses explications ...

Franck

[SQLpro]

Ne confondez pas écriture logique => en RAM et écriture physique => disque.

A +

[Francky8]

Bonjour Frédéric,

Je voulais être certain d'avoir bien compris le fonctionnement de CHECKSUM.
Voilà comment je vois le fonctionnement :
une vérification est faite lors de toute lecture c'est-à-dire
la page est chargée en mémoire,
un recalcul du CHECKSUM est fait
et la valeur trouvée est comparée avec la valeur stockée dans l'entête de la page.
C'est bien cela ?

Merci pour vos éclaircissements

Franck