The information in this article applies to:
|
- Microsoft SQL Server 7.0,2000
|
?
?
?
數據庫日志文件丟失時的恢復步驟
Revision History:
Version
|
Date
|
Creator
|
Description
|
1.0.0.1 |
2003-3-25 |
鄭昀 |
草稿 |
?
|
?
|
?
|
?
|
Implementation Scope :
本文是用于向
Microsoft SQL Server
維護人員描述我誤刪除了數據庫的事務日志文件
(.ldf)之后,如何經過各種嘗試,重新恢復數據庫的。
本文面向的讀者是數據庫維護人員。
Disclaimers :
本文檔所包含的信息代表了在發布之日,
鄭昀
對所討論問題的當前看法。
鄭昀
不保證所給信息在發布之日以后的準確性。
本文檔僅供參考。
用戶必須遵守所有適用的版權法。在不對版權法所規定的權利加以限制的情況下,如未得到
鄭昀
明確的書面許可,不得出于任何目的、以任何形式或手段(電子的、機械的、影印、錄制等等)復制、傳播本文的任何部分,也不得將其存儲或引入到檢索系統中。
繼續閱讀之前,我們假設您熟悉以下知識:
n
????????
Microsoft SQL Server
關鍵詞:
Emergency Mode
、
DBCC CHECKDB
、
DTS
參考資料清單:
名稱
|
作者
|
編號
|
發布日期
|
《 當 SQL Server 數據庫崩潰時如何恢復? 》 |
怡紅公子
|
?
|
?
|
《 SQL Server 非正常刪除日志文件( ldf )恢復方法 》 |
_Rambo
|
?
|
?
|
事情的起因
昨天,系統管理員告訴我,我們一個內部應用數據庫所在的磁盤空間不足了。我注意到數據庫事件日志文件
XXX_Data.ldf
文件已經增長到了
3GB
,于是我決意縮小這個日志文件。經過收縮數據庫等操作未果后,我犯了一個自進入行業以來的最大最愚蠢的錯誤:竟然誤刪除了這個日志文件!后來我看到所有論及數據庫恢復的文章上都說道:“無論如何都要保證數據庫日志文件存在,它至關重要”,甚至微軟甚至有一篇
KB
文章講如何只靠日志文件恢復數據庫的。我真是不知道我那時候是怎么想的?!
這下子壞了!這個數據庫連不上了,企業管理器在它的旁邊寫著“
(
置疑
)
”。而且最要命的,這個數據庫從來沒有備份了。我唯一找得到的是遷移半年前的另外一個數據庫服務器,應用倒是能用了,但是少了許多記錄、表和存儲過程。真希望這只是一場噩夢!
沒有效果的恢復步驟
附加數據庫
_Rambo
講過被刪除日志文件中不存在活動日志時,可以這么做來恢復:
1
,分離被置疑的數據庫,可以使用
sp_detach_db
2
,附加數據庫,可以使用
sp_attach_single_file_db
但是,很遺憾,執行之后,
SQL Server
質疑數據文件和日志文件不符,所以無法附加數據庫數據文件。
DTS
數據導出
不行,無法讀取
XXX
數據庫,
DTS Wizard
報告說“初始化上下文發生錯誤”。
緊急模式
怡紅公子
講過沒
有日志用于恢復
時,可以這么做:
1,
把數據庫設置為
emergency mode
2,
重新建立一個
log
文件
3, 把 SQL Server 重新啟動一下
4, 把應用數據庫設置成單用戶模式
5, 做 DBCC CHECKDB
6, 如果沒有什么大問題就可以把數據庫狀態改回去了,記得別忘了把系統表的修改選項關掉
?
我實踐了一下,把應用數據庫的數據文件移走,重新建立一個同名的數據庫
XXX
,然后停掉
SQL
服務,把原來的數據文件再覆蓋回來。之后,按照
怡紅公子的步驟走。
但是,也很遺憾,除了第
2
步之外,其他步驟執行非常成功。可惜,重啟
SQL Server
之后,這個應用數據庫仍然是置疑
!
不過,讓我欣慰的是,這么做之后,倒是能夠
Select
數據了,讓我大出一口氣。只不過,組件使用數據庫時,報告說:“發生錯誤:
-2147467259,
未能在數據庫
'XXX'
中運行
BEGIN TRANSACTION
,因為該數據庫處于回避恢復模式?!?
?
最終成功恢復的全部步驟
設置數據庫為緊急模式
ü
????????
停掉
SQL Server
服務;
ü
????????
把應用數據庫的數據文件
XXX_Data.mdf
移走;
ü
????????
重新建立一個同名的數據庫
XXX
;
ü
????????
停掉
SQL
服務;
ü
????????
把原來的數據文件再覆蓋回來;
ü
????????
運行以下語句,把該數據庫設置為緊急模式;
?
??
運行
“Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go”
執行結果:
DBCC
執行完畢。如果
DBCC
輸出了錯誤信息,請與系統管理員聯系。
已將配置選項
'allow updates'
從
0
改為
1
。請運行
RECONFIGURE
語句以安裝。
?
接著運行
“update sysdatabases set status = 32768 where name = 'XXX'”
執行結果:
(所影響的行數為
1
行)
?
ü
????????
重啟
SQL Server
服務;
ü
????????
運行以下語句,把應用數據庫設置為
Single User
模式;
?????
運行
“sp_dboption 'XXX', 'single user', 'true'”
執行結果:
?????
命令已成功完成。
?
ü
????????
做
DBCC CHECKDB
;
?????
運行
“DBCC CHECKDB('XXX')”
執行結果:
'XXX'
的
DBCC
結果。
'sysobjects'
的
DBCC
結果。
對象
'sysobjects'
有
273
行,這些行位于
5
頁中。
'sysindexes'
的
DBCC
結果。
對象
'sysindexes'
有
202
行,這些行位于
7
頁中。
'syscolumns'
的
DBCC
結果。
………
?
ü
????????
運行以下語句把系統表的修改選項關掉;
?????
運行
“sp_resetstatus "XXX"
go
sp_configure 'allow updates', 0
reconfigure with override
Go”
執行結果:
在
sysdatabases
中更新數據庫
'XXX'
的條目之前,模式
= 0
,狀態
= 28
(狀態
suspect_bit = 0
),
沒有更新
sysdatabases
中的任何行,因為已正確地重置了模式和狀態。沒有錯誤,未進行任何更改。
DBCC
執行完畢。如果
DBCC
輸出了錯誤信息,請與系統管理員聯系。
已將配置選項
'allow updates'
從
1
改為
0
。請運行
RECONFIGURE
語句以安裝。
?
ü
????????
重新建立另外一個數據庫
XXX.Lost
;
DTS
導出向導
ü
????????
運行
DTS
導出向導;
ü
????????
復制源選擇
EmergencyMode
的數據庫
XXX
,導入到
XXX.Lost
;
ü
????????
選擇“在
SQL Server
數據庫之間復制對象和數據”,試了多次,好像不行,只是復制過來了所有表結構,但是沒有數據,也沒有視圖和存儲過程,而且
DTS
向導最后報告復制失?。?
ü
????????
所以最后選擇“從源數據庫復制表和視圖”,但是后來發現,這樣總是只能復制一部分表記錄;
ü
????????
于是選擇“用一條查詢指定要傳輸的數據”,缺哪個表記錄,就導哪個;
ü
????????
視圖和存儲過程是執行
SQL
語句添加的。
?
?? 這樣, XXX.Lost 數據庫就可以替換原來的應用數據庫了。
?
Written by zhengyun@tomosoft.com
?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=12715
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
