Проверить базу sql на ошибки

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Как проверить и восстановить базу данных SQL Server

1. На всякий случай делаем резервную копию базы данных

2. Выполняем проверку базы данных

Если в процессе проверки обнаружены ошибки переходим к п.3, если нет ошибок — к п.4

3. Переводим базу данных в однопользовательский режим и запускаем процедуру исправления ошибок

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

4. Возвращаем базу данных в многопользовательский режим

Дополнительная информация:

еще один блог об IT. по-простому

среда, 19 февраля 2014 г.

DBCC CHECKDB. Решение одной из ошибок проверки целостности базы данных.

Эта ошибка описывает несоответствие размещения данных в страницах индекса согласно указателям — ошибка логического уровня. Сказывает это тем, что при обращение к данным страницам возможны некорректные ошибки или ошибки выполнения запроса.

1) Если объектов много , то для начала выяснить что за объект — локализации проблемы:
Можно взять из текста ошибки

Либо запросом:
select object_name ( 228195863 )

index ID 1 – это кластерный индекс

если номер индекса >1 , то тогда запросом:
select * from sys . indexes where object_id = 228195863 and index_ >= 1
Мой результат : PK_t_DSY_PB_wrk_dosye

В данном случае просто это возможно простым перестроением индекса:

Либо возможен как вариант пересоздать индекс.
Проверить исправление возможно запусти команду:

Все началось с того, что после проблем с жестким диском на сервере и "не совсем удачным" восстановлением рабочей базы данных 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 >

Обращаем внимание на сообщенную таблицу 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_DataOffice.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

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

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;

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

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

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

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