Рассмотрим типовую ситуацию для обслуживающей бухгалтерии (бухгалтерского аутсорсинга): на сервере развернуто около сотни информационных баз 1С:Бухгалтерия объемом от 400 МБ до 1 ГБ. В системе работают одновременно всего 2–3 бухгалтера, причем каждый обращается к ограниченному числу баз. При этом экземпляр MS SQL Server и процессы кластера 1С потребляют значительный объем оперативной памяти и ресурсов процессора из-за фоновых регламентных заданий (полнотекстовый поиск, обновление классификаторов, расчет итогов).
Проанализируем технические плюсы и минусы перехода на файловый режим, разберем вопросы быстродействия, безопасности, организации резервного копирования, а также методы оптимизации существующего SQL-сервера.
Архитектурные различия: почему SQL создает оверхед на пуле мелких баз
Клиент-серверная архитектура 1С ориентирована на высокую конкурентную нагрузку, когда в одной или нескольких базах одновременно работают десятки и сотни пользователей. В этом случае затраты ресурсов на передачу данных по сети между клиентом, сервером 1С (rphost) и СУБД полностью оправданы параллелизмом транзакций и отсутствием блокировок на уровне файлов.
В случае обслуживающей бухгалтерии ситуация противоположная:
Фоновые процессы кластера: При подключении 100 баз к серверу 1С каждая база регистрирует собственные регламентные задачи. Даже если в базу никто не заходит, кластер серверов и СУБД регулярно инициируют обращения к диску и памяти для обновления индекса полнотекстового поиска, служебных проверок и сбора статистики.
Сетевой оверхед и сериализация данных: В файловом режиме при работе одного пользователя на локальном диске или через терминальный сервер (RDP) все вычисления и доступ к таблицам 1Cv8.1CD происходят в адресном пространстве одного процесса. В клиент-серверном варианте на каждый запрос накладываются накладные расходы на сериализацию данных между сервером 1С и SQL-сервером, что на небольших объемах данных (400–500 МБ) делает отчеты и закрытие месяца субъективно и объективно медленнее.
Специфика базовых версий: Клиенты аутсорсинга часто передают базы базовых версий конфигураций. Размещение базовой версии на SQL-сервере невозможно без конвертации в ПРОФ, а обратная выгрузка клиенту требует дополнительных трудозатрат.
Ограничения и риски файлового режима
Принимая решение о переводе баз в файлы, необходимо учитывать технические ограничения файловой СУБД 1С:
Предельный размер таблиц: По умолчанию размер страницы в файловой базе равен 4 КБ, что ограничивает максимальный размер любой отдельной внутренней таблицы величиной в 4 ГБ. Если база вырастет или накопит объемные присоединенные файлы (BLOB), потребуется утилита изменения формата или возврат на SQL.
Блокировки и целостность при сбоях: Файловая база использует блокировки на уровне всей таблицы и структуры файла. При падении сеанса RDP или сетевом сбое во время транзакции записи повышается риск логического повреждения структуры файла. Для восстановления целостности требуется штатная утилита chdbfl.exe.
Остановка регламентных заданий: В файловой базе регламентные задания не выполняются в фоновом режиме, пока в базу не зашел хотя бы один пользователь, если база не опубликована на веб-сервере.
Вариант решения 1: Переход на файловый режим и организация инфраструктуры
Если принято решение перевести базы в файловый формат, разберем по шагам правильную организацию файлового пула:
Хранение на едином быстром диске: Базы размещаются в структурированном каталоге на сервере (например, на быстром SSD/NVMe-накопителе). Доступ пользователей организуется исключительно через терминальный сервер (RDP / RemoteApp) либо через публикацию на веб-сервере (IIS / Apache). Прямой доступ к файлам базы через общий сетевой ресурс (SMB/SAMBA) категорически не рекомендуется из-за высокого риска повреждения файлов 1Cv8.1CD при обрывах сети.
Централизация списков баз: Чтобы исключить ручное добавление 100 баз каждым бухгалтером, настраивается общий файл со списком баз 1CESCmn.v8i, подключаемый в окне запуска 1С.
Настройка резервного копирования через теневые копии (VSS): Для горячего бэкапа сотен файловых баз без остановки работы пользователей настраивается механизм теневых копий тома (Volume Shadow Copy). Схема выглядит следующим образом:
Создается снимок файловой системы (VSS-снапшот), фиксирующий состояние всех файлов на момент времени.
Скрипт архивации считывает файлы 1Cv8.1CD из теневой копии, исключая блокировки со стороны открытых сеансов пользователей.
Архивы баз сжимаются и перемещаются во внешнее хранилище или на резервный сервер.
Пакетное обслуживание: Для регулярной выгрузки конфигураций в .dt или проверки целостности используются пакетные скрипты командной строки в нерабочее время:
Вариант решения 2: Оптимизация существующего SQL-сервера без миграции
Если сохранение базы на SQL предпочтительно из соображений безопасности (защита от прямого копирования файлов базы пользователями) и единого централизованного бэкапа, уменьшим потребление ресурсов настройками кластера и СУБД:
Отключение регламентных заданий на неактивных базах: В консоли администрирования кластера серверов 1С для архивных или редко используемых баз включаем параметр Блокировка регламентных заданий включена. Это предотвратит постоянную фоновую активность процессов rphost.
Отключение полнотекстового поиска: В самих конфигурациях отключаем регламентное обновление индекса полнотекстового поиска для неактивных организаций через меню «Администрирование — Обслуживание — Регламентные операции».
Настройка параметров MS SQL Server:
Ограничиваем параметр Max Server Memory, чтобы SQL-сервер не забирал всю доступную память виртуальной машины.
Проверяем, чтобы у баз было отключено автоматическое сжатие (Auto Shrink = False) и автоматическое закрытие (Auto Close = False), так как эти параметры приводят к постоянным скачкам нагрузки на процессор и диск.
Автоматизация резервного копирования SQL: Вместо ручной настройки 100 планов обслуживания используем единый SQL-скрипт или планы обслуживания с перебором баз через курсор по системному представлению sys.databases.
Сравнительный итог
Для конфигурации 1С:Бухгалтерия в рамках аутсорсинга (100 баз до 1 ГБ, 2–3 пользователя) перевод в файловый режим с работой через RDP или веб-сервер и бэкапами через VSS является технически и экономически оправданным. Он снимает нагрузку со СУБД, обеспечивает более быстрый отклик типовых отчетов и упрощает обмен базами базовых версий с клиентами.