Présentation et gestion de la table suspect_pages
Mis à jour : 5 décembre 2005
SQL Server 2005 conserve des informations au sujet des pages suspectes dans la table suspect_pages de la base de données msdb de chaque instance du serveur. La table suspect_pages permet de décider si une restauration est nécessaire ou non.
Lorsque le moteur de base de données SQL Server lit une page de la base de données contenant une erreur 824 (voir le tableau ci-dessous), la page est jugée « suspecte » et son ID 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. Les erreurs 824 suivantes sont enregistrées dans la colonne event_type de la table suspect_pages.
| Description de l'erreur | Valeur event_type |
|---|---|
Erreurs 824 autres 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
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. Lorsque la table est sur le point d'atteindre sa taille maximale, 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. Aucune autre entrée n'est autorisée tant qu'un administrateur n'a pas effectué cette opération.
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
Voir aussi
Concepts
Autres ressources
DROP DATABASE (Transact-SQL)
RESTORE (Transact-SQL)
BACKUP (Transact-SQL)
DBCC (Transact-SQL)
suspect_pages (Transact-SQL)