Короткий ответ

Accounting в SUSPECT на SQL01\MSSQLSERVER — сначала копия файлов MDF/NDF/LDF на другой том, затем попытка restore из проверенного backup. SET EMERGENCY и тем более REPAIR_ALLOW_DATA_LOSS — только когда копии файлов лежат отдельно и backup не встаёт. Repair с потерей данных может выкинуть страницы документов 1С без отмены.

Не запускайте 1С «проверить, вдруг откроется». Не трогайте chdbfl — это не файловая 1С.

Симптомы и как отличить

Типичная картина:

  • 1С: не удалось начать сеанс с СУБД / база недоступна;
  • SSMS: Accounting красная, Suspect;
  • ERRORLOG: I/O, 823/824, «suspect».

Отличия:

state_descНе SuspectДействие
RECOVERING долгоcrash recoveryждать, диск
RECOVERY_PENDINGфайл недоступенпуть, диск
OFFLINEкто-то сделал offlineпочему
ONLINE, 1С не коннектитсясеть/логинSQL недоступен

Возможные причины

  1. Кончилось место на томе log/data в момент crash.
  2. I/O ошибка диска/RAID/thin pool.
  3. Жёсткое выключение SQL01.
  4. Повреждение после неудачного restore.
  5. Антивирус портит файл на записи.
  6. Редко: баг, оборванный detach.

Диагностика

1. Состояние и файлы

SELECT name, state_desc, user_access_desc FROM sys.databases WHERE name = N'Accounting';
SELECT file_id, type_desc, name, physical_name, state_desc, size
FROM sys.master_files WHERE database_id = DB_ID(N'Accounting');

2. ERRORLOG

Ищите 823/824/825, checksum, «Closing file», нехватку места. Путь ERRORLOG: MSSQL15 (2019) или MSSQL16 (2022) + \MSSQLSERVER\MSSQL\Log\ERRORLOG.

3. Место и диск

Get-Volume
Get-Item 'D:\SQL\Data\Accounting.mdf','D:\SQL\Log\Accounting_log.ldf' -ErrorAction SilentlyContinue |
  Format-Table FullName, Length, LastWriteTime

Подставьте свои physical_name.

4. Backup есть?

Последний успешный full/diff/log. Restore предпочтительнее surgery.

Решение

Шаг 0. Копия файлов

Остановите 1С к этой базе (кластер: запрет сеансов / монопольно). Если SQL ещё держит файлы, для файловой копии может понадобиться:

  • предпочтительно: backup, если ещё возможен;
  • иначе: остановить экземпляр MSSQLSERVER в согласованное окно и скопировать файлы, либо copy-on-read если служба отпустила.

Не копируйте только MDF без LDF.

New-Item -ItemType Directory -Force D:\SQL\SuspectCopy\Accounting | Out-Null
Copy-Item 'D:\SQL\Data\Accounting.mdf' 'D:\SQL\SuspectCopy\Accounting.mdf'
Copy-Item 'D:\SQL\Log\Accounting_log.ldf' 'D:\SQL\SuspectCopy\Accounting_log.ldf'

Пути — ваши из sys.master_files.

Сценарий A. Есть цепочка backup

Restore на другое имя Accounting_restore или другой экземпляр, проверка документов, затем переключение. Не REPLACE на проде, пока аварийные файлы не отложены. См. restore и резервирование SQL 1С.

Сценарий B. Backup нет / не встаёт, файлы скопированы

Только тогда, осознавая риск:

ALTER DATABASE [Accounting] SET EMERGENCY;
ALTER DATABASE [Accounting] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB (N'Accounting') WITH NO_INFOMSGS;

Читайте вывод. Если повреждение ограничено и бизнес принимает потерю страниц:

-- разрушительно, только после копии файлов и решения бизнеса
-- DBCC CHECKDB (N'Accounting', REPAIR_ALLOW_DATA_LOSS);

Затем SET MULTI_USER, сверка 1С. Часто честнее restore на вчера + ввод дня.

Сценарий C. RECOVERY_PENDING из-за пути

Верните диск, исправьте путь, не EMERGENCY. Если log потерян безвозвратно — это уже salvage с потерей, всё равно копия того, что осталось.

Не оставляйте базу в EMERGENCY для работы пользователей 1С.

Контур Accounting: что делать бизнесу, пока база Suspect

1С на SRV-1C в этом состоянии не «переподключить». Запретите сеансы в кластере, чтобы регламент не долбил SUSPECT и не плодил ошибки. Сообщите, что проведение невозможно, не предлагайте файловую копию «на час», если прод давно на SQL — разъедете данные.

Снимите копию файлов до любых ALTER DATABASE. Если SQL ещё держит хендлы и copy неполный — согласуйте короткий Stop MSSQLSERVER (это простой всех баз экземпляра, не только Accounting). На экземпляре с несколькими базами 1С это критично: предупредите все отделы.

ERRORLOG с 823/824 на конкретный file_id почти всегда сторадж. Пока SMART/RAID не разобран, restore на тот же LUN может снова дать Suspect. Восстанавливайте на другой диск/том, если есть. После ONLINE сразу полный backup на другой носитель.

Не путайте EMERGENCY с SINGLE_USER: emergency — аварийный доступ, не режим работы 1С. После repair, если вы на него пошли, CHECKDB без repair должен стать чистым или с документированным остаточным повреждением, которое бизнес принял. Затем новый full. Если CHECKDB всё ещё орёт — база не для пользователей, только копия «до» или более старый backup.

Для 1С после salvage обязательна сверка: оборотно-сальдовая, касса, банк, последние поступления. Расхождение — не «ещё раз repair», а ввод из первички или работа консультанта на копии.

Как проверить, что проблема устранена

SELECT name, state_desc FROM sys.databases WHERE name = N'Accounting';
DBCC CHECKDB (N'Accounting') WITH NO_INFOMSGS;

state_desc = ONLINE. 1С открывает Accounting на SRV-1C. Контрольные остатки. Новый full backup сразу после выхода из аварии.

Если не помогло

  • Repair не открывает — только более старый backup или вендор диска.
  • После repair 1С ругается на метаданные — копия «до» + консультант 1С, не ручной SQL к таблицам конфигурации.
  • Повторяется — диск, RAID, исключения антивируса на MDF/LDF.

Профилактика

  • Полная цепочка backup + test restore.
  • Алерт по месту томов SQL и 823/824.
  • ИБП, не «kill VM» с SQL.
  • Исключения антивируса на файлы СУБД.
  • Не shared LUN на 100% с бэкапами в прайм.

Отдельно проговорите с бизнесом RPO: если последний годный backup вчерашний, salvage через EMERGENCY может сохранить сегодняшний день ценой дыр в регистрах. Часто честнее вчерашний restore плюс ввод первички, чем «дырявая» база, которую никто не сверит. После любого исхода сразу полный backup Accounting на другой том, не на тот, где лежат подозрительные MDF.

FAQ

Можно ли просто restart SQL, чтобы снять Suspect?

Иногда recovery добьёт и база ONLINE. Если нет — повторный рестарт не лечит битые страницы. Копия файлов всё равно нужна до экспериментов.

EMERGENCY позволяет работать в 1С?

Это аварийный доступ DBA, не режим работы учётки 1С. Не держите прод в EMERGENCY.

Отличается ли процедура на SQL 2019 и 2022?

Логика та же. Пути ERRORLOG: MSSQL15 vs MSSQL16.

Нужно ли chdbfl?

Нет. Это SQL, не 1Cv8.1CD.

Кто подтверждает REPAIR_ALLOW_DATA_LOSS?

Владелец данных (финдир/главбух), не только админ. Иначе откатите restore-ом вчера.