Сдох внезапно бесперебойник при мне когда пришел вырубился еще раз, сервак SQL в этот момент на экране дошел до ввода пароля. После этого вырубил его. Как теперь оказалось держит ток два моника теперь, но суть не в этом. После этих внезапных отключений база перешла в SUSPECT.... Пока стопнул скуль. копирую на другой комп базу. Опыта восстановления подобных дел не было. Пока копируется прошу помощи что смотреть и что делать? Бэкап с субботы есть надеюсь что рабочий. Хочется восстановить все до отрубания сервака так как, данные даже за эти несколько дней будет проблемно восстановить, к примеру заявки и тд... Первая мысль что проверить оттатачить базу удалить лдф и присоеденить назад...

https://www.google.ru/search?as_sitesearch=forum.mista.ru&q=sql+suspect

http://infostart.ru/public/59520/

http://blog.galievr.ru/?p=382 восстанавливал ли кто так? какие рекомендации в данно

й ситуации в первую очередь?

В первую скопировать mdf и ldf на другой диск.

а если бы база была ZUP или БП, алгоритм был бы другим?

(5) скопировано

(6) сарказм 5+ без обид

если отключу то скорее всего не подключу это наверняка, попробовал на другом с таким же расположением и именем не подключается...

дали ж ответ в (2)

от щас попробую

сколько по времени знает кто?

займет из (2)

от 2 сек до  хз

запустил на тестовом с checkdb долго идет....
сколько по времени может кто подскажет checkdb на базе  30Гб?

(15)
все зависит от железа.  примерно 1 гигабайт в минуту.
на обычных sata дисках

и так на копии все запустилось через (3). В принципе почти одно и то же выполняется на рабочем из (2) во время выполнения есть ошибки
Table error: table '_Document334' (ID 1453000703). Index row in index '_Documen334_ByField6335_R' (ID 5) does not match any data row. Possible extra or invalid keys for:
Msg 8956, Level 16, State 1, Line 2
Index row (1:3472559:52) with values (_Fld6226RRef = 0x97C50015172F9DB911E27BF324BE284C and _IDRRef = 0xABA30015172F9DB911E2F359B62750CC) pointing to the data row identified by (_IDRRef = 0xABA30015172F9DB911E2F359B62750CC).
Msg 8952, Level 16, State 1, Line 2
Table error: table '_Document334' (ID 1453000703). Index row in index '_Documen334_ByField6336_RR' (ID 6) does not match any data row. Possible extra or invalid keys for:
Msg 8956, Level 16, State 1, Line 2
Index row (1:3468494:101) with values (_Fld6230RRef = 0xBC110018E7369D5B11E05C20F0EF3112 and _IDRRef = 0xABA30015172F9DB911E2F359B62750CC) pointing to the data row identified by (_IDRRef = 0xABA30015172F9DB911E2F359B62750CC).
There are 130019 rows in 9317 pages for object "_Document334".
CHECKDB found 0 allocation errors and 2 consistency errors in table '_Document334' (object ID 1453000703).
Table error: Object ID 1819569966, index ID 1, partition ID 72057617695571968, alloc unit ID 72057617748590592 (type In-row data). Page (1:3097486) is missing a reference from previous page (1:3186683). Possible chain linkage problem.
Msg 8935, Level 16, State 1, Line 2
Table error: Object ID 1819569966, index ID 1, partition ID 72057617695571968, alloc unit ID 72057617748590592 (type In-row data). The previous link (1:3257775) on page (1:3186687) does not match the previous page (1:3187055) that the parent (1:2916348), slot 67 expects for this page.
Msg 8936, Level 16, State 1, Line 2
Table error: Object ID 1819569966, index ID 1, partition ID 72057617695571968, alloc unit ID 72057617748590592 (type In-row data). B-tree chain linkage mismatch. (1:3187055)->next = (1:3186687), but (1:3186687)->Prev = (1:3257775).
Msg 8981, Level 16, State 1, Line 2
Table error: Object ID 1819569966, index ID 1, partition ID 72057617695571968, alloc unit ID 72057617748590592 (type In-row data). The next pointer of (1:3186683) refers to page (1:3258152). Neither (1:3258152) nor its parent were encountered. Possible bad chain linkage.
There are 1119294 rows in 236484 pages for object "_InfoRg19851".
CHECKDB found 0 allocation errors and 4 consistency errors in table '_InfoRg19851' (object ID 1819569966).

Требуется ли запускать после этого с параметром REPAIR_REBUILD тоже самое как рекомендуют в (3)

(16) по времени примерно попали.
После выполнения база приросла на 10 ГБ

(17) Если запускали с repair_allow_data_loss, проверьте что за таблица _InfoRg19851 - оттуда у вас могли пропасть данные.
Советую почитать вот это: http://habrahabr.ru/post/136979/ (и особое внимание обратить на разделы "Повреждение только некластерных индексов" и "Повреждение кластерного индекса или кучи" - у вас оба случая)

(19) спасибо, полезная статья.

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

+(21) расшифровки многих ошибок не нашел в статье из (19)