Часто при переносе старых конфигураций, таких как «Торговля и Склад» (ТиС) на платформе 1С 7.7, на современные серверы (например, Windows Server 2012 R2 и SQL Server 2012), администраторы и пользователи сталкиваются с критической проблемой. При работе большого количества пользователей (например, около 100 активных сеансов) система начинает регулярно «зависать», а пользователи получают системное сообщение: «Ошибка блокировки при модификации или удалении записи. Таблица: 1SSYSTEM». Давайте подробно разберем эту ситуацию, выясним причину конфликта и рассмотрим практические способы ее решения.
Для начала проанализируем, за что отвечает таблица 1SSYSTEM в архитектуре платформы 1С 7.7. Эта таблица является ключевой системной сущностью базы данных. В ней хранится Точка Актуальности (ТА) итогов, текущая системная дата, время и идентификаторы последовательностей документов.
Механика работы такова: при оперативном проведении любого документа, который сдвигает Точку Актуальности (создает новые движения в регистрах и изменяет остатки), 1С открывает транзакцию и накладывает эксклюзивную блокировку на таблицу 1SSYSTEM. Это сделано для обеспечения целостности данных — чтобы другие пользователи не могли параллельно сдвинуть ТА и провести свои документы "в тот же момент".
Если транзакция первого пользователя затягивается во времени, все остальные пользователи, пытающиеся провести документы, выстраиваются в очередь ожидания. Если ожидание превышает допустимый таймаут, платформа выдает сообщение об ошибке блокировки, парализуя работу операторов.
Многие задаются вопросом: почему на старом SQL Server 2000 база работала стабильно, а при переходе на мощное железо и SQL Server 2012 начались массовые блокировки? Главная причина кроется в генераторе SQL-запросов самой платформы 1С 7.7 и логике работы современного оптимизатора запросов SQL Server.
Платформа 1С 7.7 генерирует запросы в устаревшем синтаксисе, который был идеально "заточен" под оптимизатор SQL Server 2000. Современный оптимизатор SQL Server 2012 зачастую не понимает специфику этих конструкций и строит для них крайне неэффективные планы выполнения (Execution Plans). Из-за этого время обработки даже штатного запроса (например, проверки остатков при проведении, использование метода ВыбратьПодчиненные и т.д.) увеличивается с миллисекунд до нескольких секунд. Транзакция остается открытой на всё это время, таблица 1SSYSTEM удерживается, и при нагрузке система быстро блокируется.
Чтобы не «выгонять» вслепую всех пользователей из базы для ее оживления, нам необходимо научиться находить конкретный процесс, который повесил блокировку.
Рассмотрим современные инструменты SQL Server, так как старый Profiler может быть неудобен. Гораздо быстрее найти блокирующую сессию можно следующими способами:
Blocked By, который сразу покажет SPID (идентификатор сессии) пользователя, повесившего блокировку на системную таблицу.Посмотрим на пример запроса для поиска блокировок:
SELECT
session_id AS SPID,
blocking_session_id AS Blocker_SPID,
wait_type,
wait_time
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
Выявив SPID, мы можем посмотреть, кто из пользователей стоит за этой сессией, и при необходимости принудительно завершить процесс (командой KILL), тем самым мгновенно сняв блокировку таблицы 1SSYSTEM.
Если ваши операторы работают через RDP (терминальный сервер), велика вероятность обрыва сетевых соединений. Если сессия пользователя зависает или завершается аварийно прямо в момент записи и проведения документа, процесс на стороне SQL Server может остаться висеть с открытой транзакцией. Именно поэтому принудительный вывод зависших пользователей "оживляет" базу.
Также обращайте внимание на временные файлы блокировок вида 1cv7.lck в локальных каталогах пользователей — иногда они остаются после сбоев и мешают корректной работе, требуя ручного удаления.
Чтобы кардинально улучшить ситуацию и избавиться от постоянных блокировок, мы применим комплексный подход. Рассмотрим основные шаги оптимизации:
1SSYSTEM. Также можно рассмотреть отказ от оперативного проведения в часы пик: документы будут просто записываться, а фактический сдвиг ТА и проведение по партиям будет выполнять отдельный робот (регламентное задание) ночью в монопольном режиме.ВыбратьПодчиненные без указания узкого периода или циклы по регистрам, перепишите их на прямые SQL-запросы с использованием компоненты 1С++. Применение хинта блокировки NOLOCK для чтения данных (где это допустимо) многократно ускорит транзакции и снимет нагрузку с системных таблиц.BkEnd.dll) или библиотеку vk_hook1c, которые оптимизируют работу устаревшего ядра 7.7 с современными архитектурами и устраняют часть проблем с ожиданием на блокировках.Подводя итог, можно с уверенностью сказать: платформа 1С 7.7 способна стабильно держать 100 и более активных пользователей даже на SQL Server 2012. Однако для этого требуется тонкая настройка SQL Server, отказ от неэффективных типовых методов запросов и строгий контроль за зависшими терминальными сессиями.