v8: База УПП в состоянии SUSPECT #674028

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

восстанавливал ли кто так? какие рекомендации в данно

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

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

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

скопировано

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

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

дали ж ответ в

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

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

займет из

от 2 сек до  хз

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

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

и так на копии все запустилось через . В принципе почти одно и то же выполняется на рабочем из во время выполнения есть ошибки 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 тоже самое как рекомендуют в

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

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

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

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

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