ERP係統全國統一谘詢熱線:400-186-6556/業務專線:180 2468 7814
4問題解答
您的位置: 首页 ->  問題解答 -> 如何修複損壞的資料庫

如何修複損壞的資料庫


任何數據庫係統都無法避免崩潰的狀況,即使你使用了Clustered,雙機熱備……仍然無法完全根除係統中的單點故障,何況對於大部分用戶來說,無法承受這樣昂貴的硬件投資。所以,在係統崩潰的時候,如何恢複原有的寶貴數據就成為一個極其重要的問題了。

在恢複的時候,最理想的情況就是你的數據文件和日誌文件都完好無損了,這樣隻需要sp_attach_db,把數據文件附加到新的數據庫上即可,或者在停機的時候把所有數據文件(一定要有master等)都copy到原有路徑下也行,不過一般不推薦這樣的做法,sp_attach_db比較好,雖然麻煩許多。

但是呢,一般數據庫崩潰的時候係統是未必能有時間把未完成的事務和髒頁等寫入磁盤的,這樣的情況sp_attach_db就會失敗。那麼,寄期望於DBA製定了一個良好的災難恢複計劃吧。按照你的恢複計劃,還原最新的完全備份,增量備份或者事務日誌備份,然後如果你的活動事務日誌還能讀得出來的話,恭喜你!你可以還原到崩潰前的狀態。

一般的單位都是沒有專職的DBA的,如果沒有可用的備份,更可能是最近一次備份的時間過於久遠而導致不可接受的數據損失,而且你的活動事務日誌也處於不可用的狀態,那就是最麻煩的情況了。

不幸的很的是,一般數據庫崩潰都是由於存儲子係統引起的,而這樣的情況是幾乎不可能有可用的日誌用於恢複的。那麼就隻好試一下這些方案了。當然,是要求至少你的數據文件是存在的,要是數據文件、日誌文件和備份都沒有了的話,別找我,你可以到樓頂上去唱“神啊,救救我吧”。

首先,你可以試一下sp_attach_single_file_db,試著恢複一下你的數據文件,雖然能恢複的可能性不大,不過假如這個數據庫剛好執行了一個checkpoint的話,還是有可能成功的。

如果你沒有好到有摸彩票的手氣,最重要的數據庫沒有像你期盼的那樣attach上去,不要氣餒,還是有別的方案的。

我們可以試著重新建立一個log,先把數據庫設置為emergency mode,sysdatabases的status為32768 就表示數據庫處於此狀態。不過係統表是不能隨便改的,設置一下先

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

然後

update sysdatabases set status = 32768 where name = ''

現在,祈求滿天神佛的保佑吧,重新建立一個log文件。成功的機會還是相當大的,係統一般都會認可你新建立的日誌。如果沒有報告什麼錯誤,現在就可以鬆一口氣了。

雖然數據是恢複了,可是別以為事情就算完成了,正在進行的事務肯定是丟失了,原來的數據也可能受到一些損壞。

先把SQL Server 重新啟動一下,然後檢查你的數據庫吧。

先設置成單用戶模式,然後做dbcc

sp_dboption '', 'single user', 'true'

DBCC CHECKDB('')

如果沒有什麼大問題就可以把數據庫狀態改回去了,記得別忘了把係統表的修改選項關掉。

update sysdatabases set status = 28 where name = '' --當然你的數據庫狀態可能不是這個,自己改為合適的值吧。也可以用sp_resetstatus

go

sp_configure 'allow updates', 0

reconfigure with override

Go

checkdb的時候可能報告有一些錯誤,這些錯誤的數據你可能就隻好丟棄了。

checkdb有幾種修複選項,自己看著用吧,不過最後你可能還是得用REPAIR_ALLOW_DATA_LOSS,完成所有修複。

chekcdb並不能完成所有的修複,我們需要更進一步的修複,用DBCC CHECKTABLE對每一個表做檢查吧。

表的列表可以用sysobjects裏麵得到,把OBJECTPROPERTY是IsTable的全部找出來檢查一下吧,這樣能夠基本上解決問題了,如果還報告錯誤,試著把數據select into到另一張表檢查一下。這些都做完了之後,把所有索引、視圖、存儲過程、觸發器等重新建立一下。DBCC DBREINDEX也許可以幫你一些忙。

陝西統率資訊有限公司 Copyright © 2018 版權所有 [BMAP] [GMAP] [後臺管理] 訪問量:
ERP系統,財務進銷存軟件,製造業ERP,雲ERP,東莞ERP軟件
手機網站手機網站 公眾號公眾號