Разберем крайне неприятную и специфическую ситуацию, с которой иногда сталкиваются системные администраторы и программисты 1С. Суть проблемы заключается в следующем: при попытке запустить информационную базу (в режиме «Предприятие» или «Конфигуратор») процесс зависает на этапе появления сплеш-скрина (заставки), а дисковое пространство на системном диске начинает стремительно таять. Папка %temp% разрастается до невероятных размеров — 200, 300 и более гигабайт, даже если сама база весит всего несколько сотен мегабайт. При этом стандартная утилита chdbfl.exe гордо сообщает, что ошибок в базе не обнаружено.
Проанализируем причины этого явления и рассмотрим пошаговый алгоритм действий для спасения данных, когда традиционные методы не помогают и бэкапов под рукой не оказалось.
Первым делом проанализируем, почему платформа ведет себя подобным образом. Ситуация, когда объем временных файлов в сотни раз превышает объем самой базы, указывает на логическую циклическую ссылку или повреждение структуры внутренних таблиц, отвечающих за хранение конфигурации (прежде всего, таблицы CONFIG и CONFIGSAVE).
В файловой базе .1CD конфигурация хранится в виде упакованных блоков данных. Когда мы запускаем 1С, платформа пытается «собрать» конфигурацию воедино, декомпрессируя эти блоки во временные файлы. Если в цепочке блоков данных возникает логический сбой (например, блок ссылается сам на себя или указывает на некорректный адрес следующего фрагмента), алгоритм распаковки уходит в бесконечный цикл. Платформа раз за разом пишет одни и те же данные в %temp%, пока не закончится место на диске. Поскольку физически файл базы цел (страницы данных читаются), chdbfl.exe не видит проблемы, так как она лежит на уровне логики хранения объектов конфигурации.
Как показывает практика, иногда самый простой (хотя и долгий) путь — это дать платформе завершить начатое. Рассмотрим этот вариант подробнее:
TEMP и TMP на этот носитель через настройки операционной системы.Если графическая оболочка конфигуратора «умирает» при попытке отрисовки интерфейса, попробуем обратиться к базе напрямую через командную строку. Иногда это позволяет миновать некоторые этапы инициализации, на которых происходит зацикливание.
Попробуем выполнить выгрузку файла конфигурации (.cf). Для этого воспользуемся командой:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "ПутьКВашейБазе" /DumpCfg "C:\temp\config.cf"
Проанализируем результат: если файл выгрузился, создадим чистую информационную базу и попробуем загрузить этот .cf туда. Если загрузка прошла успешно, значит, сама конфигурация жизнеспособна, а проблема кроется в конкретном файле данных .1CD или кэше служебных таблиц.
Если нам удалось зайти в «Конфигуратор» после долгого ожидания, не спешите радоваться. База всё еще находится в «аварийном» состоянии. Нам необходимо провести полное Тестирование и исправление. Разберем, какие настройки критически важны:
Важный нюанс: при выполнении ТИИ база снова начнет потреблять место в Temp, поэтому убедитесь, что у вас всё еще подключен диск с огромным запасом памяти.
Иногда проблема вызвана не самой конфигурацией, а «зависшими» параметрами в служебных таблицах базы данных. Рассмотрим шаги по их устранению:
%userprofile%\AppData\Local\1C\1cv8 и %userprofile%\AppData\Roaming\1C\1cv8..1CD без запуска самой платформы 1С. Проанализируем таблицу CONFIG. Если её размер кажется аномальным, или утилита выдает ошибки при чтении, это подтверждает версию о повреждении метаданных.Если зайти в «Конфигуратор» удалось, но ТИИ вылетает с ошибкой или требует терабайты места, попробуем метод «замещения»:
Рассмотрим последовательность действий:
Конфигурация -> Поддержка -> Настройка поддержки -> Снять с поддержки.Конфигурация -> Загрузить конфигурацию из файла.....cf той же самой версии конфигурации (например, из типового дистрибутива или другого рабочего бэкапа этой же базы).Этот процесс полностью перезаписывает таблицу CONFIG, что зачастую устраняет логические циклы и битые блоки декомпрессии.
Посмотрим на ситуацию глобально. Чаще всего такие сбои происходят при аварийном завершении работы 1С (отключение света, зависание компьютера) в момент обновления конфигурации или при динамическом обновлении («демоническое обновление»).
Основные рекомендации для профилактики:
Подводя итог, проанализируем ситуацию автора: база открылась через 2 часа, съев 300 Гб места. Это классический пример «тяжелого» логического повреждения. В таких случаях после успешного открытия крайне рекомендуется не продолжать работу в этом же файле .1CD, а выгрузить данные в чистую базу через обработку «Выгрузка и загрузка данных XML», чтобы начать жизнь с «чистого листа» без скрытых дефектов в структуре таблиц.