← На главную

В процессе эксплуатации высоконагруженных и объемных баз данных (размером более 100 ГБ) нередко возникает ситуация, когда при попытке открыть отдельные документы или справочники программа аварийно завершает работу с ошибкой. При этом сбой проявляется выборочно: часть пользователей не может работать с конкретными объектами, в то время как у других сотрудников те же действия выполняются штатно.

В условиях активного рабочего дня полная остановка системы и запуск длительных регламентных процедур приводят к простою бизнеса. Разберем по шагам, почему возникает эта проблема, как быстро вернуть базу в работоспособное состояние без длительного простоя и как правильно выполнять тестирование баз большого объема.

Причина 1. Рассинхронизация метаданных после динамического обновления

Чаще всего выборочное падение сеансов у части пользователей при открытии документов связано с последствиями так называемого «демонического» (динамического) обновления конфигурации. При обновлении метаданных «на лету» без монопольного захвата базы в таблицах Config и ConfigSave на уровне СУБД могут возникнуть расхождения версий структур или повреждения записей, а сервер приложений 1С начинает отдавать сеансам некорректно скомпилированные формы.

Разберем способы быстрого устранения этой проблемы:

1. Фиктивное изменение метаданных (быстрый способ). Откроем конфигурацию в Конфигураторе, внесем любое незначительное изменение (например, добавим символ в синоним или комментарий любого реквизита), сохраним и применим изменения через Обновить конфигурацию базы данных (клавиша F7). Это действие инициирует принудительную полную перезапись и перекомпиляцию таблиц метаданных, устраняя накопившиеся ошибки динамических обновлений.
2. Полная накатка файла конфигурации (надежный способ). Если фиктивное изменение не помогло, снимем блокировку сеансов в нерабочее время, выгрузим конфигурацию в файл через меню Конфигурация — Сохранить конфигурацию в файл (.cf) из заведомо исправной копии или архива и загрузим ее в рабочую базу через команду Конфигурация — Загрузить конфигурацию из файла. Загрузка файла полностью пересоздает структуру метаданных в СУБД.

Причина 2. Повреждение клиентского и серверного кэша

Если после обновления структуры метаданных у части пользователей ошибка сохраняется, проанализируем состояние кэша сеансов и рабочих процессов кластера 1С.

1. Очистка кэша на клиенте: удалим базу из списка в окне запуска 1С и добавим ее заново либо вручную очистим каталоги временных файлов пользователя %AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8.
2. Очистка серверного кэша кластера: при повреждении кэша на сервере приложений остановим службу ragent, перейдем в рабочий каталог кластера (по умолчанию srvinfo или reg_1541), удалим временные папки с GUID-именами сеансов (сохраняя конфигурационные файлы 1CV8Clst.lst и 1CV8Clst.cfl) и повторно запустим службу сервера.

Диагностика сбоев без остановки пользователей

Если перезапись метаданных и очистка кэша не решили проблему, выясним точную причину падения без отключения работающих пользователей:

1. Настройка Технологического журнала (ТЖ): настроим сбор событий в файле logcfg.xml для фиксации критических ошибок процессов rphost. Соберем события EXCP и EXCPCNTX, чтобы перехватить точный текст исключения, имя сбойного метода и проблемный SQL-запрос.
2. Фоновая проверка на уровне СУБД:

   Для MS SQL Server выполним быструю проверку физической целостности без монопольного захвата базы:

   DBCC CHECKDB ('ИмяБазы') WITH PHYSICAL_ONLY, NO_INFOMSGS;

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

   Для PostgreSQL используем модуль amcheck для фоновой проверки индексов типа B-tree на наличие повреждений без блокировки читающих и пишущих транзакций.

Методика тестирования баз объемом более 100 ГБ

Запуск стандартного механизма Тестирование и исправление (ТиИ) через Конфигуратор на базе объемом более 100 ГБ требует монопольного режима и может длиться десятки часов, что неприемлемо в течение рабочего дня.

Рассмотрим правильный регламент обслуживания крупных баз:

1. Тестирование только на копии: перед любыми исправлениями развернем резервную копию на тестовом сервере и выполним полный цикл проверок на ней. Это позволит оценить время выполнения операций и предотвратить потерю данных в рабочей среде.
2. Поэтапный запуск проверок: если необходимо выполнить ТиИ в рабочей базе, запускаем опции по отдельности в ночное технологическое окно:

   — сначала Реиндексация таблиц;

   — затем Проверка логической целостности;

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

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