К статье
Практический материал

Администрирование · 10 мин

Как проверить базу 1С на ошибки

Как проверить базу 1С на ошибки: тестирование и исправление в конфигураторе, утилита chdbfl для файловых баз, проверка логической целостности и профилактика.

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

Главное правило перед любой проверкой — сделать резервную копию. Операции исправления изменяют данные, и при неудачном стечении обстоятельств (отключение питания, разрыв соединения с сервером) база может оказаться в худшем состоянии, чем до запуска. Копия файловой базы — это файл 1Cv8.1CD, который достаточно скопировать при закрытой программе; для клиент-серверной базы делается выгрузка в dt или бэкап средствами СУБД.

Как понять, что базу пора проверить

Тревожные признаки обычно заметны без специальной диагностики: программа аварийно закрывается при открытии определённых документов или отчётов, появляются ошибки вида «Ошибка формата потока», «Ошибка СУБД», записи в списках отображаются как «<Объект не найден>». Ещё один симптом — документ не проводится, хотя заполнен корректно, либо отчёты показывают разные итоги при одинаковых отборах.

Даже без явных сбоев файловую базу полезно проверять после внеплановых событий: отключения электричества, зависания компьютера во время работы 1С, разрыва сетевого соединения, если база лежит на сетевом диске. Именно такие ситуации чаще всего приводят к физическим повреждениям файла данных.

«Ошибка формата потока»Возможно физическое повреждение

Проверить файл базы утилитой chdbfl

«<Объект не найден>» в спискахБитые ссылки в данных

Запустить тестирование и исправление в конфигураторе

Медленная работа и большой размер файлаТаблицы содержат мусор

Выполнить реструктуризацию и сжатие

Ошибки только у одного пользователяПроблема в кэше, а не в базе

Очистить кэш метаданных на его компьютере

Резервная копия перед проверкой

Для файловой базы скопируйте файл 1Cv8.1CD из каталога базы в отдельную папку — все пользователи при этом должны выйти из программы. Универсальный способ для любого режима работы — выгрузка в файл dt через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Такой файл восстанавливается даже на другом компьютере и в другой версии платформы.

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

Проверка файловой базы утилитой chdbfl

Утилита chdbfl.exe входит в поставку платформы и лежит в каталоге bin установленной версии (например, C:\Program Files\1cv8\<версия>\bin\). Она проверяет физическую целостность файла 1Cv8.1CD: структуру таблиц, индексов и свободных страниц. Это первый инструмент при подозрении на «битый» файл.

Порядок работы: закройте все сеансы 1С с этой базой, запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, отметьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита покажет ход проверки и список найденных ошибок. Для больших баз проверка занимает заметное время — не прерывайте процесс.

Проверка через chdbfl
  1. 1
    Завершите работу всех пользователей с базой и сделайте копию файла 1Cv8.1CD
  2. 2
    Откройте chdbfl.exe из каталога bin установленной платформы
  3. 3
    Укажите путь к файлу базы и включите режим исправления ошибок
  4. 4
    Нажмите «Выполнить» и дождитесь окончания проверки
  5. 5
    Откройте базу в конфигураторе и дополнительно запустите тестирование и исправление

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

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

Откройте базу в конфигураторе в монопольном режиме и перейдите: «Администрирование» → «Тестирование и исправление». Доступны несколько проверок, которые можно комбинировать.

  • Реиндексация таблиц — перестраивает индексы, ускоряет работу и устраняет ошибки индексных страниц.
  • Проверка логической целостности — основной режим: находит битые ссылки, повреждённые записи, несоответствия в служебных таблицах.
  • Проверка ссылочной целостности — ищет ссылки на несуществующие объекты; в режиме исправления может удалять такие ссылки или создавать объекты-заглушки.
  • Пересчёт итогов — восстанавливает итоги регистров, если обороты и остатки в отчётах расходятся с документами.
  • Сжатие таблиц — физически уменьшает файл за счёт удаления пустых страниц (только файловый вариант).
  • Реструктуризация таблиц — пересоздаёт таблицы по текущей структуре метаданных; помогает при ошибках формата данных.

Внизу окна выбирается режим: «Тестирование» (только диагностика, данные не меняются) или «Тестирование и исправление» (ошибки устраняются). Разумная тактика — сначала прогнать только диагностику, посмотреть список ошибок и уже потом запускать исправление. По окончании платформа выводит протокол: сохраните его, он пригодится при повторных проблемах.

Проверка клиент-серверной базы

Если база работает на MS SQL Server, PostgreSQL или другой СУБД, утилита chdbfl неприменима — файла 1Cv8.1CD просто нет. Основной инструмент остаётся тем же: «Тестирование и исправление» в конфигураторе. Оно работает поверх СУБД и проверяет данные на уровне платформы.

Физическую целостность на уровне самой СУБД проверяют её штатными средствами: для MS SQL Server это команда DBCC CHECKDB, для PostgreSQL — проверка через pg_amcheck или анализ журналов сервера. Эти операции выполняет администратор СУБД, обычно по расписанию и вместе с перестроением индексов.

Чем проверять разные варианты базы

Файловая база

chdbfl для физической проверки файла плюс тестирование и исправление в конфигураторе. Ограничение: всё делается в монопольном режиме.

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

Тестирование и исправление в конфигураторе плюс средства СУБД (DBCC CHECKDB, pg_amcheck). chdbfl не применяется.

База в кэше/на сетевом диске

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

Если ошибки не устраняются

Когда chdbfl и тестирование с исправлением не помогают, рабочий метод — полная выгрузка и загрузка базы через dt. При загрузке таблицы пересоздаются с нуля, и многие повреждения исчезают. Если выгрузка тоже падает с ошибкой, попробуйте выгружать на другом компьютере или с другой версией платформы — иногда сбой вызван конкретным окружением.

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

Типичные ошибки
01
Запуск исправления без резервной копии — при сбое во время процедуры данные теряются безвозвратно
02
Прерывание тестирования по кнопке «отмена» или через диспетчер задач — база остаётся в промежуточном состоянии
03
Проверка файловой базы по сети, пока кто-то в ней работает, — результат недостоверен, файл можно повредить
04
Удаление «лишних» файлов из каталога базы вручную — теряются служебные данные и настройки
05
Многократный запуск chdbfl с исправлением подряд в надежде «дочистить» — если ошибки не уходят, нужна выгрузка в dt, а не повторы

Профилактика: как снизить риск повреждений

Большинство повреждений файловых баз связано с внешними факторами, а не с самой 1С. Работающие меры: источник бесперебойного питания на компьютере с базой, отказ от размещения файловой базы на сетевых дисках с нестабильным соединением, регулярные автоматические копии (хотя бы ежедневные) и периодическое тестирование без исправления — раз в месяц или после каждого сбоя питания.

Для клиент-серверных баз профилактика ложится на СУБД: регламентные бэкапы, контроль целостности, обслуживание индексов. Если файловая база выросла и с ней работает больше 5–10 пользователей, частые сбои — сигнал задуматься о переходе на клиент-серверный вариант, где механизмы защиты данных существенно надёжнее.

Контрольные точки

Как проверить результат

Открытие базы после проверки
Норма

База открывается в режиме предприятия без ошибок

Тревожный признак

Ошибка формата потока или аварийное закрытие повторяется

Протокол тестирования
Норма

Список ошибок пуст или все ошибки помечены как исправленные

Тревожный признак

Те же ошибки появляются при повторном запуске

Отчёты и итоги
Норма

Обороты и остатки сходятся с данными документов

Тревожный признак

Итоги расходятся, значит нужен пересчёт итогов

Работа пользователей
Норма

Ошибки не воспроизводятся ни у одного пользователя

Тревожный признак

Ошибка только у одного — проблема в кэше, а не в базе

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

Можно ли проверять базу, пока в ней работают пользователи?

Нет. И chdbfl, и тестирование с исправлением требуют монопольного доступа. Запуск при активных сеансах либо невозможен, либо опасен: файл может быть повреждён. Дождитесь выхода пользователей и завершите зависшие соединения.

Чем отличается chdbfl от тестирования и исправления?

chdbfl проверяет физическую структуру файла 1Cv8.1CD — страницы, индексы, служебные области. Тестирование в конфигураторе работает на уровне логики данных: ссылки, итоги, соответствие таблиц метаданным. Они дополняют друг друга, а не заменяют.

Что делать, если база вообще не открывается?

Скопируйте каталог базы целиком, затем на копии попробуйте: chdbfl с исправлением, открытие в конфигураторе, выгрузку в dt. Если ничего не помогает, восстанавливайтесь из последней резервной копии — поэтому копии должны делаться регулярно, а не перед сбоем.

Сколько времени занимает проверка?

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

Опасен ли режим «Тестирование и исправление» для данных?

Сама по себе процедура безопасна, но она изменяет данные: удаляет битые ссылки, пересчитывает итоги, пересоздаёт таблицы. При сбое посередине (питание, разрыв связи) база может остаться в повреждённом состоянии. Резервная копия перед запуском обязательна.

Нужно ли проверять базу, если ошибок нет?

Да, в профилактическом режиме без исправления — например, раз в месяц и после каждого аварийного завершения работы. Такие проверки не меняют данные и позволяют обнаружить проблему до того, как она проявится в работе пользователей.

Итог

Что важно запомнить

Файловую базу проверяют chdbfl и тестированием в конфигураторе, клиент-серверную — конфигуратором и средствами СУБД. Перед любым исправлением делайте копию, работайте только в монопольном режиме и не прерывайте процесс. Если исправление не помогает — выгрузка и загрузка через dt или восстановление из резервной копии.