Столкнулся с проблемой, когда на SQL Server 2008R2 распараллеленный запрос INSERT WITH(TABLOCK) сам себя убивает по DEAD LOCK'у.
Думал сделать plan guide с MAXDOP(1), но запрос использует временную таблицу и каждый раз с новым именем (сам запрос при этом не меняется). Возможно ли параметризовать имя таблицы?
Если нет, есть ли какой-нибудь вариант повлиять на этот запрос без глобального задания MAXDOP? (Запрос создаётся 1С, 1Сники уверяют что модифицировать его со стороны 1С, чтобы добавить OPTION (MAXDOP 1) невозможно)
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте.
S>Столкнулся с проблемой, когда на SQL Server 2008R2 распараллеленный запрос INSERT WITH(TABLOCK) сам себя убивает по DEAD LOCK'у.
Можешь граф дедлока приложить?
Re[2]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, _ABC_, Вы писали:
S>>Столкнулся с проблемой, когда на SQL Server 2008R2 распараллеленный запрос INSERT WITH(TABLOCK) сам себя убивает по DEAD LOCK'у. _AB>Можешь граф дедлока приложить?
S>Столкнулся с проблемой, когда на SQL Server 2008R2 распараллеленный запрос INSERT WITH(TABLOCK) сам себя убивает по DEAD LOCK'у. S>Думал сделать plan guide с MAXDOP(1), но запрос использует временную таблицу и каждый раз с новым именем (сам запрос при этом не меняется). Возможно ли параметризовать имя таблицы? S>Если нет, есть ли какой-нибудь вариант повлиять на этот запрос без глобального задания MAXDOP? (Запрос создаётся 1С, 1Сники уверяют что модифицировать его со стороны 1С, чтобы добавить OPTION (MAXDOP 1) невозможно)
1. На всякий случай бить 1с-ников табуретом, чтобы неповадно было такие запросы писать
2. Давно это было, но для начала http://programmist1s.ru/1c-ekspert-vzaimoblokirovki-1s/
•Intra-query parallelism caused your server command to deadlock
•Transaction was deadlocked on thread communication buffer resources with another process and has been chosen as the deadlock victim
Решается данная проблема установкой параметра max degree of parallelism СУБД в значение «1» (по-умолчанию там «0»).
В остальных случаях — средствами 1с — пусть определяют в каком месте возникает блокировка и пусть разбираются — что там делается. Например, выносять сбор остатков из проведения документа.
Единственный момент — проверить, что делаются регламенты над скульной базой делаются — взять, например, у Гилева.
Re[3]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, Somescout, Вы писали:
S>Я мало имел дел с дедлоками, поэтому запросто могу ошибаться в причинах. Но лочится всё при выполнении этого запроса, всегда.
План смотрел? Может быть, его можно оптимизировать индексами, либо переписать нормально?
И сейчас какой MAX DOP стоит у вас?
Re[2]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, Sammo, Вы писали:
S>1. На всякий случай бить 1с-ников табуретом, чтобы неповадно было такие запросы писать
А какие претензии к самому запросу?
S>
•Intra-query parallelism caused your server command to deadlock
S>•Transaction was deadlocked on thread communication buffer resources with another process and has been chosen as the deadlock victim
S>Решается данная проблема установкой параметра max degree of parallelism СУБД в значение «1» (по-умолчанию там «0»).
Вышенаписанное звучит как "скуль не осилил межпроцессную синхронизацию при параллельном выполнении".
S> В остальных случаях — средствами 1с — пусть определяют в каком месте возникает блокировка и пусть разбираются — что там делается. Например, выносять сбор остатков из проведения документа.
И причем тут 1С? Она не просила распараллеливать этот запрос.
S>Столкнулся с проблемой, когда на SQL Server 2008R2 распараллеленный запрос INSERT WITH(TABLOCK) сам себя убивает по DEAD LOCK'у.
Никто сам себя не убивал, ты просто не умеешь читать очеты
У тебя дедлок пошел через 2 разных коннекта, и не через временную таблицу а через dbo._Documents506
1й выполнял
INSERT INTO dbo._Document506 (_IDRRef,_Marked,_Date_Time,_NumberPrefix,_Number,_Posted,_Fld14332RRef,_Fld26341RRef,_Fld26332,_Fld26325,_Fld14338RRef,_Fld14344RRef,_Fld26330,_Fld26326,_Fld26327,_Fld26340RRef,_Fld14333_TYPE,_Fld14333_RTRef,_Fld14333_RRRef,_Fld14342,_Fld14343,_Fld26324,_Fld26335,_Fld26331,_Fld26329,_Fld29222RRef,_Fld14335,_Fld26336,_Fld14334,_Fld26328,_Fld14339RRef,_Fld26333,_Fld26334,_Fld26339,_Fld26337,_Fld26338,_Fld14340,_Fld14336,_Fld14341RRef,_Fld14337,_Fld22664,_Fld27288,_Fld28824,_Fld29223,_Fld30259,_Fld30940RRef,_Fld30941RRef,_Fld31152,_Fld31153,_Fld31154,_Fld31155,_Fld31156,_Fld31157,_Fld31158,_Fld32392,_Fld33478)
2й
INSERT INTO #tt15 WITH(TABLOCK)...
никакой план гайд тебе не нужен, переключи базу в RCSI
ALTER DATABASE [UPP] SET READ_COMMITTED_SNAPSHOT ON
Re[2]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, Sammo, Вы писали:
S> В остальных случаях — средствами 1с — пусть определяют в каком месте возникает блокировка и пусть разбираются — что там делается. Например, выносять сбор остатков из проведения документа.
За такой совет уже можно руки отрезать. Медленно. По фаланге. И так до самой попы, откуда они и растут
Здравствуйте, rm822, Вы писали:
R>Никто сам себя не убивал, ты просто не умеешь читать очеты
Ну, такой отчет достаточно сложно прочитать, справедливости ради. Он слишком загроможден.
В остальном ты прав — это конфликт на _Document506
R>никакой план гайд тебе не нужен, переключи базу в RCSI
Кхм... Ты бы это... Не советовал так безапелляционно.
Т.к., во-первых 1С (как, впрочем, и другие приложения) не всегда безболезненно переживает включение этого
режима. Со стороны сервера 1С должен быть включен особый режим управления блокировками (с какой версии 1С
он поддерживается, я не помню). Запорченные данные куда хуже, чем дедлок.
Во-вторых, 1С при рестарте сервера 1С вернет базу в режим RC, если не был включен режим управляемых блокировок.
Гораздо лучше и безопаснее переписать запрос. Изменить порядок обращения к таблицам 1Сники смогут.
Re[3]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Sammo, Вы писали:
S>>1. На всякий случай бить 1с-ников табуретом, чтобы неповадно было такие запросы писать
W>А какие претензии к самому запросу?
S>>
•Intra-query parallelism caused your server command to deadlock
S>>•Transaction was deadlocked on thread communication buffer resources with another process and has been chosen as the deadlock victim
S>>Решается данная проблема установкой параметра max degree of parallelism СУБД в значение «1» (по-умолчанию там «0»).
W>Вышенаписанное звучит как "скуль не осилил межпроцессную синхронизацию при параллельном выполнении".
Не, на самом деле установка MAXDOP=1 не помогла. Проблема была в самом запросе, всё решилось его переписыванием.
S>> В остальных случаях — средствами 1с — пусть определяют в каком месте возникает блокировка и пусть разбираются — что там делается. Например, выносять сбор остатков из проведения документа.
W>И причем тут 1С? Она не просила распараллеливать этот запрос.
В данном случае всё-же действительно она виновата.
ARI ARI ARI... Arrivederci!
Re[4]: [SQL Server] Plan guide для временных таблиц
DC>За такой совет уже можно руки отрезать. Медленно. По фаланге. И так до самой попы, откуда они и растут
Я имел ввиду новую политику по проверке остатков из рекомендаций 1с, т.е. не в проведении проверяется наличие остатков, а проводится и смотрится результат. Это было сделано в том числе для уменьшения блокировок.
Re[4]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, Sammo, Вы писали:
S> DC>За такой совет уже можно руки отрезать. Медленно. По фаланге. И так до самой попы, откуда они и растут S> Я имел ввиду новую политику по проверке остатков из рекомендаций 1с, т.е. не в проведении проверяется наличие остатков, а проводится и смотрится результат. Это было сделано в том числе для уменьшения блокировок.
Ты совершенно неправильно понял эту новую политику.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Somescout, Вы писали:
S>>Не, на самом деле установка MAXDOP=1 не помогла. Проблема была в самом запросе, всё решилось его переписыванием.
W>Так я и хочу понять, в чем была проблема. Покажи запрос в 1С-ном виде до и после.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Somescout, Вы писали:
S>>http://files.rsdn.org/103613/1CQuery.zip
W>Мой Notepad++ не смог распарсить эту кодировку.
Странно (если это не сарказм), вроде это обычная Win1251. Эти файлы даже обычный notepad понимает.
ARI ARI ARI... Arrivederci!
Re[4]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Я мало имел дел с дедлоками, поэтому запросто могу ошибаться в причинах. Но лочится всё при выполнении этого запроса, всегда. _AB>План смотрел? Может быть, его можно оптимизировать индексами, либо переписать нормально? _AB>И сейчас какой MAX DOP стоит у вас?
Изменение MAX DOP не помогло, помогло переписывание запроса.
ARI ARI ARI... Arrivederci!
Re[5]: [SQL Server] Plan guide для временных таблиц
Здравствуйте, Somescout, Вы писали:
S>Изменение MAX DOP не помогло, помогло переписывание запроса.
По поводу переписывание запроса я уже написал. Но вопрос остался актуальным.
К нему добавляется вопрос о том, какие процессоры стоят на сервере СУБД.
Re[6]: [SQL Server] Plan guide для временных таблиц
S>http://files.rsdn.org/103613/1CQuery.zip
Я же говорю — табуретом...
Они фактически просто вынесли счета-фактуры во временную таблицу — т.е. сначала собрали только нужные с.ф. и только потом их соединяют.
Пусть еще (по возможности) отказываются от двойной точки, особенно в соединениях
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПоступлениеТоваровУслуг.Товары КАК ПоступлениеТоваровУслугТовары
ПО СчетФактураПолученныйДокументыОснования.ДокументОснование = ПоступлениеТоваровУслугТовары.Ссылка
И (ПоступлениеТоваровУслугТовары.Ссылка.НомерRECADV <> &ПустаяСтрока)
И (ПоступлениеТоваровУслугТовары.Ссылка.ДатаRECADV <> &ПустаяДата)
Может быть в первой временной таблице попробовать собрать данные по счет-фактуре и ее табличной части ДокументыОснования и потом уже использовать во втором подзапросе.
+
(ВЫРАЗИТЬ(СчетФактураПолученныйДокументыОснования.ДокументОснование.СкладОрдер КАК Справочник.Склады)
Документ основание у них ПоступлениеТоваровУслуг — так пусть в явном виде эту таблицу вытягивают и потом используют и в условии и в получении
СчетФактураПолученныйДокументыОснования.ДокументОснование.ДатаВходящегоДокумента КАК ДатаПН,
СчетФактураПолученныйДокументыОснования.ДокументОснование.НомерВходящегоДокумента КАК НомерПН,
Резюм. У меня ощущение, что в данном случае запрос не очень оптимален и работает не всегда быстро
P.S. пусть еще посмотрят отражение пустой даты в запросе, а то некрасиво. Подсказка ДатаВремя. А &ПустаяСтрока, имхо, это забавно.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Somescout, Вы писали:
S>>Изменение MAX DOP не помогло, помогло переписывание запроса. _AB>По поводу переписывание запроса я уже написал. Но вопрос остался актуальным.
Насчёт плана? Нет, не смотрел — проблема в том, что в этих запросах часто используются ранее созданные временные таблицы, поэтому захватить целиком план со всеми запросами тяжко. Плюс эти таблицы любезно очищаются 1С по завершении обработки, что ещё больше усложняет анализ.
_AB>К нему добавляется вопрос о том, какие процессоры стоят на сервере СУБД.
