Комментарии 5
Немного оффтоп – также для этой таблицы нужно отключить страничные блокировки на индексах. Так как выборка из этой таблицы всегда происходит по уникальному ID, эскалация блокировок на уровень страниц здесь не имеет смысла и даже вредна.
Вообще, эскалацию блокировок SQL Server всегда делает только на уровень таблицы, а не страниц/экстентов, поэтому, отключая страничные блокировки, можно неожиданно для себя получить очень неприятные результаты. Трешхолд, ЕМНИП, составляет около 5000 блокировок, т.е. заблокировав 5000 строк, sql server эскалирует блокировку до табличной, вместо того, чтобы изначально заблокировать десяток страниц. Если для вас это не проблема, то для кого-то может стать.
Ситуация, когда вместо построчной блокировки СУБД блокирует страницами и в этих страницах есть строки не относящиеся к текущему запросу обновления/удаления это не эскалация? Возможно тут какая то некорректная терминология, но в результате это приводит к блокировкам параллельных процессов, т.к. блокируется больше строк, чем реально нужно обновить.
В данном случае и эскалацию на таблице тоже имеет смысл отключить (ALTER TABLE [dbo].[INVENTSUMDELTA] SET (LOCK_ESCALATION = DISABLE))
В этой таблице не бывает слишком больших объемов данных, затраты ресурсов на поддержание строчных блокировок незначительны. Важнее избежать блокировок параллельных процессов.
В данном случае и эскалацию на таблице тоже имеет смысл отключить (ALTER TABLE [dbo].[INVENTSUMDELTA] SET (LOCK_ESCALATION = DISABLE))
В этой таблице не бывает слишком больших объемов данных, затраты ресурсов на поддержание строчных блокировок незначительны. Важнее избежать блокировок параллельных процессов.
Ситуация, когда вместо построчной блокировки СУБД блокирует страницами и в этих страницах есть строки не относящиеся к текущему запросу обновления/удаления это не эскалация?Нет — это не эскалация блокировок. MSDN.
В данном случае и эскалацию на таблице тоже имеет смысл отключить
Не знаю ничего про данный случай, а в общем случае, кмк, хорошо бы писать к чему такие действия могут привести.
Да, вы правы. Но поэтому в этом примере я и написал «Специфика данной таблицы такова, что данные в ней не хранятся. Но очень интенсивно добавляются\удаляются. Это, по сути, таблица-семафор.». Естественно, эта рекомендация применима только для этой таблицы.
Хорошая статья, но довольно странные выводы. Так в том то и дело что даже если все правильно написано SQL2019 подберет корректный план для первого случайного набора параметров, и не факт что это будет в среднем лучше для всех остальных.
В своем блоге я описил утилиту, которая позволяет мониторить и выявлять такие запросы, внедрение не сказать чтобы простое - т.е. вам нужно будет знать несколько сотен топ запросов к базе, но как результат, получится система мониторинга которая позволит предотвратить такие проблемы(а они могут возникнуть в любой момент) https://denistrunin.com/performance-snifmonitor
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация производительности Microsoft Dynamics AX 2012 & 365 FO. Использование Plan guides для тяжелых запросов