CHECKDB нашёл ошибки. Что именно пропало в 1С

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

Проверка целостности базы CHECKDB нашла ошибки и выдала простыню: object id, index id, номера страниц, служебные имена таблиц и совет с минимальным уровнем исправления. Администратору этого хватает. 1С-нику по этой простыне надо решить, что пропало в базе и что поднимать из бэкапа: всю базу на вчера или несколько документов.

Ответ переводится на язык 1С двумя полями каждого сообщения: служебным именем таблицы и номером индекса. Дальше платформа сама скажет, какой это объект метаданных, а по виду таблицы уже видно, чего стоит потеря. Я испортил страницы на копии типовой УТ для Казахстана и разобрал, что стоит за каждым видом ошибки. Из четырёх испорченных страниц данные из бэкапа понадобились для двух. Битый индекс перестроился без потерь, хотя CHECKDB и для него написал минимальный уровень исправления. Движения регистра вернуло перепроведение, копия из бэкапа понадобилась только чтобы узнать, какие документы перепровести. А список конкретных документов с номерами и датами собирается штатными средствами 1С.

Стенд

Копия пустой типовой УТ для Казахстана 3.4, платформа 8.3.27. Данные синтетические: 3 000 реализаций и 1 500 приобретений товаров, у каждого документа от двух до шести строк табличной части "Товары" и движения по регистру "Товары на складах". Номера и суммы вымышленные.

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

Как читать сообщение проверки целостности

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

Сообщение 8928, уровень 16, состояние 1, строка 1
Идентификатор объекта 680389493, идентификатор индекса 1, ... (тип In-row data).
Не удалось обработать страницу (1:136102).
Сообщение 8976, уровень 16, состояние 1, строка 1
Ошибка в таблице. Идентификатор объекта 680389493, идентификатор индекса 1, ...
Страница (1:136102) не обнаружена при просмотре, хотя на нее ссылаются
родительская страница (1:137167) и предыдущая страница (1:136101).
...
CHECKDB обнаружил 0 ошибок размещения и 8 ошибок согласованности в таблице
"(имя таблицы документа)" (идентификатор объекта 680389493).

Для 1С-ника тут важны два поля, имя таблицы и номер индекса, и ещё номера соседних страниц, они пригодятся позже. Ни одно не требует лезть в SQL Server.

Служебное имя таблицы. Оно стоит в итоговой строке "в таблице ...". Это техническое имя вида "объект плюс номер", его печатает сама проверка. Если итоговые строки при копировании обрезали, имя по числовому object id назовёт администратор.

Номер индекса (index id). Единица означает основную таблицу: там лежат сами строки объекта, шапки документов, строки табличных частей, движения. Ноль означает таблицу без основного упорядочивания, в базах 1С это редкость. Всё, что больше единицы, это отдельный индекс для быстрого поиска, например по дате или номеру документа. Строк объекта в нём нет, есть только копия нескольких полей.

Номера соседних страниц. CHECKDB называет страницу до испорченной и страницу после. Это место дыры в цепочке страниц таблицы, и по нему видно, одна страница выпала или несколько разных.

Служебная таблица в объект метаданных

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

ИмяТаблицы = "имя из итоговой строки"; // например то, что проверка написала в кавычках
Для Каждого Описание Из ПолучитьСтруктуруХраненияБазыДанных(, Истина) Цикл
	Если НРег(Описание.ИмяТаблицыХранения) = НРег(ИмяТаблицы) Тогда
		Сообщить(Описание.Метаданные + " (" + Описание.Назначение + ")");
	КонецЕсли;
КонецЦикла;

На стенде это вернуло Документ.РеализацияТоваровУслуг (Основная). Функция работает в любой конфигурации, с БСП (Библиотекой стандартных подсистем) и без неё: структура хранения платформенная.

Ключевое здесь поле Назначение. Оно сразу говорит, чего стоит потеря страницы, и по нему обработка ставит вердикт.

Вердикт по виду таблицы

Одна и та же ошибка целостности значит разное в зависимости от того, что это за таблица объекта. Разбор по видам.

Основная таблица ссылочного объекта (документ, справочник, план видов характеристик, план счетов). Здесь лежат сами объекты, их шапки. Потеря страницы это потеря объектов целиком, пересчитать их не из чего. Вердикт красный: нужен бэкап. При этом строки табличных частей и движения этих же документов лежат в других таблицах и обычно целы.

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

Основная таблица регистра накопления, бухгалтерии, расчёта. Это движения документов. Движения получаются проведением, поэтому бэкап не нужен: достаточно перепровести документы-регистраторы, когда таблица снова читается. Вердикт жёлтый: восстановимо без бэкапа. Сами строки на испорченной странице прочитать уже нельзя, поэтому какие документы перепровести, говорит сверка с копией ниже: копия здесь нужна как справочник, данные из неё не переносятся. Исключение: движения, введённые руками (ручная корректировка, операции, где проводки вводят вручную). Перепроведение их не вернёт. Если в вашей конфигурации регистр так заполняют, жёлтый вердикт по нему читайте как красный.

Итоги регистра. Отдельная таблица, назначение Итоги. Итоги пересчитываются из движений штатным пересчётом (Тестирование и исправление или "Управление итогами"). Вердикт жёлтый: восстановимо без бэкапа.

Регистрация изменений для обмена. Назначение РегистрацияИзменений. Данные учёта тут не задеты вовсе, задета очередь изменений для планов обмена. Сама она не восстановится: после исправления объекты регистрируют для узла заново или делают полную синхронизацию, иначе узел недополучит изменения. Вердикт жёлтый.

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

Константа. Значение вводится вручную, пересчёта нет. Вердикт красный: посмотреть значение в копии и ввести заново.

Служебные таблицы платформы (настройки пользователей, хранилища настроек, история работы). Данные учёта не задеты. Настройки сбрасываются, пользователи настроят заново. Вердикт от жёлтого до "разобрать вручную", смотря что за таблица. Если задеты таблицы, где платформа хранит саму конфигурацию, база может не открыться вовсе, и разбор по объектам уже не поможет: это работа для администратора и бэкапа.

Обработка проходит этот разбор автоматически: по выводу проверки целостности называет объект и красит строку. Зелёный "Данные целы", жёлтый "Восстановимо без бэкапа", красный "Нужен бэкап". Сверху крупная строка итога.

Битый индекс: данные целы, хотя совет пугает

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

Лечится перестроением индекса. Тонкость в порядке: обычное перестроение читает старый индекс и падает на той же испорченной странице. Индекс сначала отключают, потом строят заново из основной таблицы. На стенде после этого проверка целостности чистая, число строк в индексе совпало с числом строк в таблице. Команды выполняет администратор, они не трогают данные.

Список документов средствами 1С

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

Список собирается сравнением с копией, целиком на языке запросов 1С. Порядок такой:

1. Последний бэкап до сбоя поднимается как отдельная информационная база, рядом с рабочей.
2. В рабочей базе (после того как администратор убрал испорченные страницы и она снова открывается) обработка снимает слепок: перечень ссылок на объекты и число строк табличных частей и движений по каждому владельцу. Слепок сохраняется файлом.
3. В копии из бэкапа открывается та же обработка, ей указывают файл слепка рабочей базы. Она снимает такой же слепок у копии и сравнивает два. Что есть в копии и пропало в рабочей базе, и есть потерянный список. Соединения между базами нет, только файл.

Слепок снимается обычными запросами. Пример для документов и их табличной части:

Слепок = Новый Массив;
// перечень документов
Запрос = Новый Запрос("ВЫБРАТЬ Т.Ссылка КАК Ссылка ИЗ Документ.РеализацияТоваровУслуг КАК Т");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
	Слепок.Добавить(Строка(Выборка.Ссылка.УникальныйИдентификатор()));
КонецЦикла;

// число строк табличной части по каждому документу
Запрос = Новый Запрос("ВЫБРАТЬ Т.Ссылка КАК Ссылка, КОЛИЧЕСТВО(*) КАК К
	|ИЗ Документ.РеализацияТоваровУслуг.Товары КАК Т СГРУППИРОВАТЬ ПО Т.Ссылка");

Для движений слепок группирует по регистратору:

Запрос = Новый Запрос("ВЫБРАТЬ Т.Регистратор КАК Регистратор, КОЛИЧЕСТВО(*) КАК К
	|ИЗ РегистрНакопления.ТоварыНаСкладах КАК Т СГРУППИРОВАТЬ ПО Т.Регистратор");

Сравнение двух слепков даёт по каждому объекту: документы, пропавшие целиком, документы с недостающими строками табличной части и документы с пропавшими движениями.

По времени: на стенде слепок задетых объектов (документ и регистр, 10 499 строк слепка) снимается за 0,7 секунды на сервере, сравнение идёт 1,2-1,4 секунды. Слепок и сравнение обработка делает порциями по месяцам, так что память не растёт с размером базы, а время растёт с числом строк задетых объектов. На больших базах я это не мерил. Отдельная задача там другая: поднять рядом копию базы из бэкапа, на это нужны место и время администратора.

На стенде сравнение копии с рабочей базой после исправления дало ровно то, что было испорчено: 9 документов "Реализация товаров и услуг" пропали целиком, у 5 документов пропали строки табличной части (19 строк), у 10 документов пропали движения по складу (44 движения). Совпало со списком, снятым до порчи.

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

Что после исправления служебными средствами

Если администратор убирает испорченные страницы штатным исправлением сервера баз данных, оно удаляет строки этих страниц и не сообщает, какие документы удалило. На стенде у девяти удалённых документов их собственные строки табличной части и движения остались на других, целых страницах: 41 строка и 41 движение (в синтетике стенда по движению на строку, на рабочей базе соотношение будет своё). То есть остатки на складе после такого исправления считаются в том числе по документам, которых уже нет. База открывается, повторная проверка целостности чистая, а отчёт по остаткам врёт.

Ловится это той же сверкой с копией и штатным тестированием и исправлением с проверкой логической целостности: оно покажет висящие строки и движения без документа. Поэтому порядок такой: сначала полный бэкап базы как есть, с повреждением, и отчёт обработки по выводу CHECKDB, потом исправление, потом сверка с копией. Бэкап с повреждением нужен на случай, если исправление удалит больше, чем ожидали.

Обработка

Всё, что выше, собрано во внешнюю обработку "Повреждение базы 1С на MS SQL: что задето и что поднимать из бэкапа". Она разбирает вывод проверки целостности (текст на русском или английском), называет объекты 1С и ставит вердикт по каждой битой странице. Список конкретных документов даёт кнопка сверки с копией: сравнение двух баз запросами 1С. Отчёт выгружается одним файлом Markdown, чтобы отдать коллеге или нейросети. Обработка к SQL Server не подключается, ничего не исправляет и в базу не пишет. MS SQL, любая конфигурация, проверено на платформе 8.3.27.

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

Файловая база подойдёт? Нет, только клиент-серверная на MS SQL. Для файловой .1CD есть отдельные средства, PostgreSQL в первой версии нет.

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

Какие права нужны? Прав на SQL Server никаких. В 1С проще всего запускать под пользователем с полными правами: структуру хранения платформа отдаёт для административных действий, а слепок читает все задетые объекты в обеих базах.

Насколько точен список сверки? Он называет ровно то, что пропало относительно бэкапа: на стенде 9 документов целиком, 5 документов без части строк табличной части (19 строк) и 10 документов без части движений (44 движения). Главное ограничение: документ, введённый после бэкапа и потерянный на битой странице, сверка не увидит, в копии его нет. Такие ищут по первичным документам и журналу регистрации за период между бэкапом и сбоем.

Что делать с движениями, если документ пропал целиком? Сначала вернуть документ из копии, потом перепровести: без регистратора проводить нечего.

Работает ли на БП, ЗУП, ERP? Перевод таблиц в объекты и сверка работают в любой конфигурации, они платформенные. Сам разбор я гонял на УТ для Казахстана.

А у вас проверка целостности находила ошибки только в индексах, или сразу в данных? И поднимали вы после этого всю базу из бэкапа или отдельные документы?

Обработка из этой статьи: Повреждение базы 1С на MS SQL: что задето и что поднимать из бэкапа.

Другие наши инструменты

• Чек-ап СУБД под 1С: правильно ли база стоит на сервере баз данных, вердикт по каждому пункту и история бэкапов.
• Карта объёмов базы 1С: из каких объектов состоит база, с сопоставлением объектам метаданных.
• Чек-ап чистоты базы 1С: сколько займёт уборка и что сломается: битые ссылки на несуществующие объекты поимённо и мусор на уровне 1С.
• Аудит паролей СУБД: можно ли восстановить пароли баз по файлам кластера 1С.
• Выгрузка метаданных для LLM: структура конфигурации одним файлом для нейросети.