[Corrigé] : Erreur SQL Server 8966 – La page ne peut être lue et verrouillée en raison d'une corruption

Le moteur MS SQL Server utilise des primitives de synchronisation légères, appelées « latches », pour garantir la cohérence des structures en mémoire, des pages de données et des index. Les deux types courants de latches sont PAGELATCH et PAGEIOLATCH. PAGELATCH se trouve dans le pool de tampons et protège les pages qu'il contient. PAGEIOLATCH se trouve sur le disque dur et protège les pages qui n'ont pas encore été chargées dans le pool de tampons.

Dans SQL Server, il n'existe pas de chemin d'accès direct au disque dur. Lorsque vous appelez une page, le serveur la lit d'abord à partir du pool de tampons. La page est ensuite déplacée vers le pool de tampons, créant ainsi un verrou de page. Si le serveur ne peut pas lire le verrou de page en raison de conflits de verrous ou pour d'autres raisons, un message d'erreur similaire au suivant peut s'afficher :

Msg 8966, niveau 16, état 1, ligne 1 La page (1:1681) avec le type de verrou SH n'a pas pu être lue et verrouillée. sysindexes a échoué  .

Cette erreur se produit généralement lorsque le pool de tampons, les pages et leurs index, les pages de données et les méta-pages (PFS/GAM), les index (arbre B, arbre de hachage) ou les pages de verrouillage de tout type, telles que SH, EX, DT, sont endommagés dans la base de données MS SQL. Voici comment résoudre cette erreur.

Causes de l'erreur 8966 de SQL Server – Impossible de lire et de sécuriser la page

L'erreur « Msg 8966, niveau 16, état 1, ligne 1 Impossible de lire et de verrouiller la page (1:1681) avec le type de verrou SH. sysindexes a échoué » peut se produire pour l'une des raisons suivantes :

• Problèmes d'E/S ou de CRC sur le disque dur de votre système
• Corruption des valeurs dans l'en-tête de la page PFS_PAGE
• Index corrompus ou défectueux dans le fichier NDF/MDF
• Corruption du fichier de base de données MS SQL
• Le serveur ne peut pas obtenir le verrou requis à temps en raison de conflits importants lorsque plusieurs threads tentent d'accéder à la même page en même temps

Méthodes pour corriger l'erreur 8966 – Impossible de lire et d'enregistrer la page

Veuillez suivre les méthodes ci-dessous pour résoudre cette erreur SQL Server.

Méthode 1 – Supprimer le conflit de verrouillage

SQL Server utilise un verrou pour protéger les pages du pool de tampons et crée un thread pour chaque session. Des conflits de verrouillage peuvent parfois se produire. C'est le cas, par exemple, lorsque plusieurs utilisateurs tentent de mettre à jour une même page simultanément. Pour cette raison, plusieurs threads sont créés pour chaque session de connexion, ce qui entraîne des temps d'attente. Pour vérifier si l'erreur est due à un conflit de verrouillage, vous pouvez exécuter les DMV (Dynamic Management Views) de SQL Server. Cela vous permet de déterminer le type spécifique de conflit de verrouillage qui a causé votre erreur. Pour vérifier cela, vous pouvez ouvrir les System Dynamic Management Views en exécutant la requête suivante :

Sélectionnez wait_type, wait_time_ms

FROM sys.dm_os_wait_stats;

Vous pouvez également exécuter les DMV à partir de votre système pour vérifier les temps d'attente des verrous et l'utilisation du processeur, et résoudre le problème. Pour ce faire, ouvrez

• Ouvrez l'application Exécuter de votre système, tapez « perfmon » et cliquez sur « OK ».

• Dans la fenêtre Moniteur de performances, cliquez sur Moniteur de performances, puis sur le signe plus (+).

• Dans la fenêtre Ajouter des mesures, recherchez « SQLServer:BufferManager » et « SQLServer:Latches », puis créez un rapport.

Vérifiez le rapport. Une fois que vous avez identifié le problème de verrouillage spécifique à l'origine de l'erreur, résolvez le conflit de verrouillage comme suit :

• Utilisez le partitionnement par hachage.
• Utilisez une clé/un index non séquentiel au lieu d'une clé/un index séquentiel. Par exemple, si vous souhaitez répartir les valeurs sur la plage de clés d'index, utilisez une colonne de la table elle-même.

Méthode 2 – Vérification et correction de la corruption de la base de données SQL

L'erreur 8966 – Impossible de lire et de verrouiller la page peut se produire en raison de la corruption de pages, d'index ou d'autres éléments dans la base de données MS SQL. Pour vérifier cela, exécutez la commande DBCC CHECKDB ou sélectionnez l'instruction SELECT comme indiqué ci-dessous :

SELECT FROM msdb..suspect_pagesCopier le code

Cette commande renvoie une grille avec une ligne pour chaque page endommagée. Elle contient l'ID du fichier et l'ID de la page. Une fois que vous connaissez les pages spécifiques de la base de données qui sont endommagées, vous pouvez effectuer une sauvegarde au niveau de la page pour corriger la corruption de la page dans SQL Server. Pour ce faire, exécutez la commande suivante :

REMETTRE DATABASE  
 PAGE = ' [ ,... n ] ' [ ,... n ]
 FROM [ ,... n ]
 WITH NORECOVERY Copier le code

Sinon, vous pouvez remettre le fichier de sauvegarde pour récupérer le fichier MDF/NDF endommagé.

Si la sauvegarde est illisible, vous pouvez réparer la base de données à l'aide de la commande DBCC CHECKDB. Cela vous permet de corriger les problèmes de corruption au niveau des pages dans la base de données. La commande peut être utilisée avec différentes options de réparation. Avant d'exécuter l'une des options de réparation, veuillez vérifier les autorisations au niveau de la base de données.

Étapes à suivre pour utiliser la commande DBCC CHECKDB afin de réparer une base de données MS SQL :

• Commencez par mettre la base de données endommagée en mode SINGLE_USER.
• Cliquez ensuite sur « Next Query » (Requête suivante) dans SSMS. Exécutez ensuite la commande DBCC CHECKDB avec l'option REPAIR_ALLOW_DATA_LOSS pour réparer la base de données.

DBCC CHECKDB (N 'Department', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS ;

GO

Copier le code

• Après avoir réparé la base de données, vous devez changer le mode de la base de données de SINGLE_USER à MULTI_USER. Pour ce faire, exécutez la commande suivante :

ALTER DATABASE Department SET MULTI_USER Copier le code

La commande DBCC CHECKDB peut vous aider à corriger l'erreur « Error 8966 - Page cannot be read and locked » si elle se produit en raison d'une corruption des pages dans la base de données SQL « ». Cependant, les pages corrompues peuvent être réattribuées ou supprimées pendant la récupération, ce qui peut entraîner une perte de données. Étant donné que la récupération complète des données de la base de données n'est pas garantie, vous pouvez réparer la base de données SQL avec Stellar® Repair for MS SQL.

Pourquoi cet outil de réparation SQL est-il plus efficace ?

• Avec STELLAR Repair for MS SQL, vous pouvez réparer les fichiers NDF/MDF, y compris les pages, les index et les procédures stockées, dans les plus brefs délais.
• Répare les fichiers NDF/MDF créés dans n'importe quelle version, taille et condition de serveur.
• Récupère les pages endommagées sans perte de données.
• Offre du soutien pour la récupération des données à partir des données compressées ROW et PAGE de MS SQL Server.
• Permet d'enregistrer la base de données réparée dans divers formats de fichiers tels que CSV, HTML, XLS, ainsi que dans une nouvelle base de données et une base de données active.
• Offre une option permettant de prévisualiser la base de données réparée avant de l'enregistrer. Dans la fenêtre d'aperçu, vous pouvez même utiliser l'option de recherche pour sélectionner des éléments spécifiques.
• Vous aide à réparer les corruptions au niveau de la page, telles que 8966, 8946, etc., avec une intégrité totale.

Conclusion

Les causes de l'erreur 8966 de SQL Server (la page ne peut être lue et est verrouillée) sont la corruption de la page et les conflits de verrouillage. Si les pages sont corrompues, vous pouvez utiliser la commande PAGE RESTORE ou DBCC CHECKDB dans MS SQL Server pour résoudre le problème. Toutefois, si ces commandes ne produisent pas le résultat souhaité, l'utilisation de Stellar® Repair for MS SQL est la solution appropriée. Il peut réparer rapidement les fichiers de base de données SQL gravement corrompus et récupérer toutes les données, y compris le pool de tampons, les index de hachage et les pages.