Что такое блокировки в 1С, зачем они нужны и как избежать проблем при работе с ними

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

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

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

Мы определились, что при превышении таймаута пользователю выводиться сообщение об ошибке, сам процесс ожидания для него выглядит залипанием экрана информационной системы 1С. На вероятность появления сообщения о таймауте (ошибки 1С у пользователя) влияют следующие показатели:

• Множество блокировок 1С в транзакции;
• Длительность транзакции.

Для минимизации сообщений, связанных с ошибками блокировок, необходимо либо уменьшать множество блокировок (оптимизировать селективность), либо уменьшать длительность транзакций.
Теперь определимся каким образом на эти показатели можно влиять в реальной информационной системе 1С.

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

В 1С:Предприятие 7.7:

Информационная система 1С 7.7. для блокировок используют табличные блокировки, которые парализуют работу пользователей. Как правило более 50 человек в одной базе данных не могут безошибочно работать, при этом проблемы могут появляться и в базах данных от 20 пользователей.
Решение:

• Гибкие блокировки 1С от компании «Софтпоинт». С их помощью вы не только оптимизируете множество блокировок (замена табличных блокировок на пользовательские), но и ускорите подборы, поиски и отчеты.

В 1С:Предприятие 8.x:
Информационная система 1С 8.1., 1С 8.2., 1С 8.3. в автоматическом режиме использует избыточные блокировки вида (REPEATABLEREAD, SERIALIZABLE). Это приводит к ухудшению работы пользователей от 100.
Решение:

• Управляемые блокировки 1С – встроенное средство платформы 1С для более селективной настройки блокировок. Чтобы его использовать, программист должен сам прописать в нужных местах кода специальные операторы, чтобы заблокировать нужные (по его мнению! ) записи в таблицах информационной системы;
• Гибкие блокировки 1С – технология компании Софтпоинт для замены стандартных блокировок на пользовательские.

Для уменьшения длительности транзакций:

Для любых информационных систем 1С (1С 7.7., 1С 8.1, 1С 8.2, 1С 8.3) как и для других информационных систем применяется схожие подходы:

Проверка и правильная настройка регламентного обслуживания базы данных (обслуживание файлов, индексов, статистик, базы временных таблиц, настройка Windows и SQLServer);

Анализ и оптимизация тяжелых запросов 1С и SQL (индексный тюнинг, переписывание запросов);

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

1. Если Вы хотите самостоятельно разбираться с техническими проблемами производительности 1С (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) и других информационных систем , то для Вас уникальный список технических статей в нашем Альманахе (Блокировки и взаимоблокировки, большая нагрузка на CPU и диски, обслуживание баз данных и индексный тюнинг - лишь малая часть технических материалов, которые Вы там найдете).
2. сли Вы хотите обсудить с нашим экспертом проблемы производительности или заказать решение мониторинг производительности PerfExpert , то оставьте заявку и мы свяжемся с Вами в кратчайшие сроки.

Не мог записать изменения для передачи в распределенную базу, обратился в поддержку 1с предложили следующее. У меня решилось просто перезагрузкой сервера приложений и cсервера с SQL. Вообще можно поставить галочку «Блокировка регламентных
заданий включена»
Тоже помогло без перезагрузки.

Регламентные операции на уровне СУБД для MS SQL Server

Инструкция по выполнению регламентных операций на уровне СУБД.

Информация применима к клиент-серверному варианту 1С:Предприятия 8 при использовании СУБД MS SQL Server.

Общие сведения

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

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

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

Обновление статистик

MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.

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

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

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

exec sp_msforeachtable N"UPDATE STATISTICS ? WITH FULLSCAN"

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

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

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

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

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

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

Обновление статистик необходимо проводить с включенной опцией Full Scan.

Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.

Очистка процедурного КЭШа

Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:

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

Настройка очистки процедурного КЭШа (MS SQL 2005)

Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.

В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:

Дефрагментация индексов

При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.

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

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация».Добавьте в него задачу Rebuild Index Task:

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

Реиндексация таблиц базы данных

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

sp_msforeachtable N"DBCC DBREINDEX (""?"")"

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

Настройка реиндексации таблиц (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

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

Конфликт блокировок в 1С 8.3 и его значение

Для большинства пользователей сообщение о конфликте блокировок 1С означает лишь ошибку, мешающую им выполнять свою работу. Они хотят поскорее избавиться от этой проблемы и осаждают IT-отдел жалобами на то, что «1С не работает».

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

Причины возникновения ошибок блокировки в 1С

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

Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:

Одновременная работа пользователей с большим объемом данных. Эта первопричина продиктована внутренними механизмами 1С. Они предполагают запрет изменения данных, вовлеченных в транзакцию, запущенную от имени другого пользователя;

Ошибки и недочеты в конфигурации. В структуре типовых решений от компании «1С» учтены рекомендации по максимизации производительности. Но сторонние разработчики не всегда придерживаются высоких стандартов, и в их коде часто можно встретить следующие недочеты:

• Неоптимальные запросы;
• Запрос остатков в начале действий;
• Непонимание предназначения объектов конфигурации и их неправильное применение;
• Избыточность заложенных в системе или дополнительно разработанных блокировок.

Как исправить конфликт блокировок в 1С 8.3

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

Решением проблемы конфликта блокировок в 1С 8.3 может стать перевод конфигурации на управляемый (ручной) режим управления блокировками. Реализованный в версии 8.1, механизм в руках грамотных специалистов решает проблему конфликта блокировок при транзакции в 1С.

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

Быстрое решение конфликта блокировок 1С

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

Для быстрого решения проблемы существуют два пути:

• Найти и завершить сеанс, заблокировавший необходимые данные. В небольших компаниях, где количество пользователей 1С не превышает пары десятков человек, это оптимальный вариант решения;
• Если вы контролируете систему, в которой работают сотни сотрудников, поиск нужного сеанса без специализированного программного обеспечения может затянуться надолго. В этом случае намного эффективнее будет перезагрузить сервер.

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