Sixième article de la série Une approche pragmatique de la production SQL Server, c’est le contrôle de cohérence des objets d’une base qui est abordé ici.
Cohérence d’un objet ?
Un fichier de données est constitué de pages (ensembles contigu de 8 k. octets). Lorsque SQL Server écrit une page sur disque, il calcule une signature (CHECKSUM) sur quelques octets et l’écrit dans l’entête de la page. Cette signature est recalculée lors d’une lecture et comparée à la valeur stockée dans l’entête pour garantir la cohérence.
Cet entête contient aussi plusieurs informations comme l’objet auquel elle appartient, la page qui la précède dans le chaînage de l’objet et la page qui la suit. Certaines pages spécifiques (pages IAM) listent l’ensemble des pages d’un objet.
Problème de cohérence ?
Lors de la lecture d’une page depuis le disque, la signature est calculée et comparée à la signature stockée. Si les deux valeurs sont différentes, la page est considérée non cohérente.
Si la page IAM d’un objet référence une page, et que cette page référence un autre objet, il y a incohérence.
Si une page A désigne une page B comme « suivante » dans le chaînage et que cette page B ne désigne pas la page A comme « précédente », il y a incohérence.
SQL Server refusera de lire une page incohérente et renverra une erreur (que cette lecture corresponde à un « select » ou un « backup database » par exemple…).
Et concrêtement ?
Lorsqu’une page est incohérente, certains objets ne seront plus consultables, et les tâches de maintenance critiques comme la sauvegarde ne fonctionneront plus. Il est donc important de détecter au plus vite un problème de cohérence.
Il est possible de récupérer une page corrompue sans perdre de données sous certaines conditions :
• Soit la page corrompue appartient à un indexe non clustérisé. La page ne contient donc aucune donnée, l’indexe peut être reconstruit sans risque (option REPAIR_REBUILD de la commande DBCC CHECKDB)
• Soit la base est en miroir. Le mécanisme Automatic Page Repair (à partir de SQL Server 2008 ) utilisera la base miroir pour récupérer la page corrompue.
• Soit la base est en mode de recouvrement COMPLET. Il est possible de restaurer une ou plusieurs pages (à partir de la dernière sauvegarde de base) puis de réappliquer les modifications sur ces pages (restauration des sauvegardes transactionnelles). Cette opération entraine une indisponibilité, mais elle est minime.
Donc si vos bases sont en miroir ou qu’elles sont en mode de recouvrement COMPLET, la fréquence de lancement du contrôle de cohérence peut être plus faible. Pour les autres bases, la fréquence de lancement dépend de la perte de données acceptable.
En pratique
Le lancement du contrôle est simple, puisqu’il consiste simplement à lancer la commande DBCC CHECKDB.
Le script suivant permet de lancer DBCC CHECKDB sur toutes les bases, à l’exception des Snapshots, de tempdb et des bases en lecture seule, et ne remonte que les messages d’erreur :
EXEC sp_msforeachdb 'IF (CAST(DATABASEPROPERTYEX(''?'',''Updateability'') as varchar(15)) = ''READ_WRITE'' AND ''?'' NOT IN (''tempdb''))
DBCC CHECKDB(''?'') WITH NO_INFOMSGS, ALL_ERRORMSGS
'
Un fichier de dump est créé chaque fois que DBCC CHECKDB rencontre une erreur de cohérence. La remonté d’alertes lors de corruption peut donc correspondre à l’arrivée d’un nouveau fichier SQLDUMP<Id>.txt ( où <Id> est un nombre à 4 chiffres qui s’incrémente automatiquement).
Continuez votre lecture sur le blog :
- Production SQL Server : Sauvegardes (Benjamin VESAN) [SQL Server]
- Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David Baffaleuf) [SQL Server]
- Production SQL Server : Les Statistiques (Benjamin VESAN) [SQL Server]
- Production SQL Server: Réorganisation des objets (Benjamin VESAN) [SQL Server]
- Production SQL Server: Suivi et Contrôle du parc (Benjamin VESAN) [SQL Server]