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

Ошибки в базе 1С 8.3 проявляются по-разному: программа аварийно закрывается, документы не проводятся, отчёты выдают неверные цифры, а при открытии объектов появляются сообщения о нарушении целостности. Причины чаще всего одни и те же — внезапное отключение электричества, разрыв сетевого соединения при работе с файловой базой, нехватка места на диске или сбой жёсткого диска в момент записи данных.

Платформа 1С:Предприятие 8.3 включает встроенный механизм диагностики — процедуру «Тестирование и исправление информационной базы». Она проверяет физическую и логическую целостность данных, находит «битые» ссылки, повреждённые таблицы и может автоматически исправить часть проблем. Для файловых баз дополнительно доступна утилита chdbfl.exe, которая работает на более низком уровне.

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

Признаки, по которым можно понять, что база повреждена

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

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

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

Резервная копия перед любыми проверками

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

Для файловой базы достаточно скопировать файл 1Cv8.1CD в отдельную папку при закрытых сеансах всех пользователей. Для серверной базы используйте выгрузку через конфигуратор (Администрирование → Выгрузить информационную базу в файл .dt) либо штатные средства СУБД — для MS SQL, PostgreSQL это полноценный backup средствами самой СУБД.

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

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

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

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

1. 1
   Завершите работу всех пользователей и сделайте резервную копию базы
2. 2
   Откройте базу в конфигураторе под учётной записью с полными правами
3. 3
   Выберите Администрирование → Тестирование и исправление
4. 4
   Отметьте проверки: реиндексация, логическая целостность, ссылочная целостность
5. 5
   Выберите режим «Тестирование» (без исправления) для первого прогона и изучите протокол
6. 6
   Если ошибки подтвердились — повторите в режиме «Тестирование и исправление»
7. 7
   Проверьте работоспособность базы и сравните ключевые отчёты до и после

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

Как трактовать результаты проверки ссылочной целостности

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

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

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

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

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

Очистка кэша и проверка без вмешательства в данные

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

Самый надёжный способ очистить кэш — удалить базу из списка в окне запуска 1С и добавить её заново. Альтернатива — вручную удалить содержимое папок кэша в профиле пользователя (каталоги вида %APPDATA%\1C\1cv8 с вложенными папками-идентификаторами баз). Данные при этом не затрагиваются — удаляются только локальные временные файлы.

Также к безопасным методам относится пересчёт итогов в режиме Предприятия (раздел Администрирование → Обслуживание → Управление итогами в типовых конфигурациях) и проверка базы на другом компьютере — это помогает отделить проблемы данных от проблем оборудования.

Диагностика серверных баз и журнала регистрации

В клиент-серверном варианте работы физическая структура данных находится под управлением СУБД, и подход меняется. Для MS SQL запустите проверку целостности командой DBCC CHECKDB через SQL Server Management Studio — сначала в режиме только чтения, чтобы оценить масштаб. Для PostgreSQL полезны проверка логов сервера и анализ с помощью штатных утилит.

Журнал регистрации 1С помогает локализовать момент возникновения ошибки: откройте его через конфигуратор (Администрирование → Журнал регистрации) или в режиме Предприятия и отфильтруйте события с уровнем «Ошибка» за период, когда появились симптомы. По тексту ошибки и имени объекта метаданных часто можно точно определить повреждённую таблицу.

Маршрут решения

Как выбрать действие

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

Файловая база не открывается совсемСкопируйте файл и прогоните chdbfl.exe, затем тестирование в конфигураторе

База открывается, но есть битые ссылки и ошибки в отчётахТестирование и исправление с проверкой ссылочной целостности и пересчётом итогов

Серверная база, ошибки на уровне СУБДПроверка средствами СУБД (DBCC CHECKDB и аналоги), при серьёзных повреждениях — восстановление из backup

Повреждены критичные данные за большой периодСравните стоимость восстановления из архивной копии с рисками автоматического исправления

Проверка результата после исправления

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

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

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

Открытие проблемных объектов

Норма

Документы и элементы справочников открываются без ошибок

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

Ошибки сохраняются или появились новые

Итоги ключевых отчётов

Норма

Цифры совпадают с контрольными значениями до исправления

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

Итоги изменились без объяснимой причины

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

Норма

Повторный прогон показывает отсутствие ошибок

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

Ошибки обнаруживаются снова

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

Норма

Все сеансы работают стабильно

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

Аварийные завершения продолжаются

Если после исправления итоги отчётов изменились, изучите протокол: какие записи были удалены или изменены. Удалённые движения документов иногда можно восстановить перепроведением, удалённые объекты — только из резервной копии с последующим переносом данных.

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

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

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

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

Частые вопросы о тестировании 1С 8.3

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

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

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

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

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

Для файловой базы скопируйте файл 1Cv8.1CD и прогоните его через chdbfl.exe. Если и это не помогло, остаётся восстановление из резервной копии. Для серверной базы проверяйте целостность средствами СУБД и состояние службы сервера 1С.

Удалит ли тестирование и исправление мои документы?

В режиме только тестирования — нет, данные не меняются. В режиме исправления платформа может удалить записи, которые невозможно восстановить, и очистить битые ссылки. Именно поэтому перед исправлением делают копию и изучают протокол предварительной проверки.

Поможет ли тестирование при ошибке «Ошибка формата потока»?

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

Как часто нужно проверять базу в профилактических целях?

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