Работаем в SQL версии 1С:УПП. Платформа 8.3.16.1814, конфигурация в режиме совместимости с 8.2.13, как положено для УПП.
С некоторых пор народа стало больше работать и всех замучали взаимные блокировки.
То есть не просто два пользователя зашли в один документ, и один из них не может его сохранить, пока второй с ним не закончит работу.
А буквально - куча разного народу работает в РАЗНЫХ документах, начиная от требований-накладных и заканчивая заказами покупателей. И блокируется проведение этих разных документов.
То есть менеджер залез в заказ, оператор в реализацию, бухгалтер в отчет производства за смену, и никто не может провести, вылезает ошибка (см.скриншот), и они сидят ждут друг друга, жмут на ОК, кто первый освободит документ, и дальше по цепочке проведение уже нормально проходит.
Я так понимаю, при проведении документа блокируются транзакции по всем регистрам, которые он двигает, поэтому затрагивается целый круг других документов, которые работают с этими же регистрами.
Не очень понятно, что можно сделать в рамках ограничений платформы 8.2 и УПП, но народ у нас ропщет, мол, где они раньше работали, ничего подобного не наблюдалось.
Какие-то рекомендации по оптимизации настроек SQL-сервера и сервера 1С делали, вроде даже сначала эффект какой-то был, но потом все вернулось на круги своя.
Как-то решается эта проблема? Или ничего не сделать до перехода на платформу 8.3 и ERP?
С некоторых пор народа стало больше работать и всех замучали взаимные блокировки.
То есть не просто два пользователя зашли в один документ, и один из них не может его сохранить, пока второй с ним не закончит работу.
А буквально - куча разного народу работает в РАЗНЫХ документах, начиная от требований-накладных и заканчивая заказами покупателей. И блокируется проведение этих разных документов.
То есть менеджер залез в заказ, оператор в реализацию, бухгалтер в отчет производства за смену, и никто не может провести, вылезает ошибка (см.скриншот), и они сидят ждут друг друга, жмут на ОК, кто первый освободит документ, и дальше по цепочке проведение уже нормально проходит.
Я так понимаю, при проведении документа блокируются транзакции по всем регистрам, которые он двигает, поэтому затрагивается целый круг других документов, которые работают с этими же регистрами.
Не очень понятно, что можно сделать в рамках ограничений платформы 8.2 и УПП, но народ у нас ропщет, мол, где они раньше работали, ничего подобного не наблюдалось.
Какие-то рекомендации по оптимизации настроек SQL-сервера и сервера 1С делали, вроде даже сначала эффект какой-то был, но потом все вернулось на круги своя.
Как-то решается эта проблема? Или ничего не сделать до перехода на платформу 8.3 и ERP?
Прикрепленные файлы:
По теме из базы знаний
- Оптимизация проблемных участков конфигурации
- 1С:Специалист по платформе. Система подготовки к экзамену. Личное мнение (C)
- Восстановление учета затрат (41 счет) и состояния расчетов с контрагентами (УПП ред. 1.3)
- Документ на документ. Автоматическое создание связанных документов
- Замеры APDEX против "ощущений" бухгалтеров
Найденные решения
Для начала перестроение, дефрагментация индексов, обновление статистики, шринк базы, шринк лога.
и если после стандартного обслуживания базы проблема не уходит то:
Блокировки можете разобрать снимая тж
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="ваш путь" history="8">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<event>
<eq property="name" value="SDBL"/>
</event>
<event>
<eq property="name" value="CALL"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
и события SQL lock_deadlock, lock_deadlock_chain, lock_timeout, lock_escalation, lock_timeout_greater_than_0, xml_deadlock_report, rpc_completed, sql_batch_completed
По событиям SQL найдете блокировки SQL далее тж чтоб строки кода найти используете тж, по ТЖ управляемые блокировки, а далее править.
Сюдя по ошибке у вас управляемые блокировки и держать должно куда поболее 100 пользователей естественно при типовой конфигурации.
и если после стандартного обслуживания базы проблема не уходит то:
Блокировки можете разобрать снимая тж
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="ваш путь" history="8">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<event>
<eq property="name" value="SDBL"/>
</event>
<event>
<eq property="name" value="CALL"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
и события SQL lock_deadlock, lock_deadlock_chain, lock_timeout, lock_escalation, lock_timeout_greater_than_0, xml_deadlock_report, rpc_completed, sql_batch_completed
По событиям SQL найдете блокировки SQL далее тж чтоб строки кода найти используете тж, по ТЖ управляемые блокировки, а далее править.
Сюдя по ошибке у вас управляемые блокировки и держать должно куда поболее 100 пользователей естественно при типовой конфигурации.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4) Это обнадеживает. Есть мысли что где можно настроить для оптимизации?
Можете поделиться настройками кластера 1С и сервера 1С? Например "количество соединений на процесс" у вас какое стоит? Мы пробовали менять этот параметр, вроде бы как раз улучшения наблюдались, но какие-то временные. Так в итоге и не поняли, с каким значением лучше.
Можете поделиться настройками кластера 1С и сервера 1С? Например "количество соединений на процесс" у вас какое стоит? Мы пробовали менять этот параметр, вроде бы как раз улучшения наблюдались, но какие-то временные. Так в итоге и не поняли, с каким значением лучше.
Средствами SQL база обслуживается? Не выполняется ли, например, реиндексация в момент возникновения ошибок?
(10) Хм... Есть планы обслуживания. В том числе выполняется задание по резервному копированию журнала транзакций раз в 2 часа.
Совсем не подумал, что это может влиять.
P.S. Но вроде бы по времени не бьётся. Бэкап в 9, 11, 13, 15 и 17. Затыки, например, в 10:30. То есть первый бэкап по любому уже отработал, а второй еще не начался.
Совсем не подумал, что это может влиять.
P.S. Но вроде бы по времени не бьётся. Бэкап в 9, 11, 13, 15 и 17. Затыки, например, в 10:30. То есть первый бэкап по любому уже отработал, а второй еще не начался.
(12) Копирование журнала транзакций как-бы не должно (на 100% не уверен, мы ЖТ не бекапим), но лучше проследить что творится на сервере в момент возникновения блокировок. Другие планы и их расписание также посмотрите что и во сколько.
(28) да.. ибо на некоторых типовых еще режим совместимости с 8.2.
Это же полный ПЭ.
Да. Всем кто захочет режим совместимости >=8.3.15, надо иметь ввиду, что РБ теперь имеет движенияССубконто как реальную табличку, добавив 24 новых поля в основную табличку регистра бухгалтерии. Для баз чуть больше ларька, обычная реструктуризация может длиться сутками и..не закончиться, при ошибках. Чтоб не ждать - делайте реструктуризацию V2
Это же полный ПЭ.
Да. Всем кто захочет режим совместимости >=8.3.15, надо иметь ввиду, что РБ теперь имеет движенияССубконто как реальную табличку, добавив 24 новых поля в основную табличку регистра бухгалтерии. Для баз чуть больше ларька, обычная реструктуризация может длиться сутками и..не закончиться, при ошибках. Чтоб не ждать - делайте реструктуризацию V2
У себя отказались от режима совместимости года 2 назад. Стоит 8.3.12 - полет нормальный. Примерно 100 сеансов каждый день - блокировок нет. Кроме изменения собственно свойства режим совместимости и управляемых блокировок приходится комментировать строковые функции в общем модуле ЕГАИС, которые появились в платформе 8.3 и переименовать структуру НаправлениеПоиска, которая в платформе 8.3 является системным перечислением.
1. Уйти на режим совместимости 8.3*, чтобы sql иначе блокировал данные
2. Если есть обмены, внимательно на них посмотреть.
2. Если есть обмены, внимательно на них посмотреть.
Для начала перестроение, дефрагментация индексов, обновление статистики, шринк базы, шринк лога.
и если после стандартного обслуживания базы проблема не уходит то:
Блокировки можете разобрать снимая тж
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="ваш путь" history="8">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<event>
<eq property="name" value="SDBL"/>
</event>
<event>
<eq property="name" value="CALL"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
и события SQL lock_deadlock, lock_deadlock_chain, lock_timeout, lock_escalation, lock_timeout_greater_than_0, xml_deadlock_report, rpc_completed, sql_batch_completed
По событиям SQL найдете блокировки SQL далее тж чтоб строки кода найти используете тж, по ТЖ управляемые блокировки, а далее править.
Сюдя по ошибке у вас управляемые блокировки и держать должно куда поболее 100 пользователей естественно при типовой конфигурации.
и если после стандартного обслуживания базы проблема не уходит то:
Блокировки можете разобрать снимая тж
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="ваш путь" history="8">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<event>
<eq property="name" value="SDBL"/>
</event>
<event>
<eq property="name" value="CALL"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<event>
<eq property="name" value="TLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<property name="all"/>
</log>
</config>
и события SQL lock_deadlock, lock_deadlock_chain, lock_timeout, lock_escalation, lock_timeout_greater_than_0, xml_deadlock_report, rpc_completed, sql_batch_completed
По событиям SQL найдете блокировки SQL далее тж чтоб строки кода найти используете тж, по ТЖ управляемые блокировки, а далее править.
Сюдя по ошибке у вас управляемые блокировки и держать должно куда поболее 100 пользователей естественно при типовой конфигурации.
Забыл отписаться. По факту помогла корректная настройка обслуживания базы.
Обновление статистики, дефрагментация индексов, перестроение, вот это вот всё.
Обновление статистики, дефрагментация индексов, перестроение, вот это вот всё.
(31) Добрый день!
Тоже похожая проблема на предприятии, УПП sql 8.3. Только пользователей 500+
Сделали свертку, после этого начались блокировки.
Что только уже не делали, и сервер поменяли, мощный теперь, и все процедуры в ТИ, и dt ввгружали-загркжали. Не помогает ничего.
Подскажите какие настройки использовали?
Тоже похожая проблема на предприятии, УПП sql 8.3. Только пользователей 500+
Сделали свертку, после этого начались блокировки.
Что только уже не делали, и сервер поменяли, мощный теперь, и все процедуры в ТИ, и dt ввгружали-загркжали. Не помогает ничего.
Подскажите какие настройки использовали?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот