DB2崩潰后用事務(wù)日志恢復(fù)的原理和技巧（1）
在系統(tǒng)崩潰之后，使用DB2的事務(wù)日志恢復(fù)數(shù)據(jù)庫?！ ∧嗌俅闻龅竭^錯(cuò)誤消息“SQL0946C The transaction log for the database is full?” 在盡力解決該問題時(shí)，您是否停下來思考如下兩個(gè)問題：1. 為何存在事務(wù)日志；2. 事務(wù)日志記錄服務(wù)的目的是什么呢？ 若沒有事務(wù)，多個(gè)用戶和應(yīng)用程序同時(shí)與一個(gè)數(shù)據(jù)庫進(jìn)行交互時(shí)就必然會(huì)破壞數(shù)據(jù)。而假如沒有事務(wù)日志記錄，DB2 UDB中的一些據(jù)庫恢復(fù)方法就不會(huì)存在。 假如您還沒有完全理解這些概念，也不必?fù)?dān)憂。我將解釋事務(wù)是什么以及事務(wù)日志記錄背后的機(jī)制。然后，我將展示在系統(tǒng)崩潰或程序故障之后，如何使用數(shù)據(jù)庫事務(wù)日志文件中所存儲(chǔ)的信息來使數(shù)據(jù)庫回歸到一致、可用的狀態(tài)?！ ∧€可以通過這些重要的日志做更多事情。在今后的專欄中，我將展示如何使用事務(wù)日志文件重現(xiàn)操作，以將數(shù)據(jù)庫恰好恢復(fù)到給定時(shí)間點(diǎn)所處的狀態(tài)?！ ?/div>
事務(wù) 事務(wù)（也稱作工作單元）是指一個(gè)或多個(gè)SQL操作的序列，這些操作組合成一個(gè)單元且通常位于一個(gè)應(yīng)用程序進(jìn)程內(nèi)。該單元通常稱作是“原子的”，因?yàn)樗遣豢煞值摹乃泄ぷ饕慈紙?zhí)行，要么全都不執(zhí)行。一個(gè)給定的事務(wù)可以執(zhí)行任何數(shù)目的SQL操作（從一個(gè)到幾千個(gè)，取決于業(yè)務(wù)邏輯里對(duì)于“一步”的定義）?！ ∫粋€(gè)事務(wù)的開始和終止定義了數(shù)據(jù)庫里數(shù)據(jù)一致性的點(diǎn)；要么將事務(wù)里所執(zhí)行的所有操作的結(jié)果應(yīng)用到數(shù)據(jù)庫上，并使之成為永久的（已提交），要么將之都撤銷（回滾），使數(shù)據(jù)庫返回到啟動(dòng)該事務(wù)之前的狀態(tài)?！ ∈聞?wù)是在建立到數(shù)據(jù)庫的連接之后第一次執(zhí)行SQL語句時(shí)或在現(xiàn)有事務(wù)終止時(shí)立即啟動(dòng)。一旦啟動(dòng)，就可以使用名為原子提交的功能隱式地終止該事務(wù)。通過原子提交，會(huì)將每條可執(zhí)行的SQL語句當(dāng)作一個(gè)事務(wù)。假如該語句執(zhí)行成功，那它所做的任何修改都將應(yīng)用到數(shù)據(jù)庫上，但假如語句失敗，那修改將被丟棄。 還可以通過執(zhí)行COMMIT或ROLLBACK SQL語句顯式地終止事務(wù)。
這些語句的基本語法是：
COMMIT <WORK> ROLLBACK <WORK>
在COMMIT終止事務(wù)時(shí)，會(huì)將該事務(wù)從開始時(shí)對(duì)數(shù)據(jù)庫所做的所有修改變成永久性的。
使用ROLLBACK，所有修改都將撤銷?！ ?br>
事務(wù)所做的未提交的修改對(duì)其他用戶和應(yīng)用程序來說是無法訪問的，除非那些用戶和應(yīng)用程序使用的是未提交讀（UR）隔離。然而，一旦提交了事務(wù)所做的修改，它們對(duì)于所有其他用戶和應(yīng)用程序來說就都是可以訪問的了，并且只能通過執(zhí)行新事務(wù)中的新SQL語句來刪除?！ ?br>
事務(wù)日志記錄 在向一個(gè)基表進(jìn)行INSERT時(shí)，首先在緩沖池中創(chuàng)建一條記錄，該緩沖池與指定該表的數(shù)據(jù)存儲(chǔ)于何處的表空間相關(guān)聯(lián)。每次更新或刪除一條記錄時(shí)，就從存儲(chǔ)器中檢索包含該記錄的頁面，并復(fù)制到適當(dāng)?shù)木彌_池中，然后由UPDATE/DELETE進(jìn)行修改。一旦進(jìn)行了這一修改，就會(huì)向日志緩沖器寫入一條反映該動(dòng)作的記錄，日志緩沖器是內(nèi)存中的另一指定存儲(chǔ)區(qū)（為日志緩沖器預(yù)留的真正存儲(chǔ)大小是由logbufsiz數(shù)據(jù)庫配置參數(shù)控制的）。假如執(zhí)行INSERT，就會(huì)寫入一條包含了新行數(shù)據(jù)值的記錄。當(dāng)出現(xiàn)刪除時(shí)，就寫入一條包含了該行原始值的記錄。假如執(zhí)行UPDATE，就寫入一條包含了該行原始值和新值的記錄（在大多數(shù)情況下，通過用該行的更新值在原始值上執(zhí)行EXCLUSIVE OR，為更新操作生成日志記錄）。最終，當(dāng)執(zhí)行INSERT、UPDATE或DELETE的事務(wù)終止時(shí)，就將相應(yīng)的COMMIT或ROLLBACK記錄寫入日志緩沖器?！ ∶慨?dāng)激活緩沖池I/O頁面清理器，日志緩沖器本身已滿，或者提交或回滾事務(wù)時(shí)，就立即將日志緩沖器中存儲(chǔ)的所有記錄寫入磁盤上所存儲(chǔ)的一個(gè)或多個(gè)事務(wù)日志文件中。假如發(fā)生系統(tǒng)故障，日志緩沖器的不斷刷新將最小化可能丟失的日志記錄數(shù)目。一旦將與特定事務(wù)相關(guān)聯(lián)的所有日志記錄（包括相應(yīng)的COMMIT或ROLLBACK記錄）成功具體化（externalize）為一個(gè)或多個(gè)日志文件，就會(huì)將事務(wù)本身的結(jié)果復(fù)制到適當(dāng)?shù)谋砜臻g容器以永久存儲(chǔ)（已修改的數(shù)據(jù)頁本身仍保留在內(nèi)存中，在必要時(shí)可以快速進(jìn)行訪問；它們最終將被改寫）。該過程稱作寫前日志記錄（write-ahead logging），保證對(duì)數(shù)據(jù)所做的修改在記錄到數(shù)據(jù)庫之前，總是被具體化為日志文件。
因?yàn)槎鄠€(gè)事務(wù)可以在任何時(shí)候使用一個(gè)數(shù)據(jù)庫，所以一個(gè)日志文件可能包含屬于幾個(gè)不同事務(wù)的日志記錄。為了追蹤一條日志記錄屬于哪個(gè)事務(wù)，要給每條日志記錄分配一個(gè)非凡的事務(wù)ID，將之綁定到創(chuàng)建它的事務(wù)。通過使用事務(wù)ID，可以隨時(shí)將與特定事務(wù)相關(guān)聯(lián)的日志記錄寫入一個(gè)或多個(gè)日志文件，而不影響數(shù)據(jù)一致性——最終，對(duì)于終止該事務(wù)的操作的COMMIT或ROLLBACK記錄也將進(jìn)行日志記錄。 崩潰恢復(fù) 在還未提交事務(wù)的修改之前，假如發(fā)生問題——例如，發(fā)生停電或應(yīng)用程序異常終止——會(huì)發(fā)生什么事情呢？事務(wù)所做的任何未提交或已回滾的工作都將丟失。此外，假如正在將其數(shù)據(jù)具體化（externalize）到數(shù)據(jù)庫的已提交事務(wù)遭到破壞，該數(shù)據(jù)庫將處于不一致、不可用的狀態(tài)（每當(dāng)嘗試建立連接時(shí)，不一致的數(shù)據(jù)庫將生成返回代碼和錯(cuò)誤消息）。您無法恢復(fù)內(nèi)存中所存儲(chǔ)的事務(wù)記錄，但是可以通過執(zhí)行名為崩潰恢復(fù)的操作，將不一致的數(shù)據(jù)庫恢復(fù)為一致、可用的狀態(tài)?！ ?dòng)崩潰恢復(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ù)庫的名稱?！ serName 指示分配給用戶的名稱，崩潰恢復(fù)將在該用戶的權(quán)限下執(zhí)行。 上一頁1234下一頁 Password 指示與用戶名稱相對(duì)應(yīng)的密碼，崩潰恢復(fù)將在該用戶的權(quán)限下執(zhí)行。 TS_Name 指示分配給一個(gè)或多個(gè)表空間的名稱，假如在嘗試將表空間恢復(fù)為一致狀態(tài)時(shí)碰到錯(cuò)誤，那么這些表空間將被禁用或置為Drop Pending模式?！ ∽⒅兀杭饫ㄌ?hào)（< >）中顯示的參數(shù)是可選的；方括號(hào)（[ ]）中顯示的參數(shù)是必需的；逗號(hào)后面加省略號(hào)（, ...）表示前面的參數(shù)可以重復(fù)多次。關(guān)于 RESTART 命令的完整語法，請(qǐng)參閱IBM DB2 Universal Database, Version 8 Command Reference(ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2n0e80.pdf)?！ 〖偃缧枰诿麨镾AMPLE的數(shù)據(jù)庫上執(zhí)行崩潰恢復(fù)操作，就執(zhí)行RESTART DATABASE SAMPLE命令?！ ∧€可以配置數(shù)據(jù)庫，以便每當(dāng)用戶或應(yīng)用程序嘗試連接處于不一致狀態(tài)時(shí)，它就會(huì)自動(dòng)啟動(dòng)崩潰恢復(fù)。僅僅需要將值ON分配給數(shù)據(jù)庫的AUTORESTART配置參數(shù)（每當(dāng)激活數(shù)據(jù)庫或嘗試建立連接時(shí)，DB2 Database Manager就檢查數(shù)據(jù)庫的狀態(tài)。當(dāng)autorestart配置參數(shù)設(shè)置為ON時(shí)，假如數(shù)據(jù)庫處于不一致的狀態(tài)，Database Manager就自動(dòng)執(zhí)行RESTART命令）?！ ≡谶M(jìn)行崩潰恢復(fù)時(shí)，將分析數(shù)據(jù)庫事務(wù)日志文件中存儲(chǔ)的記錄，并將每條具有相應(yīng)COMMIT記錄的事務(wù)記錄重新應(yīng)用到數(shù)據(jù)庫。重現(xiàn)然后撤銷沒有相應(yīng)COMMIT記錄的所有記錄（這就是為何要為所有更新操作記錄前后信息的原因）。因?yàn)槿罩居涗涱l繁進(jìn)行具體化，且由特定事務(wù)所做的修改只有當(dāng)事務(wù)本身成功終止時(shí)才進(jìn)行具體化，所以在故障之后將數(shù)據(jù)庫恢復(fù)到一致性狀態(tài)的能力總是能得到保證。 崩潰恢復(fù)只是事務(wù)日志所提供的功能中的一種。在處理前滾恢復(fù)時(shí)，我將展示如何可以使用事務(wù)日志文件中所存儲(chǔ)的記錄將數(shù)據(jù)庫恢復(fù)到任何指定時(shí)間點(diǎn)所處的狀態(tài)。本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
