MSSQLSERVER_832

S’applique à :SQL Server

Détails

Attribut	Valeur
Nom du produit	SQL Server
ID de l’événement	832
Source de l’événement	MSSQLSERVER
Composant	SQLEngine
Nom symbolique	B_CONSTPAGECHANGED
Texte du message	Une page qui aurait dû être constante a changé (somme de contrôle attendue : <valeur attendue, somme> de contrôle réelle : <valeur> réelle, dbid> de base de données<, fichier « filename> »,< pageno<>). Cela indique généralement une défaillance de la mémoire ou tout autre dommage au niveau du matériel ou du système d'exploitation.

Explication

Un facteur externe a entraîné la modification d’une page de base de données en dehors du code normal du moteur SQL Server qui est utilisé pour modifier les pages de base de données. Ce facteur externe peut être :

• Un thread s’exécutant dans le processus SQL Server qui génère des écritures incorrectes dans une page de base de données. Dans ce cas, on parle souvent de « scribbler ».
• Un problème lié au matériel ou au système d’exploitation, lors duquel la mémoire qui est allouée à la page de la base de données est incorrecte ou endommagée

Lorsque SQL Server détecte ce problème, l’erreur 832 est générée.

Action requise

Pour déterminer la cause de l’erreur, envisagez les options suivantes :

• Vous devez exécuter toutes les vérifications habituelles du matériel ou du système afin de détecter tout problème lié à la mémoire, au processeur ou autre composant matériel. Vérifiez que tous les pilotes système, les mises à jour du système d’exploitation et les mises à jour matérielles ont été appliqués au système. Envisagez d’exécuter des diagnostics de fabrication de matériel, y compris des tests liés à la mémoire.
• Parmi les DLL « externes » chargées dans SQL Server, évaluez lesquelles sont susceptibles de provoquer ce problème, notamment les procédures stockées étendues, les objets COM ou d’autres DLL qui peuvent modifier à tort la mémoire SQL Server qui est réservée aux pages de base de données.

Chaque fois que vous voyez cette erreur, vous devez immédiatement envisager de l’exécuter DBCC CHECKDB sur la base de données référencée par le <dbid> dans le message d’erreur.

Informations complémentaires

Cette erreur est détectée par la tâche en arrière-plan, souvent appelée LazyWriter (la « commande » associée à cette tâche s’affiche sous le nom de LAZY WRITER). Par conséquent, cette erreur n’est pas retournée à une application cliente. L’erreur est écrite dans le Journal des événements de l’application Windows, avec EventID=832.

Seules les pages qui ne sont pas modifiées dans le cache (ou « compromises ») sont vérifiées. C’est la raison pour laquelle le message utilise le terme « constant », car la page n’a jamais été modifiée depuis qu’elle a été lue à partir du disque. De plus, la page a été lue sous sa forme « propre » à partir du disque, car elle a une valeur de somme de contrôle et n’a pas rencontré d’échec de somme de contrôle (Msg 824). Toutefois, la page peut avoir été modifiée après cette erreur, puis avoir été écrite sur le disque avec une modification incorrecte. Si cette erreur se produit, une nouvelle somme de contrôle est calculée sur la base de toutes les modifications, avant d’être écrite sur le disque. Par conséquent, la page peut être endommagée sur le disque, sans qu’une lecture ultérieure ne déclenche l’échec de la somme de contrôle. Il est important d’exécuter DBCC CHECKDB sur toutes les bases de données référencées par cette erreur.

Il est possible que même DBCC CHECKDB ne signale pas d’erreur pour une page dans cet état après son écriture sur le disque. Cela est dû au fait que la modification incorrecte peut se trouver là où la page ne contient pas de données ni d’informations importantes sur la structure de la page ou de la ligne. Cela peut être aussi dû à des modifications de données que CHECKDB ne peut pas détecter.

Pour plus d’informations sur Msg 832, consultez le livre blanc SQL Server I/O Basics, Chapter 2.