|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Читаю на уважаемом ресурсе askit.ru : askit.ru... а) при выполнении операций, которые должны быть выполнены с большим количеством записей в таблице, SQL Server пытается вначале использовать блокировки уровня записи. В результате на установку и последующее снятие таких блокировок расходуется значительное количество системных ресурсов. Этого можно было бы избежать, если сразу применить для выполнения операции нужный уровень блокировок (PAG или TAB) ; … б) вторая, более важная проблема, заключается в том, что SQL Server применяет эскалацию блокировок , в том числе и на мощных серверах, с которыми одновременно работает большое число пользователей. Типичная ситуация выглядит таким образом: в базе данных есть большая таблица, с которой постоянно работают пользователи (назовем ее главной таблицей). За счет эскалации блокировок количество записей, которые одновременно блокируют пользователи, автоматически увеличивается, в результате чего другие пользователи не могут получить к ним доступ. Таким образом, при достижении определенного количества пользователей работа с этой таблицей резко затрудняется. Особенно неприятно то, что заблокированными оказываются те записи, с которыми пользователи на самом деле не работают: просто они попали на одну страницу с другими записями, открытыми в данный момент. Собственно, вопрос о более поздних версиях SQL Server - там тоже самое, - эскалация перехода блокировок с уровня строк на таблицы, а не на страницы или что-то всё-таки улучшено по данной теме? Или везде надо руками постоянно настраивать уровни блокировок и расставлять хинты? ============================================================================================================ "О, сколько нам открытий чудных готовит просвещения дух, и опыт - сын ошибок трудных, и гений - парадоксов друг, и случай - бог изобретатель" (Пушкин, однако). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 18:08 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Уже много версий эскалацию можно отключать на конкретных таблицах. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 18:18 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
dab2, Едим слона по частям. Проблема возникает при несовместимых типах блокировки, например, если происходит одновременная запись и чтение. Для чего требуется эскалация. Каждая блокировка потребляет какой-то объем памяти сервера. Для установки большого количества строковых блокировок вы рискуете получить ошибку out of memory. Кроме того, потребуется просмотреть большое количество блокировок, чтобы определить возможность установки очередной блокировки. Если количество блокировок превышает определенное количество, сервер принимает решение укрупнить блокировки, чтобы снизить их общее количество. Укрупнение никак не мешает совместимым типам блокировки. В случае, если на таблице имеются несовместимые типы блокировки, эскалация не происходит. В этом случае также есть риск получить out of memory при определенных уровнях изоляции. В более поздних версия появилась возможность версионирования страниц таблиц, при включении этого режима блокировки друг другу не мешают, но версионированные страницы сохраняются в tempdb. понятно, что tempsb не резиновая и имеет конечную пропускную способность. Рекомендации автора относятся к мерам "застолбить" для себя таблицу в случае критичности выполнения запроса относительно других запросов к этой же таблице. Однако, такой подход может привести к ожиданием освобождения таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 18:26 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Владислав Колосов Кроме того, потребуется просмотреть большое количество блокировок, чтобы определить возможность установки очередной блокировки. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2020, 18:42 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич Уже много версий эскалацию можно отключать на конкретных таблицах. Вопросик: Вот есть у меня "большая таблица". И сыпются в нее обновления/вставки/удаления через простой merge из временной таблицы. Пока размер батча был < 10000 строк - усе было тип-топ. Как появились батчи > 10000 строк - начало блокировать таблицу. Т.е. все батчи стоят и ждут выполнения батча > 10000 строк. Ну отключил я на "большой таблице" эскалацию. А ничо не изменилось. Что я сделал не так? ЗЫ. Пришлось, ведь, тупо понижать размер батча. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 05:49 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
aleks222 Гавриленко Сергей Алексеевич Уже много версий эскалацию можно отключать на конкретных таблицах. Вопросик: Вот есть у меня "большая таблица". И сыпются в нее обновления/вставки/удаления через простой merge из временной таблицы. Пока размер батча был < 10000 строк - усе было тип-топ. Как появились батчи > 10000 строк - начало блокировать таблицу. Т.е. все батчи стоят и ждут выполнения батча > 10000 строк. Ну отключил я на "большой таблице" эскалацию. А ничо не изменилось. Что я сделал не так? ЗЫ. Пришлось, ведь, тупо понижать размер батча. По-мимо отключения эскалации нужно ещё и начальный уровень блокировок до уровня строк явно указывать хинтом rowlock. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 09:46 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
msLex По-мимо отключения эскалации нужно ещё и начальный уровень блокировок до уровня строк явно указывать хинтом rowlock. пардон, а зачем? у нас тоже есть табличищe(вернее, уже 4 таких), в которую вечно вставляют по 1,5 млн за раз. и апдэйты такие же. отключивши эскалацию на этих таблицах получили на апдэйтах (на всех четырех таблицах) миллионы построчных локов. пришлось насильно паглоки прописать. на инсертах конечно роулоки устраивают, но на апдэйтах нет. апдэйтим старое, и оно никак не на последней странице. Microsoft SQL Server 2014 (SP3-CU3) (KB4491539) - 12.0.6259.0 (X64) Apr 1 2019 22:19:54 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 11:21 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Yasha123 msLex По-мимо отключения эскалации нужно ещё и начальный уровень блокировок до уровня строк явно указывать хинтом rowlock. пардон, а зачем? у нас тоже есть табличищe(вернее, уже 4 таких), в которую вечно вставляют по 1,5 млн за раз. и апдэйты такие же. отключивши эскалацию на этих таблицах получили на апдэйтах (на всех четырех таблицах) миллионы построчных локов. пришлось насильно паглоки прописать. на инсертах конечно роулоки устраивают, но на апдэйтах нет. апдэйтим старое, и оно никак не на последней странице. Microsoft SQL Server 2014 (SP3-CU3) (KB4491539) - 12.0.6259.0 (X64) Apr 1 2019 22:19:54 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor) Как зачем? Чтобы иметь возможность параллельно мёржить по 10000 из разных коннектов. Тут вопрос баланса между гранулярностью блокировок и возможностью параллельно модифицировать данные в одной таблице ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 11:32 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
msLex Как зачем? Чтобы иметь возможность параллельно мёржить по 10000 из разных коннектов. Тут вопрос баланса между гранулярностью блокировок и возможностью параллельно модифицировать данные в одной таблице так сервер сам, как только отключаешь эскалацию, выбирает именно роулоки. мне казалось, должен бы наоборот, паглоки выбирать, чтобы не хранить такую тучу локов, но пришлось заставлять... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 12:04 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
Yasha123 так сервер сам, как только отключаешь эскалацию, выбирает именно роулоки. Это точно? Насколько я помню, отключение эскалации не влияет на начальный выбор уровня гранулярности и sql engine вполне может выбрать блокировку уровня таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 12:11 |
|
Сравнение эскалации блокировок SQL Server 2005 и более поздних версий
|
|||
---|---|---|---|
#18+
msLex Yasha123 так сервер сам, как только отключаешь эскалацию, выбирает именно роулоки. Это точно? Насколько я помню, отключение эскалации не влияет на начальный выбор уровня гранулярности и sql engine вполне может выбрать блокировку уровня таблицы. это нигде не написано, просто стабильно воспроизводится на всех 4х таблицах. и вроде это против всякой логики, ведь когда так много локов, казалось бы, почему не страницами лочить? у нас не 10.000 за раз, стабильно 1,5млн... это не говоря об исключительных случаях, когда начальнику приходят гениальные идеи типа апдэйтить 17млн строк за раз. ведь все равно сервер не выбрал страницы, лочил построчно и вывалил в результате дамп памяти в еррор лог и ошибку начальнику. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2020, 12:33 |
|
|
start [/forum/topic.php?fid=46&fpage=69&tid=1686497]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 328ms |
total: | 454ms |
0 / 0 |