Сколько ждать, пока Конфигуратор проверит и починит информационную базу
Содержание
Тестирование и исправление файловой базы 1С размером 1–3 ГБ на SSD обычно занимает от 10 до 40 минут при всех включённых галочках. База на 10–20 ГБ проверяется ориентировочно 1–4 часа, а серверная на 50–100 ГБ и больше — от нескольких часов до суток. Самые долгие этапы — пересчёт итогов и проверка ссылочной целостности, самые быстрые — реиндексация и сжатие на небольшой базе.
Точное время заранее не скажет никто: оно зависит от объёма таблиц, диска, числа регистров и выбранного режима. Зато его можно прикинуть заранее по прошлой проверке или по пробному запуску на копии — и сократить в разы, если не включать лишние этапы.
От чего зависит время тестирования базы 1С
Размер файла 1Cv8.1CD или базы на СУБД — главный, но не единственный фактор. Две базы по 5 ГБ могут проверяться 30 минут и 3 часа.
Что сильнее всего влияет на длительность:
- 💾 Тип диска. На HDD проверка идёт в 3–5 раз дольше, чем на SSD: платформа постоянно читает и пишет страницы таблиц вразброс. Сетевой диск — ещё медленнее, и к тому же опасен (об этом ниже).
- 📦 Объём данных, а не только размер файла. Внутри может быть 2 ГБ документов и 6 ГБ присоединённых файлов, хранящихся в базе. Файлы проверяются быстро, а таблицы регистров — долго.
- 📊 Число записей в регистрах. Пересчёт итогов проходит по всем движениям регистров накопления и бухгалтерии. Десять лет учёта без свёртки — это десятки миллионов строк.
- ⚙️ Выбранные операции. Реиндексация плюс сжатие — одно время. Всё сразу с пересчётом итогов и реструктуризацией — совсем другое.
- 🔧 Режим «Только тестирование» или «Тестирование и исправление». При исправлении платформа ещё и записывает изменения, а при «Создавать объекты» плодит новые элементы-заглушки.
- 🧠 Оперативная память и процессор. Для файловой базы работает один процесс Конфигуратора, поэтому важнее частота ядра и свободная память, чем число ядер.
- 🛡️ Антивирус. Проверка «на лету» каждой операции записи в
1Cv8.1CDспособна удвоить время. - 🗄️ Вариант работы. В клиент-серверной базе часть операций выполняет СУБД, и время зависит ещё от её настроек и нагрузки на сервер.
Если базу уже проверяли раньше, засеките время прошлой проверки. Это лучший прогноз: база растёт плавно, и следующая проверка займёт примерно столько же плюс процент прироста объёма.
Из каких этапов состоит тестирование и исправление
Запускается процедура в Конфигураторе: Администрирование → Тестирование и исправление. Для запуска нужен монопольный доступ — все пользователи должны выйти из базы, фоновые задания остановлены.
В окне шесть флажков. Каждый — отдельный этап со своей ценой по времени.
| Этап | Что делает | Доля времени |
|---|---|---|
| Реиндексация таблиц информационной базы | Перестраивает индексы всех таблиц | Небольшая, растёт с объёмом |
| Проверка логической целостности | Проверяет внутреннюю структуру записей | Средняя |
| Проверка ссылочной целостности | Ищет ссылки на несуществующие объекты | Большая |
| Пересчёт итогов | Заново считает итоги регистров по движениям | Самая большая на «длинных» базах |
| Сжатие таблиц информационной базы | Убирает пустое место из таблиц | Небольшая |
| Реструктуризация таблиц информационной базы | Пересоздаёт таблицы целиком | Большая, нужна редко |
Флажок проверки ссылочной целостности ставится только вместе с логической. Это логично: сначала платформа убеждается, что записи читаются, и только потом ищет «битые» ссылки.
Ниже выбирают режим:
- Только тестирование — платформа находит ошибки и пишет их в окно сообщений, ничего не меняя. Подходит для разведки.
- Тестирование и исправление — найденное сразу исправляется по выбранным правилам.
Для исправления задают два правила. При ссылках на несуществующие объекты: создавать объекты, очищать ссылки или не изменять. При частичной потере данных объектов: создавать объекты, удалять объекты или не изменять.
Вариант «Удалять объекты» стирает повреждённые документы и элементы без возможности вернуть их из самой базы. Выбирайте его, только если есть свежая резервная копия и вы понимаете, что именно будет удалено. Безопаснее «Создавать объекты»: платформа добавит элементы-заглушки, которые потом можно найти и разобрать.
Перед запуском в режиме исправления сделайте копию: выгрузку Администрирование → Выгрузить информационную базу в файл .dt или копию каталога файловой базы при закрытой программе.
Почему одна конфигурация проверяется дольше другой
Сложность конфигурации влияет на время не меньше, чем гигабайты. Платформа проходит по каждой таблице метаданных, а таблиц у типовых решений очень разное количество.
- 🟢 Небольшие конфигурации вроде «Бухгалтерии предприятия» с одной-двумя организациями — несколько тысяч таблиц, и большая часть из них почти пустая. Проверка идёт быстро.
- 🟡 ЗУП и УТ — больше регистров с периодическими записями. Пересчёт итогов заметно длиннее.
- 🔴 ERP и КА — тысячи регистров, сотни видов документов, длинная история. На таких базах тестирование легко растягивается на ночь даже при умеренном размере.
Что ещё замедляет проверку в любой конфигурации:
- 📈 Регистры без свёртки. Остатки за 8–10 лет хранятся в виде полного набора движений, и итоги считаются по каждой строке.
- 📅 Период рассчитанных итогов. Если итоги рассчитаны до далёкой будущей даты, при пересчёте платформе приходится строить больше записей.
- 🧩 Доработки и расширения. Свои регистры и реквизиты добавляют таблицы и индексы — каждая новая таблица проверяется так же, как типовая.
- 🗃️ Хранение файлов в базе. Вложения и сканы раздувают таблицы присоединённых файлов: они быстро читаются, но долго сжимаются и реиндексируются.
Ориентиры по времени для баз разного объёма
Цифры ниже — ориентировочные, для полного набора флажков в режиме «Тестирование и исправление». Получены на типовом железе: современный процессор, 8–16 ГБ памяти, SSD. На HDD умножайте примерно на 3–5.
| Размер базы | Вариант | Только реиндексация и сжатие | Полная проверка |
|---|---|---|---|
| до 1 ГБ | файловая | 2–5 мин | 5–20 мин |
| 1–4 ГБ | файловая | 5–15 мин | 20–60 мин |
| 5–10 ГБ | файловая | 15–40 мин | 1–3 ч |
| 10–30 ГБ | файловая | 40 мин – 1,5 ч | 3–8 ч |
| 30–100 ГБ | клиент-серверная | средствами СУБД | 4–12 ч |
| свыше 100 ГБ | клиент-серверная | средствами СУБД | от 12 ч до нескольких суток |
Как прикинуть время для своей базы на практике:
- Сделайте копию базы и разверните её на соседнем компьютере или в отдельном каталоге.
- Запустите на копии только реиндексацию и засеките время.
- Полная проверка обычно идёт в 4–10 раз дольше реиндексации. Чем больше движений в регистрах, тем ближе к верхней границе.
Файловые базы больше 10–15 ГБ — сигнал задуматься о переходе на клиент-серверный вариант. Дело не только в проверке: при таком объёме растёт и риск повреждения самого файла 1Cv8.1CD.
Когда Конфигуратор «висит» и окно не отвечает, это ещё не значит, что процесс завис. Откройте Диспетчер задач: если процесс 1cv8.exe нагружает процессор или диск, работа идёт. Ждите.
Как ускорить тестирование и исправление
Сократить время можно в разы, если не гонять все этапы подряд без причины и подготовить окружение.
Запускайте только нужные этапы
Для профилактики раз в месяц–квартал достаточно реиндексации и сжатия. Полную проверку с пересчётом итогов оставьте на случай, когда есть конкретная проблема: ошибки при проведении, неверные остатки, сообщения о повреждении.
Реструктуризацию включайте только по совету поддержки или при ошибках структуры таблиц. В обычной профилактике она не нужна, а времени съедает много.
Перенесите файловую базу на быстрый локальный диск
Скопируйте каталог базы при закрытой программе на локальный SSD, проверьте там, верните обратно. Копирование 10 ГБ занимает минуты, а проверка на SSD вместо сетевой папки экономит часы.
Ограничьте время и продолжайте частями
В окне тестирования платформы 8.3 есть настройки, которые позволяют прервать проверку по истечении заданного времени и в следующий раз продолжить с места остановки. Это выручает, когда окно для обслуживания — одна ночь, а база проверяется дольше.
Запуск по расписанию из командной строки
Проверку можно запустить без участия человека — например, ночью через планировщик Windows. Пакетный запуск Конфигуратора с параметром /IBCheckAndRepair:
"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /IBCheckAndRepair -ReIndex -IBCompression -LogIntegrity -RecalcTotals -BadRefCreate -BadDataCreate /Out "D:\Logs\tii.log" /DisableStartupDialogs
Номер версии в пути замените на установленный у вас. Ключ -TestOnly включает режим «только тестирование», ключи -BadRefClear и -BadDataDelete — более жёсткие правила исправления. Результат проверки окажется в файле из параметра /Out. Пароль в bat-файле храните только на защищённом сервере.
Для клиент-серверной базы используйте средства СУБД
Индексы и статистику в MS SQL Server и PostgreSQL дешевле обслуживать регламентными заданиями самой СУБД: перестроение индексов, обновление статистики, очистка процедурного кэша. Такое обслуживание идёт быстрее и не требует монопольного доступа к базе.
Тестирование и исправление в Конфигураторе на сервере оставьте для логических ошибок, которые СУБД не видит: битые ссылки, рассогласованные итоги.
Пересчёт итогов без Конфигуратора
Если проблема только в остатках, полную проверку можно не запускать. В пользовательском режиме откройте Все функции → Стандартные → Управление итогами и пересчитайте итоги нужных регистров. Пункт «Все функции» включается в настройках главного меню.
Утилита chdbfl.exe для файловой базы
В каталоге bin платформы лежит chdbfl.exe — утилита проверки физической целостности файла 1Cv8.1CD. Она работает быстрее Конфигуратора и помогает, когда база не открывается совсем. Запускайте её при закрытой базе и на копии; флажок исправления ставьте, только убедившись, что копия сохранена.
| Способ | Когда применять | Риски |
|---|---|---|
| Реиндексация + сжатие в Конфигураторе | Плановая профилактика | Минимальные |
| Полная проверка с исправлением | Ошибки проведения, сбойные данные | Удаление объектов при жёстких правилах |
| Управление итогами | Неверные остатки в отчётах | Почти нет, но нагружает базу |
| chdbfl.exe | Файловая база не открывается | Потеря повреждённых страниц |
| Регламент СУБД | Серверная база, индексы и статистика | Нагрузка на сервер в момент выполнения |
Чем рискуете при долгой проверке
Само тестирование безопасно, пока его не прерывают и пока есть резервная копия. Проблемы начинаются, когда ожидание затягивается и терпение заканчивается.
Основные риски:
- ❌ Принудительное закрытие Конфигуратора. Если снять процесс в середине исправления или реструктуризации, база может остаться в недособранном состоянии и перестать открываться. Восстановление — только из копии.
- 🔌 Отключение питания и спящий режим. То же, что и принудительное закрытие. Для ноутбука выключите сон, для сервера проверьте ИБП.
- 🌐 Работа с файловой базой по сети. Обрыв соединения на час-другой проверки почти гарантированно повредит файл. Поэтому базу и переносят на локальный диск.
- 💽 Нехватка места. Сжатие и реструктуризация создают временные данные. Если диск заполнится посередине, процесс аварийно завершится.
- 🗑️ Удаление объектов при исправлении. С правилом «Удалять объекты» документы с повреждёнными реквизитами исчезнут вместе с движениями. Остатки и обороты после этого изменятся.
- 🧱 Заглушки при «Создавать объекты». Вместо битых ссылок появятся элементы вида «Объект не найден (…)». Их надо найти и разобрать вручную: подставить правильные значения или пометить на удаление.
- ⏰ Простой работы. Пока идёт проверка, база недоступна. Сообщите пользователям заранее и выбирайте нерабочее время.
Если проверка идёт заметно дольше прогноза, а процесс 1cv8.exe нагружает диск, не прерывайте её. Если же нагрузка на диск и процессор ноль уже больше часа, а сообщения не появляются — выясните причину на копии, прежде чем снимать задачу в рабочей базе.
После проверки обязательно прочитайте окно сообщений. Сохраните его в файл через контекстное меню окна: этот журнал понадобится, если результат придётся разбирать с программистом или поддержкой.