DBCC CHECKDB для базы 1С: как запустить проверку целостности и что делают ключи REPAIR_*

DBCC CHECKDB — это команда Transact-SQL, которая проверяет логическую и физическую целостность всех объектов указанной базы данных Microsoft SQL Server. База 1С для SQL Server — такая же база, как любая другая, и проверяется тем же запросом: DBCC CHECKDB(N'имя_базы') WITH NO_INFOMSGS. Трудное начинается после того, как проверка вернула ошибки согласованности. Ключей восстановления у команды три, и документация Microsoft называет их применение «last resort», крайним средством: гарантии, что база после них станет чистой, первоисточник не даёт. Ниже — синтаксис, ключи и требования платформы по действующей документации Microsoft, а за ними разбор нашего инцидента 2019 года, где REPAIR_REBUILD не изменил ничего, а REPAIR_ALLOW_DATA_LOSS устранил 85 ошибок из 2603 и встал.

Коротко

• DBCC CHECKDB проверяет логическую и физическую целостность всех объектов базы данных и включает в себя DBCC CHECKALLOC, DBCC CHECKTABLE по каждой таблице и представлению и DBCC CHECKCATALOG. Отдельно эти три команды запускать не нужно.
• Минимальный запуск для базы 1С: DBCC CHECKDB(N'имя_базы') WITH NO_INFOMSGS. Ключ NO_INFOMSGS в документации Microsoft описан одной строкой: «Suppresses all informational messages».
• Однопользовательский режим базы — требование документации Microsoft, поставленное сразу ко всем трём ключам REPAIR_*: «The specified database must be in single-user mode to use one of the following repair options».
• Microsoft ставит восстановление из последней известной хорошей резервной копии основным путём: «Microsoft always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB». Ключ REPAIR_ALLOW_DATA_LOSS там же назван «emergency last resort option».
• В нашем инциденте 2019 года проверка нашла 2603 ошибки согласованности. REPAIR_REBUILD результат не изменил, REPAIR_ALLOW_DATA_LOSS довёл счёт до 2518 и встал. Помогла очистка проблемной таблицы регистра — операция с потерей данных, которую мы приводим как факт инцидента, а не как рекомендацию; через час ошибка вернулась, и базу вылечило тестирование и исправление в конфигураторе 1С — прогон, перед которым сама 1С рекомендует сделать резервную выгрузку информационной базы, потому что он необратим.

Цитаты о поведении команды взяты со страницы документации Microsoft DBCC CHECKDB (Transact-SQL) (внешняя ссылка) и сверены живыми запросами 6 сентября 2026 года; версия документации — sql-server-ver17, диапазон в шапке страницы — SQL Server начиная с 2017, Azure SQL Database и Azure SQL Managed Instance. Русское зеркало страницы — машинный перевод, в служебных данных страницы стоит ms.translationtype: MT, поэтому несущие формулировки приведены и по-английски. Разбор инцидента — наш собственный материал, опубликованный здесь 10 декабря 2019 года; хронология и цифры сохранены без изменений, техническая часть переписана и сверена по первоисточнику 6 сентября 2026 года. Позиция 1С о тестировании и исправлении информационной базы приведена по двум страницам 1С:ИТС, снятым под подпиской 7 сентября 2026 года: адрес и дату публикации каждой я ставлю рядом с цитатой.

Что именно проверяет DBCC CHECKDB

Лид страницы документации Microsoft формулирует назначение команды так: «Checks the logical and physical integrity of all the objects in the specified database». Внутри одного запуска выполняется несколько проверок: DBCC CHECKALLOC по базе, DBCC CHECKTABLE по каждой таблице и каждому представлению, DBCC CHECKCATALOG по базе, проверка каждого индексированного представления, проверка согласованности FILESTREAM на уровне ссылок и проверка данных Service Broker. Вывод из этого документация делает прямо: «This means that the DBCC CHECKALLOC, DBCC CHECKTABLE, or DBCC CHECKCATALOG commands don't have to be run separately from DBCC CHECKDB».

Права на запуск документация Microsoft называет в разделе Permissions: «Requires membership in the sysadmin fixed server role or the db_owner fixed database role». Других требований к правам этот раздел не содержит.

Синтаксис DBCC CHECKDB

Полный синтаксис команды, дословно с той же страницы документации Microsoft:

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Из всего набора для первой проверки базы 1С нужны имя базы и один-два параметра после WITH. Три параметра — NO_INFOMSGS, PHYSICAL_ONLY и DATA_PURITY — меняют то, что вы увидите в выводе, сколько проверка идёт и что именно она проверит; разбираю их отдельно.

NO_INFOMSGS: короткий вывод вместо простыни

NO_INFOMSGS документация Microsoft описывает так: «Suppresses all informational messages». Без него команда печатает многострочный отчёт DBCC results for '<object>'… по каждому объекту базы и заканчивает строкой CHECKDB found 0 allocation errors and 0 consistency errors in database '<db>'. вместе с DBCC execution completed. If DBCC printed error messages, contact your system administrator. С NO_INFOMSGS на чистой базе вы увидите только The command(s) completed successfully., а ошибки, если они есть, напечатаются отдельно. Читать отчёт по каждому объекту базы 1С глазами я не готов, поэтому запускаю проверку сразу с этим ключом.

PHYSICAL_ONLY: облегчённая проверка для регулярных прогонов

PHYSICAL_ONLY ограничивает проверку физической структурой страниц и заголовков записей плюс согласованностью выделения места. Документация Microsoft прямо рекомендует этот вариант для частых запусков на продуктивных системах: «using the PHYSICAL_ONLY option might cause a much shorter run-time for DBCC CHECKDB on large databases and is recommended for frequent use on production systems. We still recommend that a full run of DBCC CHECKDB be performed periodically». Три ограничения при этом надо знать заранее. PHYSICAL_ONLY «always implies NO_INFOMSGS and isn't allowed with any one of the repair options», то есть с ключами восстановления его не совместить. Он «causes DBCC CHECKDB to skip all checks of FILESTREAM data». И проверки целостности значений столбцов при нём не выполняются вовсе.

Что молчит в базе, переехавшей со старых версий SQL Server

DATA_PURITY заставляет CHECKDB искать значения столбцов вне допустимого диапазона: например, дату и время за пределами того, что принимает тип datetime, или столбцы decimal с некорректной точностью. Оговорка документации Microsoft здесь важнее самого параметра: «Column-value integrity checks are enabled by default and don't require the DATA_PURITY option. For databases upgraded from earlier versions of SQL Server, column-value checks aren't enabled by default until DBCC CHECKDB WITH DATA_PURITY has been run error free on the database». База 1С, которую последовательно переносили с версии на версию SQL Server, — как раз такой случай: пока один безошибочный прогон WITH DATA_PURITY не сделан, эта категория проверок молчит. И ещё одно: найденные так ошибки ключами восстановления не лечатся — «Validation errors reported by this option can't be fixed by using DBCC repair options».

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

SQL Server пишет итог проверки в свой журнал ошибок, а не только в окно клиента: по документации Microsoft, «After the DBCC CHECKDB command finishes, a message is written to the SQL Server error log». Запись об успешной проверке выглядит так: CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required. Именно она и называется в документации last known clean check — устоявшегося русского перевода у этого термина нет, в русской версии страницы Microsoft оставляет его латиницей, как и сам формат строки журнала. Практический смысл записи простой: по ней видно, когда база в последний раз проходила проверку чисто.

Если CHECKDB наткнулся на повреждение, SQL Server создаёт дамп стека: файлы SQLDump<nnnn>.txt, .log и .mdmp в каталоге LOG службы SQL Server. Доступ к ним есть у учётной записи службы и у членов роли sysadmin. Когда проверка прерывается, в сообщении приходит код состояния; из таблицы состояний документации Microsoft на практике чаще нужны два: 3 — «indicates a corruption in metadata that terminated the DBCC command», и 4 — «An assert or access violation was detected».

Три ключа REPAIR_*: что о них говорит документация Microsoft

На странице 2019 года эти три формулировки стояли со ссылкой на безымянную «справочную информацию». Теперь у них есть адрес: страница DBCC CHECKDB (Transact-SQL) документации Microsoft, версия sql-server-ver17, дата сверки 6 сентября 2026 года. Русские формулировки взяты из машинного перевода страницы, поэтому рядом стоит английский текст.

Действующая формулировка REPAIR_REBUILD отличается от той, что стояла у нас на странице 2019 года: там было «это может быть быстрое восстановление… или более ресурсоемкие операции…», на живой странице сегодня «может включать быстрый ремонт… а также более длительный ремонт…». Смысл сохранился, слова переписаны, причину расхождения я не установил; цитирую действующую версию с действующего адреса. Английская версия страницы добавляет к REPAIR_REBUILD фразу, которой в русской нет: «This argument doesn't repair errors involving FILESTREAM data».

Требование к режиму доступа документация Microsoft ставит одним абзацем перед перечислением всех трёх ключей: «Use the REPAIR_* options only as a last resort. The specified database must be in single-user mode to use one of the following repair options». Это правило платформы для любого из трёх ключей, а не особенность какого-то одного. Для запуска CHECKDB без ключей восстановления такого условия страница не содержит.

Почему Microsoft ставит восстановление из копии впереди REPAIR_ALLOW_DATA_LOSS

Раздел «Data loss warning with REPAIR_ALLOW_DATA_LOSS» на странице документации Microsoft говорит буквально: «Microsoft always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. […] [The REPAIR_ALLOW_DATA_LOSS option] is an emergency last resort option recommended for use only if restoring from a backup isn't possible». Та же мысль повторена в разделе «Resolve errors»: «If any errors are reported by DBCC CHECKDB, we recommend restoring the database from the database backup, instead of running DBCC CHECKDB with one of the REPAIR_* options. If no backup exists, running repair corrects the errors reported».

Механика риска описана там же. Часть ошибок лечится только REPAIR_ALLOW_DATA_LOSS, и лечение может состоять в деаллокации строки, страницы или серии страниц: «Any deallocated data is no longer accessible or recoverable for the user». Перед запуском Microsoft требует сделать физические копии файлов базы — .mdf, .ndf, .ldf, файлы полнотекстовых каталогов. Ограничений и связей между таблицами операция восстановления не учитывает: «Repair operations don't consider any of the constraints that might exist on or between tables». Отсюда обязательный следующий шаг: «The user must inspect the referential integrity of their database (using DBCC CHECKCONSTRAINTS) after using the REPAIR_ALLOW_DATA_LOSS option».

Microsoft рекомендует оборачивать любой запуск с ключом REPAIR_* в транзакцию: «execute BEGIN TRANSACTION before running the command», посмотреть на результат и либо COMMIT TRANSACTION, либо ROLLBACK TRANSACTION, чтобы «undo the effects of the repair operations». На нашей странице 2019 года этого шага не было. Для базы учёта это дешёвая страховка, и я считаю её обязательной.

Порядок проверки, который следует из документации Microsoft

1. Сделать резервную копию перед запуском с ключом восстановления. Документация Microsoft просит об этом дословно: «If you use the REPAIR_ALLOW_DATA_LOSS level, we recommend that you back up the database before you run DBCC CHECKDB with this option», плюс физические копии файлов базы перед самим восстановлением. Мы в своём инциденте делали бэкап ещё раньше — до первого прогона проверки.
2. Запустить проверку: DBCC CHECKDB(N'имя_базы') WITH NO_INFOMSGS.
3. Прочитать результат — в выводе Management Studio и в журнале ошибок SQL Server, где остаётся строка о завершении проверки.
4. Если найдены ошибки — восстанавливать базу из последней известной хорошей резервной копии. Это основной путь по документации Microsoft.
5. Ключи REPAIR_* — только если восстановление из копии невозможно. Перед этим база переводится в однопользовательский режим; в нашем инциденте это делалось запросом ALTER DATABASE KA SET SINGLE_USER WITH ROLLBACK IMMEDIATE.
6. Запускать восстановление внутри транзакции, чтобы результат можно было откатить.
7. После REPAIR_ALLOW_DATA_LOSS проверить ссылочную целостность командой DBCC CHECKCONSTRAINTS.
8. Вернуть базу в многопользовательский режим — в нашем случае запросом ALTER DATABASE KA SET MULTI_USER. Страница документации этого шага не описывает: это выход из режима, который она требует.

2603 ошибки согласованности: как это было у нас

Дальше — наш собственный случай, из-за которого эта страница вообще появилась. Ценность его в одном: документированный путь в нём не сработал до конца.

Началось всё с жалобы бухгалтера: перестали проводиться документы, 1С сообщила о проблемах с согласованностью внутри базы и предложила проверку на согласованность. Мы сделали бэкап текущего состояния, перевели базу в однопользовательский режим и запустили DBCC CHECKDB(N'ka') WITH NO_INFOMSGS. Проверка шла около 15 минут.

Результат дословно: «CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных "KA"». Разбивка по объектам оказалась неровной: 1783 ошибки в таблице _AccRg1051, 766 не связанных ни с одним объектом, 49 в _AccRg1025, 3 в _AccRgAT21046 и по одной в sys.sysdbfiles и sys.sysxmlcomponent.

Бэкапы показали, что ошибка накапливалась

Первым вариантом мы пошли по рекомендованному пути и начали восстанавливать копии. Дословный вывод со страницы: восстановление «выявило накопительный характер ошибки: чем раньше сделан бэкап — тем меньше в базе ошибок, вплоть до самого „дальнего“ (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться — стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить».

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

REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS

REPAIR_REBUILD выполнился без эффекта: те же 2603 ошибки. Мы вернули базу в многопользовательский режим, провели обслуживание, перепроверили — результат тот же. Тестирование и исправление средствами 1С завершилось ошибкой, выгрузка в *.dt не удалась.

Затем пошёл REPAIR_ALLOW_DATA_LOSS. После нескольких прогонов количество ошибок немного уменьшилось: 2603 стало 2518. И остановилось. База по-прежнему не выгружалась и не лечилась средствами 1С, а дальнейшие чередования REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS не давали ничего.

Задним числом это ровно то, о чём документация Microsoft и предупреждает. Ключ REPAIR_ALLOW_DATA_LOSS описан там как «emergency last resort option». Обещания «одна команда — и порядок» на странице документации Microsoft нет ни в каком виде.

Что сработало — и почему это не рекомендация

Сработала очистка проблемной таблицы регистра без удаления самой таблицы: TRUNCATE TABLE _AccRg1051. Повторный DBCC CHECKDB через 15 минут показал, что все ошибки исчезли, в том числе и в остальных таблицах. База выгрузилась в *.dt, загрузилась обратно, проблемные документы у бухгалтера заработали.

Проговорю прямо, потому что этот абзац легче всего прочитать как инструкцию. TRUNCATE TABLE на таблице регистра — операция с потерей данных. Мы применили её тогда, когда рекомендованные пути были пройдены и не дали результата, и я привожу её как факт о том, что было сделано в конкретном инциденте, а не как совет для вашей базы. Что именно потерял клиент и как это закрывали в учёте, на исходной странице 2019 года не зафиксировано — поэтому я об этом и не говорю: остаётся сам факт очистки таблицы регистра и то, что было дальше. Связи между общей оговоркой документации Microsoft и тем, что помогла именно очистка таблицы, тоже нет — документация такой связи не устанавливает, это наш случай, а не следствие из первоисточника.

Через час ошибка вернулась

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

1С предупреждает, что тестирование с исправлением необратимо, и рекомендует перед ним сделать резервную выгрузку информационной базы. В ответе специалиста 1С это вынесено во врезку «Внимание»: «Перед проведением тестирования с исправлением рекомендуется сделать резервную выгрузку информационной базы, т.к. процедура тестирования с исправлением – операция необратимая» (раздел «Отвечает специалист 1С» на 1С:ИТС, страница от 11.10.2024, разбор сделан на релизе конфигурации «1С:Бухгалтерия 8» 3.0.160; доступ по подписке 1С:ИТС, сверено 7 сентября 2026 года). Порядок там описан в четыре строки: запустить базу от пользователя с ролью «Администратор системы» в режиме «Конфигуратор», раздел «Администрирование – Тестирование и исправление...», установить флажки нужного режима проверки, кнопка «Выполнить».

Наш случай попадает в эту рекомендацию неудобной стороной. На тяжёлой стадии тестирование и исправление средствами 1С завершилось ошибкой, а выгрузка в *.dt не удалась. Что именно 1С понимает под резервной выгрузкой, в ответе специалиста не раскрыто; у нас в тот момент страховкой служила резервная копия средствами SQL Server, сделанная до первого прогона проверки. А вылечил базу в итоге тот самый прогон, который 1С называет необратимым, — уже на финальной стадии, после того как ошибка вернулась.

1С не рекомендует включать проверку ссылочной целостности в информационных базах, хранящих неполный набор объектов. Это базы обмена: часть ссылок в них разрешается только в «глобальной» базе. По методической поддержке 1С:ИТС, тестирование с исправлением в таких условиях «может привести к частичному разрушению (изменению содержания или полному удалению объектов ссылки) в рамках "глобальной" информационной базы», и вывод сформулирован прямо: «В информационных базах, хранящих неполный набор объектов, такую проверку, а, тем более, проверку с исправлением, в силу приведенных выше причин, проводить не следует». Управляет проверкой флажок в диалоге «Тестирование и исправление», а из командной строки — параметры ключа /IBCheckAndRepair: -LogIntegrity («проверка только логической целостности») и -LogAndRefsIntegrity («проверка логической и ссылочной целостности»). Страница датирована 06.06.2008, версия платформы на ней не названа, доступ тоже по подписке — так что «это верно для вашей платформы» из неё не следует. Проверить, не про вашу ли базу этот абзац, стоит до того, как ставить флажок.

Актуально ли это для вашей версии SQL Server

Формулировки трёх ключей REPAIR_* и требование однопользовательского режима на странице документации Microsoft версионных оговорок не имеют: они одинаковы для всего диапазона, который заявлен в шапке, — SQL Server начиная с 2017, Azure SQL Database и Azure SQL Managed Instance, дата сверки 6 сентября 2026 года. Это и есть ответ на вопрос, не устарела ли процедурная часть текста семилетней давности.

Версионные оговорки на странице есть, и относятся они к другим параметрам. MAXDOP — «Applies to: SQL Server 2014 (12.x) Service Pack 2 and later versions». EXTENDED_LOGICAL_CHECKS работает при уровне совместимости 100, появившемся в SQL Server 2008. До SQL Server 2005 SP2 запуск CHECKDB очищал кэш планов, начиная с SP2 — «executing DBCC CHECKDB no longer clears the plan cache for the instance of SQL Server». В SQL Server 2016 и новее часть дополнительных проверок (вычисляемые столбцы, столбцы UDT, отфильтрованные индексы) по умолчанию не выполняется, что экономит время. А в Azure SQL Database Hyperscale DBCC CHECKDB не поддерживается вовсе — вместо него документация предлагает DBCC CHECKTABLE ('TableName') WITH TABLOCK.

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

Что с этим делать в регламенте

В плане обслуживания базы 1С проверка целостности стоит первой задачей — так она описана на нашей соседней странице про обслуживание баз, перед всеми остальными регламентными операциями. Как собирается сам план в Microsoft SQL Server Management Studio, расписано там же, в статье «Обслуживание баз Microsoft SQL Server для работы 1С»; здесь я эту тему не повторяю.

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

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

Как запустить DBCC CHECKDB?

Запрос выполняется в любом клиенте T-SQL, например в Management Studio, под учётной записью с членством в роли sysadmin или db_owner. Минимальная форма для базы 1С: DBCC CHECKDB(N'имя_базы') WITH NO_INFOMSGS. Ключ NO_INFOMSGS подавляет информационные сообщения, поэтому на чистой базе в выводе останется только The command(s) completed successfully. Для регулярных запусков на работающей системе документация Microsoft рекомендует PHYSICAL_ONLY, оговариваясь, что полную проверку всё равно надо делать периодически.

Нужен ли однопользовательский режим для обычной проверки?

Требование однопользовательского режима документация Microsoft ставит как условие применения ключей REPAIR_*: «The specified database must be in single-user mode to use one of the following repair options». Для запуска DBCC CHECKDB без ключей восстановления такого условия на странице нет.

Сколько времени идёт проверка базы 1С?

Точную оценку по объёму базы документация Microsoft не даёт, и я не буду её выдумывать. Наш замер один и конкретный: DBCC CHECKDB(N'ka') WITH NO_INFOMSGS на базе того клиента отработал около 15 минут, а результат повторной проверки после очистки таблицы мы увидели через те же 15 минут. Размер базы на исходной странице не указан, так что переносить эти 15 минут на свою базу как ориентир не стоит. Для больших баз документация советует PHYSICAL_ONLY — «might cause a much shorter run-time for DBCC CHECKDB on large databases».

Чем REPAIR_REBUILD отличается от REPAIR_ALLOW_DATA_LOSS?

REPAIR_REBUILD выполняет только те исправления, которые не могут привести к потере данных: от восстановления отсутствующих строк в некластеризованных индексах до перестроения индекса. REPAIR_ALLOW_DATA_LOSS пытается устранить все обнаруженные ошибки, и эти исправления «могут привести к частичной потере данных» — вплоть до деаллокации строки, страницы или серии страниц, после которой данные «no longer accessible or recoverable for the user». После REPAIR_ALLOW_DATA_LOSS документация Microsoft требует проверить ссылочную целостность командой DBCC CHECKCONSTRAINTS.

CHECKDB нашёл ошибки согласованности. С чего начинать?

С резервной копии. Позиция Microsoft однозначна: восстановление из последней известной хорошей копии — основной способ уйти от ошибок, о которых сообщил DBCC CHECKDB, а REPAIR_ALLOW_DATA_LOSS рекомендован «only if restoring from a backup isn't possible». В нашем инциденте этот путь не помог по конкретной причине: ошибка накапливалась и присутствовала уже в самом дальнем доступном бэкапе за 14 дней.

Поможет ли встроенное «Тестирование и исправление» 1С?

В нашем инциденте на тяжёлой стадии оно не помогло: тестирование и исправление средствами 1С завершилось ошибкой, выгрузка в *.dt не удалась. А на финальной стадии, после того как ошибка вернулась через час, базу вылечило именно тестирование и исправление в режиме конфигуратора. Это два факта об одном случае, а не правило. Сама 1С в ответе специалиста говорит о страховке: перед тестированием с исправлением рекомендуется сделать резервную выгрузку информационной базы, «т.к. процедура тестирования с исправлением – операция необратимая» (1С:ИТС, страница от 11.10.2024, релиз конфигурации «1С:Бухгалтерия 8» 3.0.160, доступ по подписке, сверено 7 сентября 2026 года). Обещания вылечить любое повреждение базы в этом ответе нет.

Где посмотреть, когда база в последний раз проверялась без ошибок?

В журнале ошибок SQL Server. После завершения команды туда пишется сообщение, у чистой проверки оно выглядит как CHECKDB for database '<database>' finished without errors on <дата и время> (local time). This is an informational message only; no user action is required. Документация Microsoft называет эту отметку last known clean check; в русской версии страницы термин оставлен латиницей.

Александр Жогов, основатель компании «+Альянс». Цитаты документации Microsoft сверены 6 сентября 2026 года по странице learn.microsoft.com версии sql-server-ver17; цитаты 1С сняты со страниц 1С:ИТС под подпиской 7 сентября 2026 года; хронология и цифры инцидента — наш материал, опубликованный на этой странице 10 декабря 2019 года.