Diagnostics SQL Server pour détecter les problèmes d’e/s non signalés obsolètes lectures ou écritures perdues

S’applique à : Microsoft SQL Server 2005 Compact EditionMicrosoft SQL Server 2005 Developer EditionMicrosoft SQL Server 2005 Enterprise Edition

N° de bogue : 470086 (SQL Server 8.0)

Symptômes


Si la cause de problèmes de système d’exploitation, un pilote ou matériel perdu écrire des conditions ou des conditions de lecture obsolètes, vous pouvez voir les messages d’erreur connexes l’intégrité des données telles que les erreurs 605, 823, 3448, 3456. Vous pouvez recevoir des messages d’erreur qui sont semblables aux exemples suivants :

2003-07-24 16:43:04.57 spid63 Getpage : bstat = 0 x 9, sstat = 0 x 800, cache
2003-07-24 16:43:04.57 spid63 NumPage est/doivent être : objid est/doivent être :
2003-07-24 16:43:04.57 spid63 (1:7040966)/(1:7040966) 2093354622/2039782424

spid63 de 16:43:04.57 2003-07-24... IAM indique que la page est allouée à cet objet

Erreur de spid63 de 16:52:37.67 2003-07-24 : 605, gravité : 21, état : 1
2003-07-24 16:52:37.67 spid63 tentative d’extraire la page logique (1:7040966) dans la base de données 'pubs' appartient à l’objet 'auteurs', pas pour les titres d’objet' '...

Erreur de spid63 de 16:52:40.99 2003-07-24 : 3448, gravité : 21, état : 1
2003-07-24 16:52:40.99 spid63 n’a pas pu annuler l’enregistrement de journal (63361:16876:181), pour l’ID de transaction (0:159696956), sur la page (1:7040977), la base de données 'pubs' (12 de l’ID de base de données). Informations de page : LSN = (63192:958360:10), type = 2. Enregistrer les informations : OpCode = 2, contexte 1...

2003-07-09 14:31:35.92 spid66 erreur : gravité 823, : 24, état : 2
2003-07-09 14:31:35.92 spid66 erreur e/s (ID de page incorrect) détectée pendant la lecture au décalage 0x00000016774000 dans le fichier 'h:\sql\MSSQL\data\tempdb.mdf'...

Erreur de spid17s de 15:57:24.14 06-02-2010 : 3456, gravité : 21, état : 1.
06-02-2010 15:57:24.14 spid17s n’a pas pu l’enregistrement de journal (58997:5252:28), pour l’ID de transaction (0:109000187), sur la page (1:480946), la base de données 'MyDatabase' (17 de l’ID de base de données). Page : LSN de = (58997:5234:17), type = 3. JRN : OpCode = 2, contexte 5, PrevPageLSN : (58997:5243:17). Restaurer à partir d’une sauvegarde de la base de données, ou réparer la base de données.

Plus d'informations


Microsoft a introduit les fonctionnalités de suivi étendues commençant par SQL Server 2000 Service Pack 4 et les tests de diagnostic ont été partie du produit dans SQL Server 2005 et versions ultérieures. Ces fonctions sont conçues pour vous aider à détecter des problèmes externes liés au e/s et à résoudre les messages d’erreur décrits dans la section « Symptômes »

Si vous recevez l’un des messages d’erreur mentionnés dans la section « Symptômes » et qu’ils ne peuvent pas être expliquées par un événement tel qu’une panne de disque physique, puis examinez les problèmes connus avec SQL Server, le système d’exploitation, les pilotes et le matériel. Les tests de diagnostic essayez de fournir des informations sur les deux conditions suivantes :
  • Perte d’écriture : Un appel à l’API WriteFile , mais le système d’exploitation, un pilote ou du contrôleur de mise en cache ne pas correctement vide les données au média physique même si SQL Server est informé que l’écriture a réussi.
  • Lecture obsolète : Un appel à l’API ReadFile , mais le système d’exploitation, un pilote ou la mise en cache du contrôleur renvoie à tort une ancienne version des données.
Par exemple, Microsoft a confirmé les scénarios où un appel WriteFile API retourne comme un succès, mais une lecture immédiate, réussie du même bloc de données renvoie les données plus anciennes, y compris les données sont probablement stockées dans un cache de lecture de matériel. Parfois, ce problème se produit en raison d’un problème de cache de lecture. Dans d’autres cas, les données d’écriture ne sont jamais écrite sur le disque physique.

Pour activer des diagnostics supplémentaires pour ces types de problèmes, SQL Server a ajouté l’indicateur de trace 818. Vous pouvez spécifier l’indicateur de trace 818 comme paramètre de démarrage,-T818, pour l’ordinateur qui exécute SQL Server, ou vous pouvez exécuter l’instruction suivante :
DBCC TRACEON(818, -1)

L’indicateur de trace 818 permet un tampon en anneau de mémoire qui est utilisée pour le suivi de que la dernière 2048 réussie écrire des opérations qui sont effectuées par l’ordinateur qui exécute SQL Server, tri et workfile e/s non compris. En cas d’erreurs telles que l’erreur 605 ou 823 3448, valeur de nombre (LSN) de séquence de journal de la mémoire de tampon entrante est comparée à la liste d’écriture récents. Si le numéro LSN qui est récupéré au cours de l’opération de lecture est antérieure à celle spécifiée au cours de l’opération d’écriture, un message d’erreur est enregistré dans le journal des erreurs de SQL Server. La plupart des opérations d’écriture SQL Server se produisent sous forme de points de contrôle ou écritures différées. Une opération d’écriture différée est une tâche d’arrière-plan qui utilise des e/s asynchrones. L’implémentation de la mémoire tampon d’anneau est léger, rendant ainsi les performances affectent le système négligeable.

Le message suivant indique que SQL Server n’a pas reçu une erreur à partir de l’appel de l’API WriteFile ou l’appel de ReadFile API. Toutefois, lorsque le LSN a été révisé, la valeur n’était pas correcte :

SQL Server a détecté un niveau de système d’exploitation ou de matériel non signalé lire ou d’écrire un problème sur la Page (1:75007) de la base de données 12

LSN retournée (63361:16876:181), LSN prévu (63361:16876:500)

Contactez le fournisseur du matériel et envisagez de désactiver les mécanismes de mise en cache pour résoudre le problème

À partir de SQL Server 2005, le message d’erreur est signalé en tant que :

SQL Server a détecté une erreur d’e/s basée sur la cohérence logique : lecture obsolètes. Il s’est produit au cours d’un << en lecture/écriture >> de page << PAGEID >> dans la base de données ID << DBID >> au décalage << décalage physique >> dans le fichier << nom de fichier >>. Des messages supplémentaires dans le journal d’événements SQL Server erreur système ou le journal peuvent fournir plus de détails. Il s’agit d’une condition d’erreur sévère qui menace l’intégrité de la base de données et doit être corrigée immédiatement. Effectuer une vérification de cohérence de base de données complète (DBCC CHECKDB). Cette erreur peut être provoquée par de nombreux facteurs ; Pour plus d’informations, consultez la documentation en ligne de SQL Server.

À ce stade, le cache de lecture contienne une version plus ancienne de la page, soit les données n’était pas correctement écrites sur le disque physique. Dans les deux cas (écrire une perte ou une lecture périmé), SQL Server signale un problème externe avec les couches de matériel, le pilote ou le système d’exploitation.

Si l’erreur 3448 se produit lorsque vous essayez de restaurer une transaction avec l’erreur 605 ou l’erreur 823, l’ordinateur exécutant SQL Server automatiquement ferme la base de données et essaie d’ouvrir et de récupérer la base de données. La première page qui rencontre l’erreur 605 ou l’erreur 823 est considérée comme une page incorrecte, et l’id de la page est conservé par l’ordinateur qui exécute SQL Server. Lors de la récupération (avant la phase redo) lors de la lecture de l’id de page incorrect, les détails principaux relatifs à l’en-tête de page sont enregistrés dans le journal des erreurs de SQL Server. Cette action est importante car il permet de faire la distinction entre les scénarios perdu d’écriture et de lecture obsolètes.

Vous pouvez voir les deux comportements communs dans les scénarios de lecture obsolètes :
Les comportements mentionnés dans le paragraphe précédent indiquent un problème de mise en cache de lecture, et ils sont souvent résolus en désactivant le cache de lecture. Les actions qui sont décrites dans le paragraphe précédent, généralement forcer une invalidation du cache et les lectures qui se produisent à afficher que le média physique est correctement mis à jour. Le comportement de la perte d’écriture se produit lorsque la page qui est lu précédent est toujours l’ancienne version des données, même après un vidage forcé des mécanismes de mise en cache.

Parfois, le problème ne soit pas spécifique à un cache de matériel. Il peut être un problème avec un pilote de filtre. Dans ce cas, passez en revue vos logiciels, y compris les utilitaires de sauvegarde et un logiciel antivirus et puis vérifier s’il existe des problèmes avec le pilote de filtre.

Microsoft a noté également des conditions qui ne remplissent pas les critères pour l’erreur 605 ou l’erreur 823, mais sont provoquées par la même activité obsolètes de lecture ou d’écriture de perdu. Dans certains cas, une page s’affiche pour mettre à jour deux fois, mais avec le LSN de même valeur. Ce problème peut se produire si l' ID de l’objet et l' ID de la Page sont correcte (déjà allouée à l’objet de la page), et si une modification est apportée à la page et vidée sur le disque. L’extraction de page suivante retourne une image plus ancienne, et ensuite une deuxième modification est effectuée. Le journal des transactions SQL Server indique que la page a été mis à jour deux fois avec la même valeur LSN. Cela devient un problème lorsque vous essayez de restaurer une séquence de journaux de transactions ou de problèmes de cohérence des données, telles que des erreurs de clé étrangères ou des entrées de données manquantes. Le message d’erreur suivant illustre un exemple de cette condition :

Erreur : 3456, gravité : 21, état : 1 n’a pas pu l’enregistrement de journal (276666:1664:19), pour l’ID de la transaction (0:825853240), sur la page (1:1787100), de la base de données 'auteurs' (7). Page : LSN de = (276658:4501:9), type = 1. JRN : OpCode = 4, contexte 2, PrevPageLSN : (275565:3959:31)...

Certains scénarios sont décrites plus en détail dans les listes suivantes :
  • LSN SequenceAction1Checkpoint
    2Begin Transaction
    3Table created or truncated
    4Inserts (Pages allocated)
    5Newly allocated page written to disk by Lazy Writer
    6Select from table – Scans IAM chain, newly allocated page read back from disk (LRU | HASHED = 0x9 in getpage message), encounters Error 605 - Invalid Object ID
    7Rollback of transaction initiated

  • LSN SequenceAction1Checkpoint
    2Begin Transaction
    3Page Modification
    4Page written to disk by Lazy Writer
    5Page read in for another modification (stale image returned)
    6Page Modified for a second time but because of stale image does not see first modification
    7Rollback – Fails – Transaction Log shows two different log records with the same PREV LSN for the page

Les opérateurs de « Tri » de SQL Server effectuent les activités d’e/s, essentiellement pour et à partir de la base de données tempdb . Ces opérations d’e/s sont similaires aux opérations d’e/s de mémoire tampon ; Toutefois, ils ont été déjà conçus pour utiliser la logique des nouvelles tentatives de lecture pour tenter de résoudre des problèmes similaires. Les tests de diagnostic supplémentaires décrites dans cet article ne s’appliquent pas à ces opérations d’e/s.

Microsoft a constaté que la cause de l’ordre de tri suivant lu échecs est généralement un obsolètes en lecture ou une écriture perdue :

2003-04-01 20:13:31.38 spid122 SQL Server Assertion : fichier : < p:\sql\ntdbms\storeng\drs\include\record.inl >, ligne = 1447 Échec de l’Assertion = ' m_SizeRec > 0 & & m_SizeRec < = MAXDATAROW'.

2003-03-29 09:51:41.12 tri des spid57 Échec de la lecture (ID de page incorrect). PageID = (0x1:0x13e9), dbid = 2, fichier = e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf. Une nouvelle tentative.

Erreur de spid57 de 09:51:41.13 2003-03-29 : gravité 823, : 24, état : 7
Erreur d’e/s de spid57 de 09:51:41.13 2003-03-29 (ID de page incorrect) détectée pendant la lecture au décalage 0x000000027d2000 dans le fichier « e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf »...

* Module(sqlservr+00531097) 00931097 (utassert_fail + 000002E3)
* 005B1DA8 Module(sqlservr+001B1DA8) (RecBase::Resize+00000091)
* 00407EE7 Module(sqlservr+00007EE7) (RecBase::LocateColumn+00000012)
* Module(sqlservr+00452520) 00852520 (mergerow + 000000A4)
* 008522B3 Module(sqlservr+004522B3) (merge_getnext+00000285)
* 0085207D Module(sqlservr+0045207D) (mergenext+0000000D)
* 004FC5FB Module(sqlservr+000FC5FB) (getsorted+00000021)

Les clients qui ont rencontré ces erreurs de tri ont fréquemment résolus les problèmes par déplacement de tempdb vers un lecteur local non mise en cache, ou en désactivant les mécanismes de mise en cache en lecture.

Car une obsolète de lecture ou une écriture perdue dans le stockage de données qui n’est pas prévu, une grande variété de comportements peut-être se produire. Il peut apparaître sous forme de données manquantes, mais certains des effets plus courantes des données manquantes apparaissent comme des altérations de l’index, comme erreur 644 ou code d’erreur 625 :

Erreur 644 gravité niveau 21 Message texte pourrait trouver l’entrée d’index pour le RID ' %. * hs' de la page d’index % S_PGID, index ID = %d, base de données ' %. * ls'.

Texte de Message d’erreur 625 gravité niveau 21 ne peut pas extraire la ligne de la page % S_PGID avec son RID parce que la slotid (%d) n’est pas valide.

Certains clients ont signalé manquant lignes après qu’ils effectuent des activités de compte de ligne. Ce problème se produit en raison d’une écriture perdue. Peut-être la page était censé être lié à la chaîne de pages d’index ordonné en clusters. Si l’écriture a été physiquement perdu, les données sont également perdues.

Important Si vous rencontrez les problèmes, ou si vous êtes suspects de problèmes similaires, ainsi que la désactivation des mécanismes de mise en cache, Microsoft recommande fortement que vous procurer la dernière mise à jour de SQL Server et le simulateur de Stress de d’e/s de SQL Server plus récente. Microsoft encourage également vivement d’effectuer une révision stricte de votre système d’exploitation et de ses configurations associées.

Remarque : Microsoft a confirmé que la charge d’e/s lourde et rares, certaines plates-formes de matériel peuvent renvoyer une lecture obsolète. Si les tests de diagnostic étendues indiquent une possible périmés lecture/perdu écrire la condition, contactez votre fournisseur de matériel pour le suivi immédiat des et tester à l’aide de l’utilitaire SQLIOSim .

SQL Server nécessite des systèmes pour prendre en charge une livraison garantie sur un support stable comme indiqué sous les Conditions du programme d’e/s la fiabilité de SQL Server. Pour plus d’informations sur la configuration d’entrée et de sortie pour le moteur de base de données SQL Server, reportez-vous à la section Configuration requise de Microsoft SQL Server de base de données moteur Input/Output.