Obserwujemy bardzo wysokie typy oczekiwania PAGELATCH_EX i PAGELATCH_SH oraz wysokie oczekiwania WRITELOG. Zdiagnozowałem zapytanie powodujące, że PAGELATCH czeka i mogę je wyeliminować, zmniejszając szybkość wstawiania do zajętego klucza podstawowego klastrowanego zdefiniowanego wartością TOŻSAMOŚĆ. Rozumiem, że to zjawisko jest znane jako rywalizacja o zatrzask wstawiania ostatniej strony.
Jednak moje pytanie brzmi: kiedy wstawiany jest nowy rekord, czy SQL Server pobiera wyłączny PAGELATCH_EX na stronie bufora, wstawia rekord na stronę bufora, zapisuje rekord w dzienniku transakcji, a następnie zwalnia wyłączny PAGELATCH_EX, jak opisano szczegółowo https: // www.microsoft.com/en-ie/download/details.aspx?id=26665 Strona 24. Czy zapisuje najpierw rekord w dzienniku transakcji przed pobraniem PAGELATCH_EX jako szczegółowe „Rozwiązywanie problemu PAGELATCH w sprawie wysoce współbieżnych” INSERT obciążeń - Informacje podstawowe Przewodnik SQLCAT: Relational Engine
Jeśli rekord zostanie zapisany w dzienniku poza mechanizmem zatrzasku, mogę wykluczyć powolne zapisywanie na dysk, ponieważ powoduje to wysokie oczekiwania PAGELATCH. Ale jeśli zatrzask zostanie przytrzymany, dopóki rekord nie zostanie zahartowany do rejestrowania, prawdopodobnie powinienem wziąć pod uwagę WRITELOG.
Czy także posiadanie wielu indeksów nieklastrowych spowodowałoby dłuższe utrzymywanie zatrzasku PAGELATCH_ *, tj. Jeśli tabela ma klastrowane i wiele indeksów nieklastrowych jest dodawanych i zwalnianych na każdej ze stron bufora indeksów jednocześnie?
Aktualizacja 1 Po przeczytaniu confio-sql-server-writelog-wait slajd dwa i ogólna architektura WAL. Rozumiem teraz, że krok „Zapisz wpis dziennika, że wiersz został zmodyfikowany” szczegółowo opisany w obu oficjalnych dokumentach, odnosi się do SQL Server rejestrowania zmiany w pamięci podręcznej dziennika transakcji, a nie dysku. Po zakończeniu transakcji lub zapełnieniu bufora wszystkie rekordy są natychmiast opróżniane na dysk.