|
Восстановление базы в SQL ansh15, PR, Tarlich, ptiz, Double_Medved, DiMel_77, BSV, trad, Fedor-1971, wolk, zzz_zzz_zzz, shuhard, Страждущий
| ☑ | ||
|---|---|---|---|---|
|
0
Meladonimi
17.02.26
✎
13:35
|
Добрый день, вопрос касательно серверной базы и 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 так же база крайне не охотно выходит из однопользовательского режима. |
|||
|
1
АгентБезопасной Нацио
17.02.26
✎
13:43
|
Что в логах-то? При бэкапе...
|
|||
|
2
Ёпрст
гуру
17.02.26
✎
13:45
|
>>>REPAIR_ALLOW_DATA_LOSS
вот так сразу шашкой махать не стоит |
|||
|
3
Ёпрст
гуру
17.02.26
✎
13:45
|
Диск поди посыпался, где mdf лежит, да ?
|
|||
|
4
АгентБезопасной Нацио
17.02.26
✎
13:50
|
(2) если бэкап 22 года, то можно и "дата лосс". Не так уж и нужна базёнка...
|
|||
|
5
АгентБезопасной Нацио
17.02.26
✎
13:50
|
(3) дык этта, логи читать надоть...
|
|||
|
6
Ёпрст
гуру
17.02.26
✎
13:51
|
(4) ну, хотя бы детатач и копи мдф/лдф куда нить в сторонку.
|
|||
|
7
Ёпрст
гуру
17.02.26
✎
13:51
|
так и эту недолго прое.. если она еще вообще живая.
|
|||
|
8
АгентБезопасной Нацио
17.02.26
✎
13:54
|
(6) Это святое. вопрос, пройдет ли потом аттач..
|
|||
|
9
Meladonimi
17.02.26
✎
13:57
|
(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) База живая |
|||
|
10
Сергиус
17.02.26
✎
14:02
|
(9)[Запрос не был выполнен из-за ошибки ввода/вывода на устройстве.] Проблема с диском какая-то явно, пробовать копировать на другой физический(а в идеале и на другой сервак) и там уже реанимировать.
|
|||
|
11
АгентБезопасной Нацио
17.02.26
✎
14:10
|
(9) Живая. Но не вся.
|
|||
|
12
АгентБезопасной Нацио
17.02.26
✎
14:11
|
(10) Есть ненулевая вероятность, что после детача приаттачить не сможет.
|
|||
|
13
АгентБезопасной Нацио
17.02.26
✎
14:13
|
(9) Как вариант, создавать копию (по структуре) базы, скриптами, и туда потаблично, скриптами же, копировать.
Ну или для начала скриптом почитать все таблички, чтоб узнать, на чем заткнется... |
|||
|
14
Meladonimi
17.02.26
✎
14:13
|
(10) Присоединение к базе идет нормально.
(9) Благодарю, хоть и простое копирование базы не помогает, но теперь буду знать куда точно копать. |
|||
|
15
Fedor-1971
17.02.26
✎
14:15
|
(9) RAID со SPARE? Похоже на восстановление данных прибитом диске (проверь через мониторинг)
Как вариант - погоди до восстановления целостности RAID (сервак выведи из работы, дабы не повалили БД окончательно) Но тут есть опасность, если выйдет из строя ещё один диск - уже ничего не поможет. Имеет смысл запустить копирование физических файлов |
|||
|
16
АгентБезопасной Нацио
17.02.26
✎
14:21
|
(14) Если аттачится нормально, то детачь, копируй к заначку (хоть какая, но копия), аттачь и читай все таблички.
зы. что значит "простое копирование не помогает"? чему не помогает? |
|||
|
17
Meladonimi
17.02.26
✎
14:27
|
(16) застревает процесс на 4% и уходит в бесконечность.
|
|||
|
18
1cVandal
17.02.26
✎
14:38
|
а в xml база выгружается?
|
|||
|
19
Meladonimi
17.02.26
✎
14:54
|
(18) увы нет.
|
|||
|
20
shuhard
17.02.26
✎
15:00
|
(18) вытаскивай по частям, то, что цело
|
|||
|
21
Ёпрст
гуру
17.02.26
✎
15:00
|
(17) диск посыпался. Рейд поди еще ?
|
|||
|
22
АгентБезопасной Нацио
17.02.26
✎
15:13
|
(17) ну так бы и написал, что "не копируется".
тогда см (10)(15)(21), ну и (20)(13) |
|||
|
23
Tarlich
17.02.26
✎
22:56
|
то что бекап 22 - а версии конфигурации одинаковые ? а то может из бекапа когфиг придется копировать
|
|||
|
24
PR
17.02.26
✎
23:42
|
(0) После "данная серверная база не может сделать бэкап как ... простое копирование файла mdf" дальше можно не читать, забей, базы уже нет
|
|||
|
25
PR
17.02.26
✎
23:46
|
+(24) Единственное, что можно пробовать в такой ситуации — это запустить 1С в пользовательском режиме и в режиме конфигуратора
Если запустится в пользовательском режиме, то можно попробовать вытянуть часть данных выгрузкой в XML Если запустится в режиме конфигуратора, можно попробовать поиграться с разными там выгрузками в dt (хотя это уже вряд ли), перезаливками config и пр. Ну еще может SQL помочь со своим DBCC checkdb Но по большому счету пора копать могилку базе и искать бэкап |
| Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |