Ревизор закрылся с журналом и ушёл на обед

На складе готовятся к инвентаризации. Кладовщица Лена хочет записать движение партии К-311. Главный журнал лежит у ревизора. Ревизор заперся в кабинете, разложил страницы по столу и потребовал никого не впускать.

Лена стучит. В ответ тишина.

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

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

Блокировка часто защищает общий журнал. Сбой начинается, когда никто не знает, кто держит его и когда освободит.

Почему совместная работа вообще требует блокировок

Шаг 1. Сотрудник берёт страницу для чтения

Несколько человек могут смотреть остаток по картошке. Каждый читает журнал и никому не мешает.

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

След: активные сеансы и выполняемые действия.

Шаг 2. Сотрудник начинает менять запись

Лена исправляет количество К-311. В это же время Борис пытается записать другую цифру в ту же строку. Без правила последней записи один из них сотрёт работу другого.

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

След: объект, время начала операции и сеанс, который держит блокировку.

Шаг 3. Ревизор забирает весь журнал

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

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

След: причина монопольного режима, согласованное окно и список активных сеансов.

Шаг 4. Журнал держит внешний работник

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

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

След: процесс, расписание внешней операции и время захвата ресурса.

Шаг 5. Ревизор давно ушёл, ключ остался в двери

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

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

След: состояние процесса, его владелец, время последней активности и план безопасного завершения.

Синхронная схема

СКЛАД
[1. Несколько сотрудников читают журнал]
                 ↓
[2. Двое хотят изменить одну строку]
                 ↓ ожидание или конфликт
[3. Ревизору нужен весь журнал]
                 ↓ монопольное окно
[4. Журнал может держать внешняя служба]
                 ↓
[5. Ответственный освобождает журнал по плану]

1С
[1. Параллельные сеансы читают данные]
                 ↓
[2. Блокировка защищает конкурентную запись]
                 ↓ тайм-аут или конфликт
[3. Операция запрашивает монопольный режим]
                 ↓ окно обслуживания
[4. Файл или ресурс может использовать другой процесс]
                 ↓
[5. Блокировка снята, контрольная операция выполнена]

Три разных конфликта под похожими словами

Конфликт внутри данных

Два сеанса меняют одни и те же данные. В клиент-серверной базе детали ищут в сеансах 1С, журнале регистрации и инструментах системы управления базами данных. В файловой базе устройство блокировок другое, однако вопрос тот же: какая операция кого ждёт.

Монопольная операция

Обновлению, тесту или обслуживанию нужен исключительный доступ. Причина может быть обычной: кто-то оставил открытый сеанс, работает фоновое задание или окно обслуживания не подготовили.

Внешний процесс держит файловый ресурс

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

Дерево проверки

Что написано в сообщении полностью?

  • Есть объект или ожидание блокировки. Проверяем конфликт операций с данными.
  • Требуется монопольный режим. Проверяем все пользовательские и фоновые сеансы.
  • Упоминается файл, каталог или другое приложение. Определяем режим базы и владельца файлового ресурса.
  • Текст другой. Не подгоняем его под заголовок статьи. Сохраняем сообщение и разбираем отдельно.

Файловая база или клиент-серверная?

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

Ошибка у всех или в одной операции?

  • У одного сотрудника при записи конкретного документа. Ищем конфликт по этому объекту и времени.
  • У нескольких сотрудников в разных действиях. Ищем долгую общую операцию или широкий конфликт.
  • Только при обновлении или обслуживании. Проверяем подготовку монопольного окна.
  • Файловая база не открывается ни у кого. Проверяем сеансы и внешние процессы, которые держат ресурс.

Известен владелец блокировки?

  • Да, операция работает. Даём ей завершиться или согласуем остановку с ответственным.
  • Да, процесс завис. Готовим копию и план безопасного завершения.
  • Нет. Администратор ищет владельца средствами 1С, операционной системы и системы управления базами данных. Угадывание прекращаем.

После освобождения ресурса ошибка исчезла?

  • Да. Выполняем контрольную запись и фиксируем источник конфликта.
  • Нет. Проверяем следующий слой. Массовое завершение процессов проблему уже не объяснит.

Что видит бизнес

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

Для руководителя важны длительность, охват и повторяемость:

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

Что можно собрать безопасно

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

Стоп-действия

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

Лом действительно открывает кабинет ревизора. Заодно он меняет стоимость ремонта двери. В информационной базе цена бывает выше.

Как выглядит проверяемый результат

Плохой итог: «прибили зависший процесс, ошибка пропала».

Рабочий итог содержит:

  1. режим информационной базы;
  2. точный ресурс, который был занят;
  3. процесс, сеанс или операция-владелец;
  4. причина длительного удержания;
  5. безопасный способ освобождения;
  6. изменение, которое предупреждает повтор;
  7. контрольную операцию после исправления.

Пример: «Файловая база была доступна пользователям до начала архивирования. Программа резервного копирования удерживала файл в рабочее время. Операция штатно завершена. Расписание перенесено в согласованное окно, способ копирования проверен администратором. После освобождения ресурса два контрольных пользователя вошли в базу и записали тестовые документы. Ошибка не повторилась».

Другой вариант: «Монопольный режим не включался из-за активного фонового задания. Задание завершили штатно, окно обслуживания теперь включает проверку фоновых и пользовательских сеансов. Обновление сначала проверено на копии, затем выполнено по утверждённому плану».

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

Покажите одно сообщение и одну операцию

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

Обсудить ситуацию