База 1С выдаёт ошибки структуры и не открывается: что делать

Базу 1С не «чинят» поверх рабочей копии. Сначала копируют файл 1Cv8.1CD (или делают бэкап SQL-базы), и только потом запускают любое исправление. Нарушение целостности системы 1С 8.3 чаще всего означает повреждение самой информационной базы, а не платформы: сбилась структура таблиц, порвался индекс, потерялась запись.

Типичные тексты, с которых всё начинается: Ошибка в структуре файла базы данных, Обнаружены ошибки в структуре таблиц, Нарушена целостность базы данных, Файл базы данных повреждён. Лечат это по нарастающей: сначала встроенное тестирование, потом chdbfl.exe для файловой базы, для клиент-серверной — средства СУБД.

Что сломалось и какая у вас база

Первое, что нужно знать, — тип базы. От него зависит весь маршрут.

• 📁 Файловая. Каталог с файлом 1Cv8.1CD. Открывается без сервера 1С, путь виден в списке баз.
• 🖥️ Клиент-серверная. В списке баз указано имя сервера и имя базы, данные лежат в PostgreSQL или MS SQL Server.

Откройте окно запуска 1С, выделите базу и нажмите «Изменить»: в первой строке будет либо «На данном компьютере или на компьютере в локальной сети» (файловая), либо «На сервере 1С:Предприятия» (клиент-серверная).

Затем определите, насколько всё плохо:

Тестирование и исправление средствами платформы

Это самый безопасный способ, с него и начинайте. Он встроен в Конфигуратор и работает как для файловых, так и для клиент-серверных баз.

Подготовка

1. Все пользователи должны выйти из базы. Проверьте в консоли администрирования или в Администрирование → Активные пользователи (если база ещё открывается).
2. Сделайте копию: для файловой базы — скопируйте каталог целиком, для серверной — бэкап средствами СУБД.
3. Запустите «1С:Предприятие» в режиме Конфигуратор и откройте нужную базу.

Запуск

1. В меню Конфигуратора выберите Администрирование → Тестирование и исправление.
2. Включите нужные проверки:
   • логическую целостность информационной базы;
   • ссылочную целостность;
   • реструктуризацию таблиц информационной базы;
   • пересчёт итогов;
   • сжатие таблиц информационной базы.
3. В блоке «Режим» выберите «Тестирование и исправление». Если хотите сначала только посмотреть масштаб бед, поставьте «Только тестирование».
4. Нажмите «Выполнить».

Для базы потребуется монопольный доступ: платформа сама предложит его, если в базе остался чей-то сеанс. Закройте сеансы и повторите.

Как читать результат

Окно с сообщениями покажет, что найдено и что исправлено. Нормальный исход: «Тестирование завершено» без ошибок или с перечнем исправленного.

Ссылочная целостность — отдельная история. Платформа может обнаружить «битые» ссылки на несуществующие объекты. Для них доступны два варианта: создавать объекты или очищать ссылки. Очистка безопаснее для учёта, но потеряет связь в документе; создание сохраняет ссылку, но в справочнике появится пустой элемент.

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

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

chdbfl.exe лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exe (вместо xx.xxxx подставьте свой номер релиза). Она работает с файлом 1Cv8.1CD напрямую, без запуска платформы, поэтому помогает, когда Конфигуратор уже не может открыть базу .

Утилита предназначена только для файловых баз. Для серверных она не подходит.

Порядок работы

1. Закройте все программы и сеансы, которые держат файл базы. Проверьте, нет ли процессов 1cv8.exe, 1cv8c.exe в диспетчере задач.
2. Сделайте копию 1Cv8.1CD. Это не формальность: chdbfl переписывает файл на месте.
3. Запустите chdbfl.exe от имени администратора.
4. В поле «Имя файла» укажите путь к 1Cv8.1CD.
5. Поставьте флажок «Исправлять обнаруженные ошибки». Без него утилита только проверит файл.
6. Нажмите «Выполнить» и дождитесь конца. На большой базе (десятки гигабайт) это может занять от получаса до нескольких часов.

После исправления

Утилита чинит низкоуровневую структуру файла, но не гарантирует, что данные в таблицах логически согласованы. Поэтому следом:

1. Откройте базу в Конфигураторе и повторите Администрирование → Тестирование и исправление.
2. Запустите базу в обычном режиме и проверьте последние документы: даты, суммы, проведённость.
3. Выгрузите базу в .dt (Администрирование → Выгрузить информационную базу) и загрузите в чистую новую базу. Это сбрасывает остатки мусорных структур.

Когда и этого мало

Бывает, что chdbfl отработал, а база всё равно не открывается или тестирование снова находит ошибки. Тогда идут по запасному маршруту:

1. Берут последний исправный бэкап и разворачивают его в отдельный каталог.
2. Сравнивают, за какой период в повреждённой базе есть данные, которых нет в бэкапе.
3. Если разрыв небольшой, документы за этот период вводят заново. Если большой, пробуют выгрузить из повреждённой базы нужные журналы документов в табличный вид и загрузить обработкой или перенести вручную.
4. Не подключайте повреждённую базу обратно в рабочий контур, пока не прошла проверка на копии: пользователи продолжат вводить данные в испорченную структуру, и потери вырастут.

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

Клиент-серверная база: проверка на уровне СУБД

Здесь chdbfl не поможет: данных в файле 1CD нет. База хранится в PostgreSQL или MS SQL Server, и сначала проверяют именно СУБД.

⚠️ Перед любой проверкой, которая требует остановить кластер или перезапустить службу, предупредите пользователей: сеансы оборвутся. Выбирайте нерабочее время.

Порядок действий

1. Сделайте полный бэкап базы средствами СУБД и проверьте, что файл бэкапа читается.
2. Запустите тестирование и исправление из Конфигуратора (раздел выше). Для серверной базы он штатно работает с монопольным доступом.
3. Если Конфигуратор не помог или не открывает базу, проверьте саму СУБД.

MS SQL Server. Выполните DBCC CHECKDB по нужной базе. Команда проверяет физическую и логическую целостность и показывает найденные проблемы. Параметры исправления, которые удаляют данные, применяйте только на копии и только если нет свежего бэкапа: они могут стереть записи.

PostgreSQL. Проверьте журнал сервера на ошибки чтения страниц. Для индексов помогает REINDEX по повреждённой таблице или всей базе. Для освобождения места и обновления статистики используется VACUUM (с ANALYZE). Если есть признаки повреждения самих данных, надёжнее восстановиться из свежего бэкапа.

4. Если СУБД чиста, а платформа всё равно видит ошибки, выгрузите базу в .dt и загрузите в новую пустую базу на том же сервере. Старую оставьте до окончательной проверки.

Чего не делать: не удаляйте базу и кластер «чтобы пересоздать», пока не убедились, что бэкап читается и восстанавливается.

Аппаратные причины: откуда берётся порча

Если ошибка вернулась через неделю после лечения, дело не в базе. Искать нужно причину.

• 🔌 Отключение питания. Файловая база не любит жёсткого выключения: запись обрывается на середине. Помогает ИБП на компьютере, где лежит база, или на сервере.
• 💽 Диск. Битые сектора, износ SSD. Проверьте SMART диска, а на сервере — состояние массива RAID.
• 🌐 Сеть. Файловая база по сетевой папке или через Wi-Fi — частый источник порчи. При обрыве соединения запись не доходит до конца.
• 🛡️ Антивирус. Сканирует 1Cv8.1CD во время записи или блокирует файл. Добавьте каталог базы в исключения.
• 👥 Много пользователей в файловой базе. Когда работает больше 10–15 человек, риск сбоя резко растёт. Это повод перенести базу на сервер.
• 🧠 Оперативная память. Редкий случай: сбойный модуль даёт случайные ошибки в разных местах. Проверьте память утилитой тестирования ОЗУ.
• 🗂️ Копирование на лету. Копировать файл, пока в нём работают, нельзя. Такая «копия» заведомо битая.

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

Резервное копирование: что и как делать

Бэкап — единственное, что реально защищает от потери данных. Никакая утилита не вернёт то, что физически стёрто.

Какой бэкап нужен

Практические правила

1. Делайте копию ежедневно, а перед обновлением конфигурации, перед сворачиванием периода и перед «Удалением помеченных объектов» — отдельно.
2. Храните копии не на том же диске, где лежит база. Минимум — второй физический диск; лучше сетевое хранилище или облако.
3. Держите несколько поколений: 7 ежедневных, 4 еженедельных, 3 ежемесячных. Повреждение часто замечают не сразу, и вчерашняя копия уже может быть битой.
4. Раз в квартал проверяйте восстановление: разверните копию в тестовую базу и откройте.
5. Выгрузка .dt из повреждённой базы может пройти, но принести порчу с собой. Поэтому после загрузки в новую базу всё равно прогоните тестирование.

Частые вопросы