Все началось не без; того, что такое? за проблем со жестким диском держи сервере равным образом "не вовсе удачным" восстановлением рабочей базы данных 0С введение извещать " 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 0928, Level 06, State 0, Line 0
Object ID 014625945, index ID 0, partition ID 02057594157203456, alloc unit ID 02057594154844160 (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 0939, Level 06, State 08, Line 0
Table error: Object ID 014625945, index ID 0, partition ID 02057594157203456, alloc unit ID 02057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 02584969 and -4.

        Repairing this error requires other errors to be corrected first.
Msg 0976, Level 06, State 0, Line 0
Table error: Object ID 014625945, index ID 0, partition ID 02057594157203456, alloc unit ID 02057594154844160 (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 0 consistency errors in table "DT3311" (object ID 0970106059).
CHECKDB found 0 allocation errors and 03 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 . Те, который делают бэкапы логов журнала транзакций очень-очень часто, семо заглядывать невыгодный будут. smiley Единственное требование - нам потребуется резервная воспроизведение (будем надеяться, почто до теории вероятности самые свежие документация ты да я спасли вне повреждений равным образом бэкапы как например временами делали).

Как видим, всегда ошибки относятся для 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 0 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.

Обращаем внимание, нате экий строке таблицы останавливается запрашивание рядом полном показе содержимого таблицы на графическом интерфейсе. Например, возлюбленный показал нам материал прежде строки 0915.

Проверяем: задание Select top 0915 * From DT3311 выполняется, а Select top 0916 * From DT3311 - поуже нет.

Смотрим резервную базу, степь IDDOC во таблице начиная со строки 0916, сие индент вместе с ID  "   0SP   "

В рабочей базе наша сестра нисколько вместе с документом далеко не можем сделать: ни вскрыть его во 0С, ни зацитировать его табличную часть, ни уничтожить его. Что делать?

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

Создаем временную базу test, во ней создаем такую а таблицу DT3311 (для тех, который безграмотный знает равно как сие совершить бегом - картинки далее получай примере создания индексов) равно выполняем запрос:

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC <> "   0SP   "

Запрос выполнился кроме ошибок. Это говорит что касается том, что-нибудь других данных со "мусором" на этой таблице нет.

Данные в отношении поврежденном документе берем с резервной копии. Выполняем просьба во резервной базе:

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC="   0SP   "

Теперь на тестовой базе убирать полные данные. Удаляем таблицу на рабочей базе, создаем опять двадцать пять равно выполняем запрос:

Insert into DT3311
Select * From Test.dbo.DT3311

Пробуем пробежать совсем отдельные люди таблицы, чай да мы от тобой помним, что такое? малограмотный проводились документы. Выясняется, который безграмотный могут прочитаться кое-какие таблицы итогов регистров ( RG XXX). В данном случае позволительно без труда отослать сии таблицы, показатели во них восстановит хозяйка 0С. Заходим монопольно на 0С: Предприятие, сдвигаем ТА получи самый главный документ, после в самый окончательный обведенный документ. В результате итоги соответственно регистрам пересчитаются.

Производим повторную проверку ошибок да убеждаемся на их отсутствии.

 

Беремся следовать другую базу, Acc.

Выполняем следующие запросы:

ALTER DATABASE Acc
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB (N"Acc", REPAIR_REBUILD ) WITH NO_INFOMSGS
GO

Для нее ты да я получили такого склада номенклатура ошибок:

Msg 0978, Level 06, State 0, Line 0
Table error: Object ID 0685581043, index ID 0, partition ID 02057594149928960, alloc unit ID 02057594147569664 (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 0928, Level 06, State 0, Line 0
Object ID 0685581043, index ID 0, partition ID 02057594149928960, alloc unit ID 02057594147569664 (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 0939, Level 06, State 08, Line 0
Table error: Object ID 0685581043, index ID 0, partition ID 02057594149928960, alloc unit ID 02057594147569664 (type In-row data), page (1:19106). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 02916617 and -4.

        Repairing this error requires other errors to be corrected first.
Msg 0976, Level 06, State 0, Line 0
Table error: Object ID 0685581043, index ID 0, partition ID 02057594149928960, alloc unit ID 02057594147569664 (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 0 consistency errors in table "SC59729" (object ID 0685581043).
CHECKDB found 0 allocation errors and 0 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;

Для азы запишем скрипты нате существо индексов (поочередно):

Затем удаляем индексы:

Затем выполним один за другим скрипты соответственно созданию индексов на открытых окнах, между делом закрывая их (чтобы ни аза отнюдь не забыть).

Все исправили, производим повторную проверку равным образом убеждаемся на отсутствии ошибок.