Восстановление удаленных объектов с сервера SQL

Question

Кто-нибудь знает какие-либо инструменты, которые могут помочь в восстановлении удаленных таблиц и хранимых процедур?

Резервное копирование не производилось, и эта БД была случайно синхронизирована с другой БД, и новые таблицы, созданные в этой БД, были удалены.

спасибо

Answer 1

Если база данных находилась в режиме полного восстановления и имеются резервные копии журнала транзакций или журнал транзакций никогда не урезался, вы можете попробовать использовать стороннее средство чтения журналов, такое как ApexSQL Log или SQL Log Rescue (бесплатно, но только SQL Server 2000).

Другой вариант чтения журнала транзакций - не так хорошо документированная функция DBCC LOG.

Если существует полная цепочка транзакций, это означает, что предыдущая таблица CREATE или ALTER, которая была выполнена для этой таблицы, все еще где-то находится в журнале транзакций. К сожалению, найти эту информацию непросто, если ваш журнал транзакций очень большой, особенно без сторонних инструментов.

Answer 2

Вы также можете восстановить удаленный объект из журнала SQL Server, если у вас нет резервной копии.

Select Convert(varchar(Max),Substring([RowLog Contents 0]
,33
,LEN([RowLog Contents 0]))) as [Script]
from fn_dblog(NULL,NULL)
Where [Operation]='LOP_DELETE_ROWS' And [Context]='LCX_MARK_AS_GHOST'
And [AllocUnitName]='sys.sysobjvalues.clst'

Ссылка: http://raresql.com/2012/12/04/sql-server-recover-the-dropped-objects-view-stored-procedure-function-trigger/

Answer 3

Я погуглил "таблица удаленных восстановлений сервера sql" и нашел полезный ответ на форуме.

http://www.eggheadcafe.com/community/aspnet/13/11519/are-you-sure-you-dont-ha.aspx

"Когда база данных создается в SQL Server, по умолчанию устанавливается полное резервное копирование. Таким образом, ваша таблица должна быть доступна после восстановления резервной копии транзакции. Попробуйте перейти к параметрам« восстановить базу данных », щелкнув правой кнопкой мыши имя базы данных в Enterprise Manager и выбор всех задач. "

Я спрашиваю, восстановит ли это таблицу или только данные.

Существует довольно дешевое программное обеспечение от RedGate, которое называется «SQL Log Rescue», которое должно помочь в этом. Проверьте эту статью SQL Server Central: http://www.sqlservercentral.com/articles/Product+Reviews/sqlrescuereview/2086/

РЕДАКТИРОВАТЬ: программное обеспечение RedGate требует полного резервного копирования, так что это не поможет. Я только что поймал это.

Но, возможно, журнал транзакций поможет вам восстановить структуры таблиц, даже если он на самом деле не может восстановить саму таблицу.

Answer 4

Это сработало для меня:

Select Convert(varchar(Max), Substring([RowLog Contents 0]
, 33
, LEN([RowLog Contents 0]))) as [Script]
from fn_dblog(NULL, NULL)
Where [Operation] = 'LOP_DELETE_ROWS' And [Context] = 'LCX_MARK_AS_GHOST'
And [AllocUnitName] = 'sys.sysobjvalues.clst'

Answer 5

В какой модели восстановления ваш БД?

Краткий ответ: Без резервной копии вы потеряли свои данные. В этом весь смысл резервного копирования.

Длинный ответ: Если модель восстановления ПОЛНАЯ, и вы никогда не делали полную резервную копию, она фактически работает так же, как и в простой модели восстановления. Это означает, что вы не можете сделать резервную копию журнала транзакций, и что еще хуже: ваш журнал транзакций усекается на каждой контрольной точке. Это означает, что даже если ваша удаленная таблица была в журнале транзакций, она почти наверняка перезаписывается новыми транзакциями и теряется навсегда. Там вам не помогут никакие инструменты.

Если вы знакомы с внутренними структурами sql db, вы можете провести экспертизу с DBCC PAGE и надеяться, что эти экстенты еще не перезаписаны данными других объектов, но для этого нужны настоящие экспертные знания - вы можете нанять их. Вы также можете проверить, не перезаписаны ли записи журнала транзакций вашей таблицы (вероятно, есть) с помощью fn_dblog (). Существует трассировка на стороне сервера, которую можно использовать для определения точного времени удаления таблицы.

Итог: автоматическое резервное копирование имеет важное значение. Только модель полного восстановления обеспечивает восстановление на определенный момент времени, которое можно использовать для восстановления таблицы до точки непосредственно перед командой сброса.