Все началось с того, что после проблем с жестким диском на сервере и "не совсем удачным" восстановлением рабочей базы данных 1С начала сообщать "could not continue scan with nolock" при проведении документов и закрываться с непоправимой ошибкой. Бэкап был, но не самый свежий, а данные терять не хотелось. Что же лучше делать?
Такое сообщение говорит, как правило, о том, что данные базы разрушены.
Первым делом нужно сделать резервную копию.
Далее запускаем в SQL Management Studio и выполняем DBCC CHECKDB. Выполняем ее так, чтобы данные не терялись, параметр REPAIR_ALLOW_DATA_LOSS оставим на случай совсем безнадежный.
Например, наша база называется Office
Выполняем следующие запросы:
ALTER DATABASE Office
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'Office', REPAIR_REBUILD) WITH NO_INFOMSGS
GO
Смотрим что сообщила проверка и видим множество сообщений примерно такого содержания:
Msg 8928, Level 16, State 1, Line 2
Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data): Page (1:3605) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data). Page (1:3605) was not seen in the scan although its parent (1:6481) and previous (1:8859) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
...
CHECKDB found 0 allocation errors and 8 consistency errors in table 'DT3311' (object ID 1970106059).
CHECKDB found 0 allocation errors and 43 consistency errors in database 'Office'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Office, repair_rebuild).
После проверки выполняем запрос для дальнейших операций с базой данных:
ALTER DATABASE Office
SET MULTI_USER;
Как восстанавливать поврежденные страницы писать не буду. Статья рассчитана на простое администрирование и поможет даже при модели Simple. Те, кто делают бэкапы логов журнала транзакций очень-очень часто, сюда заходить не будут. 
Единственное условие - нам потребуется резервная копия (будем надеяться, что по теории вероятности самые свежие данные мы спасли без повреждений и бэкапы хоть иногда делали).
Как видим, все ошибки относятся к index id = 0 или index id = 1. Это говорит о том, что повреждены данные. Но не будем отчаиваться и воспользуемся резервной копией.
Обращаем внимание на сообщенную таблицу DT3311. Пытаемся открыть ее или прочитать данные запросом, возникает сообщение об ошибке:
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xacafd5b7; actual: 0x21c9cf6a). It occurred during a read of page (1:8473) in database ID 8 at offset 0x00000004232000 in file 'E:\SQL_Data\Office.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Обращаем внимание, на какой строке таблицы останавливается запрос при полном показе содержимого таблицы в графическом интерфейсе. Например, он показал нам данные до строки 1915.
Проверяем: запрос Select top 1915 * From DT3311 выполняется, а Select top 1916 * From DT3311 - уже нет.
Смотрим резервную базу, поле IDDOC в таблице начиная со строки 1916, это документ с ID ' 1SP '
В рабочей базе мы ничего с документом не можем сделать: ни открыть его в 1С, ни прочитать его табличную часть, ни удалить его. Что делать?
Предлагаю перебросить по кусочкам данные из разных баз (рабочей и резервной), удалить таблицу в рабочей базе, создать ее повторно и положить данные на место.
Создаем временную базу test, в ней создаем такую же таблицу DT3311 (для тех, кто не знает как это сделать быстро - картинки ниже на примере создания индексов) и выполняем запрос:
Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC <> ' 1SP '
Запрос выполнился без ошибок. Это говорит о том, что других данных с "мусором" в этой таблице нет.
Данные о поврежденном документе берем из резервной копии. Выполняем запрос в резервной базе:
Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC = ' 1SP '
Теперь в тестовой базе есть полные данные. Удаляем таблицу в рабочей базе, создаем заново и выполняем запрос:
Insert into DT3311
Select * From Test.dbo.DT3311
Пробуем прочитать полностью другие таблицы, ведь мы помним, что не проводились документы. Выясняется, что не могут прочитаться некоторые таблицы итогов регистров (RGXXX). В данном случае можно просто удалить эти таблицы, данные в них восстановит сама 1С. Заходим монопольно в 1С: Предприятие, сдвигаем ТА на самый первый документ, затем на самый последний проведенный документ. В результате итоги по регистрам пересчитаются.
Производим повторную проверку ошибок и убеждаемся в их отсутствии.
Беремся за другую базу, Acc.
Выполняем следующие запросы:
ALTER DATABASE Acc
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'Acc', REPAIR_REBUILD) WITH NO_INFOMSGS
GO
Для нее мы получили такой перечень ошибок:
Msg 8978, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:17191) is missing a reference from previous page (1:19106). Possible chain linkage problem.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 2
Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data): Page (1:19106) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data), page (1:19106). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 62916617 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:19106) was not seen in the scan although its parent (1:20741) and previous (1:15201) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'SC59729' (object ID 1685581043).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'Acc'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Acc, repair_rebuild).
Тут картина совсем нестрашная. Данные не повреждены. Ошибки можно исправить удалением и созданием некластерных индексов.
Не забываем вернуть доступ к базе данных:
ALTER DATABASE Acc
SET MULTI_USER;
Для начала запишем скрипты на создание индексов (поочередно):
Затем удаляем индексы:
Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть).
Все исправили, производим повторную проверку и убеждаемся в отсутствии ошибок.
