Présentation et gestion de la table suspect_pages
La table suspect_pages réside dans la base de données msdb et a été introduite dans SQL Server 2005. La table suspect_pages, conçue pour gérer les informations sur les pages suspectes, permet de décider si une restauration est nécessaire ou non.
Une page est considérée « suspecte » quand le Moteur de base de données SQL Server rencontre l'une des erreurs suivantes alors qu'il essaie de lire une page de données :
Une erreur 823 provoquée par un contrôle de redondance cyclique (CRC) généré par le système d'exploitation, telle qu'une erreur disque (certaines défaillances matérielles)
Une erreur 824 telle qu'une page endommagée (toute erreur logique)
L'ID de page de chaque page suspecte est enregistré dans la table suspect_pages. Le moteur de base de données enregistre toutes les pages suspectes détectées lors du traitement standard, notamment dans les cas suivants :
une requête doit lire une page ;
au cours d'une opération DBCC CHECKDB ;
au cours d'une opération de sauvegarde.
La table suspect_pages est aussi mise à jour selon les besoins au cours d'une opération de restauration, une opération de réparation DBCC ou une opération de suppression de base de données.
Erreurs enregistrées dans la table suspect_pages
La table suspect_pages contient une ligne pour chaque page dans laquelle une erreur 824 (avec une limite de 1 000 lignes) s'est produite. Le tableau suivant présente les erreurs consignées dans la colonne event_type de la table suspect_pages.
Description de l'erreur |
Valeur event_type |
|---|---|
Erreur 823 provoquée par une erreur CRC du système d'exploitation ou erreur 824 autre qu'une somme de contrôle incorrecte ou une page endommagée (par exemple, ID de page incorrect) |
1 |
Somme de contrôle incorrecte |
2 |
Page endommagée |
3 |
Page restaurée (la page a été restaurée après avoir été marquée comme incorrecte) |
4 |
Page réparée (par DBCC) |
5 |
Page désallouée par DBCC |
7 |
La table suspect_pages enregistre aussi les erreurs temporaires. Elles peuvent être le résultat notamment d'une erreur d'E/S (un câble déconnecté, par exemple) ou de l'échec temporaire d'un test de somme de contrôle répété sur une page.
Mise à jour de la table suspect_pages à l'aide du moteur de base de données
Le moteur de base de données entreprend les actions suivantes dans la table suspect_pages :
Si la table n'est pas remplie, elle est mise à jour à chaque erreur 824 afin de signaler qu'une erreur s'est produite, et le compteur d'erreurs est incrémenté.
Si une page comporte une erreur après qu'elle ait été corrigée par réparation, restauration ou désallocation, sa valeur number_of_errors est incrémentée et sa colonne last_update est mise à jour.
Après la correction d'une page répertoriée par une opération de restauration ou de réparation, cette opération met à jour la ligne suspect_pages pour indiquer que la page est réparée (event_type = 5) ou restaurée (event_type = 4).
Si vous procédez à une vérification DBCC, toutes les pages exemptes d'erreurs sont marquées comme étant réparées (event_type = 5) ou désallouées (event_type = 7).
Mises à jour automatiques dans la table suspect_pages
Un serveur partenaire de mise en miroir de bases de données met à jour la table suspect_pages après l'échec d'une tentative de lecture d'une page d'un fichier de données pour l'une des raisons suivantes :
Une erreur 823 provoquée par une erreur CRC du système d'exploitation
Une erreur 824 (altération logique telle qu'une page endommagée)
Les actions suivantes suppriment automatiquement des lignes de la table suspect_pages.
ALTER DATABASE REMOVE FILE
DROP DATABASE
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS met à jour la table suspect_pages pour indiquer chaque page qu'il a désallouée ou réparée.
L'action RESTORE met également à jour la liste. Une restauration complète de fichier ou de page marque les entrées de pages comme restaurées.
Rôle de maintenance de l'administrateur de base de données
Les administrateurs de base de données sont responsables de la gestion de la table ; leur rôle consiste principalement à supprimer les lignes anciennes. La table suspect_pages est limitée en taille ; une fois la table remplie, les nouvelles erreurs ne sont plus consignées. Pour empêcher la saturation de la table, l'administrateur de la base de données ou l'administrateur système doit manuellement y effacer les anciennes entrées en supprimant les lignes. Par conséquent, nous vous recommandons de supprimer ou d'archiver régulièrement les lignes dont la colonne event_type indique que la page a été restaurée ou réparée, ou les lignes dont la valeur last_update est ancienne.
Pour surveiller l'activité sur la table suspect_pages, vous pouvez utiliser la Classe d'événements Database Suspect Data Page. Des lignes sont parfois ajoutées à la table suspect_pages à cause d'erreurs temporaires. Cependant, si de nombreuses lignes sont ajoutées à la table, le sous-système d'E/S est probablement défectueux. Si vous remarquez une augmentation soudaine du nombre de lignes ajoutées à la table, nous vous recommandons de rechercher la source des problèmes éventuels dans le sous-système d'E/S.
Un administrateur de base de données peut également insérer ou mettre à jour des enregistrements. Par exemple, la mise à jour d'une ligne peut être utile si un administrateur de base de données sait qu'une page suspecte particulière est intacte en réalité, mais souhaite malgré tout conserver l'enregistrement correspondant pendant un certain temps.
Exemples
L'exemple ci-dessous supprime toutes les lignes de la table suspect_pages.
' Select restored, repaired, or deallocated pages.
DELETE FROM msdb..suspect_pages
WHERE (event_type = 4 OR event_type = 5 OR event_type = 7);
GO
L'exemple ci-dessous sélectionne des pages incorrectes dans la table suspect_pages.
' Select nonspecific 824, bad checksum, and torn page errors.
SELECT * FROM msdb..suspect_pages
WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);
GO