有没有人知道有哪些工具可以帮助恢复丢弃的表和存储过程?
没有进行备份,并且此DB意外地与另一个DB同步,并且删除了在此DB中创建的新表。
感谢
答案 0 :(得分:8)
如果数据库处于完全恢复模式并且事务日志备份或事务日志从未被截断,您可以尝试使用第三方日志阅读器,例如ApexSQL Log或SQL Log Rescue(免费但是sql server 2000只)。
读取事务日志的其他选项没有很好地记录功能DBCC LOG。
如果存在完整的事务链,则意味着针对此表执行的先前CREATE或ALTER表仍在某个事务日志中。不幸的是,如果您的交易日志非常大,特别是没有第三方工具,那么找到这些信息并不是一件容易的事。
答案 1 :(得分:7)
您也可以从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'
答案 2 :(得分:4)
我用google搜索“sql server restore drop table”,并提出了一个有用的论坛答案。
http://www.eggheadcafe.com/community/aspnet/13/11519/are-you-sure-you-dont-ha.aspx
“在SQL Server中创建数据库时,默认情况下会将其设置为”完全备份“。因此,通过还原事务备份可以使用表。尝试通过右键单击”恢复数据库“选项企业管理器中的数据库名称,然后选择“所有任务”。“
我确实怀疑这是否会恢复表格或仅恢复数据。
RedGate有一些相当低成本的软件称为“SQL Log Rescue”,它可以帮助解决这个问题。查看此SQL Server Central文章: http://www.sqlservercentral.com/articles/Product+Reviews/sqlrescuereview/2086/
编辑:RedGate软件确实需要完整备份,因此无济于事。我抓住了。
但是,事务日志可能会帮助您恢复表结构,即使它实际上无法恢复表本身。
答案 3 :(得分:3)
您的数据库在哪个恢复模型中?
简短回答: 没有备份,您丢失了数据。这就是备份的重点。
答案很长: 如果恢复模型已满,并且您从未进行完整备份,则它实际上是在简单恢复模型中运行。这意味着您无法进行事务日志备份,更糟糕的是:您的事务日志在每个检查点都被截断。这意味着即使您的被删除的表位于事务日志中,它现在几乎肯定会被更新的事务覆盖并永远丢失。没有工具可以帮助你。
如果您了解sql db结构的内部结构,您可以使用DBCC PAGE进行取证,并希望这些范围尚未被其他对象数据覆盖,但这需要真正的专业知识 - 您可以雇用一个。您还可以使用fn_dblog()检查表的事务日志记录是否已被覆盖(可能是)。有服务器端跟踪,您可以使用它来确定删除表的确切时间。
底线:拥有自动备份至关重要。只有完全恢复模型才能启用时间点恢复,您可以使用该恢复将表恢复到drop命令之前的某个点。
答案 4 :(得分:3)
这对我有用:
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'