Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
Доброе утро, коллеги!
Прошу не судить строго, это мой первый пост про sql. Ранее дело с базами не имел... А тут упала база, настроенная до меня, а я расхлебываю...
Дело было так:
в пятницу упал сервер, на котором крутился SQL. После загрузки - рабочая база стала подозрительной. Почитал и попробовал инструкции по проверки и восстановлению, а также переводу базы в emergency и однопользовательский режимы. Ничего не помогло. По совету "знающего" перевел базу в автономный режим и отсоединил, переименовал и хотел подключить. При подключении выдал ошибку:
+
"ЗАГОЛОВОК: Microsoft SQL Server Management Studio
------------------------------

Действие Присоединить базу данных завершилось неудачно для объекта "Сервер" "SERVER". (Microsoft.SqlServer.Smo)

Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft SQL Server&ProdVer=10.50.1600.1 ((KJ_RTM).100402-1539 )&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Присоединить базу данных Server&LinkId=20476

------------------------------
ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ:

При выполнении инструкции или пакета Transact-SQL возникло исключение. (Microsoft.SqlServer.ConnectionInfo)

------------------------------

Возможно, файл "c:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\base.mdf" был усечен операционной системой. Ожидаемый размер составляет 1750592 КБ, однако реальный размер - 1748544 КБ.
Невозможно открыть новую базу данных "base". Операция CREATE DATABASE прервана. (Microsoft SQL Server, ошибка: 5125)

Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft SQL Server&EvtSrc=MSSQLServer&EvtID=5125&LinkId=20476

------------------------------
КНОПКИ:

ОК
------------------------------


Про ошибку (Microsoft SQL Server, ошибка: 5125) толком ничего не пишут...
Прошу помощи новичку.
Заранее спасибо!
20 апр 15, 09:51    [17537677]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
stavgreengo
Member

Откуда:
Сообщений: 710
1. знающий на поверку оказался малознающий, никогда нельзя деаттачить подозрительные базы или перезапускать инстанс
2. только из бэкапа восстанавливаться, больше без вариантов
20 апр 15, 10:01    [17537746]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 21241
pvderby
Возможно, файл "c:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\base.mdf" был усечен операционной системой. Ожидаемый размер составляет 1750592 КБ, однако реальный размер - 1748544 КБ.
Это - разрушение, относящееся к классу фатальных. Какой кретин включил на сервере БД автопроверку файловой системы, да ещё с автолечением???

Восстанавливайся из бэкапа.
20 апр 15, 10:04    [17537767]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
o-o
Guest
и бэкапа нет?

у вас была присоединенная SUSPECTED база,
а теперь она еще и отдетачена.
т.е. никакой возможности попробовать REPAIR_ALLOW_DATA_LOSS.
когда проблемы с файлом лога, еще есть workaround, но у вас именно файл данных.
это ппц.
20 апр 15, 10:08    [17537786]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
o-o
и бэкапа нет?

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

бэкап 2-ух недельной давности. Как же печально-то.
20 апр 15, 10:32    [17537928]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
А что будет если создать новую БД с таким же названием, дальше остановить сервер и подменить mdf?

Я не советую, просто интересно, что произойдет.
20 апр 15, 11:56    [17538512]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
churupaha
Member

Откуда: Краснодар
Сообщений: 1015
Gviber
А что будет если создать новую БД с таким же названием, дальше остановить сервер и подменить mdf?

Я не советую, просто интересно, что произойдет.


все будет норм. главное чтобы логические имена и порядковый номер совпадали. это называется hack attach. подробнее у рандала.
20 апр 15, 11:59    [17538536]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
o-o
Guest
churupaha
Gviber
А что будет если создать новую БД с таким же названием, дальше остановить сервер и подменить mdf?

Я не советую, просто интересно, что произойдет.


все будет норм. главное чтобы логические имена и порядковый номер совпадали. это называется hack attach. подробнее у рандала.

по идее же, вернется в состояние как и было с присоединенной SUSPECTED базой.
только если подумать, то толку все равно 0, в EMERGENCY не перейдет.
одно дело не накатывать проблемный лог,
другое дело иметь все тот же обрезанный mdf.
так что какой уж "норм"...
20 апр 15, 12:12    [17538607]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Т.е. если так сделать и попытаться выполнить:

EXEC sp_resetstatus 'BD'; GO
ALTER DATABASE [BD] SET EMERGENCY GO
ALTER DATABASE [BD] SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO
DBCC CHECKDB ('BD', REPAIR_ALLOW_DATA_LOSS) GO
ALTER DATABASE [BD] SET MULTI_USER GO


Будет ошибка на втором шаге?
20 апр 15, 12:23    [17538695]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
o-o
Guest
Gviber
Т.е. если так сделать и попытаться выполнить:

EXEC sp_resetstatus 'BD'; GO
ALTER DATABASE [BD] SET EMERGENCY GO
ALTER DATABASE [BD] SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO
DBCC CHECKDB ('BD', REPAIR_ALLOW_DATA_LOSS) GO
ALTER DATABASE [BD] SET MULTI_USER GO


Будет ошибка на втором шаге?


что это за первое sp_resetstatus, не знаю, пишут оно deprecated.
на втором шаге у меня урезанная база в EMERGENCY перешла,
на третьем тоже в SINGLE_USER перевелась.
только все равно файл .mdf мной лично обрезан,
dbcc checkdb (Gviber, REPAIR_ALLOW_DATA_LOSS)

выдает
Msg 5028, Level 16, State 4, Line 1
The system could not activate enough of the database to rebuild the log.
DBCC results for 'Gviber '.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'Gviber '.
Msg 7909, Level 20, State 1, Line 1
The emergency-mode repair failed.You must restore from backup.


после чего она снова переходит в suspected
20 апр 15, 13:02    [17538950]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Занятно размер не совпадает 1750592-1748544 = 2048 = ровно 2мб. Как будто авторасширение mdf сработало, но значение размера внутри файла осталось старое. Интересно как такое правильное значение получилось?
20 апр 15, 13:47    [17539349]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Может это ([тут невинный взгляд и глаза как у кота]), если ничего не поможет, отрезать в конце файла два мб? Ради эксперимента =)
20 апр 15, 13:59    [17539455]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 53696
Gviber
Занятно размер не совпадает 1750592-1748544 = 2048 = ровно 2мб. Как будто авторасширение mdf сработало, но значение размера внутри файла осталось старое. Интересно как такое правильное значение получилось?

NTFS - журналируемая ФС. Расширение файла долго не писалось на диск и после сбоя питания - откатилось. Это подколка, известная ещё с прошлого столетия.
20 апр 15, 14:06    [17539523]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Dimitry Sibiryakov,

Я правильно себе это представляю: sql server подготовил 2мб (с нужными page+check sum ит.п.) передал их NTFS для дополнения файла mdf, но в этот момент произошел сбой?

Или данные все же были записаны, но потом каким-то образом файл стал меньше?
20 апр 15, 14:42    [17539881]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
Gviber,

Gviber
Т.е. если так сделать и попытаться выполнить:

EXEC sp_resetstatus 'BD'; GO
ALTER DATABASE [BD] SET EMERGENCY GO
ALTER DATABASE [BD] SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO
DBCC CHECKDB ('BD', REPAIR_ALLOW_DATA_LOSS) GO
ALTER DATABASE [BD] SET MULTI_USER GO


Будет ошибка на втором шаге?


Создал новую базу, заменил оба файла:
дохожу до 3 пункта и такая же ситуация:

o-o
dbcc checkdb (Gviber, REPAIR_ALLOW_DATA_LOSS)

выдает
Msg 5028, Level 16, State 4, Line 1
The system could not activate enough of the database to rebuild the log.
DBCC results for 'Gviber '.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'Gviber '.



Тольуо у меня второе сообщение в конце выдает:
Сообщение 926, уровень 14, состояние 1, строка 1
Database 'testovaya' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
20 апр 15, 14:52    [17539983]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Я в этом ничего не понимаю.

Но у вас БД названа testovay - т.е. скорее всего название не оригинальное.

https://www.sql.ru/forum/796864/ispravlenie-bd-posle-togo-kak-ushla-v-rezhim-suspect
автор
1. Создайте новую бд с тем же имененм и расположением файлов;
2. Остановите службу сервера;
3. Подмените файлы теми, которые пытаетесь аттачить.
4. Запустите службу сервера;
5. Попробуйте перевести бд в EMERGENY

Если получится - вытаскивайте что-сможете (скрипты на объекты, данные).


Там и скрипт есть другой:
автор
Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
alter database имябазы set EMERGENCY, SINGLE_USER
go
DBCC checkdb('имябазы')
go

DBCC checkdb('имябазы', REPAIR_ALLOW_DATA_LOSS)
go

alter database имябазы set ONLINE, MULTI_USER
Go

sp_configure 'allow updates', 0
reconfigure with override
go
20 апр 15, 15:03    [17540073]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
o-o
Guest
pvderby
Тольуо у меня второе сообщение в конце выдает:
Сообщение 926, уровень 14, состояние 1, строка 1
Database 'testovaya' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.

такое выдает, если она уже снова в SUSPECT.
заново ее в EMERGENCY и SINGLE_USER переведите, мое сообщение выпадет
20 апр 15, 15:06    [17540091]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
o-o
Guest
Gviber
Там и скрипт есть другой:
автор
Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
alter database имябазы set EMERGENCY, SINGLE_USER
go
DBCC checkdb('имябазы')
go

DBCC checkdb('имябазы', REPAIR_ALLOW_DATA_LOSS)
go

alter database имябазы set ONLINE, MULTI_USER
Go

sp_configure 'allow updates', 0
reconfigure with override
go

что здесь другого, интересно?
в EMERGENCY, SINGLE_USER для проведения DBCC checkdb('имябазы', REPAIR_ALLOW_DATA_LOSS).
+ у меня точно правильное название. с вас скопировано :)

allow updates???
мы разве 2000-ый обсуждаем?
какое тогда еще EMERGENCY, его же не было?
а раз есть, то сервер версии не ниже 2005, а тогда allow updates фиолетово
20 апр 15, 15:16    [17540165]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
pvderby,

use master
GO
ALTER DATABASE [testovaya] SET EMERGENCY
GO
ALTER DATABASE [testovaya] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKDB ('testovaya', REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE [testovaya] SET MULTI_USER
GO

Попробуйте выполнить этот скрипт, какой результат? Естественно это нужно запускать от пользователя с полными правами (например sa)

Если будет ошибка примерно такая: 5028 + 7909 то БД уже не восстановить.

Но можно попробовать выполнить только одну команду:
ALTER DATABASE [testovaya] SET EMERGENCY

Тогда БД перейдет в аварийный режим и часть данных можно будет прочитать.

Я сейчас воссоздал ваш сценарий: БД у меня восстановить не получилось. Но в режиме EMERGENCY часть данных прочиталось. Но у меня БД была 15 мб, при этом удалил из нее 1мб (т.е. у вас больше шансов на успех ) + файл лога я не подключал (удалил ldf даже у вновь созданной БД).
20 апр 15, 17:29    [17541054]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Название БД и путей можно не воссоздавать.

Проверял так:
1. Создал пустую БД с другим названием
2. Остановил сервер
3. На место новой mdf подсунул от поломанной БД + удалил ldf.
4. Включил, но изменений не заметил: аналогичное поведение при попытке восстановить и при попытке прочитать БД в режиме EMERGENCY
20 апр 15, 17:53    [17541149]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
Gviber
Member

Откуда:
Сообщений: 124
Провел эксперименты с размером БД:
1. Увеличиваем размер. Если мы открываем файл mdf через HEX редактор и дописываем его 0000 (на любой размер хоть на 100 мб) то при запуске сервера он это нормально обрабатывает и просто уменьшает размер mdf до FileSize.
2. Уменьшаем размер. В конце файлов mdf во всех БД полно 0000 т.е. там нет никаких страниц с checksum (просто 0000 - притом много). Если удалить эти 0000 и запустить сервер, то БД переведется в режим Suspect.
Но интересно то, что если попытаться сделать:
DBCC CHECKDB ('test', REPAIR_ALLOW_DATA_LOSS) -- он выдает ошибки 5028 + 7909
Т.е. хоть мы ничего серьезного не удаляли (там были одни 0000 и страниц с данными там не было) он все равно не смог восстановить БД.

Автор, попробуй дописать файл 0000 через HEX редактор до любого размера который больше FileSize, есть вероятность, что все взлетит.
20 апр 15, 20:59    [17541572]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
use master
GO
ALTER DATABASE [testovaya] SET EMERGENCY
GO
ALTER DATABASE [testovaya] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKDB ('testovaya', REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE [testovaya] SET MULTI_USER
GO


Вывод следующий:
+
Сообщение 5028, уровень 16, состояние 4, строка 1
The system could not activate enough of the database to rebuild the log.
DBCC results for 'work_base'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'work_base'.
Сообщение 926, уровень 14, состояние 1, строка 1
Database 'work_base' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
Сообщение 926, уровень 14, состояние 1, строка 1
Database 'work_base' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
Сообщение 5069, уровень 16, состояние 1, строка 1
ALTER DATABASE statement failed.
Сообщение 926, уровень 14, состояние 1, строка 1
Database 'work_base' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
Сообщение 5069, уровень 16, состояние 1, строка 1
ALTER DATABASE statement failed.
Сообщение 5125, уровень 24, состояние 2, строка 1
File 'c:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\work_base.mdf' appears to have been truncated by the operating system. Expected size is 1750592 KB but actual size is 1748544 KB.
Сообщение 3414, уровень 21, состояние 1, строка 1
An error occurred during recovery, preventing the database 'work_base' (database ID 7) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
21 апр 15, 00:51    [17542023]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
Gviber
Провел эксперименты с размером БД:
1. Увеличиваем размер. Если мы открываем файл mdf через HEX редактор и дописываем его 0000 (на любой размер хоть на 100 мб) то при запуске сервера он это нормально обрабатывает и просто уменьшает размер mdf до FileSize.
2. Уменьшаем размер. В конце файлов mdf во всех БД полно 0000 т.е. там нет никаких страниц с checksum (просто 0000 - притом много). Если удалить эти 0000 и запустить сервер, то БД переведется в режим Suspect.
Но интересно то, что если попытаться сделать:
DBCC CHECKDB ('test', REPAIR_ALLOW_DATA_LOSS) -- он выдает ошибки 5028 + 7909
Т.е. хоть мы ничего серьезного не удаляли (там были одни 0000 и страниц с данными там не было) он все равно не смог восстановить БД.

Автор, попробуй дописать файл 0000 через HEX редактор до любого размера который больше FileSize, есть вероятность, что все взлетит.


Дописал 200 Мб, при первом запуске скрипта
DBCC CHECKDB ('work_base' REPAIR_ALLOW_DATA_LOSS)
вылетело много ошибок

второй раз ошибок намного меньше и следующий вывод:

+
Сообщение 2510, уровень 16, состояние 17, строка 1
DBCC checkdb error: This system table index cannot be recreated.
Сообщение 259, уровень 16, состояние 1, строка 1
Ad hoc updates to system catalogs are not allowed.
Сообщение 608, уровень 16, состояние 1, строка 1
No catalog entry found for partition ID 562949957025792 in database 7. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption.
Сообщение 259, уровень 16, состояние 1, строка 1
Ad hoc updates to system catalogs are not allowed.
Сообщение 608, уровень 16, состояние 1, строка 1
No catalog entry found for partition ID 562949957025792 in database 7. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption.
DBCC results for 'work_base'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.


Я не понял как, но после трех проверок - к ней появился доступ, теперь в программу не пускает отсутствие лицензии из-за яко бы новой базы. Завтра на работе посмотрю) Буду надеяться, что всё получилось.
21 апр 15, 02:02    [17542050]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
angel_zar
Member

Откуда: Барнаул
Сообщений: 902
Только сперва прочитайте про параметр REPAIR_ALLOW_DATA_LOSS
А то потом долго удивляться будете, что где то что то пропало. Может проще БэкАп 2х недельной давности накатить.
21 апр 15, 08:32    [17542193]     Ответить | Цитировать Сообщить модератору
 Re: Присоединение подозрительной базы  [new]
pvderby
Member

Откуда:
Сообщений: 7
angel_zar
Только сперва прочитайте про параметр REPAIR_ALLOW_DATA_LOSS
А то потом долго удивляться будете, что где то что то пропало. Может проще БэкАп 2х недельной давности накатить.


Самое главное, чтобы осталась определенная информация. Если она осталась - то хорошо, если нет - то откат будем делать.

Жду пока лицензия придет. Как перед сдачей экзамена... Сижу как на иголках.
21 апр 15, 08:46    [17542230]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить