High PAGELATCH_ * und WRITELOG warten. Sind sie verwandt?

Wir sehen sehr hohe PAGELATCH_EX- und PAGELATCH_SH-Wartetypen zusammen mit hohen WRITELOG-Wartezeiten. Ich habe die Abfrage diagnostiziert, die das Warten auf PAGELATCH verursacht, und kann sie beseitigen, indem ich die Einfügungsrate in einen ausgelasteten Cluster-Primärschlüssel reduziere, der mit einem IDENTITY-Wert definiert ist. Ich verstehe, dass dieses Phänomen als Latch-Konflikt beim Einfügen der letzten Seite bekannt ist.

Meine Frage ist jedoch, wenn SQL Server eingefügt wird, ob SQL Server ein exklusives PAGELATCH_EX auf einer Pufferseite verwendet, den Datensatz in die Pufferseite einfügt , den Datensatz in das Transaktionsprotokoll schreibt und dann das exklusive PAGELATCH_EX als detailliertes https: // freigibt www.microsoft.com/en-ie/download/details.aspx?id=26665 Page 24. Oder schreibt er den Datensatz zuerst in das Transaktionsprotokoll, bevor er den PAGELATCH_EX als detailliert "PAGELATCH-Konflikt bei sehr gleichzeitigen" INSERT-Workloads lösen - Hintergrundinformationen SQLCAT-Handbuch zu: Relational Engine

Wenn der Datensatz so geschrieben wird, dass er außerhalb des Latching-Mechanismus protokolliert wird, kann ich langsame Schreibvorgänge auf die Festplatte als Ursache für hohe PAGELATCH-Wartezeiten ausschließen. Aber wenn die Verriegelung gehalten wird, bis der Datensatz zum Protokollieren gehärtet ist, sollte ich wahrscheinlich WRITELOG in Betracht ziehen.

Würden mehrere nicht gruppierte Indizes dazu führen, dass der PAGELATCH_ * -Latch länger gehalten wird, dh wenn eine Tabelle einen Cluster aufweist und mehrere nicht gruppierte Indizes gleichzeitig Latches hinzugefügt und für jede der Indexpufferseiten freigegeben werden?

Update 1 Nach dem Lesen von confio-sql-server-writelog-wait Folie zwei und der allgemeinen WAL-Architektur. Ich bin jetzt der Ansicht, dass der in beiden Whitepapers beschriebene Schritt "Aufzeichnen eines Protokolleintrags, bei dem die Zeile geändert wurde" sich auf SQL Server bezieht, der eine Änderung im Transaktionsprotokollcache protokolliert, nicht auf der Festplatte. Sobald die Transaktion abgeschlossen oder der Puffer voll ist, werden alle Datensätze sofort auf die Festplatte geschrieben.

Meine Frage ist jedoch, wenn SQL Server eingefügt wird, ob SQL Server einen exklusiven PAGELATCH_EX auf einer Pufferseite verwendet, den Datensatz in die Pufferseite einfügt, den Datensatz in das Transaktionsprotokoll schreibt und dann den exklusiven PAGELATCH_EX freigibt

Sie müssen beachten, dass der Latch nur die physische Integrität der Seite schützt, während sie sich im Speicher befindet, sodass ein Latch durchgeführt wird, wenn sich die Seite im Speicher befindet. Angenommen, ein Datensatz wird eingefügt und für diese Seite muss abgerufen werden. Zuerst würde die Seite gesperrt und in den Speicher gebracht, dann würde sie zwischengespeichert und Informationen würden geschrieben. Der Prozess danach wäre

• Protokolldatensatz generieren

• Aktualisieren Sie die Seiten-LSN so, dass sie mit der des Protokolldatensatzes übereinstimmt

• Daten ändern (Seite verschmutzen)

• Latch lösen

• Transaktion wird festgeschrieben

• FlushToLSN von Commit

• Lösen Sie die Sperren

• Commit-Transaktion abgeschlossen

Weitere Details und Erläuterungen zu den oben genannten Schritten finden Sie im I / O-Präsentationsblog von Bob Dorr

Pagelatch * -Warten sind keine E / A-Wartezeiten, und ich habe die meiste Zeit gesehen, dass diese Wartezeiten aufgrund von Zuordnungskonflikten auffällig sind. Meine Vermutung ist, dass es etwas damit zu tun hat, wie tempdb is configured. Wie ist Ihre Tempdb konfiguriert? Wie viele Tempdb-Datendateien sind vorhanden? Stellen Sie sicher, dass sie das gleiche Autogrowth und die gleiche Größe haben. Wenn neue Seiten erstellt werden , müssen Systemseiten wie GAM-, SGAM- und PFS-Seiten aktualisiert werden oder auf sie zugegriffen werden, und wenn SQL Server beim Zugriff auf diese Seiten Konflikte findet, kommt diese Wartezeit ins Spiel.