99久久99久久精品免观看,国产精品久久久久国产精品,国产黄色录像视频,免费的黄色毛片,国产一区精品普通话对白,色妞妞成人在线观看,最新aⅴ福利在线观看免费

綠色資源網(wǎng):您身邊最放心的安全下載站! 最新軟件|熱門排行|軟件分類|軟件專題|廠商大全

綠色資源網(wǎng)

技術(shù)教程
您的位置:首頁數(shù)據(jù)庫類SQL Server → SQL Server數(shù)據(jù)庫損壞檢測以及SQL Server數(shù)據(jù)庫修復(fù)的解決方案

SQL Server數(shù)據(jù)庫損壞檢測以及SQL Server數(shù)據(jù)庫修復(fù)的解決方案

我要評(píng)論 2013/09/22 19:00:21 來源:綠色資源網(wǎng) 編輯:www.siawh.com [ ] 評(píng)論:0 點(diǎn)擊:360次

在一個(gè)理想的世界中,不會(huì)存在任何數(shù)據(jù)庫的損壞,就像我們不會(huì)將一些嚴(yán)重意外情況列入我們生活中的日常一樣,而一旦這類事情發(fā)生,一定會(huì)對(duì)我們的生活造成非常顯著的影響,在SQL Server中也同樣如此,或許幾年內(nèi)您沒有遇見過數(shù)據(jù)庫中出現(xiàn)這類情況,而一旦遇見這類情況,往往伴隨著數(shù)據(jù)的丟失,宕機(jī),嚴(yán)重甚至您本身的職業(yè)生涯也會(huì)受到影響。因此對(duì)于這類情況,我們需要了解數(shù)據(jù)庫損壞方面的知識(shí),以便我們能夠事前準(zhǔn)備,事后能夠處理。本篇文章會(huì)對(duì)數(shù)據(jù)庫損壞的原因、現(xiàn)象、事前和事后的一些處理方法以及簡單的修復(fù)方法進(jìn)行探討。

數(shù)據(jù)庫為什么會(huì)損壞?

在了解數(shù)據(jù)庫損壞之前,首先我們要了解SQL Server是如何將數(shù)據(jù)保存到數(shù)據(jù)文件(MDF、NDF等)。無論更新還是插入數(shù)據(jù),數(shù)據(jù)都需要首先在內(nèi)存中的Buffer Pool駐留,然后通過CheckPoint和Lazy Writer等過程將內(nèi)存中的數(shù)據(jù)持久化到磁盤。在這個(gè)過程中,數(shù)據(jù)臟頁由內(nèi)存寫入持久化的IO子系統(tǒng),在此期間,按照IO子系統(tǒng)的不同,數(shù)據(jù)可能經(jīng)過這幾層:

Windows(寫數(shù)據(jù)一定調(diào)用的是WINDOWS API)

Windows底層的中間層(殺毒軟件,磁盤加密系統(tǒng))

網(wǎng)卡、路由器、交換機(jī)、光釬、網(wǎng)線等(如果IO子系統(tǒng)不是直連的話)

SAN控制器(如果使用了SAN)

RAID控制器(IO子系統(tǒng)做了RAID)

磁盤或SSD等持久化存儲(chǔ)器

因此,數(shù)據(jù)頁被寫入持久化存儲(chǔ)期間,可能經(jīng)過上述列表中的幾項(xiàng)。在經(jīng)歷上述過程中,硬件環(huán)境會(huì)受到很多方面的影響,比如說電壓是否穩(wěn)定、斷電、溫度過高或過低、潮濕程度等,而軟件方面,由于軟件都是人寫的,因此就可能存在BUG,這些都可能導(dǎo)致數(shù)據(jù)頁在傳輸過程中出現(xiàn)錯(cuò)誤。

此外,影響磁盤的因素也包括電壓是否穩(wěn)定、灰塵等因素,這些也有可能引起磁盤壞道或整體損壞。

上面提到的所有因素都可以被歸結(jié)為IO子系統(tǒng)。因此,造成數(shù)據(jù)損壞的情況絕大部分是由IO子系統(tǒng)引起的,還有非常非常小的概率內(nèi)存芯片也會(huì)導(dǎo)致數(shù)據(jù)頁損壞,但這部分情況微乎其微,因此不在本文的討論之列。

上面提到的這些導(dǎo)致數(shù)據(jù)損壞的原因都屬于天災(zāi),還有一些人禍。比如說通過編輯器等手動(dòng)編輯數(shù)據(jù)文件、數(shù)據(jù)庫中還有需要Redo和Undo的事務(wù)時(shí)(也就是沒有Clean Shutdown)刪除了日志文件(通常會(huì)導(dǎo)致數(shù)據(jù)庫質(zhì)疑)。

發(fā)現(xiàn)數(shù)據(jù)庫損壞

在我們知道可能造成數(shù)據(jù)庫的損壞原因之后,接下來我們來看SQL Server是如何監(jiān)測數(shù)據(jù)庫頁損壞的。

在SQL Server的數(shù)據(jù)庫級(jí)別,可以設(shè)置頁保護(hù)類型,一共有三個(gè)選項(xiàng):None,CheckSum,Torn_Page_Detection,如圖1所示:


圖1.頁保護(hù)的三種選項(xiàng)

關(guān)于這三種選項(xiàng),首先,請無視None,請不要在任何場景下選擇該選項(xiàng),該選項(xiàng)意味著SQL Server不對(duì)頁進(jìn)行保護(hù)。

其次是TORN_PAGE_DETECTION,在SQL Server中,數(shù)據(jù)的最小單位是頁,每一頁是8K,但是對(duì)應(yīng)磁盤上往往是16個(gè)512字節(jié)的扇區(qū),如果一個(gè)頁在寫入持久化存儲(chǔ)的過程中,只寫了一半的頁,這就是所謂的TORN_PAGE_DETECTION,SQL Server通過每個(gè)扇區(qū)提512字節(jié)中前2位作為元數(shù)據(jù),總共16個(gè)扇區(qū)32位4字節(jié)的元數(shù)據(jù)(頁頭中標(biāo)識(shí)為:m_tornBits),通過該元數(shù)據(jù)來檢測是否存在部分寫的TORN_PAGE,但該類型的頁驗(yàn)證無法檢測出頁中的寫入錯(cuò)誤,因此在SQL Server 2005及以上版本,盡量選擇CheckSum。

在SQL Server 2005及以上版本,引入了CheckSum,CheckSum可以理解為校驗(yàn)和,當(dāng)數(shù)據(jù)頁被寫入持久化存儲(chǔ)時(shí),會(huì)根據(jù)頁的值計(jì)算出一個(gè)4字節(jié)的CheckSum存于頁頭(頁頭中標(biāo)識(shí)同為:m_tornBits),和數(shù)據(jù)在同一頁中一起保存在數(shù)據(jù)庫中。當(dāng)數(shù)據(jù)從IO子系統(tǒng)被讀取到內(nèi)存中時(shí),SQL Server會(huì)根據(jù)頁內(nèi)的值再次計(jì)算CheckSum,用該重新計(jì)算的CheckSum和頁頭中存儲(chǔ)的CheckSum進(jìn)行比對(duì),如果比對(duì)失敗,則SQL Server就會(huì)認(rèn)為該頁被損壞。

由CheckSum的過程可以看出,只有在頁被寫入SQL Server的過程中才會(huì)計(jì)算CheckSum,因此如果僅僅改變數(shù)據(jù)庫選項(xiàng)的話,則頁頭中的該元數(shù)據(jù)并不會(huì)隨之改變。

與IO相關(guān)的三種錯(cuò)誤

通過上述CheckSum的原理可以看出,SQL Server可以檢測出頁損壞,此時(shí),具體的表現(xiàn)形式可能為下述三種錯(cuò)誤的一種:

823錯(cuò)誤,也就是所謂的硬IO錯(cuò)誤,可以理解為SQL Server希望讀取頁,而Windows告訴SQL Server,無法讀取到該頁。

824錯(cuò)誤,也就是所謂的軟IO錯(cuò)誤,可以理解為SQL Server已經(jīng)讀取到該頁,但通過計(jì)算CheckSum等值發(fā)現(xiàn)不匹配,因此SQL Server認(rèn)為該頁已經(jīng)被損壞。

825錯(cuò)誤,也就是所謂Retry錯(cuò)誤。

其中, 上述823和824錯(cuò)誤都是錯(cuò)誤等級(jí)為24的嚴(yán)重錯(cuò)誤,因此會(huì)被記錄在Windows應(yīng)用程序日志和SQL Server的錯(cuò)誤日志中,而引起該錯(cuò)誤的頁會(huì)被記錄在msdb.dbo.suspect_pages中。SQL Server錯(cuò)誤日志中也會(huì)記錄到出錯(cuò)頁的編號(hào),如圖2所示。


圖2.824錯(cuò)誤在SQL Server錯(cuò)誤記錄中的描述

因此,如果我們存在完善的備份的話,我們可以通過備份進(jìn)行頁還原(在此再次強(qiáng)調(diào)一下對(duì)于DBA來說,有”備”無患),一個(gè)簡單的頁還原代碼如代碼清單1所示。

USE [master]
RESTORE DATABASE [Corrupt_DB] PAGE='1:155' 
FROM  DISK = N'C:\xxx.bak' 
WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5

代碼清單1.一個(gè)簡單的頁還原代碼,從備份中還原文件ID1中的第155頁

記得我們前面說的,在讀取頁計(jì)算校驗(yàn)和時(shí)出錯(cuò),這既可能是被寫入持久化存儲(chǔ)的頁本身出錯(cuò),也可能是在頁被讀取的過程中出錯(cuò),此時(shí)SQL Server會(huì)嘗試從IO子系統(tǒng)中再次讀取該頁,最多可能是4次嘗試,如果在4次嘗試過程中校驗(yàn)和通過,則會(huì)是825錯(cuò)誤,否則是824錯(cuò)誤。這里要注意,與823和824錯(cuò)誤不同的是,825錯(cuò)誤是一個(gè)等級(jí)僅為10的信息。

因此,由于有固定的錯(cuò)誤編號(hào),因此可以在SQL Server Agent中對(duì)823和824設(shè)置警報(bào)。

備份CheckSum

上述頁CheckSum只有在頁被使用時(shí)才會(huì)被校驗(yàn)頁的正確性。在備份數(shù)據(jù)庫時(shí),可以指定CheckSum選項(xiàng)來使得備份讀取的頁也計(jì)算校驗(yàn)和,從而保證了被備份的數(shù)據(jù)庫是沒有損壞的。在圖3的備份選項(xiàng)我們可以注意到這兩條:


圖3.CheckSum和Continue_After_Error選項(xiàng)

如果啟用了CheckSum,當(dāng)備份過程中發(fā)現(xiàn)了頁校驗(yàn)和錯(cuò)誤時(shí),就會(huì)終止備份,而啟用了Continue_After_Error選項(xiàng)的話,在檢測到校驗(yàn)和錯(cuò)誤時(shí),仍然繼續(xù)從而使得備份成功。

備份如果啟用了CheckSum選項(xiàng),除去檢測每一頁的校驗(yàn)和之外,還會(huì)在備份完成后,對(duì)整個(gè)備份計(jì)算校驗(yàn)和并存儲(chǔ)于備份頭中。

此外,對(duì)于備份,我們還可以通過Restore Verifyonly with CheckSum來驗(yàn)證備份,來保證備份的數(shù)據(jù)沒有被損壞。

DBCC CheckDB

前面提到SQL Server發(fā)現(xiàn)錯(cuò)誤的方法有兩種,分別為在讀取頁時(shí)和在備份時(shí)(本質(zhì)上也是讀取頁)。但如果我們希望對(duì)于數(shù)據(jù)一致性的檢查更加的激進(jìn),那我們應(yīng)該定期使用CheckDB來檢查數(shù)據(jù)的一致性,而不至于在生產(chǎn)時(shí)間數(shù)據(jù)被讀取時(shí)才能發(fā)現(xiàn)錯(cuò)誤。

CheckDB命令會(huì)對(duì)整個(gè)數(shù)據(jù)庫做所有的一致性檢查。當(dāng)檢查對(duì)象是Master數(shù)據(jù)庫時(shí),CheckDB還會(huì)檢查ResourceDB。

CheckDB最簡單的用法如代碼清單2所示,在當(dāng)前數(shù)據(jù)庫上下文中直接執(zhí)行CheckDB,將會(huì)檢查當(dāng)前數(shù)據(jù)庫中所有的一切。

DBCC CHECKDB

代碼清單2.CheckDB最簡單的用法

CheckDB命令在企業(yè)版中會(huì)使用多線程來進(jìn)行,會(huì)對(duì)整個(gè)數(shù)據(jù)庫進(jìn)行一致性檢查,在該過程中,使用了內(nèi)建數(shù)據(jù)庫快照的方式進(jìn)行,因此不會(huì)造成阻塞,但CheckDB會(huì)消耗大量的CPU、內(nèi)存和IO。因此CheckDB要選擇在維護(hù)窗口時(shí)間或是系統(tǒng)閑時(shí)進(jìn)行。

默認(rèn)情況下,CheckDB命令會(huì)將輸出所有的信息,但通常我們并不關(guān)心這些信息,而是只關(guān)心錯(cuò)誤信息,因此實(shí)際中通常給DBCC指定不顯式信息的參數(shù),如代碼清單3所示。

DBCC CHECKDB WITH NO_INFOMSGS;

代碼清單3.CheckDB通常搭配No_InfoMsgs參數(shù)

實(shí)際上,CheckDB是一套命令的匯總,CheckDB會(huì)依次檢查下述內(nèi)容:

初次檢查系統(tǒng)表

分配單元檢查(DBCC CHECKALLOC)

完整檢查系統(tǒng)表

對(duì)所有表進(jìn)行一致性邏輯檢查(DBCC CHECKTABLE)

元數(shù)據(jù)檢查(DBCC CHECKCATALOG)

SSB檢查

索引視圖、XML索引等檢查

首先,當(dāng)發(fā)現(xiàn)系統(tǒng)表損壞時(shí),只能通過備份進(jìn)行恢復(fù)(這也是為什么備份除TempDB之外的系統(tǒng)表非常重要)。其次,在一個(gè)大數(shù)據(jù)庫中,做一次CheckDB時(shí)間會(huì)非常長,維護(hù)窗口時(shí)間或系統(tǒng)閑時(shí)的時(shí)間可能無法Cover這段時(shí)間,那么我們可以將CheckDB的任務(wù)分散到CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG這三個(gè)命令中。

更多關(guān)于CheckDB的詳細(xì)信息,請參閱:http://technet.microsoft.com/en-us/library/ms176064.aspx。

數(shù)據(jù)庫損壞的修復(fù)

數(shù)據(jù)庫損壞最

關(guān)鍵詞:SQL,數(shù)據(jù)庫,解決方案

閱讀本文后您有什么感想? 已有 人給出評(píng)價(jià)!

  • 0 歡迎喜歡
  • 0 白癡
  • 0 拜托
  • 0 哇
  • 0 加油
  • 0 鄙視