Диагностика информационной базы 1С: от тестирования до автоматического контроля

Проверить базу 1С на ошибки можно штатно: Конфигуратор → Администрирование → Тестирование и исправление информационной базы. Режим «Только тестирование» ничего не меняет, он показывает проблемы. Для серверной базы добавьте проверку на уровне СУБД, для любой — разбор журнала регистрации и проверку конфигурации.

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

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

Что сделать до начала диагностики

Диагностика с исправлением меняет данные. Поэтому подготовка — не формальность.

Сделайте по порядку:

1. Попросите всех выйти из базы. Для тестирования нужен монопольный доступ.
2. Сохраните копию. Файловую базу копируйте целиком: каталог с файлом 1Cv8.1CD. Серверную выгружайте средствами СУБД или через Администрирование → Выгрузить информационную базу в Конфигураторе.
3. Проверьте свободное место. Тестирование со сжатием и пересозданием таблиц требует места под временные данные — ориентировочно в размер базы плюс запас.
4. Определите тип базы. От него зависит набор инструментов.

💡 Если база большая и тестирование займёт часы, сначала проверьте на копии, развёрнутой отдельно. Заодно узнаете, сколько времени нужно будет окну обслуживания.

Встроенное тестирование и исправление: настройки по шагам

Это основной инструмент платформы. Работает и в файловом, и в серверном варианте.

Как запустить

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

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

Какие проверки включать

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

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

Что делать с найденными ошибками

Для ссылочной целостности платформа предлагает варианты обработки:

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

Анализ журнала регистрации и технологического журнала

Тестирование показывает состояние данных. Журналы объясняют, что к нему привело.

Журнал регистрации

Он есть в Конфигураторе: Администрирование → Журнал регистрации. В пользовательском режиме он находится в разделе администрирования программы.

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

1. Поставьте отбор по уровню «Ошибка» и по дате, когда начались сбои.
2. Обратите внимание на события «Ошибка проведения» и «Ошибка записи». Рядом указан пользователь и объект, это быстро сужает круг.
3. Ищите серию однотипных ошибок за одну минуту. Это признак блокировки или обрыва соединения.
4. Сравните время первой ошибки с событиями вокруг: обновление, завершение сеанса администратором, перезапуск сервера.

Пример. В базе 12 пользователей. С 14:05 у бухгалтеров вылетает проведение реализаций. В журнале в 14:04 событие «Завершение работы сервера», в 14:05 первая ошибка записи. Значит, искать надо не в данных, а в перезапуске, который оборвал транзакции.

Технологический журнал

Он ведётся на сервере и настраивается файлом logcfg.xml в каталоге conf платформы. Подходит, когда ошибка плавающая и в журнале регистрации ничего нет: долгие блокировки, падения рабочих процессов, исключения платформы.

Правила работы:

• 📌 Включайте журнал на короткое время и с узким отбором по событиям. Полный журнал быстро занимает диски.
• 📌 Храните его на отдельном диске, не на том, где лежит база.
• 📌 Задайте срок хранения, чтобы каталог не рос бесконечно.
• 📌 После диагностики верните настройки.

Подробные события и их свойства смотрите в справке платформы: набор тегов в logcfg.xml меняется от версии к версии.

Проверка целостности на уровне СУБД и файла базы

Платформа тестирует то, что видит через свои механизмы. Повреждение страниц данных на диске она может не заметить или заметит слишком поздно.

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

Для файловой базы есть утилита chdbfl.exe. Она лежит в каталоге bin установленной платформы.

1. Закройте все сеансы и сделайте копию файла 1Cv8.1CD.
2. Запустите chdbfl.exe.
3. Укажите путь к файлу базы.
4. Отметьте исправление ошибок только после копии.
5. Запустите проверку.

Утилита ищет нарушения на уровне физической структуры файла. Если после неё платформа по-прежнему не открывает базу, дальше нужно разворачивать из копии.

MS SQL Server

Проверка выполняется командой:

DBCC CHECKDB (N'ИмяБазы') WITH NO_INFOMSGS;

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

PostgreSQL

Простой способ проверить, что данные читаются, — снять дамп. Ошибка чтения повреждённой страницы покажет себя именно во время дампа:

pg_dump -U postgres -Fc ИмяБазы > check.dump

Если дамп завершился без ошибок, чтение таблиц проходит. Для углублённой проверки индексов есть расширение amcheck, но оно требует отдельной установки и знаний администратора СУБД.

Диагностика конфигурации и результатов обновлений

Ошибка не всегда в данных. Иногда сломана конфигурация: после неудачного обновления, правок разработчика, конфликта расширений.

Проверка конфигурации

В Конфигураторе откройте Конфигурация → Проверка конфигурации. Включите проверки, которые нужны: синтаксис модулей, обращения к несуществующим объектам, логическую целостность.

Что даёт этот режим:

• находит ошибки в модулях и формах, которые не проявляются до запуска конкретной функции;
• показывает ссылки на удалённые реквизиты;
• помогает проверить базу после слияния конфигураций.

На типовой конфигурации без доработок замечаний быть не должно. На доработанной — оцените каждое: часть может быть известной и неопасной.

Если проблемы начались после обновления

1. Откройте Конфигурация → Поддержка → Настройка поддержки и проверьте, что снято с поддержки: правки в снятых объектах не обновились.
2. Просмотрите расширения. Отключите их по очереди и найдите виновника.
3. Убедитесь, что обработчики обновления выполнились. Откройте журнал регистрации и найдите события обновления.
4. Проверьте, что версия платформы подходит под конфигурацию. Требование указано в описании релиза.

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

Когда выгрузка в файл полезнее тестирования

Выгрузка Администрирование → Выгрузить информационную базу в файл .dt читает все данные. Если выгрузка падает на конкретной таблице, у вас есть точный указатель на проблемное место. Загрузка этого файла в новую пустую базу заодно пересоздаёт все таблицы и индексы с нуля, это радикальный способ вылечить структуру.

Автоматизация контроля и профилактика

Разовая проверка решает текущую проблему. Чтобы не ловить следующую, настройте регулярный контроль.

Проверка из командной строки

Конфигуратор можно запускать без интерфейса. Базовый вид:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Админ" /P "пароль" /IBCheckAndRepair -TestOnly /Out "D:\Logs\check.log"

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

Расписание

• 🕒 Планировщик заданий Windows или cron на Linux запускает проверку по ночам.
• 🕒 Перед проверкой скрипт делает копию базы .
• 🕒 После проверки скрипт ищет в логе слова об ошибках и отправляет уведомление администратору.
• 🕒 Для серверных баз ставьте в расписание DBCC CHECKDB отдельно от платформы.

Что включить в регламент

Что влияет на целостность в повседневной работе

• ИБП на сервере и рабочих местах с файловой базой. Аварийное отключение — главная причина повреждений.
• Файловая база на сетевом диске по слабой сети. Обрыв во время записи ломает файл. Для многих пользователей лучше клиент-серверный вариант.
• Антивирус, проверяющий каталог базы на лету, добавьте каталог в исключения.
• Не копируйте файл базы, пока в ней работают.

Когда базу проверять не нужно, а когда нельзя откладывать

Не каждый сбой — повод запускать исправление. Лишний прогон с изменением данных только добавляет риска.

Проверка не нужна, если:

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

Откладывать нельзя, если:

1. База не открывается и в сообщении фигурируют слова о повреждении или об ошибке чтения.
2. Итоги в отчётах расходятся с документами, а пересчёт не помогает.
3. Закрытие месяца падает на одном и том же документе.
4. Есть сообщения о ссылках на несуществующие объекты.

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

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