Высокие PAGELATCH_ * и WRITELOG ждут. Связаны ли они?

Мы видим очень высокие типы ожиданий 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 Contention on High Concurrent» INSERT Workloads - Background информация Руководство SQLCAT для: Реляционный движок

Если запись записывается для записи вне механизма фиксации, я могу исключить медленную запись на диск, поскольку причина высокого ожидания PAGELATCH. Но если защелка удерживается до тех пор, пока запись не будет затвердевать, тогда я, вероятно, должен принять WRITELOG.

Также было бы иметь несколько некластеризованных индексов, заставляющих защелку PAGELATCH_ * удерживаться дольше, т. е. если таблица имеет кластерные и множественные некластеризованные индексы, то защелки, добавленные и выпущенные на каждую из страниц буфера индекса одновременно?

Обновление 1 После прочтения confio-sql-server-writelog-wait slide two и общая архитектура WAL. Теперь я понимаю, что шаг «Запись записи в журнале, который был изменен» был подробно описан в обеих документах, ссылаясь на то, что SQL Server регистрирует изменение в кеше журнала транзакций, а не на диске. После завершения транзакции или заполнения буфера все записи немедленно очищаются на диск.

11 голосов | спросил Pixelated 23 FebruaryEurope/MoscowbMon, 23 Feb 2015 17:21:38 +0300000000pmMon, 23 Feb 2015 17:21:38 +030015 2015, 17:21:38

1 ответ


1
  

Однако мой вопрос заключается в том, когда вставлена ​​новая запись, делает ли SQL Server эксклюзивный PAGELATCH_EX на странице буфера, вставляет запись на страницу буфера, записывает запись в журнал транзакций, а затем освобождает эксклюзивный PAGELATCH_EX

Вы должны заметить, что защелка защищает только физическую целостность страницы, пока она находится в памяти, поэтому защелка будет выполняться, когда страница находится в памяти. Предположим, что запись вставлена ​​и для этой страницы нужно выбрать. Во-первых, страница будет заблокирована и перенесена в память, тогда она будет заперта, и информация будет записана. После этого процесс будет

  • Создать запись журнала

  • Обновить страницу LSN в соответствии с записью журнала

  • Изменение данных (загрязнение страницы)

  • Заблокировать освобождение

  • Запуск транзакции транзакции

  • FlushToLSN of Commit

  • Блокировки релиза

  • Полное завершение транзакции

Для получения более подробной информации и объяснения описанных выше шагов, пожалуйста, прочитайте Блог презентации ввода-вывода Боба Дорра

Pagelatch * ожидания - это не ожидания ввода-вывода, и я видел большую часть времени, когда эти ожидания видны из-за разногласий по распределению. Я подозреваю, что он должен что-то сделать с помощью tempdb is configured. Итак, как настроен ваш tempdb?, Сколько файлов данных tempdb присутствует? Убедитесь, что они имеют одинаковый авторазрод и одинаковый размер. Когда на новой странице создаются системные страницы, такие как страницы GAM, SGAM и PFS необходимо обновить или получить доступ, а когда SQL Server найдет соперничество в доступе к этим страницам, такие ожидания придут в картину.

ответил Shanky 23 FebruaryEurope/MoscowbMon, 23 Feb 2015 19:30:55 +0300000000pmMon, 23 Feb 2015 19:30:55 +030015 2015, 19:30:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132