Назад | Перейти на главную страницу

Исправление несогласованных страниц в базе данных

У нас есть БД SQL 2000. Сбой сервера из-за сбоя массива Raid. Теперь, когда мы запускаем DBCC CHECKDB, мы получаем сообщение об ошибке, что на 9 страницах есть 27 ошибок согласованности.

Когда мы запускаем DBCC PAGE на этих страницах, мы получаем следующее:

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

Поскольку указанный индекс не кластеризован и создается уникальной константой, содержащей 2 столбца, мы попытались удалить и воссоздать индекс. Это привело к следующей ошибке:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

Однако бег

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

возвращает 0 строк.

Вот что мы планируем сделать:

Восстановите копию базы данных до сбоя сервера и запустите DBCC CHECKDB
Если это вернется чистым, то восстановите снова без восстановления
Применить все последующие резервные копии TLOG
Остановите производственное приложение, сделайте резервную копию хвостового журнала и примените это тоже
Отбросьте prod DB и переименуйте только что восстановленную DB, чтобы сделать ее prod
Запустить приложение prod

Может ли кто-нибудь пробить дыры в этом подходе? Может быть, предложить другой подход? Нам нужно минимальное время простоя.

Размер базы данных SQL 2000 94 ГБ Таблица с поврежденными страницами содержит более 460 миллионов строк данных

Спасибо за помощь.

Радж

sql-server dbcc

Ваше решение для восстановления - это учебник для продолжения. Предполагая, что у вас есть соответствующие резервные копии и вы можете сделать резервную копию журнала транзакций для поврежденной базы данных, тогда ваша стратегия - это учебник, который нужно реализовать.

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

Иногда вы можете создать точную копию затронутой таблицы, выполнив

select *
into NewTableFromOld
from DamagedTable

Затем просто удалите / замените поврежденную таблицу новой, не забудьте добавить соответствующие ограничения и индексы.

Я бы попробовал сначала скопировать данные в файл, а затем снова поместить их в новую таблицу. SELECT INTO не подходит (IMO) для такого количества записей ...