用於自動資料庫或文件系統維護和修復的系統和方法

2023-08-13 02:16:36

專利名稱：：用於自動資料庫或文件系統維護和修復的系統和方法
技術領域：
：本發明一般涉及資料庫和文件系統管理，尤其涉及自動資料庫和文件系統維護和修復，以確保數據可靠性。本發明的各個方面涉及響應並在數據頁面層上對所有數據頁面類型校正數據損壞，以及各種情形的恢復(包括重建或還原操作)，包括但不限於索引頁面損壞(集聚的和非集聚的)、數據頁面損壞、以及日誌文件中的頁面損壞。
背景技術：
：儘管客戶機資料庫平臺(即家用和商用臺式計算機)使用的硬體質量比伺服器平臺的低得多，但是甚至伺服器類的硬體(控制器、驅動器、盤等等)仍然可導致數據損壞，從而讀取操作不能返回應用程式寫到數據存儲器中的內容。當然，出於各種原因客戶機資料庫平臺(與伺服器資料庫平臺相對)的問題顯然更多，包括但不限於，客戶機在寫操作中期因意外停電而被任意斷電的可能性增加，從而導致受損頁面和可能的資料庫損壞。(對伺服器資料庫系統而言較常見的是利用不中斷電源來減輕因停電導致的問題。)媒體衰退是資料庫損壞的另一種來源，其中物理存儲媒體確實會隨時間而磨損。有關可靠性的關心的又一種來源是檢測由因疏忽(例如程序錯誤(bug))和惡意(例如病毒)的軟體錯誤而導致的損壞並從中恢復。通常資料庫的維護和修復是由資料庫管理員等進行的，這些資料庫管理員具有良好技能並具有對資料庫系統的深厚知識，或由至少熟悉並經常使用資料庫系統的個人一大體上是對資料庫技術相對熟練的人進行。另一方面，作業系統和應用程式的典型消費者和商業終端用戶很少用資料庫，且很大程度上被錯誤裝備來進行資料庫維護和修復。儘管這兩組之間不同的技能級別在過去很大程度上並不相關，但作業系統的資料庫實現的文件系統一諸如在"相關申請"章節中標識的相關美國專利申請中揭示的作業系統—創建了這些較不熟練的終端用戶將面對他們基本上不能解決的資料庫維護和修復問題的情形。因而商業/消費者的資料庫實現的作業系統文件系統，或簡稱為"資料庫文件系統"(DBFS)必須能夠檢測損壞並將其資料庫恢復到事務處理的一致狀態，且在不可恢復的數據丟失情形中，DBFS必須確保在維護所述數據的原子變化單元的層次上(即，在基於項的DBFS的"項"層上)的數據一致性。此外，對於預設地以懶提交模式運行的DBFS，在異常斷電之前剛提交的交易持久性無法得到確保，且必須進行說明和校正。此外，在商業/消費者終端用戶將大大受益於自動的DBFS維護和恢復的同時，資料庫管理員和具有較多資料庫技能的人也將受益於一般資料庫維護和修復的技術方案。對本領域的資料庫管理員而言常見的是利用資料庫工具(例如被提供SQLServer2000的資料庫調整顧問)，但這些工具不能直接解決可靠性問題，而是相反提供執行並管理資料庫備份的方法一且不是以大部分自動化方式，而是相反想要資料庫管理員的大量參與，特別是當資料庫備份不可用或者產生其它修復問題時。因而，解決資料庫可靠性的自動化方案也將有利於資料庫管理員和其它熟練資料庫用戶。本發明就是提供了這樣的方案。
發明內容本發明的各個實施例涉及DBFS的數據可靠性系統(DRS)，其中該DRS包括用於自動執行資料庫管理(DBA)任務而幾乎不需要或不需要終端用戶的直接參與(因而基本上對所述終端用戶透明)的框架和策略集。對於若干實施例，DRS框架實現用於將錯誤和事件通知、策略、和錯誤/事件處理算法插入DRS的機制。更特別地，對於這些實施例，DRS是負責在背景中維護和修復DBFS的背景線程，因而DRS在最高層上保護並維護DBFS的整體健康。對於本發明的若干實施例，DRS包括以下特徵(1)在頁面層上對所有頁面類型響應並校正數據損壞；以及(2)對以下嘗試第二層的恢復(重建或還原)(a)索引頁面損壞(集聚的和非集聚的)；(b)數據頁面損壞；以及(c)日誌文件中的頁面損壞。本發明某些實施例還包括DRS的特定功能，包括但不限於(i)處理修復/恢復數據損壞情形；以及(ii)(iii)改進系統的可靠性和可用性；以及(iv)保留熟練第三方的DRS錯誤/事件歷史表格，以在需要時檢修資料庫或存儲引擎問題。結合附圖閱讀前面的
發明內容和以下較佳實施例的詳細描述，能得到更好的理解。為了說明本發明，在附圖中示出本發明的示例性結構；然而，本發明並不限於所揭示的特定方法和裝置。在附圖中圖1是示出本發明各方面可結合其中的計算機系統的框圖；圖2是示出代表本發明若干實施例的資料庫文件系統(DBFS)中數據可靠性系統(DRS)的結構的框圖3A是示出資料庫FPM將數據存儲器附加到DBFS的框圖3B是示出在本發明若干實施例的資料庫附加操作期間檢測並校正被損壞頁面的過程的流程圖4A是示出根據本發明各個實施例在啟動/崩潰恢復環境中利用DRS的流程圖4B是示出在資料庫附加期間由DRS處理的錯誤的表格；圖5A是示出本發明各個實施例的在查尋引擎遭遇錯誤時的在線操作中利用DRS的流程圖5B是示出在線操作期間由DRS處理的錯誤的表格；圖6是示出當頁面在最近的瞬象中存在且具有有效處理日誌時DRS執行恢復的流程圖7是示出本發明若干DRS實施例的用於使資料庫恢復在線的方法的流程圖，在這些實施例中資料庫不能被恢復且沒有可用備份。圖8是示出根據本發明一方面DRS用來嘗試恢復數據頁面的方法的流程圖。具體實施例方式本發明的主題是專門為滿足法定需求而進行描述的。然而，該描述本身並不是要限制本專利的範圍。相反，發明者已經預期到已聲明主題也能結合其它現有或以後的技術用其它方式體現，以包括不同的步驟或類似於本文檔中所述步驟的組合。此外，儘管術語"步驟"在此可用以暗示所用方法的不同元素，該術語不應被解釋為暗示在此揭示的不同步驟之間或當中的任何特定次序，除非在明確說明單獨步驟的次序時。以上
發明內容提供了對本發明特徵的縱覽。本發明一實施例的詳細描述如下。對於以下所述的各個實施例，本發明特徵被描述為在MicrosoftSQLServer資料庫系統(在此有時簡稱為"SQL")中單獨實現，或者被結合到MicrosoftWinFS文件系統用於下一代個人計算機作業系統(通常稱為"WindowsLonghom"或簡稱為"Longhorn")，後者是先前所述許多相關專利申請的主要主題。如上所述，SQLServer結合了Microsoft.NET公共語言運行時間(CLR)，以使受管理代碼能被編寫並執行，來對SQLServer資料庫的數據存儲器進行操作。儘管以下所述的實施例在該環境中操作，但是可以理解本發明決不受限於SQLServer產品中的實現。相反，本發明可在支持面向對象編程代碼的執行以在資料庫存儲器上操作的任何資料庫系統中實現，諸如面向對象的資料庫系統和具有對象關係擴展的關係資料庫系統。因此，可以理解，本發明並不限於以下所述的特定實施例，而是旨在包括在由所附權利要求限定的本發明精神和範圍內的所有修改。計算機環境本發明的許多實施例可在計算機上執行。圖1和下面的討論旨在提供其中可實現本發明的合適計算環境的簡要描述。儘管並非必須，本發明能在計算機可執行指令的通用環境中描述，諸如由比如客戶工作站或伺服器的計算機所執行的程序模塊。通常，程序模塊包括執行特定任務或實現特定的抽象數據類型的例程、程序、對象、組件、數據結構等。此外，本領域技術人員將會理解本發明可用其它計算機系統配置實踐，包括手持式裝置、多處理器系統、基於微處理器的或可編程的消費電器、網絡PC、小型機、大型機等等。本發明也可在分布式計算環境中實踐，其中任務由經通信網絡連結的遠程處理裝置執行。在分布式計算環境中，程序模塊可位於本地或遠程存儲存儲設備中。如圖1所示，示例性通用計算系統包括常規個人計算機20等，它包括處理單元21、系統存儲器22，以及將包括系統存儲器的各個系統組件耦合到處理單元21的系統總線23。系統總線23可以是若干總線結構類型的任一種，包括存儲器總線或存儲器控制器、外圍總線，以及使用多種總線體系結構任一種的局部總線。系統存儲器包括只讀存儲器(ROM)24和隨機存取存儲器(RAM)25。包含幫助諸如在啟動階段，在個人計算機20內的元件之間傳遞信息的基本例程的基本輸入/輸出系統26(BIOS)被存儲在ROM24中。個人計算機20還可包括用於讀自或寫到硬碟(未示出)的硬碟驅動器27、用於讀自或寫到可移動磁碟29的磁碟驅動器28，以及用於讀自或寫到諸如CDROM或其它的光學介質的可移動光碟31的光碟驅動器30。硬碟驅動器27、磁碟驅動器28和光碟驅動器30分別通過硬碟驅動器接口32、磁碟驅動器接口33和光碟驅動器接口34與系統總線23相連。驅動器及其相關聯的計算機可讀媒體提供計算機可讀指令、數據結構、程序模塊和其它有關個人計算機20數據的非易失性存儲。儘管在此說明的示例性環境使用硬碟、可移動磁碟29和可移動光碟31，但是本領域技術人員會認識到在示例性操作環境中也可使用的可存儲計算機可訪問的數據的其它類型的計算機可讀媒體，諸如盒式磁帶、快閃記憶體卡、數字視頻盤、伯努利卡、隨機存取存儲器(RAM)、只讀存儲器(ROM)等等。許多程序模塊可被存儲在硬碟、磁碟29、光碟31、ROM24或RAM25上，包括作業系統35、一個或多個應用程式36、其它程序模塊37和程序數據38。用戶可將命令和信息通過諸如鍵盤40和定點裝置42的輸入裝置輸入到個人計算機20中。其它輸入裝置(未示出)可包括話筒、操縱杆、遊戲墊、圓盤式衛星電視天線、掃描儀等等。這些和其它的輸入裝置通常通過與系統總線相耦合的串行埠接口46與處理單元21相連，但也可由諸如並行埠、遊戲埠或通用串行總線(USB)的其它接口連接。監視器47或其它類型的顯示裝置也可通過諸如視頻適配器48的接口與系統總線23相連。除監視器47之外，個人計算機通常包括其它的外圍輸出器件(未示出)，諸如揚聲器和印表機。圖1的示例性系統也可包括主機適配器55、小型計算機系統接口(SCSI)總線56，以及與SCSI總線56相連的外部存儲器件62。個人計算機20可在使用與諸如遠程計算機49的一臺或多臺遠程計算機的邏輯連接的網絡化環境中操作。遠程計算機49可以是另一臺個人計算機、伺服器、路由器、網絡PC、對等裝置或其它公共網絡節點，且通常包括與上述個人計算機20相關的許多或所有元件，儘管在圖1中僅示出了存儲器存儲裝置50。圖1所述的邏輯連接包括區域網(LAN)51和廣域網(WAN)52。這樣的網絡環境常見於辦公室、企業範圍計算機網絡、內聯網和網際網路中。當在LAN網絡環境中使用時，個人計算機20通過網絡接口或適配器53與LAN51相連。當在WAN網絡環境中使用時，個人計算機20通常包括數據機54或用於在諸如網際網路的廣域網52上建立通信的其它裝置。可以內置或外置的數據機54通過串行埠接口46與系統總線23相連。在網絡化環境中，所示與個人計算機20相關的程序模塊或其各個部分，可被存儲在遠程存儲器存儲裝置中。應當理解所示網絡連接是示例性的，也可使用在計算機之間建立通信連結的其它裝置。儘管可想像本發明許多實施例特別適合於計算機化系統，但本文檔中內容並非旨在將本發明限制在這些實施例中。相反，當在此使用時，術語"計算機系統"旨在包含任何和所有能夠存儲並處理信息和/或能夠使用該存儲信息來控制裝置本身行為或執行的裝置，無論這些裝置的特性是電子、機械、邏輯還是虛擬的。數據可靠性系統(DRS)的縱覽對於本發明的若干實施例，數據可靠性系統(DRS)是在背景中維護並修複數據庫的線程，因而保護了資料庫文件系統(DBFS)的總體健康。圖2是示出DBFS中DRS的結構的框圖。在該圖中，向多個應用程式212、214和216提供作業系統級別服務的作業系統202，包括在邏輯上與持久數據存儲器232內耦合的DBFS222。作業系統202還包括DRS242，它在發現持久數據存儲器232的多個頁面234、236和238中的頁面錯誤240的任何時候由DBFS222調用(244)，然後DRS242響應於該頁面錯誤240執行修復操作。對於本發明的各個實施例，DRS可包括以下特徵(1)在頁面層上對所有頁面類型響應並校正數據損壞；以及(2)對以下嘗試第二層的恢復(重建或還原)(a)索引頁面損壞(集聚的和非集聚的)；(b)數據頁面損壞；以及(C)日誌文件中的頁面損壞。本發明某些實施例還包括DRS的特定功能，包括但不限於(i)處理修復/還原數據損壞情形；以及(ii)改進系統的可靠性和可用性；以及(iii)保留熟練第三方的DRS錯誤/事件歷史表格，以在需要時檢修資料庫或存儲引擎問題。本發明的某些實施例提供可擴展的DRS從而在已經發行DBFS之後可更新恢復策略和檢測機制。若干實施例涉及在DBFS資料庫保持在線時運行修復的DRS。其它實施例涉及具有對DBFS存儲器的全權使用(即sysadmin特權)而運行。還有其它實施例將具有實時檢測故障並對其作出反應的能力。對於若干實施例，DRS修復將在維護所述數據的變化單元層次上(即，在基於項的DBFS的"項"層上)進行事務處理。最後，對於各個實施例，修復將完全恢復項或者它將收回其改變，且DRS將具有即使重新啟動在該過程中間進行也能繼續恢復/還原工作的能力。對於本發明的若干實施例，DRS將預訂SQL事件，從而如果SQL觸發一般事件，DRS可攔截它並作出響應(包括但不限於823/824事件)。此外，本發明的另一方面是對要修改的資料庫引擎發送DRS要特別處理的錯誤條件的DRS特定事件。對於本發明的各個實施例，在DBFS從盤中讀取或寫入頁面的任何時候將檢測損壞，在該情形中SQL將取決於損壞類型生成許多錯誤之一，並還將觸發特定DRS事件以向其通知特定錯誤條件。DRS將接收那些錯誤，並將其置入要處理的輸入隊列中。對於本發明的若干實施例，確定頁面是否遭損壞通過各種手段來實現，包括但不限於(a)檢査頁面的校驗和，並且如果校驗和無效則該頁面被視為無效，或(b)通過檢查日誌序列號(LSN)來査看它是否在日誌文件末端之外(其中LSN是隨著每個處理遞增的整數)，從而如果日誌中最後處理是LSN432，並且所發現的具有更大LSN的頁面，則必然發生了寫次序錯誤。在這方面，主要有四類可影響DBFS操作(以及其它源比如bug等)的頁面損壞，且這四類包括損壞頁面、媒體衰退、硬體故障、以及無序寫入。損壞頁面在數據頁面未正確地原子寫入時發生，因而由於在例如電源故障或扇區寫入故障的故障事件之前僅對盤寫入頁面的部分扇區，該頁面的任一部分可遭到損壞。媒體衰退在數據頁面比特因物理媒體衰退而遭到損壞時發生。硬體故障可因與總線、控制器、或硬碟裝置有關的各種原因而引起。對於無序寫入，這些錯誤源自IDE驅動器不能確保寫入盤的順序的事實，特別是IDE驅動器能夠(開啟)寫緩存，因而寫入數據存儲器可無序發生是可能的。如果無序寫入的部分序列進行但被例如電源故障打斷，則會產生若干錯誤，諸如在編寫例如相關聯日誌條目之前寫入盤的數據頁面。儘管無序錯誤可通過檢查數據頁面上的日誌序列號(LSN)來檢測，但是沒有短時間內讀取每個頁面的簡便方法。頁面類為了本發明，所有頁面根據以下頁面類來進行分類，數據頁面數據頁面被視為具有用戶數據在其上的任何頁面，包括集聚索引的葉頁面。，索引頁面這些頁面僅包含索引信息，且它們包括非集聚的索引頁面以及集聚索引的非葉頁面。,系統頁面這些頁面包括GAM、SGAM、和Boot頁面，且即使DRS不具有對這些頁面的特定還原支持，DRS仍可嘗試對這些頁面的頁面層還原；無論如何，如果頁面層還原失敗，則DRS嘗試緊急修復(在後面討論)。不可恢復頁面:PFS(頁面空閒空間)頁面或來自5個系統表格(Sysrowsetcolomns、Sysrowsets、Sysallocunits、Syshobtcolumns、Syshobts)的頁面包括本類頁面，且DRS在該情形中將還原整個資料庫。，日誌頁面這些是屬於處理日誌的頁面，且DRS將在它們被損壞時嘗試緊急修復(在後面討論)。損壞類別對於本發明的若干實施例，DRS被設計成解析在檢測到損壞時定義的三類不同的數據頁面損壞，這三種類別包括(l)在資料庫附加期間；(2)在正常在線操作期間；以及(3)在處理反轉期間。資料庫附加損壞檢測圖3A是示出資料庫FPM將數據存儲器附加到DBFS的框圖。圖3B是示出在資料庫附加操作期間檢測並校正被損壞頁面的過程的流程圖。一般而言，資料庫文件屬性管理器(DBFPM)302管理DBFS存儲器304、306和308的附加和分離。在步驟352，當DBFPM302附加例如DBFS存儲器304的存儲器時，SQL在步驟354運行崩潰恢復，以在步驟356確定在處理日誌314中是否有任何在崩潰時活動的處理324(例如任何未完成處理)，且如果有則SQL在步驟358在繼續之前執行資料庫的崩潰恢復。在崩潰恢復期間SQL將正常(a)分析最後檢驗點之後的處理日誌，(b)重做日誌中未發現寫入盤的任何操作，以及(c)撤消尚未完成的任何處理。如果在步驟360未發現恢復期間有任何錯誤，則在步驟362資料庫成功附加。然而，如果在步驟360發現崩潰恢復期間有一錯誤，則在步驟364SQL將無法實現資料庫附加。該"資料庫附加"情形是重要的，因為每次附加存儲器時都要調用它。每當作業系統(例如Window作業系統)啟動時以及每當外部驅動器(例如Firewire、USB等)被附加到計算機上或與其分離時，附加存儲器。資料庫附加情形調用崩潰恢復，並因此檢測受損壞頁面(未完成寫入)，因而需要DRS來處理該情形，因為用戶可能物理地移除硬體。然而，當根據本發明各個實施例利用DRS時，行為與圖4A流程圖所示的略有不同。首先，在步驟402，DBFPM附加DBFS資料庫，且在步驟404，SQL運行崩潰恢復，且在步驟408嘗試使資料庫在線。如果在步驟410沒有崩潰恢復中的錯誤而附加資料庫，則SQL將返回成功，且資料庫將在步驟452上(在線)附加。然而，如果有錯誤，則DRS在步驟412將評估資料庫，以確定該資料庫是否事務處理一致。僅當資料庫經歷在處理反轉期間的故障時，即物理或邏輯的撤消錯誤一或者如果未知錯誤在崩漬恢復期間發生，資料庫會不一致。如果在步驟412資料庫是事務處理一致的，則DRS在步驟414將延遲修復直到完成恢復操作一換言之，DRS將聲明資料庫的狀態為對資料庫附加一致("成功")，然後等待在恢復完成之後開始修復所檢測的損壞，且資料庫在步驟452上附加以便避免與崩潰恢復的任何衝一旦恢復完成且在步驟452附加成功，在步驟478如果有延遲修復，則在步驟480DRS將開始修復，且在步驟482首先嘗試調用損壞的頁面層還原。如果在步驟484頁面層還原失敗或者不可能，則在步驟486DRS將確定是否是由於索引頁面的故障，且如果是則DRS在步驟488重建該索引。另一方面，如果在步驟490錯誤是在數據頁面中，則DRS將在步驟492嘗試數據頁面恢復。然而，如果在步驟490DRS確定資料庫不一致或者具有未知/不受支持的錯誤，則在步驟494DRS將立即使資料庫離線(從而結束恢復操作)並將該資料庫標記為"可疑"，然後在步驟496嘗試緊急修復。圖4B是示出在資料庫附加期間由DRS處理的錯誤的表格。在線操作損壞檢測圖5A是示出本發明各個實施例的在查尋引擎遭遇錯誤時的在線操作中利用DRS的流程圖。該情形是在DBFS的正常運行時間使用期間，諸如當終端用戶使用作業系統外殼來執行對DBFS的中等複雜査詢時，以及在執行該查詢期間，該査詢引擎報告一錯誤。在這些在線操作情形中，當錯誤發生時，DRS在步驟502放棄該處理以嘗試修復錯誤。DRS在步驟504將首先嘗試頁面層還原。然而，如果頁面層還原在步驟506不可用或者失敗，則DRS將在步驟508確定出故障的頁面類型。在步驟510，如果是索引頁面的故障，則DRS將在步驟512嘗試索引恢復。如果在步驟514故障是數據頁面，則DRS將在步驟516嘗試數據頁面恢復。如果在步驟518故障是因為系統或日誌頁面錯誤，則DRS將在步驟520嘗試緊急修復。如果在步驟518故障是不可恢復錯誤(5個系統表格或PFS頁面)，則DFS將在步驟522自動還原整個資料庫，或者提示終端用戶還原整個資料庫。圖5B是示出在在線操作期間由DRS處理的錯誤的表格。處理反轉損壞檢測如果錯誤在處理反轉期間發生，則DRS將使資料庫離線，將其標記為可疑，並重新啟動資料庫以便調用崩潰恢復。然後該過程將重新調用該方法，用於稍早揭示的崩潰恢復損壞檢測。恢復技術如本領域技術人員所眾所周知並易於理解的，事務處理一致性涉及僅顯示已提交數據(或使其可用)，以及僅提交(寫入持久存儲器並記錄事務處理)正確數據。在這方面，只要在崩潰恢復期間實現了所有重做和撤消請求，資料庫是事務處理一致的。因而許多類損壞可在數據和索引頁面中呈現但仍然是事務處理一致的。本發明的各個實施例認識到常常不需要在線執行許多這些事務處理，因此這些實施例嘗試在資料庫離線時執行所有修復。當SQL錯誤發生時，DRS將僅接收頁面id和資料庫id。從該信息中，DRS將詢問該頁面以確切地指出它是哪類頁面。這些實施例具有數據頁面和索引損壞的恢復機制，其中DRS嘗試恢復因為該損壞引起的DBFS項的丟失。然而，有許多可在資料庫中丟失的其它類型頁面，包括GAM、SGAM、PFS、啟動頁面及其它。儘管典型的DBFS不具有這些頁面類型的特定備份和恢復機制，但是DRS將嘗試調用頁面層還原。對於已受損壞的頁面，DRS將嘗試頁面層還原。頁面層還原是沒有記載的，因為我們可以向用戶確保我們會丟棄尚未提交的任何數據。同一技術將應用於來自任何表格的頁面，且該方法不管所還原的頁面或表格是什麼類型都不會改變。頁面層還原僅在如果頁面存在於最近瞬象之中時才發生。此外有效的處理日誌必須可用。如果頁面不在最近的瞬象之中，則我們必須使用本領域技術人員所眾所周知和理解的項層還原技術來恢復該頁面(諸如從備份操作中的還原)。如果頁面的確存在於最近瞬象之中，且具有有效的處理日誌，則DRS將執行以下動作來還原該頁面，如圖6所示U)在步驟602，確定遭損壞頁面的PageID;(2)在步驟604，從DBFS存儲器的最近瞬象中尋找並複製受損壞的頁面；(3)在步驟606，通過快進應用於該頁面的事務處理，將盤上處理日誌應用於該頁面；(4)在步驟608，將所還原的頁面應用於在線資料庫；以及(5)如果在步驟610有對所還原頁面的延遲事務處理，則在步驟612我們將必須重新啟動資料庫(從而運行崩潰恢復並清除所延遲的事務處理)，否則操作在步驟614繼續。關於前述瞬象，如本領域技術人員所理解的，VSS(巻影子副本服務)提供了用於維護某些巻(例如NTFS巻)的時間瞬象中點的一種方法。VSS瞬象通過使用寫時複製來維護巻的影子副本，即在盤頁面被修改的任何時候，該頁面的預先圖像被寫入最新瞬象的瞬象存儲區域。當在機器上使能TimeWarp時一對某些DBFS及其相應作業系統可能是預設的一瞬象可以一天兩次的預設速率取得並可維護最多63張瞬象。為了使用存儲在瞬象中的預先圖像，從取得瞬象時到現在的維護日誌，而日誌截取僅在TimeWarp瞬象時間發生，從而所有時間都有來自上一瞬象的日誌可用。在有頁面損壞且頁面在最新瞬象中可用的情形中，日誌可從瞬象重放到該頁面上的當前點以還原之。在TimeWarp瞬象期間，有關該瞬象的DBFS存儲得到恢復。這使得頁面層還原對因瞬象資料庫的恢復而觸及的頁面而言是不可能的。為了解決該問題，SQLServer視點在瞬象巻中的資料庫上取得並且該資料庫得到恢復一即，DRS在瞬象巻中的資料庫上具有未經恢復視點，且該視點中的各個頁面總是可用於頁面層還原。對於系統、日誌或未知的頁面修復一即，如果日誌損壞發生或者如果有DRS不能校正的故障(例如數據或索引)，則DRS將向用戶呈現以下選項(a)還原整個資料庫(存儲器)；或者(b)以緊急模式恢復資料庫。為了以緊急模式修複數據庫，最重要的是識別DBCC從損壞處理日誌和不可恢復的資料庫情形中恢復的新能力。然後，如果資料庫不能被恢復，或者沒有可用備份，則以下系列動作，如圖7所示，將使得資料庫對本發明的若干DRS實施例恢復在線(a)在步驟702,將資料庫設置為緊急模式；(b)在步驟704運行'DBCCCHECKDB(database,REPAIR—ALLOW—DATA—LOSS)，，它在緊急模式中具有特定含義(i)迫使資料庫恢復繼續過去的錯誤(從日誌中獲取儘可能多的數據，但導致事務處理地不一致的資料庫)，(ii)丟棄被損壞的日誌文件並創建新的日誌文件，(iii)運行全資料庫修復以使資料庫進入結構上一致的狀態(不能反轉或撤消的'原子'單向操作，且在不手動編輯文件的情形中是恢復資料庫的唯一可能方法)；以及(c)因為資料庫在物理上是一致的，DSR在步驟706對整個存儲器運行CC。這些步驟的成功執行應當確保該數據(基於項的DBFS中的各項)將是一致的，但它可能意味著某些應用程式將事務處理地不一致。有兩類索引頁面非集聚頁面和集聚的非葉頁面。帶有數據的索引頁面(集聚索引的葉頁面)被視為數據頁面。有了這樣的概念，對於可恢復索引故障，DRS嘗試使用離線索引重建來修復索引(其中資料庫將在該修復期間在線，而只有索引將離線)。如果修復失敗，則DRS丟棄該索引並嘗試重建該索引。然後，如果重建也失敗，則DRS將完全丟棄該索引或者禁用該索引，並嘗試在後來再次重建(可能無限地這樣做直到成功)。對於數據頁面恢復，如果DRS接受所處理錯誤之一，並確定該頁面是一數據頁面，則它將嘗試恢復。這可在SQLServer操作的任何狀態期間(DB附加、在線操作和反轉)進行。如圖8所示，如果DRS在步驟802檢測到數據頁面錯誤，則步驟804的嘗試頁面層還原在步驟806失敗之後，DRS將(a)通過接收受損壞頁面的PageID並如前所述確定頁面類型，在步驟808確定所損壞的頁面類型(並且給定一數據頁面損壞，DRS並非必須進行嘗試訪問該頁面的其它事務處理)；(b)在步驟810，取得所丟失ItemID的範圍(啟動Tx，運行DBCCCHECKTable(table,REPAIR—ALLOW—LOSS))，這從非集聚索引中返回所有不匹配集聚索引鍵的所有索引鍵，且非集聚索引鍵包含Itemld，所以DRS可提取它們並將其寫入內部表格；以及(c)在步驟812，將Itemld和表格名稱傳遞給WCC(其中WCC修復那些Itemld並檢查存儲器中其餘值)以確保DBFS是一致的，並提交Tx以使DRS能放棄並重新嘗試這些恢復。如果有一系列遭損壞頁面，則DRS在切斷它們作進一步處理(諸如通過從備份中還原所述頁面)之前從所有遭損壞頁面中指出所有ItemID。因為DRS可確保如果頁面層還原工作則沒有用戶數據會丟失，所以DRS僅需在名義上通知用戶，因為在進行頁面層還原時用戶極可能僅注意到比期望略慢的響應。在某些實施例中，用戶將不接收任何通知(因為這最多只花幾秒)；然而。對於其它選擇性實施例，DRS將作"事件"記錄，以捕捉DRS還原頁面的事實。在最差情形中，其中對要還原的頁面進行未完成的活動處理，資料庫將必須分離並重新啟動(以便運行崩潰恢復)，因而與資料庫的所有連接將終止。應用程式應已被設計成知道此可能性；然而這可導致設計較差的應用程式"中止"。因而本發明的某些實施例向用戶通知可導致這種事件的情形，以便使用戶能關閉所有的這類應用程式來避免這種不需要的結果。示例終端用戶體驗為了示出DRS的操作，以下示出一些情形，它們一般表徵用戶體驗以及DRS所做的用戶不可見的事情。索引損壞Abbey正在執行WindFS査詢，以找出她在上個星期修改的所有文檔。在該查詢期間，WinFS通知它花了比平常略長的時間。實際上某些隨後她的查詢也略為緩慢。然後她注意到她的任務欄上有一個小氣球。該氣球報告在她機器上發現一可靠性問題，並請在Windows修復這些錯誤時耐心等待。過了一會兒，另一個氣球出現，並通知Abbey索引已經成功重建。當Abbey注意到她的計算機現在看起來執行得更好時，她很高興。在幕後，DRS檢測並修復了索引損壞。它使得索引離線(因此執行較慢)、重建之、並使其恢復在線。損壞頁面寫入在雷雨期間，Toby在寫家庭作業一一篇有關AdamSmith的文章，並定期存檔。在約完成90%時，Toby整個家停電了。Toby沒有在可攜式電腦上工作，並且沒有備用電池。幸運地是，約30分鐘後電恢復正常。Toby登錄到計算機上並嘗試打開他的文章。他撓撓頭，因為看起來比平常花的時間要長一些。在幕後發生的是，Toby文章的文檔項受到損壞，因為停電導致他硬碟驅動器的頁面寫入遭損壞。當DBFS重新啟動時，DRS檢測到該數據頁面損壞，並嘗試恢復該數據。DRS自動地嘗試從自動瞬象中還原數據頁面。因為Toby定期存檔了，所以在最近瞬象中有該文章的副本。因此，DBFS能夠自動還原遭損壞的頁面。比特毀壞和扇區損壞Susan喜歡她的數位照相機，在過去2年中她拍攝了5800多張她的孩子們的照片。當然在5800張中她在計算機上的WinFS中保存了超過3000張。不幸地是，保存了這些珍貴照片的硬碟驅動器已經損壞了盤上的少量扇區。這些遭損壞的扇區現在已損壞了10張Susan的照片。當Susan嘗試査看這些照片時，她獲得來自作業系統外殼的錯誤，並得到提示要從備份中還原這些照片。Susan遵從提示，找到她的備份媒體(zip盤)，然後從盤上還原這些項。在幕後，DBFS正在嘗試頁面層還原。然而因為這些照片(從來)未曾修改，它們不在最新的瞬象中，因而對該特定實施例而言提示Sunsan置入(僅這些項的)備份是必要的。結論在此所述的各種系統、方法和技術可結合硬體或軟體，或在適當時結合兩者的組合來實現。因而，本發明的方法和裝置，或者其中的某些方面和部分，可取諸如軟盤、CD-ROM、硬碟驅動器、或任何其它機器可讀存儲介質的有形介質中包含程序代碼(即指令)形式，其中當程序代碼由諸如計算機的機器載入並執行時，該機器成為用於實踐本發明的裝置。在可編程計算機上的程序代碼執行情形中，計算機通常包括處理器、處理器可讀的存儲介質(包括易失性和非易失性存儲器和/或存儲元件)、至少一個輸入設備、和至少一個輸出設備。一個或多個程序最好用高級過程或面向對象的程式語言來執行，以便與計算機系統通信。然而，如果需要程序也可用彙編或機器語言來實現。無論如何，語言可以是編譯或解釋語言，並與硬體實現相組合。本發明的各個方法和裝置還可以經某些傳輸媒體傳輸的程序代碼形式來實現，這些傳輸媒體諸如經電線或電纜、通過光纖、或通過任何其它形式的傳輸，其中當程序代碼由諸如EPROM、門陣列、可編程邏輯設備(PLD)、客戶計算機、攝像機等的機器接收、載入並執行時，機器變成用於實踐本發明的裝置。當在通用處理器上實現時，程序代碼與處理器組合以提供進行操作來執行本發明的索引功能的唯一裝置。儘管本發明結合各個附圖的較佳實施例進行了描述，但是可以理解，也可使用其它類似實施例，或者可對所述實施例作修改和添加，用於執行本發明的相同功能而不背離本發明。例如，儘管本發明的示例性實施例在仿真箇人計算機功能的數字設備環境中描述，但是本領域技術人員將理解，本發明並不限於這些數字設備，如所述本申請可應用於任何數量的現有或新興的計算裝置或環境，諸如有線或無線的遊戲控制臺、手持式計算機、可攜式計算機等，並可應用於任何數量的經通信網絡連接並在網絡上交互作用的這類計算裝置。此外，應強調這裡可預期各種各樣的計算機平臺，包括手持式設備的作業系統以及其它應用程式專用的硬體/軟體接口系統，特別是當無線網絡化裝置的數量持續激增時。因此，本發明應不限於任何單個實施例，而應解釋為在根據所附權利要求的寬度和範圍內。權利要求1、一種用於附加用於資料庫文件系統的數據存儲器並使其在線的系統，所述系統包括用於附加所述數據存儲器的子系統；用於運行崩潰恢復並嘗試使所述數據存儲器在線的子系統；用於確定對使得所述數據存儲器在線的嘗試是否沒有成功的子系統；用於評估與所述數據存儲器相關聯的資料庫以確定所述資料庫是否事務處理一致的子系統；用於在所述資料庫事務處理地一致時延遲修復直到所述崩潰恢復完成的子系統。2、如權利要求l所述的系統，還包括一子系統，它嘗試頁面層還原，且如果所述頁面層還原失敗，則確定所述失敗是否由於索引頁面，並且如果是，則在對使所述數據存儲器在線的嘗試不成功時以及當資料庫事務處理地一致時重建所述索引頁面。3、如權利要求1所述的系統，還包括一子系統，它在對使所述數據存儲器在線的嘗試不成功時以及當所述資料庫未事務處理地一致時，使所述資料庫離線並嘗試緊急修復。4、一種用於附加用於資料庫文件系統的數據存儲器並使其在線的方法，所述方法包括附加所述數據存儲器；運行崩潰恢復並嘗試使所述數據存儲器在線；以及如果使得所述數據存儲器在線的嘗試沒有成功，評估與所述數據存儲器相關聯的資料庫，以確定所述資料庫是否事務處理地一致，且如果是，則延遲修復直到所述崩潰恢復完成並繼續所述崩潰恢復。5、如權利要求4所述的方法，其特徵在於，對使所述數據存儲器在線的嘗試不成功，且其中所述資料庫事務處理地一致，且其中所述修復被延遲直到所述崩潰恢復完成，所述方法還包括嘗試頁面層還原，並且如果所述頁面層還原失敗，則確定所述失敗是否由於索引頁面，並且如果是，重建所述索引頁面。6、如權利要求4所述的方法，其特徵在於，對使所述數據存儲器在線的嘗試不成功，且其中所述資料庫未事務處理一致，所述方法還包括使所述資料庫離線並嘗試緊急修復。全文摘要本發明涉及用於自動資料庫或文件系統維護和修復的系統和方法。本發明一般涉及資料庫和文件系統管理，尤其涉及自動資料庫和文件系統維護和修復，以確保數據可靠性。本發明的各個方面涉及響應並校正在數據頁面層上對所有數據頁面類型的數據損壞，以及各種情形的恢復(包括重建或還原操作)，包括但不限於索引頁面損壞(集聚的和非集聚的)、數據頁面損壞、以及日誌文件中的頁面損壞。文檔編號G06F7/00GK101604335SQ20091015213公開日2009年12月16日申請日期2004年7月29日優先權日2004年5月3日發明者A·A·歐克斯,H·R·科達瓦拉,M·J·斯利曼申請人:微軟公司