← На главную

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

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

Почему копия базы работает и выгружается без проблем, а оригинал зависает?

Для начала проанализируем ситуацию. Когда мы создаем «чистую» копию базы данных из бэкапа SQL на том же сервере, мы получаем объект, который с точки зрения платформы 1С:Предприятие полностью изолирован от накопившихся проблем оригинала:

1. Отсутствие активных сеансов и зависших транзакций: На копии нет пользователей, нет «спящих» или зависших сессий, которые могут невидимо блокировать таблицы СУБД.
2. Отключенные регламентные задания: В новой базе фоновые процессы еще не успели запуститься и начать свою работу.
3. Уникальный идентификатор (GUID) в кластере 1С: Для новой базы создается собственный уникальный идентификатор в кластере 1С. Это значит, что все серверные кэши, сеансовые данные и временные файлы, привязанные к оригинальной базе по ее старому GUID, не влияют на работу копии.

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

Шаг 1. Блокировка регламентных заданий и завершение активных сеансов

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

Выполним процедуру полной изоляции базы данных в кластере 1С:

1. Откроем консоль «Администрирование серверов 1С:Предприятия».
2. Найдем нашу рабочую информационную базу в списке.
3. Откроем свойства базы данных и установим следующие параметры:
   • Установим флаг «Блокировка начала сеансов включена».
   • Установим флаг «Блокировка регламентных заданий включена».
   • Укажем понятное сообщение для пользователей в поле «Сообщение» и при необходимости зададим код разрешения (например, КодРазрешения) для возможности входа администратора.
4. Перейдем в ветку «Сеансы» для данной информационной базы.
5. Принудительно удалим все активные сеансы пользователей и фоновые задания, выделив их и нажав кнопку «Удалить». Убедимся, что список сеансов абсолютно пуст (за исключением сеанса администратора, если вы зашли под кодом разрешения).

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

Шаг 2. Очистка серверного кэша без перезагрузки сервера

Очистка клиентского кэша на локальном компьютере пользователя (в каталогах %appdata%\1C\1Cv8) в случае клиент-серверной базы не решит проблему с зависанием на стороне сервера. Нам необходимо очистить кэш на сервере приложений 1С. В этом кэше хранятся сеансовые данные, состояния конфигурации и настройки соединений.

Для выполнения этой процедуры перезагружать весь физический сервер Windows или Linux не требуется. Достаточно перезапустить саму службу сервера 1С и удалить временные папки:

1. Остановим службу сервера 1С:Предприятия. В ОС Windows это можно сделать через оснастку services.msc (служба «Агент сервера 1С:Предприятия 8.3») или из командной строки с правами администратора: net stop "1C:Enterprise 8.3 Server Agent"
2. Перейдем в каталог данных кластера 1С. По умолчанию в Windows этот путь выглядит так: C:\Program Files\1cv8\srvinfo\reg_1541\ (где reg_1541 — порт вашего кластера).
3. Внутри каталога найдем и полностью удалим папки, названия которых начинаются со слова snccntx (например, snccntx57d9f782-e3e9-4e76-bebe-084a44f8b00a). Эти папки содержат кэш сеансовых данных конкретных информационных баз. При их повреждении монопольные транзакции могут наглухо зависать.
4. Также удалим файлы настроек баз данных с расширением .pfl из этого каталога.
5. Запустим службу сервера 1С заново: net start "1C:Enterprise 8.3 Server Agent"

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

Шаг 3. Проверка свободного места и перенаправление папки TEMP

Выгрузка базы в формат .dt — это ресурсоемкая операция архивирования, при которой платформа 1С последовательно выгружает таблицы СУБД во временные файлы на диске сервера приложений 1С, упаковывает их и только потом формирует финальный файл. Если на системном диске сервера приложений (обычно диск C:) недостаточно свободного места, процесс прервется ошибкой файловой операции.

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

1. Проверим наличие свободного места на диске C: сервера приложений 1С. Для крупных баз данных (размером от 50 Гб и выше) в процессе выгрузки может потребоваться до 100-150 Гб свободного дискового пространства под временные файлы.
2. Очистим временный каталог профиля пользователя службы 1С. Обычно он находится по пути: C:\Users\usr1cv8\AppData\Local\Temp\ или в системной папке C:\Windows\Temp\.
3. Если на системном диске физически нет места, мы можем перенаправить временные папки службы 1С на другой, более емкий диск (например, диск D:). Для этого в свойствах системы в разделе «Переменные среды» для учетной записи usr1cv8 изменим значения переменных TEMP и TMP, указав путь к новой папке на диске D: (например, D:\1C_Temp). Обязательно предоставим полные права доступа учетной записи usr1cv8 на эту новую папку.

Шаг 4. Очистка индекса Полнотекстового поиска (ППД)

Иногда рабочий процесс сервера 1С (rphost.exe) зависает из-за сбоев в работе механизма полнотекстового поиска данных. Индексы могут заблокировать выполнение любых монопольных транзакций. Проверим эту гипотезу и выполним очистку:

1. Запустим оригинальную базу данных 1С в режиме «1С:Предприятие» под учетной записью администратора.
2. Перейдем в раздел «НСИ и администрирование» (или аналогичный раздел администрирования в вашей конфигурации) -> «Общие настройки» -> «Полнотекстовый поиск данных».
3. Нажмем кнопку «Очистить индекс». Система удалит физические файлы индексов с диска.
4. Временно снимем флаг «Полнотекстовый поиск разрешен» для проведения регламентных работ по выгрузке и обновлению.

Шаг 5. Проверка параметров автороста базы данных и TempDB в MS SQL

Если в процессе обновления конфигурации или выгрузки базы происходит реструктуризация таблиц, СУБД (например, MS SQL Server) начинает активно использовать системную базу данных TempDB и файл журнала транзакций (.ldf) рабочей базы.

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

Проанализируем настройки СУБД:

1. Откроем Microsoft SQL Server Management Studio (SSMS).
2. Перейдем в свойства системной базы данных tempdb.
3. Убедимся, что для файлов данных базы tempdb установлен фиксированный шаг автороста (например, 256 Мб или 512 Мб, но не в процентах), а также достаточно свободного места на диске, где она расположена.
4. Откроем свойства нашей рабочей базы данных 1С. Проверим размер и параметры роста файла журнала транзакций (.ldf). Если лог транзакций сильно разросся, выполним его сжатие (Shrink) после предварительного резервного копирования лога.

Шаг 6. Использование 64-разрядного клиента 1С для ресурсоемких операций

При выгрузке очень крупных баз данных стандартный 32-разрядный Конфигуратор 1С может упираться в ограничение адресного пространства процесса (около 2-4 Гб оперативной памяти). Превышение этого лимита приводит к аварийному завершению работы Конфигуратора с ошибками файловой системы.

Для гарантированного обхода этого ограничения мы рекомендуем запускать Конфигуратор через 64-разрядную версию платформы клиентской части 1С (начиная с версии 8.3.9 платформа предоставляет полноценный 64-битный тонкий и толстый клиент для Windows). Это позволит процессу Конфигуратора использовать весь объем доступной оперативной памяти на компьютере, с которого запускается выгрузка.

Заключение и выводы

Выгрузка базы данных в формат .dt на клиент-серверных вариантах работы — это лакмусовая бумажка стабильности всей системы. Однако помните, что для больших рабочих баз (более 50-100 Гб) использование формата .dt для регулярного резервного копирования не рекомендуется разработчиками самой фирмы 1С. В таких масштабах гораздо надежнее и быстрее использовать средства СУБД — создание бэкапов (.bak файлы в MS SQL) или снимков конфигурации (.cf файлов) совместно со схемами хранения данных.

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