База 1С сбоит: как найти повреждение и вернуть её в рабочее состояние

Лечение базы 1С начинается с копии и диагностики, а не с кнопки «Исправить». Порядок такой: сделать копию каталога или выгрузку .dt, для файловой базы прогнать утилиту chdbfl.exe, затем запустить в Конфигураторе Администрирование → Тестирование и исправление. Для клиент-серверной базы сначала проверяют саму СУБД (DBCC CHECKDB в MS SQL), и только потом — средствами 1С.

По симптомам почти всегда видно, что повреждено: файл, итоги, ссылки или только кэш на компьютере пользователя. От этого зависит, какую галочку ставить и надо ли вообще трогать данные.

Диагностика базы 1С: что говорят симптомы

Первое, что нужно сделать, — понять, повреждены ли данные на самом деле. Часто «больная база» на деле страдает от испорченного кэша клиента, зависшего сеанса или нехватки места на диске.

Соберите факты до любых действий:

• 🖥️ Где ошибка — у одного пользователя или у всех. Если у одного, почти наверняка виноват локальный кэш или профиль.
• 📄 Точный текст сообщения — скопируйте его целиком, включая строку после «по причине:».
• 🕒 Когда началось — после обновления конфигурации, отключения света, переноса базы на другой диск.
• 📂 Тип базы — файловая (каталог с 1Cv8.1CD) или клиент-серверная (на сервере 1С и СУБД).
• 💾 Свободное место — на диске с базой, на диске с временными файлами и на сервере СУБД.

Таблица «симптом → вероятная причина»

Сначала исключите кэш

Если ошибка у одного пользователя, очистите кэш, прежде чем трогать базу. Самый быстрый способ — добавить параметр /ClearCache в строку запуска или в поле «Дополнительные параметры запуска» в настройках базы в окне выбора информационных баз.

Радикальный вариант — закрыть все окна 1С на этом компьютере и удалить папки с именами-идентификаторами (вида GUID) внутри:

%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8

Файлы ibases.v8i и папки, которые не похожи на GUID, не трогайте: в первом хранится список баз пользователя.

Подготовка к лечению: копия и монопольный режим

Любое исправление начинается с резервной копии. Тестирование в режиме исправления удаляет или очищает «битые» объекты, и откатить это без копии невозможно.

Что подготовить:

1. Предупредите пользователей и назначьте окно, когда в базе никто не работает . Для тестирования и исправления нужен монопольный доступ, то есть все сеансы должны быть завершены.
2. Для файловой базы скопируйте весь каталог с файлом 1Cv8.1CD в другое место. Если база открывается — дополнительно сделайте выгрузку: в Конфигураторе Администрирование → Выгрузить информационную базу.
3. Для клиент-серверной базы сделайте полный бэкап средствами СУБД (в MS SQL — BACKUP DATABASE, в PostgreSQL — pg_dump).
4. Проверьте свободное место. Тестирование со сжатием и реструктуризацией временно требует места, сопоставимого с размером базы.

Для клиент-серверной базы сеансы видны и в консоли администрирования кластера: узел базы → «Сеансы». Там же можно поставить блокировку начала сеансов в свойствах информационной базы.

Встроенные утилиты для лечения базы 1С

У платформы два инструмента. Они делают разную работу и дополняют друг друга.

Утилита chdbfl.exe для файловой базы

Утилита лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.24.1548\bin\chdbfl.exe. Номер в пути — ваша версия платформы.

1. Закройте все сеансы базы.
2. Запустите chdbfl.exe от имени администратора.
3. В поле «Имя файла БД» укажите путь к 1Cv8.1CD.
4. Сначала запустите проверку без галочки «Исправлять обнаруженные ошибки» — так вы увидите масштаб повреждений.
5. Если ошибки найдены, сделайте ещё одну копию файла и запустите проверку с этой галочкой.

Утилита работает только с файлом, который никто не держит открытым. Если она сообщает, что файл занят, проверьте, не висит ли процесс 1cv8.exe в диспетчере задач, в том числе у других пользователей терминального сервера.

Тестирование и исправление в Конфигураторе

Путь: Конфигуратор → Администрирование → Тестирование и исправление…. В окне отмечаются проверки и выбирается режим.

Ниже выбирается режим: «Тестирование» (только отчёт) или «Тестирование и исправление». Для второго режима важны две настройки.

При наличии ссылок на несуществующие объекты:

• 🟢 «Создавать объекты» — программа создаст пустые объекты-заглушки, ссылки останутся. Самый безопасный вариант: потом заглушки видно и их можно разобрать вручную.
• 🟠 «Очищать ссылки» — реквизиты станут пустыми. Документы потеряют контрагента, номенклатуру или счёт.
• ⚪ «Не изменять» — только запись в отчёт.

При частичной потере данных объектов: «Создавать объекты» или «Удалять объекты». Удаление необратимо.

Пакетный запуск по расписанию или для большой базы

На больших базах удобно запускать тестирование без интерфейса — из командной строки или bat-файла с выводом в журнал:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -ReIndex -LogAndRefsIntegrity -RecalcTotals -IBCompression -BadRefCreate -BadDataCreate /Out"D:\Logs\check.txt"

Для клиент-серверной базы вместо /F"путь" укажите /S"сервер\имя_базы". Ключ -TestOnly включает режим только проверки, без исправлений: с него и стоит начинать.

Журнал регистрации и блокировки: найти виновника

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

Где открыть:

• в пользовательском режиме типовых конфигураций — Администрирование → Обслуживание → Журнал регистрации;
• в Конфигураторе — Администрирование → Журнал регистрации.

Что смотреть:

1. Установите отбор по уровню «Ошибка» и по периоду, когда начались проблемы.
2. Найдите повторяющиеся события: один и тот же документ, одна и та же регламентная задача, одна обработка.
3. Откройте событие и посмотрите поле «Данные» — там ссылка на проблемный объект.

Ошибки блокировок

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

Что делать:

• в клиент-серверной базе откройте в консоли кластера узел базы → «Блокировки» и посмотрите, какой сеанс держит блокировку;
• проверьте, нет ли параллельно тяжёлой операции: закрытия месяца, групповой перепроводки, обмена с другой базой;
• перенесите тяжёлые операции на нерабочее время и разнесите их по времени.

Если блокировки возникают в файловой базе при 10–15 одновременных пользователях, это предел файлового варианта, а не болезнь. Лечится переводом на клиент-серверный вариант.

Восстановление базы 1С после сбоев оборудования и СУБД

Отключение питания, сбой диска или переполнение тома — главные причины физического повреждения. Здесь важен порядок: сначала спасаем носитель, потом файл, потом данные 1С.

Файловая база после сбоя диска или питания

1. Не запускайте 1С повторно, пока не проверили диск. Каждое открытие повреждённой базы может дописать мусор.
2. Скопируйте 1Cv8.1CD на заведомо исправный диск и работайте только с копией.
3. Проверьте исходный диск: chkdsk D: /f (буква — ваша), посмотрите SMART-показатели.
4. Прогоните chdbfl.exe на копии, затем тестирование и исправление в Конфигураторе.
5. Если база открылась — сделайте выгрузку .dt и загрузите её в новую пустую базу. Это пересоздаёт файл с нуля и убирает остаточные повреждения.

Клиент-серверная база на MS SQL

Сначала проверьте базу средствами СУБД:

DBCC CHECKDB ('Buh') WITH NO_INFOMSGS;

Если CHECKDB нашёл ошибки, лучший путь — восстановление из последнего полного бэкапа плюс журналов транзакций (при полной модели восстановления). Режим REPAIR_ALLOW_DATA_LOSS удаляет повреждённые страницы вместе с данными: применяйте его только к копии и только когда бэкапа нет.

После восстановления на уровне СУБД запустите тестирование средствами 1С, хотя бы реиндексацию и проверку ссылочной целостности.

PostgreSQL

Для PostgreSQL первым делом смотрят журнал сервера СУБД на ошибки чтения страниц. Восстановление — из pg_dump или физической копии. Регулярное обслуживание — VACUUM ANALYZE и при необходимости REINDEX в нерабочее время.

Сеансовые данные сервера 1С

Если ошибка возникает у всех пользователей клиент-серверной базы после аварийной перезагрузки сервера, а СУБД чистая, виноваты бывают временные файлы кластера в каталоге srvinfo\reg_1541. Чистка этих файлов выполняется только при остановленной службе «Агент сервера 1С:Предприятия».

Профилактика: обслуживание базы 1С по графику

Базу, за которой ухаживают, лечить приходится редко. Минимальный регламент для небольшой организации:

Что ещё снижает риск:

• 🔌 ИБП на сервере и на компьютере с файловой базой. Отключение питания во время записи — классический путь к Файл базы данных поврежден.
• 🌐 Не держать файловую базу на сетевом диске через Wi-Fi. Обрыв связи в момент записи повреждает файл.
• 🧹 Чистить журнал регистрации. Многолетний журнал замедляет работу; его можно сократить в Конфигураторе, предварительно сохранив старые записи в файл.
• 📈 Следить за итогами. В типовых конфигурациях есть обработка управления итогами и агрегатами в разделе Администрирование → Обслуживание: там задаётся период рассчитанных итогов, и отчёты по прошлым периодам работают быстрее.
• 🔄 Обновлять платформу и конфигурацию с копией перед каждым обновлением. Сбой в середине обновления — частая причина нарушения структуры конфигурации.

Когда лечение базы 1С лучше доверить специалисту

Самостоятельное лечение оправдано, пока у вас есть свежая копия и ошибка укладывается в типовые сценарии выше. Специалист нужен, если:

• ❌ chdbfl.exe завершается с ошибкой или после исправления база всё равно не открывается;
• ❌ резервной копии нет, а тестирование предлагает удалить сотни объектов;
• ❌ DBCC CHECKDB находит ошибки, а бэкапа с чистой базой нет;
• ❌ повреждена конфигурация с большими доработками, и поставщика .cf нет;
• ❌ диск физически неисправен, а данные на нём единственные.

В таких случаях каждое неудачное действие уменьшает шанс спасти данные. Специалисты по восстановлению работают с посекционным разбором файла 1Cv8.1CD, извлекают таблицы из повреждённых страниц и собирают из них новую базу. Например, известная сообществу утилита Tool_1CD позволяет читать таблицы файла без запуска платформы. Применять её к единственному экземпляру базы нельзя — только к копии.

Перед обращением подготовьте: копию повреждённой базы, точный текст ошибок, версию платформы и конфигурации, отчёт тестирования, если его удалось получить. Это сэкономит время на диагностику и деньги.

Частые вопросы о лечении базы