Тестирование и исправление базы 1С: chdbfl, ТИИ и порядок действий перед обновлением

Тестирование и исправление (ТИИ) запускают из Конфигуратора, а chdbfl нужен, когда файловая база не открывается даже в нём. В обоих случаях сначала копия базы и проверка без исправления, потом правка. Ниже: что делает каждый инструмент, какие опции включать, команды для пакетного запуска и порядок перед обновлением.

Что такое ТИИ и чем он отличается от chdbfl

Вопрос «чем проверить базу 1С, если она начала глючить» мне задают чаще, чем про любое обновление. Короткий ответ такой. ТИИ, то есть пункт «Тестирование и исправление» в Конфигураторе, проверяет и чинит информационную базу на уровне логики платформы: целостность данных, ссылки, итоги регистров, индексы. chdbfl — отдельная утилита платформы, которая проверяет физическую целостность файла базы и работает без Конфигуратора. Если у вас сопровождение баз 1С отдано подрядчику, спросите, какой из двух инструментов и в каком порядке он запускает. Хороший ответ звучит как «сначала копия, потом проверка без исправления».

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

chdbfl относится к файловому варианту. В официальной документации платформы утилита описана в приложении про вспомогательные утилиты (раздел 4.1, «Утилита тестирования»), а на сайте 1C:Enterprise Development Network её описание звучит так: автономная проверка и исправление файловой базы без запуска Конфигуратора, с режимами «только проверка» и «проверка и исправление». Там же есть главное условие: проверяемая база не должна быть открыта ни в Конфигураторе, ни в режиме 1С:Предприятие. Ошибки и итог утилита показывает в своём окне. Исполняемый файл лежит рядом с остальными исполняемыми файлами платформы. Точный путь и вид окна зависят от версии, проверьте их у себя.

Для клиент-серверной базы chdbfl бесполезен: у неё нет единого файла 1Cv8.1CD, данные лежат в СУБД. Там вместо chdbfl работают ТИИ в Конфигураторе и средства самой СУБД. О них ниже.

• ТИИ в Конфигураторе: логика данных, ссылки, итоги, индексы; и для файловых, и для клиент-серверных баз
• chdbfl: физическая целостность файла базы; только файловая база, Конфигуратор не нужен
• средства СУБД (DBCC CHECKDB для MS SQL, amcheck для PostgreSQL): целостность на уровне самой СУБД
• общее правило: проверка без исправления первой, исправление только на копии или после копии

Что сделать до запуска: копия, монопольный доступ, окно

Первое правило я повторяю каждому заказчику: исправление может изменить или удалить данные, поэтому перед любым запуском с исправлением должна лежать копия базы, из которой вы реально умеете восстановиться. Копия, которую никто не пробовал разворачивать, копией не считается. Как проверять, что бэкап восстанавливается, я разбирал отдельно в материале про то, что реально восстанавливается. Для файловой базы копия — это остановка всех сеансов и копирование каталога с файлом 1Cv8.1CD. Для клиент-серверной — штатный бэкап СУБД. Дополнительно можно выгрузить базу в файл .dt: в пакетном режиме Конфигуратора для этого есть параметр /DumpIB с именем файла. Если указываете полный путь, все каталоги пути должны существовать.

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

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

И четвёртое, о чём забывают чаще всего: тест на копии. Сначала разверните копию на отдельной машине или в отдельном каталоге и прогоните всё там. Так вы узнаете и реальное время работы, и что именно проверка собирается менять. Как делать такую копию и что в ней отключить, чтобы она не слала почту и не ходила в банк, подробно описано в статье про тестовую базу для обновлений. Здесь важно одно: ТИИ на живой базе без репетиции на копии я не запускаю.

Какие галочки ставить в ТИИ и чем они отличаются

Окно тестирования и исправления открывается из Конфигуратора через меню «Администрирование». Я привожу названия опций так, как они описаны в справке по пакетному режиму, потому что в диалоге формулировки могут слегка отличаться в разных релизах. Смысл тот же. Для проверки логической целостности есть два варианта: просто логическая целостность и логическая плюс ссылочная. Это взаимоисключающие опции: в синтаксисе пакетной команды одновременно используется только одна из двух.

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

Вот что делает каждая опция, и когда я её включаю: | Опция | Что делает по документации | Когда включаю | |---|---|---| | Логическая целостность | проверяет логическую целостность данных | почти всегда, это базовая проверка | | Логическая и ссылочная целостность | то же плюс ссылки на несуществующие объекты | после сбоев и аварийных остановок | | Пересчёт итогов | пересчитывает итоги регистров | если остатки и обороты расходятся с документами | | Реиндексация таблиц | перестраивает индексы, только файловая база | для файловой базы после сбоя или перед плановой работой | | Сжатие таблиц | сжимает таблицы, только файловая база | редко, после чистки больших объёмов данных | | Реструктуризация таблиц | реструктурирует таблицы базы | только по подтверждённой необходимости | | Только проверка | ничего не исправляет | всегда первым запуском |

Отдельно скажу про пересчёт итогов. Это не лечение «непонятного», а конкретная операция над итогами регистров. Её имеет смысл включать, когда остатки и обороты в отчётах расходятся с документами. Включать её «на всякий случай» перед каждым обновлением незачем: на большой базе это лишние часы монопольного доступа. Реиндексацию и сжатие для файловой базы я включаю осознанно, как плановую работу. В клиент-серверном варианте обслуживание индексов и статистики лежит на СУБД, и о нём я писал в материале про план обслуживания MS SQL для 1С.

ТИИ из командной строки и chdbfl: как запускать на практике

Для регламентных проверок я использую пакетный режим Конфигуратора: его можно поставить в планировщик и получить лог. Синтаксис команды проверки по справке платформы такой: /IBCheckAndRepair, а затем параметры по группам, где из каждой группы допускается только один. Сюда входят -ReIndex, -LogIntegrity или -LogAndRefsIntegrity, -RecalcTotals, -IBCompression, -Rebuild, затем -TestOnly либо пара групп -BadRefCreate, -BadRefClear, -BadRefNone и -BadDataCreate, -BadDataDelete, а также -UseStartPoint и -TimeLimit:hhh:mm. Первый запуск — всегда с -TestOnly. Пример для файловой базы на копии (путь, имя пользователя и каталог лога замените на свои, остальные ключи сверьте со справкой вашей версии платформы):

& "C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "D:\Copy\IglaMaster" /N "Администратор" /DisableStartupDialogs /IBCheckAndRepair -LogAndRefsIntegrity -TestOnly /Out "D:\Logs\tii_test.log"

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

& "C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "D:\Copy\IglaMaster" /N "Администратор" /DisableStartupDialogs /IBCheckAndRepair -ReIndex -LogIntegrity -RecalcTotals -TimeLimit:003:00 /Out "D:\Logs\tii_fix.log"

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

Теперь chdbfl. Когда он нужен? Когда файловая база не открывается даже в Конфигураторе, а ТИИ до неё просто не доходит. Закройте все сеансы, сделайте копию файла 1Cv8.1CD, запустите утилиту, выберите файл базы и сначала режим «только проверка». Если утилита сообщает об ошибках, повторяем на копии с исправлением, и только затем смотрим, открывается ли база. Следующий шаг обязателен: после chdbfl я всегда запускаю ТИИ из Конфигуратора. Утилита чинит физический уровень файла, но не гарантирует, что логика данных осталась согласованной.

Есть ещё утилита консоли администрирования 1cv8a. Её режим ib-check-and-repair (короткое имя oribcr) предназначен для быстрого исправления отдельных проблем без запуска Конфигуратора: по документации платформы 8.3.22, она проверяет и исправляет таблицы узлов планов обмена и хеш-поля таблиц базы. Ключ -r (--repair) указывает, что найденные ошибки нужно исправить. Что утилита делает без этого ключа и полный список ключей, смотрите в справке режима на вашей версии. Заменой ТИИ я эту утилиту не считаю: она решает узкие задачи.

Клиент-серверная база: что проверять в самой СУБД

Если база лежит в MS SQL Server, у вас есть второй уровень проверки — DBCC CHECKDB. Он проверяет логическую и физическую целостность объектов базы данных. Для регулярной проверки на рабочем сервере Microsoft рекомендует вариант с PHYSICAL_ONLY: он быстрее и подходит для частого запуска, а полную проверку нужно делать периодически. Запуск простой:

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

Нужна роль sysadmin или db_owner. Для частых проверок большой базы добавляют PHYSICAL_ONLY, а полную проверку оставляют на окно обслуживания.

Самое важное в документации Microsoft — отношение к исправлению. При ошибках DBCC CHECKDB рекомендуется восстановить базу из последней хорошей резервной копии, а не запускать опции REPAIR. REPAIR_ALLOW_DATA_LOSS описан как последнее средство на случай, когда восстановиться из бэкапа нельзя: он может привести к потере данных, и больше, чем при восстановлении из копии. Для него база должна быть в однопользовательском режиме, а перед запуском Microsoft советует сделать резервную копию базы. Мой вывод для 1С: если CHECKDB показал ошибки, это уже не работа ТИИ. Остановите работу, поднимите копию из бэкапа и сверьте объём потерянных операций с бухгалтерией.

Если 1С работает на PostgreSQL, штатный инструмент — модуль amcheck и его клиент pg_amcheck. Модуль проверяет логическую целостность структур таблиц и индексов. Он умеет доказать наличие повреждения, но не его отсутствие: чистый результат не даёт гарантии. Проверка B-tree индекса функцией bt_index_check берёт такую же блокировку, как обычный SELECT, поэтому подходит для рабочей базы, а bt_index_parent_check блокирует запись и на горячих репликах не работает. Клиент pg_amcheck запускает проверки по всей базе в несколько потоков. Пример на основе ключей из документации PostgreSQL (имя базы замените на своё):

pg_amcheck -d mydb -j 4 --heapallindexed --progress

Документация предупреждает, что параметры --parent-check и --rootdescend требуют сильных блокировок и блокируют изменения данных, поэтому в рабочее время их не используйте. В моей практике на PostgreSQL для 1С схема такая: pg_amcheck по расписанию, а ТИИ платформы — по поводу или перед крупным обновлением. Про настройку самой СУБД под 1С есть отдельный материал: PostgreSQL для 1С: память и автовакуум.

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

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

Почему не запускать исправление «заодно» перед обновлением? Потому что обновление и так меняет структуру данных, а исправление меняет сами данные. Совмещать два изменения в одном окне значит потерять возможность понять, что именно сломалось, если после запуска что-то пойдёт не так. Один шаг — одна контрольная точка — одна копия. Это сильно проще и надёжнее, чем кажется до первой аварии.

Что можно не делать. Не нужно запускать реиндексацию, сжатие и реструктуризацию перед каждым обновлением: это плановые операции, их место в графике обслуживания, а не в окне обновления. Не нужно гонять ТИИ после каждого мелкого сбоя клиента или обрыва связи пользователя: ошибка одного сеанса не равна повреждению базы. А вот после аварийного отключения питания файлового сервера или падения сервера СУБД проверка нужна всегда.

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

Кейс: пошивочное предприятие «Игла Мастер», 42 рабочих места

К нам обратилось пошивочное предприятие «Игла Мастер»: 42 рабочих места, из них около 15 человек работают с 1С постоянно (бухгалтерия, склад, планирование раскроя). База файловая, около 7 ГБ, на выделенном файловом сервере. Поводом стало аварийное отключение питания в серверной: после включения база открывалась, но в первый день сотрудники жаловались на странности при проведении документов; позже выяснилось, что это были последствия оборванных в момент аварии сеансов, и после перезапуска клиентских машин жалобы прекратились. Через неделю предстояло плановое обновление конфигурации, и директор спросил, можно ли обновляться «как есть».

Мы действовали по описанному порядку. В пятницу вечером, когда все вышли, остановили сеансы и скопировали каталог базы; копирование заняло 14 минут. Копию развернули на отдельной виртуальной машине. На ней запустили chdbfl в режиме «только проверка», затем ТИИ в пакетном режиме с -LogAndRefsIntegrity и -TestOnly. Проверка на копии заняла около трёх с половиной часов суммарно, оба прогона шли без участия людей, лог писался в файл. Рабочая база за это время ни разу не была открыта монопольно.

Результат проверки был спокойным: для исправления ничего не потребовалось, и мы не стали ничего «лечить на всякий случай». В воскресенье в окно с 9:00 обновили конфигурацию: от остановки сеансов до проверки основных операций бухгалтером ушло 1 час 50 минут. Сначала я хотел добавить в то же окно реиндексацию, но отказался: экономия времени важнее, а плановые работы мы перенесли на следующие выходные. Для заказчика мы оформили письменный регламент на одну страницу: что запускать после аварий питания, кто даёт команду на монопольный режим и кто принимает результат.

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