DB2數(shù)據(jù)庫崩潰之后,用事務(wù)日志恢復(fù)的原因是什么?
文章介紹的是DB2數(shù)據(jù)庫崩潰之后,用事務(wù)日志恢復(fù)的主要原因與正確的操作技巧,如果你對DB2數(shù)據(jù)庫崩潰后用事務(wù)日志恢復(fù)的原與正確的操作技巧心存好奇的話,以下的文章將會揭開它的神秘面紗。
日志, 事務(wù), 技巧, 原理日志, 事務(wù), 技巧, 原理
在系統(tǒng)崩潰之后,使用DB2的事務(wù)日志恢復(fù)數(shù)據(jù)庫。 您曾多少次碰到過錯誤消息“SQL0946C The transaction log for the database is full?”
在盡力解決該問題時,您是否停下來思考如下兩個問題:1. 為何存在事務(wù)日志;2. 事務(wù)日志記錄服務(wù)的目的是什么呢?
若沒有事務(wù),多個用戶和應(yīng)用程序同時與一個數(shù)據(jù)庫進(jìn)行交互時就必然會破壞數(shù)據(jù)。而如果沒有事務(wù)日志記錄,DB2 UDB中的一些據(jù)庫恢復(fù)方法就不會存在。
如果您還沒有完全理解這些概念,也不必?fù)?dān)憂。我將解釋事務(wù)是什么以及事務(wù)日志記錄背后的機制。然后,我將展示在系統(tǒng)DB2數(shù)據(jù)庫崩潰或程序故障之后,如何使用數(shù)據(jù)庫事務(wù)日志文件中所存儲的信息來使數(shù)據(jù)庫回歸到一致、可用的狀態(tài)。您還可以通過這些重要的日志做更多事情。
事務(wù)
事務(wù)(也稱作工作單元)是指一個或多個SQL操作的序列,這些操作組合成一個單元且通常位于一個應(yīng)用程序進(jìn)程內(nèi)。該單元通常稱作是“原子的”,因為它是不可分的——它的所有工作要么全都執(zhí)行,要么全都不執(zhí)行。一個給定的事務(wù)可以執(zhí)行任何數(shù)目的SQL操作(從一個到幾千個,取決于業(yè)務(wù)邏輯里對于“一步”的定義)。
一個事務(wù)的開始和終止定義了數(shù)據(jù)庫里數(shù)據(jù)一致性的點;要么將事務(wù)里所執(zhí)行的所有操作的結(jié)果應(yīng)用到數(shù)據(jù)庫上,并使之成為***的(已提交),要么將之都撤銷(回滾),使數(shù)據(jù)庫返回到啟動該事務(wù)之前的狀態(tài)。
事務(wù)是在建立到數(shù)據(jù)庫的連接之后***次執(zhí)行SQL語句時或在現(xiàn)有事務(wù)終止時立即啟動。一旦啟動,就可以使用名為原子提交的功能隱式地終止該事務(wù)。通過原子提交,會將每條可執(zhí)行的SQL語句當(dāng)作一個事務(wù)。如果該語句執(zhí)行成功,那它所做的任何修改都將應(yīng)用到數(shù)據(jù)庫上,但如果語句失敗,那修改將被丟棄。
還可以通過執(zhí)行COMMIT或ROLLBACK SQL語句顯式地終止事務(wù)。
這些語句的基本語法是:
- COMMIT <WORK>
- ROLLBACK <WORK>
在COMMIT終止事務(wù)時,會將該事務(wù)從開始時對數(shù)據(jù)庫所做的所有修改變成***性的。使用ROLLBACK,所有修改都將撤銷。
事務(wù)所做的未提交的修改對其他用戶和應(yīng)用程序來說是無法訪問的,除非那些用戶和應(yīng)用程序使用的是未提交讀(UR)隔離。然而,一旦提交了事務(wù)所做的修改,它們對于所有其他用戶和應(yīng)用程序來說就都是可以訪問的了,并且只能通過執(zhí)行新事務(wù)中的新SQL語句來刪除。
事務(wù)日志記錄
在向一個基表進(jìn)行INSERT時,首先在緩沖池中創(chuàng)建一條記錄,該緩沖池與指定該表的數(shù)據(jù)存儲于何處的表空間相關(guān)聯(lián)。每次更新或刪除一條記錄時,就從存儲器中檢索包含該記錄的頁面,并復(fù)制到適當(dāng)?shù)木彌_池中,然后由UPDATE/DELETE進(jìn)行修改。
一旦進(jìn)行了這一修改,就會向日志緩沖器寫入一條反映該動作的記錄,日志緩沖器是內(nèi)存中的另一指定存儲區(qū)(為日志緩沖器預(yù)留的真正存儲大小是由logbufsiz數(shù)據(jù)庫配置參數(shù)控制的)。如果執(zhí)行INSERT,就會寫入一條包含了新行數(shù)據(jù)值的記錄。當(dāng)出現(xiàn)刪除時,就寫入一條包含了該行原始值的記錄。
如果執(zhí)行UPDATE,就寫入一條包含了該行原始值和新值的記錄(在大多數(shù)情況下,通過用該行的更新值在原始值上執(zhí)行EXCLUSIVE OR,為更新操作生成日志記錄)。最終,當(dāng)執(zhí)行INSERT、UPDATE或DELETE的事務(wù)終止時,就將相應(yīng)的COMMIT或ROLLBACK記錄寫入日志緩沖器。
每當(dāng)激活緩沖池I/O頁面清理器,日志緩沖器本身已滿,或者提交或回滾事務(wù)時,就立即將日志緩沖器中存儲的所有記錄寫入磁盤上所存儲的一個或多個事務(wù)日志文件中。如果發(fā)生系統(tǒng)故障,日志緩沖器的不斷刷新將最小化可能丟失的日志記錄數(shù)目。
一旦將與特定事務(wù)相關(guān)聯(lián)的所有日志記錄(包括相應(yīng)的COMMIT或ROLLBACK記錄)成功具體化(externalize)為一個或多個日志文件,就會將事務(wù)本身的結(jié)果復(fù)制到適當(dāng)?shù)谋砜臻g容器以***存儲(已修改的數(shù)據(jù)頁本身仍保留在內(nèi)存中,在必要時可以快速進(jìn)行訪問;它們最終將被改寫)。該過程稱作寫前日志記錄(write-ahead logging),保證對數(shù)據(jù)所做的修改在記錄到數(shù)據(jù)庫之前,總是被具體化為日志文件。
因為多個事務(wù)可以在任何時候使用一個數(shù)據(jù)庫,所以一個日志文件可能包含屬于幾個不同事務(wù)的日志記錄。為了追蹤一條日志記錄屬于哪個事務(wù),要給每條日志記錄分配一個特殊的事務(wù)ID,將之綁定到創(chuàng)建它的事務(wù)。
通過使用事務(wù)ID,可以隨時將與特定事務(wù)相關(guān)聯(lián)的日志記錄寫入一個或多個日志文件,而不影響數(shù)據(jù)一致性——最終,對于終止該事務(wù)的操作的COMMIT或ROLLBACK記錄也將進(jìn)行日志記錄。
崩潰恢復(fù)
在還未提交事務(wù)的修改之前,如果發(fā)生問題——例如,發(fā)生停電或應(yīng)用程序異常終止——會發(fā)生什么事情呢?事務(wù)所做的任何未提交或已回滾的工作都將丟失。此外,如果正在將其數(shù)據(jù)具體化(externalize)到數(shù)據(jù)庫的已提交事務(wù)遭到破壞,該數(shù)據(jù)庫將處于不一致、不可用的狀態(tài)(每當(dāng)嘗試建立連接時,不一致的數(shù)據(jù)庫將生成返回代碼和錯誤消息)。您無法恢復(fù)內(nèi)存中所存儲的事務(wù)記錄,但是可以通過執(zhí)行名為DB2數(shù)據(jù)庫崩潰恢復(fù)的操作,將不一致的數(shù)據(jù)庫恢復(fù)為一致、可用的狀態(tài)。
啟動崩潰恢復(fù)的最常用方法就是從DB2命令行處理器(DB2 Command Line Processor,CLP)執(zhí)行RESTART命令。該命令的基本語法是:
- RESTART [DATABASE | DB]
- [DatabaseName]
- USER [UserName] < USING
- [Password] > >
- < DROP PENDING TABLESPACES
- ( [TS_Name] , ... ) >
- < WRITE RESUME >
其中: DatabaseName 指示分配給嘗試進(jìn)行恢復(fù)的數(shù)據(jù)庫的名稱。
UserName 指示分配給用戶的名稱,崩潰恢復(fù)將在該用戶的權(quán)限下執(zhí)行。
Password 指示與用戶名稱相對應(yīng)的密碼,崩潰恢復(fù)將在該用戶的權(quán)限下執(zhí)行。
TS_Name 指示分配給一個或多個表空間的名稱,如果在嘗試將表空間恢復(fù)為一致狀態(tài)時碰到錯誤,那么這些表空間將被禁用或置為Drop Pending模式。
注意:尖括號(< >)中顯示的參數(shù)是可選的;方括號([ ])中顯示的參數(shù)是必需的;逗號后面加省略號(, ...)表示前面的參數(shù)可以重復(fù)多次。關(guān)于 RESTART 命令的完整語法,請參閱IBM DB2 Universal Database, Version 8 Command Reference(ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2n0e80.pdf)。
如果需要在名為SAMPLE的數(shù)據(jù)庫上執(zhí)行DB2數(shù)據(jù)庫崩潰恢復(fù)操作,就執(zhí)行RESTART DATABASE SAMPLE命令。
您還可以配置數(shù)據(jù)庫,以便每當(dāng)用戶或應(yīng)用程序嘗試連接處于不一致狀態(tài)時,它就會自動啟動崩潰恢復(fù)。僅僅需要將值ON分配給數(shù)據(jù)庫的AUTORESTART配置參數(shù)(每當(dāng)激活數(shù)據(jù)庫或嘗試建立連接時,DB2 Database Manager就檢查數(shù)據(jù)庫的狀態(tài)。當(dāng)autorestart配置參數(shù)設(shè)置為ON時,如果數(shù)據(jù)庫處于不一致的狀態(tài),Database Manager就自動執(zhí)行RESTART命令)。
在進(jìn)行崩潰恢復(fù)時,將分析數(shù)據(jù)庫事務(wù)日志文件中存儲的記錄,并將每條具有相應(yīng)COMMIT記錄的事務(wù)記錄重新應(yīng)用到數(shù)據(jù)庫。重現(xiàn)然后撤銷沒有相應(yīng)COMMIT記錄的所有記錄(這就是為何要為所有更新操作記錄前后信息的原因)。
因為日志記錄頻繁進(jìn)行具體化,且由特定事務(wù)所做的修改只有當(dāng)事務(wù)本身成功終止時才進(jìn)行具體化,所以在故障之后將數(shù)據(jù)庫恢復(fù)到一致性狀態(tài)的能力總是能得到保證。DB2數(shù)據(jù)庫崩潰恢復(fù)只是事務(wù)日志所提供的功能中的一種。
本主題由 hchao 于 2010-3-12 18:12 分類