Многие администраторы и специалисты по 1С сталкиваются с неприятной ситуацией: по утрам пользователи не могут войти в программу, а система выдает пугающее сообщение «Файл базы данных поврежден». Зачастую это происходит после ночных бэкапов, перед которыми принудительно завершаются все терминальные сеансы пользователей. Давайте подробно разберем эту проблему, выясним причины регулярного «падения» файловых баз и проанализируем эффективные способы предотвращения подобных сбоев.
Рассмотрим, как работает 1С в файловом варианте. Вся база данных представляет собой единственный файл 1Cv8.1CD. В отличие от клиент-серверной архитектуры, здесь нет отдельного сервиса, который управляет записью. Процесс записи данных и обновления индексов выполняется непосредственно клиентским приложением (самой программой 1С, запущенной у пользователя).
Когда системный администратор настраивает автоматическое или ручное «убийство» терминальных сессий по ночам (или по таймауту простоя), процесс записи прерывается максимально грубо. Если в этот момент 1С записывала данные (например, выполнялось фоновое задание или пользователь оставил открытым незавершенный процесс перепроведения), в файл базы успевает попасть только часть транзакции. В результате возникает рассинхронизация внутренних таблиц и индексов файла, что и приводит к ошибке целостности.
Часто системные администраторы предлагают использовать программы для резервного копирования (например, Cobian Backup), работающие через службу теневого копирования тома (VSS). На первый взгляд, это кажется отличным решением: можно копировать файл 1Cv8.1CD прямо во время работы пользователей, не выгоняя их из программы.
Проанализируем этот подход детальнее. Технология VSS гарантирует целостность только для тех приложений, которые поддерживают специальный компонент — VSS Writer (как, например, MS SQL Server). Платформа 1С для файловых баз такого компонента не имеет. Это означает, что если создание теневой копии совпадет с моментом активной записи в базу, в резервную копию попадет «разрезанная» транзакция. При попытке восстановить базу из такого бэкапа вы с высокой вероятностью получите битый файл.
В ситуациях, когда на одном сервере крутится десяток файловых баз и работает множество пользователей в терминале, классические жесткие диски (HDD) становятся узким местом. При одновременном обращении пользователей к разным базам, а также при параллельном обновлении нескольких баз, возникает колоссальная очередь ввода-вывода (так называемое «метание головок диска»).
Из-за того, что диск физически не успевает считывать и записывать данные, интерфейс 1С начинает «зависать». Нервные пользователи, не дождавшись отклика, принудительно закрывают программу через Диспетчер задач. Это возвращает нас к первой причине — жесткому обрыву сеанса и, как следствие, разрушению структуры базы.
Рассмотрим самое надежное и кардинальное решение проблемы — использование полноценной СУБД. Если бюджет ограничен (или, как говорят, «жаба давит»), отличным вариантом станет развертывание бесплатной СУБД PostgreSQL.
В клиент-серверном варианте база данных физически не существует в виде единого уязвимого файла, к которому обращаются клиенты. Записью и обеспечением целостности данных управляет сервер СУБД (в соответствии с требованиями ACID). В таком режиме:
Именно этот шаг навсегда избавит вас от ошибки повреждения базы из-за действий сисадмина.
Если переход на СУБД по каким-то причинам невозможен, проанализируем промежуточный вариант — Автономный сервер 1С (ibsrv). Это специальный режим работы платформы, который выступает прослойкой между файловой базой и пользователями.
Суть метода заключается в том, что к файлу 1Cv8.1CD получает монопольный доступ только один процесс — сам автономный сервер. Пользователи подключаются к этому серверу по сети (через HTTP/HTTPS или TCP).
Если сеанс пользователя аварийно завершится, процесс автономного сервера отработает эту ситуацию корректно, так как он сам не прерывается. Файл базы данных останется целым. Однако стоит учитывать особенность: один экземпляр автономного сервера обслуживает только одну базу. Если у вас 10 баз, придется запускать 10 процессов и распределять их по разным портам.
Посмотрим на аппаратную часть. Для нормальной работы даже файловых баз в терминальном режиме настоятельно рекомендуется перенести их на SSD-накопители серверного класса. Твердотельные накопители полностью лишены механических задержек, очередей позиционирования головок и легко справляются с параллельным вводом-выводом. Это кардинально ускоряет работу 1С, фоновых заданий и снижает риск зависаний, провоцирующих пользователей на жесткое снятие задач.
Если сбои уже происходят, для их лечения применяется утилита chdbfl.exe (находится в папке bin установленной платформы) и Тестирование и исправление (ТИИ) в режиме Конфигуратора. Если база повреждена настолько, что стандартные утилиты вылетают с ошибкой, ситуацию спасет только восстановление из резервной копии.
Вместо варварского закрытия сессий системному администратору следует использовать корректные механизмы выгона пользователей. Например, можно написать небольшой скрипт для штатного завершения работы 1С с использованием ключей запуска платформы или создать регламентное задание внутри самой базы, которое будет завершать работу активных пользователей в определенное время.
Пример логики процедуры для фонового завершения сеансов внутри 1С (Выполняется на стороне сервера):
Процедура ЗавершитьСеансыПользователей() Экспорт
МассивСеансов = ПолучитьСеансыИнформационнойБазы();
ТекущийСеанс = ТекущийСеансИнформационнойБазы();
Для Каждого Сеанс Из МассивСеансов Цикл
Если Сеанс.НомерСеанса <> ТекущийСеанс.НомерСеанса Тогда
// Блокируем новые подключения и штатно просим сеанс завершиться
ПрекратитьРаботуСистемы(Ложь);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Подведем итог: файловая база 1С в сетевом и терминальном режиме крайне уязвима к аппаратным задержкам (HDD) и обрывам соединения. Чтобы обеспечить стабильность системы, переходите на PostgreSQL, обновляйте серверные диски на SSD и запретите системным администраторам «убивать» процессы без предварительного штатного завершения работы программы.