Мы наблюдаем очень высокие типы ожидания PAGELATCH_EX и PAGELATCH_SH вместе с высокими ожиданиями WRITELOG. Я диагностировал запрос, вызывающий ожидание PAGELATCH, и могу устранить их, уменьшив частоту вставки в занятый кластерный первичный ключ, определенный со значением IDENTITY. Я понимаю, что это явление известно как конфликт защелки вставки последней страницы.
Однако мой вопрос заключается в том, что при вставке новой записи SQL Server принимает эксклюзивный PAGELATCH_EX на странице буфера, вставляет запись на страницу буфера, записывает запись в журнал транзакций и затем выпускает эксклюзивный PAGELATCH_EX в виде подробных https: // www.microsoft.com/en-ie/download/details.aspx?id=26665 Стр. 24. Или сначала записывает запись в журнал транзакций перед тем, как взять PAGELATCH_EX в качестве подробного «Разрешение конфликта PAGELATCH при высококонкурентных» рабочих нагрузках INSERT - Справочная информация Руководство SQLCAT по: реляционному движку
Если запись записывается в журнал за пределами механизма фиксации, я могу исключить медленную запись на диск, так как причина большого PAGELATCH ждет. Но если защелка удерживается до тех пор, пока запись не укрепится для записи в журнал, я, вероятно, должен принять во внимание WRITELOG.
Кроме того, наличие нескольких некластеризованных индексов приведет к тому, что защелка PAGELATCH_ * будет удерживаться дольше, т. Е. Если таблица имеет кластеризованные и несколько некластеризованных индексов, добавляются ли защелки и высвобождаются ли они на каждой странице буфера индекса одновременно?
Обновление 1 После прочтения confio-sql-server-writelog-wait слайд 2 и общая архитектура WAL. Теперь я понимаю, что шаг «Записать запись журнала, что строка была изменена», подробно описанный в обеих статьях, относится к регистрации SQL Server изменений в кэше журнала транзакций, а не на диске. После завершения транзакции или заполнения буфера все записи немедленно сбрасываются на диск.