1с какие блокировки лучше управляемые или автоматические. Перевод конфигурации на управляемые блокировки

Механизм транзакционных блокировок используется для конкурентного доступа пользователей к СУБД.
Транзакция - эта некая неразрывная операция, в ходе которой меняется состояние базы. Это минимальный квант изменений: нельзя сделать пол-транзакции; если транзакция не завершилась, то база откатится в начальное состояние.
Поскольку транзакция захватывает массив данных, возникает нюанс по доступу к этому массиву: например, одна транзакция меняет данные, а другая пробует их прочитать. Результат чтения может быть некорректным, т.к. не включит последних изменений. Поэтому, на уровне СУБД работает изоляция транзакций. Возможны следующие уровни изоляции:

Read uncommited - пока одна транзакция меняет массив, другая не может его менять, но может читать. Низший уровень изоляции.
Read commited - пока одна транзакция меняет массив, другая не может его ни менять, ни читать
Repeatable read - пока одна транзакция читает массив, другая не может его менять, но может прочесть
Serialaizable - пока одна транзакция читает массив, другая не может его ни менять, ни читать. Все операции последовательны. Максимальный уровень изоляции.

Если для конфигурации 1С:Предприятия установлен режим автоматических блокировок , то уровень изоляции транзакции выбирается СУБД. В случае с MS SQL, это будет Repeatable read или Serializable уровни, то есть изоляция данных близка к максимальной. Это решает проблемы с корректностью данных, но может приводить к появлению блокировок на уровне СУБД при интенсивной работе пользователей. Поэтому, в 1С:Предприятии есть свой функционал работы с блокировками, который активизируется включением режима управляемых блокировок. В этом случае уровень изоляции транзакций для MS SQL будет Read commited. Платформа сама будет изолировать данные, не полагаясь на СУБД.

Включение режима управляемых блокировок происходит в свойствах конфигурации:

Также, режим блокировок может быть установлен для конкретных объектов конфигурации:

В случае, если для конфигурации в целом установлен Автоматический режим блокировок, то все транзакции по всем регистрам будут работать именно в автоматическом режиме, безотносительно того режима, что выставлен для объекта конфигурации. Если Управляемый - то аналогично, все транзакции будут в управляемом. Если же для конфигурации выставлен режим Автоматический и управляемый, то режим для каждого объекта будет определяться его настройками.

Для режима Автоматический и управляемый есть один момент. Транзакция, единая для пользователя может представлять собой несколько транзакций с точки зрения платформы. Например, интерактивное проведение документа по регистру делает две транзакции - запись самого документа, и внутри этой транзакции запись набора строк по регистру. В зависимости от режима управления блокировками для самого документа и двигаемого им регистра, возможны четыре ситуации:

Режим документа Автоматический, режим регистра Автоматический ->
Режим документа Управляемый, режим регистра Управляемый-> запись по регистру в управляемом режиме
Режим документа Автоматический, режим регистра Управляемый -> запись по регистру в автоматическом режиме
Режим документа Управляемый, режим регистра Автоматический -> исключительная ситуация (ошибка)

Вопрос 06.59 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:

Правильный ответ второй, определяем по первой транзакции, если автоматическая, то все автоматически.

Вопрос 06.60 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен управляемый режим управления транзакционными блокировками, а у регистра автоматический (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:

к возникновению ошибочной ситуации
вся транзакция будет выполнена в автоматическом режиме
вся транзакция будет выполнена в управляемом режиме

Правильный ответ первый, определяем по первой транзакции, если управляемая, то ошибка.

Вопрос 06.61 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Управляемый"), то такое проведение приведет:

к возникновению ошибочной ситуации
вся транзакция будет выполнена в автоматическом режиме
вся транзакция будет выполнена в управляемом режиме

О пользе перехода на управляемые блокировки в 1С 8.3 было сказано не раз — это сильно повышает эффективность и производительность работы оборудования.

Если Вам необходим партнер для перевода конфигурации в управляемый режим блокировок, просто обратитесь к нам! Подробности — .

Сам по себе процесс не такой уж и трудный. Однако процесс достаточно тонкий. Переход на управляемый режим неквалифицированным специалистом может сделать еще хуже.

Ниже мы разберем методику перехода с режима автоматических блокировок на управляемые.

Вся методика умещается в 7 коротких пунктах:

Переключите в палитре свойств конфигурации режим блокировок — «Управляемый и автоматический»:

Получите 267 видеоуроков по 1С бесплатно:

Переключение объекта в управляемый режим

Необходимо начинать с самых «загруженных» документов. Переключите документ в режим блокировок «Управляемый»:

Перевод регистров в управляемый режим

Необходимо перевести ВСЕ регистры 1С (накопления, бухгалтерии, сведений, расчета), которые производят движения данным документом, в режим управляемых блокировок:

Найти все транзакции с этими объектами

Необходимо найти все транзакции с этими объектами метаданных. Как явные, так и не явные.

Явные — те, которые вызываются в коде с помощью метода «НачатьТранзакцию()».

НЕ явные — те, которые вызываются в обработчиках объектов — «ПриЗаписи», «ОбработкаПроведения» и т.д.

Корректировка программного кода в транзакция

Для явных транзакций необходимо передать в параметр метода «НачатьТранзакцию()» параметр «РежимУправленияБлокировкойДанных.Управляемый».

Для НЕ явных транзакций установить блокировки с помощью объекта системы «БлокировкаДанных».

Пример использования блокировки:

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(«РегистрНакопления.ТоварыНаСкладах»);
ЭлементБлокировки.УстановитьЗначение(«Качество», Справочники.Качество.НайтиПоКоду(«1»));
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ДокументОбъект.ВозвратнаяТара;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(«Номенклатура», «Номенклатура»);
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(«Склад», «Склад»);
Блокировка.Заблокировать();

Заменить конструкцию ДЛЯ ИЗМЕНЕНИЯ

Ускорить 1С нажатием нескольких кнопок 2. Управляемые блокировки. September 4th, 2011

Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки. На самом деле всё несколько сложнее - но не на много.

Для начала небольшой теоретический экскурс - зачем нужны блокировки: У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:

Пример 1. Если после включения управляемых блокировок ничего не делать, и при этом начать параллельно проводить 2 документа (один из них ведь всё равно на долю секунды раньше), то получим приблизительно следующую картину:

Транзакция 1	Транзакция 2	Состояние остатков
Начало	\|	1 шт
\|	Начало	1 шт
\|	\|	1 шт
Чтение остатков	\|	1 шт
\|	Чтение остатков	1 шт
\|	\|	1 шт
Списание с остатков	\|	0 шт
\|	Списание остатков	-1 шт
Завершение	\|
	Завершение

Что здесь не так? Контроль остатков дал сбой. 2-ой документ успел прочитать остатки раньше, чем 1-й успел их записать. При этом увидел, что на остатках 1 штука и спокойно списал их вслед за первым. Стоит оговориться, что по факту блокировки здесь всё-таки будут. 2 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно.

Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:

Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно - только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок. Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка. Добавить("РегистрНакопления.ТоварыНаСкладах" ) ;
ЭлементБлокировки. УстановитьЗначение("Качество" , Справочники. Качество. НайтиПоКоду("1" ) ) ;
ЭлементБлокировки. Режим = РежимБлокировкиДанных. Исключительный;
ЭлементБлокировки. ИсточникДанных = ДокументОбъект. ВозвратнаяТара;
ЭлементБлокировки. ИспользоватьИзИсточникаДанных("Номенклатура" , "Номенклатура" ) ;
ЭлементБлокировки. ИспользоватьИзИсточникаДанных("Склад" , "Склад" ) ;
Блокировка. Заблокировать() ;

Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.

Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:

Транзакция 1	Транзакция 2	Состояние остатков
Начало	\|	1 шт
\|	Начало	1 шт
\|	\|	1 шт
Списание с остатков	\|	0 шт
\|	Списание с остатков	-1 шт
Блокировка	\|	-1 шт
Чтение остатков	Попытка блокировки	-1 шт
\|	Ожидание на блокировке	-1 шт
\|	Ожидание на блокировке	-1 шт
Завершение	Ожидание на блокировке	-1 шт
	Блокировка	-1 шт
	Чтение остатков	-1 шт
	\|	-1 шт
	Отказ	0 шт

Разница с виду не значительная - прирост производительности получаем за счет того что на время списания остатков (запись их в базу, что, собственно занимает время) блокировки ещё нет. Блокировка возникает позже к концу транзакции, куда вынесен контроль отрицательных остатков, бизнес логике приложения это вполне удовлетворяет.

Зная для чего блокировки нужны можно действительно ими управлять исходя из бизнес задач которые вы решаете. СУБД разрабатываются исходя из предположения обеспечения максисальной защиты данных. В случае если вы, к примеру, осуществляете банковские транзакции блокировки должны быть везде и на максимальном уровне. Лучше заблокировать лишние записи, чем допустить противоречивость данных.

В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно столь много блокировок. Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки.

Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.

Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь

А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.

Как же вы поступите с управляемыми блокировками - только ваше решение. Но я бы рекоммендовал не торопиться их устанавливать. Я встречал компании в которых был автоматический режим блокировки, при этом слово "замучали блокировки" звучало даже из уст генерального директора, и при этом был отключен контроль отрицательных остатков....

Давайте рассмотрим, как выглядит типичная монопольная блокировка в 1С .

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

Я думаю, вы прекрасно знаете, что в 1С есть два режима блокировок: автоматический и управляемый .

В автоматическом режиме все просто:
- При любом чтении ставится S -блокировка .
- А при любой записи ставится X -блокировка – причем, блокировки есть только на сервере СУБД , 1С никаких блокировок не ставит.
Гораздо больше интересен управляемый режим . Его главная особенность в том, что в 8.2 и в 8.3 блокировки работают по-разному .
- Например, в 8.2 у вас любое чтение будет ставить S -блокировку . Причем, чтение – это не просто Запрос.Выполнить(), но и Ссылка.Реквизит, Ссылка.ПолучитьОбъект() и т.д.
- А в 8.3 без режима совместимости уже блокировок на чтение не будет . Таким образом, 8.3 безусловно выигрывает в плане параллельности работы.
- Ну а дальше начинается самое интересное – например, для конструкции НаборЗаписей.Прочитать() в управляемом режиме 8.2 у вас будет S-блокировка на сервере СУБД (это естественно). Но кроме этого также будет разделяемая блокировка на сервере 1С , причем это проявляется и в 8.2, и в 8.3 . И главная проблема в том, что эта разделяемая блокировка у вас будет длиться до конца транзакции – пока транзакция не закончится, данные будут блокированы.
  Поэтому рекомендация номер один – если набор записей вам нужен только для чтения, лучше использовать запрос, а не объектную модель. Тогда вы ничего блокировать не будете, а если и будете, то ненадолго.
- Естественно, при любом изменении данных (запись, проведение, удаление) будет ставиться исключительная блокировка на сервере 1С и эксклюзивная на сервере СУБД .

Имея перед глазами эту таблицу, вам будет гораздо легче понять, в каких случаях вы можете столкнуться с блокировками.

Длительность блокировок в управляемом режиме

Самое главное при работе с блокировками – это помнить, что любая управляемая блокировка всегда будет держаться до конца транзакции , поэтому важно минимизировать ее длительность .

Когда у вас есть выбор, где ставить блокировку (в начале транзакции или в конце), лучше выбрать в конце, потому что в этом случае риск возникновения ожиданий будет гораздо меньше.

Что касается конструкции Запрос.Выполнить(), то если это 8.2, блокировка будет сниматься сразу после выполнения запроса, а если это 8.3 (либо в вашей СУБД MS SQL включен режим Read Committed Snapshot Isolation), тогда блокировки вообще не будет. Поэтому если у вас 8.2 или 8.3 в режиме совместимости с 8.2 , я вам всячески рекомендую включить режим Read Committed Snapshot Isolation – у вас в любом случае повысится параллельность работы.

Вот типичный пример: можно сначала поставить блокировку, выполнить какие-то расчеты и проверки (посмотреть, заполнен ли реквизит и т.д.) и только потом транзакцию закончить – тогда у вас время блокировки будет долгим. Но лучше, если есть такая возможность, поступить по-другому: сначала сделать всякие расчеты (проверку заполнения и пр.), а блокировку наложить уже в самом конце. Тогда у вас время блокировки будет меньше, и, соответственно, риск возникновения ожиданий также снизится. Поэтому старайтесь наложение явных управляемых блокировок или любую запись в базу данных делать как можно ближе к концу транзакции .

Наиболее частые причины блокировок

Запрос со сканом

Чаще всего ожидание на блокировке возникает в случае неоптимального запроса . Например, у вас есть пользователь Иванов, который в процессе проведения документа заблокировал несколько позиций номенклатуры – только то, что ему было нужно. И есть пользователь Петров, который выполнил в транзакции запрос со сканированием (Запрос.Выполнить()). И если при чтении этот запрос нарвется на номенклатуру, которая была заблокирована Ивановым, то в случае использования вами версии 8.2 (либо 8.3 в режиме совместимости с 8.2), он остановится и будет ждать по умолчанию 20 секунд. При этом пользователь Петров встанет в ожидание, что, ему, конечно, не понравится. Как решить эту ситуацию? Казалось бы, ответ очевиден – можно взять и переписать запрос так, чтобы он не читал лишних строк , тогда все будет замечательно.

А если этот запрос платформенный? Или этот запрос используется в типовой конфигурации, которую вы по очевидным причинам изменять не можете – что тогда делать? Какие есть варианты?

Выключить режим совместимости? Правильнее сказать – перекреститься, создать копию, недельку потестировать и потом выключить, потому что если вы сразу выключите, у вас могут случиться «веселые выходные», а может быть не только выходные.

Еще один вариант – это включить режим версионирования для MS SQL Server . Сразу оговорюсь, что описанная ситуация возможна только в СУБД-блокировочнике, потому что если у вас СУБД-версионник, там этой ситуации быть не может. А если вы включаете Read Committed Snapshot Isolation, тогда у вас MS SQL начинает работать почти как версионник. И ваш запрос не будет блокировать строки .

В 1С нет «волшебной таблетки», но включение режима Read Committed Snapshot Isolation – ближайший аналог этой «волшебной таблетки» . Вы минимальными действиями сразу резко сможете снизить количество ожиданий в вашей базе. Для этого вам всего лишь нужно выполнить несколько строк приведенным на скриншоте скриптом в MS SQL сервере , и вы сразу получите очень хорошее повышение параллельности работы. Конечно, это имеет смысл только для управляемого режима блокировок в конфигурации 1С. Для автоматического режима включать на сервере СУБД режим RCSI смысла нет.

Отсутствие режима разделения регистров

Часто ожидания возникают именно на регистрах накопления и на регистрах бухгалтерии – в случае, когда идет обращение к одним и тем же данным. Чтобы избежать таких ожиданий, был придуман режим разделения итогов .

Этот режим можно включить в конфигураторе в свойствах регистра на закладке «Прочее» – там есть галочка «Разрешить разделение итогов» . Когда вы создаете новый регистр накопления, эта галочка уже по умолчанию включена. Тем самым, разработчики намекают, что использовать эту возможность очень удобно, потому что она помогает писать в регистр параллельно, даже если данные у вас пересекаются.

Но здесь есть нюанс – если по этому регистру у вас используется контроль остатков, то этот способ вам никак не поможет, вам останется только ускорять время работы транзакции, чтобы блокировка была как можно короче. Но вообще включение разделителя итогов – классная возможность и я ее крайне рекомендую использовать. Особенно полезно ее включить для регистра бухгалтерии , потому что там контроля остатков практически никогда не бывает.

Перемещение границы последовательности при проведении

Если у вас используется последовательность, в которой сдвигается граница при проведении документов, то, скорее всего, у вас возникают ожидания на блокировках. Например, два документа, у которых измерение в последовательности совпадает, параллельно провестись не смогут – кто-то кого-то будет ждать.

Что тут можно сделать? Вы ставите свойство последовательности «Не перемещать автоматически» и делаете регламентное задание, которое в вечернее время у вас эту последовательность будет двигать . Вот такое простое решение – просто разбить по времени эти операции, тогда никаких ожиданий в течение дня уже не будет.

Длительные транзакции

Старайтесь делать максимально короткие транзакции:

Выносите всякие проверки и расчеты за пределы транзакции – любую запись, любое наложение блокировок надо делать в самом конце.
Ни в коем случае никаких диалоговых окон в транзакции делать не нужно, особенно, если используется толстый клиент. Мы сталкивались с такими случаями, что у бухгалтера при проведении документа выскакивало диалоговое окно с кнопками «Да» и «Нет». И пока она решит, что нажать, пока с кем-нибудь посоветуется, пока кому-то позвонит – у нее это окно будет висеть, и все это время транзакция будет активна, и, соответственно блокировка тоже будет активна – ее время будет очень долгим. Так делать не нужно.
Как можно еще ускорить время транзакции? Можно ускорить код , который там выполняется. Ускорить запросы , если вы это умеете делать. Это сразу даст резкий прирост производительности.
Еще один вариант – это ускорить запись в регистры . Как? Можно программным путем, а можно аппаратным. Например, если вы купили нормальные SSD-диски, то скорость записи у вас естественно вырастет – даже запросы станут выполняться быстрее. И, соответственно, время транзакции также уменьшится. Это не значит, что одним апгрейдом дисков можно решить проблему блокировок, но хотя бы можно сгладить этот эффект – он будет уже не так заметен.

Эскалация в многопоточном режиме

Я очень надеюсь, что многие из вас используют многопоточность для повышения производительности всяких загрузок, выгрузок, перепроведения документов, при свертке больших объемов данных. Это действительно мощная возможность, которая позволяет получить ускорение в несколько раз. Однажды мне необходимо было свернуть регистр, содержащий более 100 миллионов строк, причем, неактуальные остатки нужно было куда-то выгрузить, оставив в базе только некоторый актуальный промежуток времени. Я подумал и решил реализовать для этого случая многопоточную обработку. В результате у меня получилось, что эти потоки стали блокировать друг друга, хотя их данные вообще никак не пересекались (в каждом потоке были разные регистраторы) – тем не менее, возникало ожидание на блокировке.

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

В связи с этим я внес в алгоритм исправление , которое учитывало такие документы , и откладывало их обработку «на потом», чтобы такой эскалации не происходило, и потоки друг друга не блокировали, не отваливались с ошибками.

Когда обычно в 1С возникает эскалация? Чаще всего это какая-то тяжелая операция – закрытие месяца, расчет себестоимости и пр. – когда у вас в одной гигантской транзакции начинает проводиться много документов, блокируется вся таблица и в это время никто работать не может – параллельность падает. Такие операции необходимо учитывать отдельно и проводить их в нерабочее время , потому что в параллельном режиме вы их обработать не сможете.

Ошибка платформы – блокировка при использовании разделителя области данных

В платформе есть несколько ошибок, которые приводят к излишним ожиданиям на блокировке. Например, есть ошибка, которая меня очень удивила. Ситуация следующая – мы собрали данные об ожиданиях и увидели, что строка Запрос.Выполнить() накладывает управляемую исключительную блокировку, чего в принципе быть не может и не должно. Когда мы это увидели, мы подумали, что инструмент «сбоит». Еще раз загрузили данные. Все перепроверили. Действительно, накладывает. Оказалось, что такая ошибка появилась в платформе 8.3.6. При чтении – неважно, Запрос.Выполнить() или Константа.Прочитать() – вообще при любом чтении – платформа накладывала управляемую исключительную (Х) блокировку на поле, которое является разделителем данных и параллельность сразу падала. Причем, блокировка была именно исключительной.

Вот такая платформенная ошибка.

К счастью для нас клиент, у которого эта проблема проявилась, вообще не использовал этот разделитель данных, поэтому мы просто у реквизита сняли признак того, что он является разделителем. И все, ошибка исчезла. Но исправлена она или нет, я до сих пор не знаю. Могу точно сказать, что в 1С про эту ошибку знают, но когда они ее исправят, мне, к сожалению, не известно. Поэтому будьте готовы, что у вас такое тоже может быть.

Ошибка платформы – скан индекса регистра расчета

Также мы часто сталкиваемся с ошибками платформы по работе с регистром расчета. С точки зрения производительности у него вообще проблем очень много, потому что регистр расчета – это единственный объект в 1С, который не имеет кластерного индекса . Поэтому, когда вы записываете в регистр расчета несколько сотен строк (если строк мало, то эта ошибка не воспроизводится), или чистите там движения (записываете туда пустой набор движений) – будет производиться скан индекса таблицы регистра расчета . А поскольку это запрос платформенный, вы его поправить никак не сможете, и, так как это – удаление (накладывается X блокировка), то включение режима Read Committed Snapshot тоже никак не меняет ситуацию.

В итоге, методом проб и ошибок для этой проблемы было найдено решение. Поскольку у регистра расчета нет кластерного индекса (там есть только некластерный), пришлось этот некластерный индекс деактивировать и создать аналогичный, но кластерный. Все. После этого индекс стал использоваться, и все стало замечательно. Вот такой получился обход ситуации. И если у вас есть ЗУП, и вы сталкиваетесь с проблемой параллельности записи в регистр расчета, можете брать, пользоваться.

Еще одна проблема регистра расчета проявляется при чтении и заключается в том, что платформенный запрос, который читает данные из регистра расчета, тоже сканирует индекс. Но здесь уже помогает именно включение либо Read Committed Snapshot, либо, если у вас 8.3, вы можете убрать режим совместимости с 8.2, тогда этой проблемы у вас уже не будет.

Ошибка платформы – невозможность параллельной записи в периодический независимый регистр сведений

Очень старая ошибка, про которую в 1С тоже прекрасно знают, но, тем не менее, она до сих пор не исправлена – это невозможность параллельной записи в периодический независимый регистр сведений . Казалось бы, если у вас периоды разные (измерения совпадают, но периоды разные), вы могли бы записывать туда данные параллельно. Но этого не происходит, хотя должно бы быть. Потому что на сервере 1С накладывается излишняя блокировка по дате . На проектах эта ситуация встречается не часто – регистр сведений очень редко становится «узким местом» для блокировок. Обычно проблемы возникают из-за регистра накопления, либо из-за регистра бухгалтерии. Но, тем не менее, если вы с этим столкнетесь, можете попробовать сделать период измерением . Да, конечно, в этом случае никаких виртуальных таблиц (срез первых, срез последних) этот регистр сведений формировать уже не будет, но зато вы сможете спокойно писать в него параллельно, а запрос для получения среза первых/последних можно и самим формировать.

Во-первых, переходите на управляемый режим блокировок . Я думаю, это довольно очевидно, потому что если у вас используется автоматический режим, вы можете даже не удивляться вопросам «Почему у нас параллельность работы маленькая, почему много блокировок?» Сначала перейдите на управляемый режим, и, если после этого у вас проблемы останутся, тогда уже можно будет дальше разбираться.
Когда перевели конфигурацию в управляемый режим блокировок, обязательно должен быть включен режим СУБД Read Committed Snapshot Isolation . Это прямо Must Have –сразу будет резкий прирост по параллельности работы.
Используйте разделитель итогов для регистров . Там, где нет контроля остатков, обязательно нужно включить, чтобы не было ожиданий.
И НаборЗаписей.Прочитать() – старайтесь вообще для чтения не использовать , потому что при этом будет наложена управляемая блокировка, которая будет «висеть» до конца транзакции. Зачем вам это нужно? Читайте данные запросом, и блокировок тогда вообще не будет, если у вас 8.3 без режима совместимости или включен режим Read Committed Snapshot.

По поводу границы последовательности – тоже постарайтесь принять по умолчанию, что границу двигать только регламентным заданием в нерабочее время . При проведении не двигать.
Большие транзакции делить на несколько . Чем проводить миллион документов в одной транзакции, лучше сделать мелкие транзакции по 100 документов, по 1000 документов – еще лучше, если в многопоточном режиме. Это будет более стабильно.
Всякие расчеты, проверки и пр. делайте за пределами транзакции . Время транзакции должно быть минимальным, как можно меньше.

Пример решения проблемы блокировок

Как еще можно избавиться от излишних ожиданий?

Допустим, у вас есть торговые представители, которые после окончания рабочего дня (в 6 часов вечера), отправляют документы в базу. А там, как только эти документы через мобильный интернет приходят, они сразу пытаются загрузиться и провестись. В результате, если торговые представители заказали один и тот же товар с одного и того же склада, возникает ожидание, потому что они обращаются к одним и тем же данным, и поскольку там есть контроль остатков, разделитель итогов не поможет и кому-то кого-то придется ждать.

Как этого можно избежать? Можно при загрузке документы создавать, но не проводить , а потом написать механизм, который , например, реализует это дальнейшее проведение в многопоточном режиме , где каждый поток будет проводить документы по своему складу. Разнести, таким образом, эти процессы во времени: первый поток проводит документы по одному складу, второй поток – по второму складу и т.д. Тогда проблема будет решена.

Блокировки и оборудование

Как блокировки влияют на оборудование? Столкнувшись с проблемой блокировок, вы можете захотеть купить новый сервер. Конечно, можно попробовать, но корневым образом вы все равно ничего не измените. Да, транзакции станут быстрее, запросы станут быстрее. Но сама проблема с блокировками останется, потому что ее можно решить только на уровне кода .

Как влияет на оборудование оптимизация блокировок? Например, вы с автоматического режима перешли на управляемый, или взяли и включили Read Committed Snapshot. Пока система ждет , она оборудование не использует и оно у вас в этом случае простаивает . А как только у вас система заработала на полную мощность, ожиданий нет , у вас сразу идет резкий прирост, . И, в зависимости от того, в каком состоянии оно у вас на данный момент находится, это может быть критично. Например, если сервер у вас был загружен на 80%, а вы еще и блокировки свои устранили, он вообще может «лечь». Это обязательно нужно учитывать.

При этом, оптимизация запросов –наоборот, снижает загрузку , поэтому, если уж вы делаете оптимизацию, лучше и блокировки устранять, и запросы по возможности, оптимизировать.

Инструмент для анализа блокировок

И в заключение я хочу показать инструмент, с помощью которого вы в реальном времени можете посмотреть, какие данные сейчас в системе заблокированы .

Сегодня речь пойдет о блокировках как на уровне 1С 8.3 и 8.2, так и на уровне СУБД. Блокировка данных — обязательный элемент любой системы, количество пользователей в которой больше одного.

Ниже я распишу, как работают блокировки, и каких типов они бывают.

Блокировка — это информация о том, что ресурс системы захвачен другим пользователем. Бытует мнение, что блокировка — это ошибка. Нет, блокировка — это неизбежная мера в многопользовательской системе для разделения ресурсов.

Вред системе могут принести только избыточные («лишние») блокировки, это те блокировки, которые блокируют лишнюю информацию. Такие блокировки необходимо научиться устранять, они могут привести к неоптимальной работе системы.

Блокировки в 1С делятся условно на объектные и транзакционные.

Объектные бывают, в свою очередь, оптимистическими и пессимистическими. А транзакционные можно разделить на управляемые и автоматические.

Объектные блокировки 1С

Данный вид блокировок полностью реализован на уровне платформы 1С и никак не затрагивает СУБД.

Получите 267 видеоуроков по 1С бесплатно:

Пессимистические блокировки

Эта блокировка срабатывает, когда один пользователь что-то изменил в форме справочника, а второй пытается так же изменить объект в форме.

Оптимистические блокировки

Данная блокировка сравнивает версии объекта: если два пользователя открыли форму, и один из них изменил и записал объект, то второму при записи система выдаст ошибку, что версии объектов отличаются.

Транзакционные блокировки 1С

Механизм тразакционных блокировок 1С гораздо интереснее и более функционален, чем механизм объектных блокировок. В этом механизме активно участвуют блокировки на уровне СУБД.

Неверная работа транзакционных блокировок может привести с следующим проблемам:

проблема потерянного изменения;
проблема грязного чтения;
неповторяемость чтения;
чтение фантомов.

Подробно эти проблемы были рассмотрены в статье об .

Автоматические транзакционные блокировки 1С и СУБД

В автоматическом режиме работы за блокировки целиком и полностью отвечает СУБД. Разработчик в данном случае абсолютно не участвует в процессе. Это облегчает труд программиста 1С, однако создание информационной системы для большого количества пользователей на автоматических блокировках нежелательно (особенно для СУБД PostgreSQL, Oracle BD — при модификации данных они полностью блокируют таблицу).

Для разных СУБД в автоматическом режиме используются разные степени изоляции:

SERIALIZABLE на всю таблицу – файловый режим 1С, Oracle;
SERIALIZABLE на записи – MS SQL, IBM DB2 при работе с не объектными сущностями;
REPEATABLE READ на записи – MS SQL, IBM DB2 при работе с объектными сущностями.

Управляемые режим транзакционных блокировок 1С и СУБД

В всю ответственность на себя берет разработчик прикладного решения на уровне 1С. При этом СУБД устанавливает достаточно высокий уровень изоляции для транзакций — READ COMMITED (SERIALIZABLE для файловой СУБД).

При выполнении любой операции с БД менеджер блокировок 1С анализирует возможность блокировки (захвата) ресурса. Блокировки одного и того же пользователя всегда совместимы.

Две блокировки НЕ совместимы, если: установлены разными пользователями, имеют несовместимые виды (исключительная/разделяемая) и установлены на один и тот же ресурс.

Физическая реализация блокировок в СУБД

Физически блокировки представляют собой таблицу, которая находится в БД под названием master. Сама таблица блокировок носит имя syslockinfo.

Таблица условно имеет четыре поля:

ИД блокирующей сессии SPID;
что именно заблокировано RES ID;
тип блокировки — S,U или X MODE (на самом деле в MS SQL их 22 типа, однако в связки с 1С используется только три);
состояние блокировки — может принимать значение GRANT (установлена) и WAIT (ожидает своей очереди).