dbcc checkdb

Добрый вечер.

select @@version
---
Microsoft SQL Server 2005 - 9.00.3050.00 (Intel X86)   Mar  2 2007 20:01:28   Copyright (c) 1988-2005 
Microsoft Corporation  Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2) 

Есть ли способ догадаться о том, сколько еще будет думать

dbcc checkdb(DbName)

над упавшей базой ?

PS. Время в полете 27.04:50:00. Размер DB - 1.8TB

Greenhorn,

Многое зависит от вашего железа, Как вы запустили script - как расположен Ваш TempDB масса всяких яких Коллега. Вот тут посмотрите на способы отпимизации :

Mr Marmelad

Greenhorn, Многое зависит от вашего железа, Как вы запустили script - как расположен Ваш TempDB масса всяких яких Коллега.

Конечно зависит, я лиш спрашивал о том, можно ли на основе анализа того, что сейчас юзает dbcc определить как далеко он продвинулся.
И сделать выводы о том - сколько ему еще пыхтеть.

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

Года два назад я пытался в запустить dbcc, но через три дня уборщица выдернула питание из компа. Т.к. тогда причина падения была очевидна - у кластера на всем скаку оторвали диски, а через пол часа еще и сеть, отчет был предоставлен быстро.

А сейчас - после "выполнения неизвестной команды произошла внутренняя ошибка SQL" и база рухнула.
Передаче логов дампов трэйсов и прочей инфы в Микрософт выявил только одно - сбоев оборудования за последний год не зафиксированно.
Вывод Мелкософта - ошибка могла сидеть в базе уже более года, а потому она есть и в backup'ах.
Отсюда использовать базу восстановленную из backup'ов можно только после checkdb.

А единственный способ проверки базы (как и backup'ов) это перидоический запуск checkdb.

Но, если он СТОЛЬКО работает (уже месяц без двух дней), то, что-то мне начинает казаться, что
выбор SQL2k5 для VLDB - был стратегической ошибкой...

Или есть способы/варианты гарантировать то, что в Backup'ах хотябы живая база сидит.

Вариант, предложенный мелкософтом, восстанавливать на отдельном серваке и запускать checkDB
уже не проходит - Backup'ы генерятся почаще чем раз в месяц.

Greenhorn

Но, если он СТОЛЬКО работает (уже месяц без двух дней), то, что-то мне начинает казаться, что выбор SQL2k5 для VLDB - был стратегической ошибкой... Или есть способы/варианты гарантировать то, что в Backup'ах хотябы живая база сидит. Вариант, предложенный мелкософтом, восстанавливать на отдельном серваке и запускать checkDB уже не проходит - Backup'ы генерятся почаще чем раз в месяц.

BOL - BACKUP DATABASE

CHECKSUM
Enables backup checksums, so that BACKUP can do the following:

Prior to writing a page to the backup media, BACKUP verifies the page (page checksum or torn page), if this information is present on the page.

Regardless of whether page checksums are present, BACKUP generates a separate backup checksum for the backup streams. Restore operations can optionally use the backup checksum to validate that the backup is not corrupted. The backup checksum is stored on the backup media, not on the database pages. The backup checksum can optionally be used at restore time,


Using backup checksums may affect workload and backup throughput.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
Controls whether a backup operation stops or continues after encountering a page checksum error.

STOP_ON_ERROR
Instructs BACKUP to fail if a page checksum does not verify. This is the default behavior.

CONTINUE_AFTER_ERROR
Instructs BACKUP to continue despite encountering errors such as invalid checksums or torn pages.