Добрый день, вопрос касательно серверной базы и SQL.
Собственно ситуация аховая с старта - данная серверная база не может сделать бэкап как через конфигуратор/SQL/простое копирование файла mdf. И по "лучшим" традициям старый бэкап условно 22 года и всем все надо срочно. И сисадмин отсутствует как вид.
Сам SQL Microsoft SQL Server 2008 R2 а win - Server 12

Пробывал даже банально выгрузить обменом через идентичные конфигурации/пройтись запросом
"
ALTER DATABASE "myDBname" SET EMERGENCY
DBCC checkdb('myDBname')
ALTER DATABASE "myDBname" SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('myDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE "myDBname" SET MULTI_USER
ALTER DATABASE "myDBname" SET ONLINE
"
На  DBCC CheckDB ('myDBname', REPAIR_ALLOW_DATA_LOSS) операция может выполняться хоть неделю, но без результата. Просто идет прерывание SQL службы и все.

Единственное вразумительное сообщение было от DBCC checkdb -
Сообщение 0, уровень 11, состояние 0, строка 0 При выполнении текущей команды возникла серьезная ошибка.. При наличии результатов они должны быть аннулированы.

Если есть соображения как с этим быть, поделитесь пожалуйста. Сроки поджимают, а изучить весь лишней недели у меня не будет.
И соображение нанять SQL - знающего не будут приняты и так крайний.

p/s так же база крайне не охотно выходит из однопользовательского режима.

Что в логах-то? При бэкапе...

>>>REPAIR_ALLOW_DATA_LOSS
вот так сразу шашкой махать не стоит

Диск поди посыпался, где mdf лежит, да ?

(2) если бэкап 22 года, то можно и "дата лосс". Не так уж и нужна базёнка...

(3) дык этта, логи читать надоть...

(4) ну, хотя бы детатач и копи мдф/лдф куда нить в сторонку.

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

(6) Это святое. вопрос, пройдет ли потом аттач..

(1) в основном
A read of the file 'D:\SQL\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\buh_fok.mdf' at offset 0x00000362af6000 succeeded after failing 1 time(s) with error: 1117(Запрос не был выполнен из-за ошибки ввода/вывода на устройстве.). Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information<c/> see SQL Server Books Online.

и

Server has encountered 5 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [D:\SQL\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\buh_fok.mdf] in database [buh_fok] (10).  The OS file handle is 0x0000000000000810.  The offset of the latest long I/O is: 0x00000362af8000

(7) База живая

(9)[Запрос не был выполнен из-за ошибки ввода/вывода на устройстве.] Проблема с диском какая-то явно, пробовать копировать на другой физический(а в идеале и на другой сервак) и там уже реанимировать.

(9) Живая. Но не вся.

(10) Есть ненулевая вероятность, что после детача приаттачить не сможет.

(9) Как вариант, создавать копию (по структуре) базы, скриптами, и туда потаблично, скриптами же, копировать.
Ну или для начала скриптом почитать все таблички, чтоб узнать, на чем заткнется...

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

(9) RAID со SPARE? Похоже на восстановление данных прибитом диске (проверь через мониторинг)
Как вариант - погоди до восстановления целостности RAID (сервак выведи из работы, дабы не повалили БД окончательно)
Но тут есть опасность, если выйдет из строя ещё один диск - уже ничего не поможет. Имеет смысл запустить копирование физических файлов

(14) Если аттачится нормально, то детачь, копируй к заначку (хоть какая, но копия), аттачь и читай все таблички.
зы. что значит "простое копирование не помогает"? чему не помогает?

(16) застревает процесс на 4% и уходит в бесконечность.

а в xml база выгружается?

(18) увы нет.

(18) вытаскивай по частям, то, что цело

(17) диск посыпался. Рейд поди еще ?

(17) ну так бы и написал, что "не копируется".
тогда см (10)(15)(21), ну и (20)(13)