級(jí)別： 初級(jí)
David Kline, DB2® 供應(yīng)商支持，PartnerWorld® for Developers, IBM 開發(fā)人員技術(shù)支持（DTS）中心 — 達(dá)拉斯
Nanda Pilaka, DB2® 供應(yīng)商支持，PartnerWorld® for Developers, IBM 開發(fā)人員技術(shù)支持（DTS）中心 — 達(dá)拉斯
2003 年 2 月 01 日
DB2 確保數(shù)據(jù)一致性和可恢復(fù)性所使用的主要機(jī)制之一是事務(wù)性日志記錄。本文概述了主要概念，幫助您了解如何能夠控制事務(wù)性日志記錄以最優(yōu)化可恢復(fù)性，并且向您介紹了 DB2 UDB V8.1 中新增的日志特性。
簡介
以下文章適用于 IBM® DB2® Universal Database™ for UNIX®、Linux 和 Windows®
任何數(shù)據(jù)庫管理系統(tǒng)都必須擁有確保數(shù)據(jù)一致性和可恢復(fù)性的機(jī)制。關(guān)系數(shù)據(jù)庫系統(tǒng)為確保那些非常重要的特性所使用的眾多機(jī)制之一是事務(wù)性日志記錄。在本文中，我們將定義和討論事務(wù)性日志記錄的類型。我們將詳細(xì)討論如何分配日志文件、如何存儲(chǔ)它們，以及您可能會(huì)遇到什么樣的錯(cuò)誤。最后，我們將討論 V8 中可用的新特性，這些特性使事務(wù)性日志記錄變得比以往更加可伸縮并且更通用。
事務(wù)性日志記錄是什么？
數(shù)據(jù)庫存儲(chǔ)了供應(yīng)用程序訪問和處理的數(shù)據(jù)。那些應(yīng)用程序會(huì)插入、讀取、更新或刪除數(shù)據(jù)。每一個(gè)這樣的活動(dòng)都是在一個(gè)事務(wù)中執(zhí)行的，該事務(wù)被 定義成“應(yīng)用程序過程中一個(gè)可恢復(fù)的操作序列”。除非已經(jīng)提交了事務(wù)（也稱作“工作單元”），否則它不會(huì)影響數(shù)據(jù)庫。
將數(shù)據(jù)庫操作組合到事務(wù)中只是確保數(shù)據(jù)一致性解決方案的一半。另一半是稱作 預(yù)寫式日志記錄（write-ahead logging）的數(shù)據(jù)庫管理器實(shí)現(xiàn)。不管事務(wù)是否被提交，只要它們發(fā)生，就會(huì)記錄這些事務(wù)。在將任何數(shù)據(jù)從緩沖池寫到數(shù)據(jù)庫結(jié)構(gòu)之前，事務(wù)會(huì)從 日志緩沖區(qū)（log buffer）寫到 日志文件（事務(wù)性日志記錄）。用于記錄事務(wù)的文件叫作 事務(wù)日志 。
事務(wù)性日志記錄的類型不止一種嗎？
DB2 UDB 有兩種可用的日志記錄類型 — 循環(huán)（circular）日志記錄和 歸檔（archive）日志記錄。
循環(huán)日志記錄
循環(huán)日志記錄是數(shù)據(jù)庫使用的缺省日志記錄策略。在此策略中，一旦日志目錄中最后一個(gè)主日志文件被寫滿了，就會(huì)將新的事務(wù)寫到第一個(gè)日志文件中，從而覆蓋現(xiàn)有的日志數(shù)據(jù)。這些新事務(wù)會(huì)繼續(xù)依次覆蓋每個(gè)舊日志文件。這種日志記錄方法確保了所有已提交事務(wù)的數(shù)據(jù)一致性，這樣就可以執(zhí)行應(yīng)急恢復(fù)。
循環(huán)日志記錄通常在數(shù)據(jù)倉庫環(huán)境中使用，在該環(huán)境中，恢復(fù)數(shù)據(jù)庫需要的只是恢復(fù)數(shù)據(jù)庫映象的問題。該策略不應(yīng)該用在線事務(wù)處理（on-line transaction processing，OLTP）環(huán)境，因?yàn)樗豢赡苓M(jìn)行前滾恢復(fù)。下面的圖 1 說明了循環(huán)日志記錄：
圖 1. 循環(huán)日志記錄
歸檔日志記錄
與循環(huán)日志記錄相比，當(dāng)最后一個(gè)日志文件寫滿時(shí)，歸檔日志記錄過程會(huì)創(chuàng)建一個(gè)新的日志文件，這樣將來的事務(wù)就不會(huì)覆蓋現(xiàn)有的日志文件。當(dāng)初始化數(shù)據(jù)庫時(shí)，系統(tǒng)會(huì)在活動(dòng)日志目錄中分配一定數(shù)量、指定大小的主日志文件。這個(gè)數(shù)量由數(shù)據(jù)庫配置參數(shù)（在 下一節(jié)中討論）控制。當(dāng)主日志文件都寫滿時(shí)，就會(huì)“根據(jù)需要”創(chuàng)建輔助日志文件，直到創(chuàng)建了最大數(shù)量的輔助日志文件為止。一旦達(dá)到了這個(gè)數(shù)量，如果需要附加的日志空間，就會(huì)發(fā)出一個(gè)錯(cuò)誤，指出沒有更多的可用日志文件，所有數(shù)據(jù)庫活動(dòng)停止。
利用歸檔日志記錄，就可能采取聯(lián)機(jī)數(shù)據(jù)庫備份，在執(zhí)行這一操作期間，會(huì)繼續(xù)記錄數(shù)據(jù)庫活動(dòng)。如果數(shù)據(jù)庫崩潰或發(fā)生故障，就會(huì)使用全備份映象，然后執(zhí)行使用歸檔日志的前滾操作，通過前滾到日志結(jié)尾，將數(shù)據(jù)庫恢復(fù)到時(shí)間點(diǎn)狀態(tài)或最近的一致狀態(tài)，從而恢復(fù)數(shù)據(jù)庫。
有兩種歸檔日志：
- 聯(lián)機(jī)歸檔日志：它們是駐留在數(shù)據(jù)庫日志目錄（“online”）中、普通數(shù)據(jù)庫活動(dòng)不再需要的日志文件。
- 脫機(jī)歸檔日志：它們是已經(jīng)從數(shù)據(jù)庫日志目錄移到脫機(jī)存儲(chǔ)位置（如備份服務(wù)器）、普通數(shù)據(jù)庫活動(dòng)不需要的日志文件。
圖 2 說明了歸檔日志記錄：
圖 2. 歸檔日志記錄
有什么參數(shù)可以控制日志？
通過數(shù)據(jù)庫配置參數(shù)在數(shù)據(jù)庫級(jí)別上控制事務(wù)性日志記錄。以下是影響事務(wù)性日志記錄的參數(shù)：
LOGRETAIN
該參數(shù)使歸檔日志保留在數(shù)據(jù)庫日志路徑目錄中。通過將它設(shè)置成“RECOVERY”來啟用它，從而允許數(shù)據(jù)庫管理器使用前滾恢復(fù)方法。當(dāng)啟用了 logretain配置參數(shù)時(shí)，就不需要啟用 userexit 。這兩個(gè)參數(shù)中的任何一個(gè)都足以允許前滾恢復(fù)方法。
使用該參數(shù)表示覆蓋了循環(huán)日志記錄（缺省值）。以下是 logretain的有效值：
- No（缺省值）— 表示不保留日志。
- Recovery— 表示保留日志，且可以用于前滾恢復(fù)。此外，如果您使用數(shù)據(jù)復(fù)制，CAPTURE 程序可以將日志中所記錄的更新寫到更改表。
- Capture— 表示只保留日志，這樣 Capture 程序可以將更新寫到更改表。如果沒有裁剪這些日志，那么它們可以用于正向恢復(fù)。注：通常僅當(dāng)為了數(shù)據(jù)復(fù)制而設(shè)置數(shù)據(jù)庫時(shí)，才使用 Capture 設(shè)置。
如果 logretain設(shè)置成“Recovery”或者 userexit設(shè)置成“Yes”（請(qǐng)參閱 下一節(jié)），將保留活動(dòng)日志文件，而且這些文件將變成聯(lián)機(jī)歸檔日志文件，以便在前滾恢復(fù)中使用。這稱為日志保留記錄。
在將 logretain設(shè)置成“Recovery”和／或?qū)?userexit設(shè)置成“Yes”之后，必須對(duì)數(shù)據(jù)庫進(jìn)行完全備份。這一狀態(tài)由 backup_pending標(biāo)志參數(shù)表示。
如果 logretain設(shè)置成“No”并且 userexit也設(shè)置成“No”，就不能對(duì)數(shù)據(jù)庫執(zhí)行前滾恢復(fù)，而且可恢復(fù)性僅限于最新的數(shù)據(jù)庫備份。
當(dāng) logretain設(shè)置成“Capture”時(shí)，在 Capture 程序完成時(shí)，它會(huì)調(diào)用 PRUNE LOGFILE 命令來刪除日志文件。雖然如果不裁剪日志，這些日志就可以用于正向恢復(fù)，但如果您想要確保可以對(duì)數(shù)據(jù)庫執(zhí)行前滾恢復(fù)，就不應(yīng)該將 logretain設(shè)置成“Capture”。
如果 logretain設(shè)置成“No”并且 userexit也設(shè)置成“No”，就不會(huì)保留日志。在這種情況下，數(shù)據(jù)庫管理器會(huì)刪除 logpath目錄中的所有日志文件（包括聯(lián)機(jī)歸檔日志文件），分配新的活動(dòng)日志文件，并且回復(fù)到循環(huán)日志記錄。
當(dāng) logretain配置參數(shù)設(shè)置成“RECOVERY”時(shí)，日志文件將保留在活動(dòng)日志路徑中。活動(dòng)日志路徑由數(shù)據(jù)庫配置文件中的“日志文件路徑（Path to Log Files）（ logpath）”或“更改的日志文件路徑（Changed Path to Log Files）（ newlogpath）”值確定。
USEREXIT
該參數(shù)使數(shù)據(jù)庫管理器調(diào)用用戶出口程序來歸檔和檢索日志。啟用了用戶出口之后，就允許前滾恢復(fù)。當(dāng)啟用了 userexit配置參數(shù)時(shí)，就不需要啟用 logretain。這兩個(gè)參數(shù)中的任何一個(gè)都足以允許前滾恢復(fù)方法。
使用該參數(shù)表示覆蓋了循環(huán)日志記錄（缺省值）。 userexit包含有 logretain的功能，反之卻不成立。
當(dāng)使用 userexit 配置參數(shù)或 logretain配置參數(shù)以允許前滾恢復(fù)時(shí)，活動(dòng)日志路徑非常重要。當(dāng)啟用了 userexit配置參數(shù)時(shí)，會(huì)調(diào)用用戶出口來歸檔日志文件，并將它們移到活動(dòng)日志路徑以外的位置。
以下是該參數(shù)的有效值：
如果啟用了該參數(shù)，無論 logretain參數(shù)如何設(shè)置，都會(huì)執(zhí)行日志保留記錄。該參數(shù)還表示用戶出口程序應(yīng)該用于歸檔和檢索日志文件。當(dāng)數(shù)據(jù)庫管理器關(guān)閉日志文件時(shí)，會(huì)歸檔日志文件。當(dāng) ROLLFORWARD 實(shí)用程序需要使用日志文件來恢復(fù)數(shù)據(jù)庫時(shí)，就會(huì)檢索它們。
在啟用了參數(shù) logretain和／或 userexit時(shí)，必須對(duì)數(shù)據(jù)庫進(jìn)行完全備份。這一狀態(tài)由 backup_pending標(biāo)志參數(shù)表示。
如果取消選擇這兩個(gè)參數(shù)，就不能對(duì)數(shù)據(jù)庫進(jìn)行前滾恢復(fù)，因?yàn)閷⒉辉俦Ａ羧罩尽Ｔ谶@種情況下，數(shù)據(jù)庫管理器會(huì)刪除 logpath目錄中的所有日志文件（包括聯(lián)機(jī)歸檔日志文件），分配新的活動(dòng)日志文件，并且回復(fù)到循環(huán)日志記錄。
LOGPRIMARY
該參數(shù)指定要?jiǎng)?chuàng)建的主日志的數(shù)量。
無論主日志是空的還是滿的，所需的磁盤空間量都是相同的。因此，如果您配置的日志數(shù)量比需要的多，那么您就不必要地多使用了磁盤空間。如果您配置的日志太少了，就會(huì)遇到“日志滿”情況。當(dāng)選擇要配置的日志數(shù)量時(shí)，必須考慮您生成的每個(gè)日志的大小，以及您的應(yīng)用程序是否能處理“日志滿”情況。
如果您對(duì)現(xiàn)有數(shù)據(jù)庫啟用前滾恢復(fù)，將主日志的數(shù)量更改成當(dāng)前正在使用的主日志和輔助日志的數(shù)量總和，再加 1。對(duì)于為了前滾恢復(fù)而在數(shù)據(jù)庫中啟用 long varchar和 LOB字段這樣的附加信息，也會(huì)記錄在日志中。
對(duì)于 V7.2，總的日志文件大小限制是 32 GB，對(duì)于 V8.1，這個(gè)限制是 256 GB。即，日志文件的數(shù)量（LOGPRIMARY ＋ LOGSECOND）乘以以字節(jié)為單位的每個(gè)日志文件的大小（LOGFILSIZ * 4096）必須分別小于 32 GB 或 256 GB。
LOGSECOND
該參數(shù)指定為恢復(fù)日志文件（僅當(dāng)需要時(shí)）而創(chuàng)建和使用的輔助日志文件的數(shù)量。請(qǐng)注意，日志文件的總數(shù)由以下等式限制：
logprimary＋ logsecond<＝ 128（DB2 UDB V7.2），256（DB2 UDB V8.1）
當(dāng)主日志文件滿了時(shí)，就會(huì)按需要每次分配一個(gè)輔助日志文件（大小為 logfilsiz），最多達(dá)到由該參數(shù)控制的最大數(shù)量。如果所需的輔助日志文件的數(shù)量比該參數(shù)允許的數(shù)量大，就會(huì)將一個(gè)錯(cuò)誤代碼返回到應(yīng)用程序，并且會(huì)停止對(duì)數(shù)據(jù)庫的操作。
LOGFILSZ
該參數(shù)確定了每個(gè)已配置日志的頁數(shù)量。一頁的大小是 4 KB。每個(gè)主日志的大小（頁數(shù)量）對(duì)數(shù)據(jù)庫性能有直接影響。當(dāng)將數(shù)據(jù)庫配置成保留日志，每當(dāng)寫滿一個(gè)日志時(shí)，就會(huì)發(fā)出一個(gè)分配和初始化一個(gè)新日志的請(qǐng)求。增加日志大小會(huì)減少為分配和初始化新日志所需的請(qǐng)求數(shù)量。但是，請(qǐng)注意，日志大小越大，格式化每個(gè)新日志所花費(fèi)的時(shí)間就越多。格式化新日志對(duì)于連接到數(shù)據(jù)庫的應(yīng)用程序是透明的，而且也不會(huì)影響數(shù)據(jù)庫性能。
LOGBUFSZ
該參數(shù)允許您指定數(shù)據(jù)庫共享內(nèi)存的數(shù)量，在將日志記錄寫到磁盤之前，用該共享內(nèi)存作為這些記錄的緩沖區(qū)。當(dāng)發(fā)生以下情況之一時(shí)，會(huì)將日志記錄寫到磁盤：
- 事務(wù)提交。
- 日志緩沖區(qū)滿了。
- 引起寫操作的其它一些內(nèi)部數(shù)據(jù)庫管理器事件。
緩沖日志記錄將導(dǎo)致使日志文件 I/O 更有效，因?yàn)閷⑷罩居涗泴懙酱疟P的頻率將更低，而每次寫入磁盤的日志記錄則更多。
MINCOMMIT
該參數(shù)允許您延遲將日志記錄寫到磁盤，直到已經(jīng)執(zhí)行了所規(guī)定的最小數(shù)量的提交。當(dāng)您有多個(gè)針對(duì)數(shù)據(jù)庫的應(yīng)用程序正在運(yùn)行，并且應(yīng)用程序在非常短的時(shí)間段里請(qǐng)求了許多提交，那么該延遲可以幫助減少與寫日志記錄相關(guān)的數(shù)據(jù)庫管理器開銷，從而提高性能。
這種提交分組只有在該參數(shù)的值大于 1 且連接到數(shù)據(jù)庫的應(yīng)用程序數(shù)量大于該參數(shù)的值時(shí)才會(huì)發(fā)生。當(dāng)執(zhí)行提交分組時(shí)，應(yīng)用程序提交請(qǐng)求將被掛起，直到以下兩種情況有一種先發(fā)生：時(shí)間過去一秒或者提交請(qǐng)求的數(shù)量等于該參數(shù)的值。
NEWLOGPATH
數(shù)據(jù)庫日志最初創(chuàng)建在名為 SQLOGDIR 的目錄中，該目錄是數(shù)據(jù)庫目錄的子目錄。可以通過將該配置參數(shù)的值更改成指向另一個(gè)目錄或設(shè)備來更改放置活動(dòng)日志和將來歸檔日志的位置。如果將數(shù)據(jù)庫配置成進(jìn)行前滾恢復(fù)，那么就不會(huì)將當(dāng)前存儲(chǔ)在數(shù)據(jù)庫日志路徑目錄中的歸檔日志移到新的位置。
因?yàn)槟梢愿娜罩韭窂轿恢茫郧皾L恢復(fù)所需的日志可能會(huì)在不同的目錄中或在不同的設(shè)備上存在。在前滾過程中可以更改此配置參數(shù)以允許您訪問多個(gè)位置中的日志。
在數(shù)據(jù)庫處于一致狀態(tài)之前，將不會(huì)更改對(duì) newlogpath的值。信息性數(shù)據(jù)庫配置參數(shù) database_consistent表示數(shù)據(jù)庫的狀態(tài)。
注：數(shù)據(jù)庫管理器每次寫一個(gè)事務(wù)日志。可以是活動(dòng)狀態(tài)的事務(wù)的總大小受數(shù)據(jù)庫配置參數(shù)限制：
日志空間
>= LOGFILSIZ * LOGPRIMARY * 4096 字節(jié)
<= LOGFILSIZ * (LOGPRIMARY + LOGSECOND) * 4096 字節(jié) <= 32 GB（對(duì)于 V7.2）或 <= 256 GB（對(duì)于 V8.1）
如何分配日志文件，將它們存儲(chǔ)在哪里？
如何分配日志文件？
一旦更新了在前一節(jié)討論的所有數(shù)據(jù)庫配置參數(shù)，就需要確保所有應(yīng)用程序從數(shù)據(jù)庫斷開連接。當(dāng)應(yīng)用程序重新連接時(shí)，新的設(shè)置將生效，日志文件將預(yù)先分配到您的磁盤。所分配的日志文件數(shù)量基于 logprimary參數(shù)值和活動(dòng)日志目錄中日志文件的總數(shù)。
使用 歸檔日志記錄 時(shí)，如果您沒有把舊的日志文件從活動(dòng)日志目錄中移走，它們將累積起來，并與活動(dòng)日志文件共享該目錄。例如，讓我們假設(shè)在活動(dòng)日志目錄中有五個(gè)日志文件。其中兩個(gè)日志文件是完全滿的，而且已被提交，因此還有三個(gè)日志文件是空閑的。在將 logprimary參數(shù)從 五更新成 八之后第一次與數(shù)據(jù)庫連接時(shí)，會(huì)多分配五個(gè)日志文件到活動(dòng)日志目錄中，從而確保總共有八個(gè)空閑的日志文件（3 個(gè)空閑文件 ＋ 5 個(gè)新文件 ＝ 8 個(gè)空閑文件）。
使用 循環(huán)日志記錄時(shí)，如果 logretain或 userexit參數(shù)被設(shè)置成 no，就會(huì)重用日志文件。這表示在第一次連接到數(shù)據(jù)庫時(shí)，主日志的總數(shù)等于駐留在活動(dòng)日志目錄中的日志文件的總數(shù)。如果我們采用前一個(gè)示例并將 logprimary參數(shù)從 五更新成 八，那么只會(huì)多分配三個(gè)日志文件到活動(dòng)日志目錄中，即使某些日志文件完全是滿的（5 個(gè)空閑的 ＋ 3 個(gè)新的 ＝ 8）。
正如我們?cè)谇耙还?jié)中討論的，根據(jù) logfilsiz參數(shù)為所創(chuàng)建的每個(gè)日志文件分配相同的空間。如果更改了 logfilsiz參數(shù)值，具有事務(wù)性數(shù)據(jù)的現(xiàn)有日志文件并不受影響，而將創(chuàng)建新的日志文件并將空的日志文件的大小增加到新值。
請(qǐng)注意，反映每個(gè)日志文件的大小主要是預(yù)先分配的空間，一些日志頭控制字符除外。通過在日志文件中預(yù)先分配這個(gè)空間，數(shù)據(jù)庫管理器就不必在它需要該日志文件時(shí)進(jìn)行空間分配。將空間分配到硬盤驅(qū)動(dòng)器將耗費(fèi)大量時(shí)間和資源，因此最好在需要空間時(shí)已經(jīng)有了可用的空間。
logsecond參數(shù)是 V7.2 和 V8 之間唯一有區(qū)別的參數(shù)。在 V7.2 中，該參數(shù)只在所有應(yīng)用程序進(jìn)行了斷開連接和重新連接之后才生效。而 V8 允許該參數(shù)在更新之后立即生效。這并不表示您會(huì)在重新連接到數(shù)據(jù)庫之后立即在日志文件目錄中看到新的日志文件。該參數(shù)只會(huì)當(dāng)超過 logprimary值時(shí)才會(huì)分配日志文件，這種情況最有可能在一系列長時(shí)間未提交的事務(wù)期間發(fā)生。
以下是說明 logsecond 如何影響日志分配的示例。您只是將 logprimary 更新成五，將 logsecond 更新成二（預(yù)先分配五個(gè)，當(dāng)需要時(shí)再分配兩個(gè)）。事務(wù)正在運(yùn)行，并用完所有五個(gè)主日志文件，但仍將記錄事務(wù)。當(dāng)需要第六個(gè)日志文件時(shí)，數(shù)據(jù)庫管理器將檢查 logsecond 值并將另一個(gè)日志文件分配到日志目錄。現(xiàn)在需要第七個(gè)日志文件，則分配該文件。由于 logsecond 參數(shù)只指定了兩個(gè)日志文件，因此在第七個(gè)日志文件寫滿之前必須提交事務(wù)，否則會(huì)返回一個(gè)錯(cuò)誤并且事務(wù)將回滾。
那么提交之后，日志文件會(huì)發(fā)生什么情況？為了保持 logprimary值，數(shù)據(jù)庫管理器將根據(jù)前一個(gè)事務(wù)中使用了多少日志文件來分配新的日志文件。例如，如果寫滿了三個(gè)日志文件，就將創(chuàng)建另三個(gè)日志文件以確保空閑日志文件的總數(shù)等于 logprimary值。
當(dāng)所有應(yīng)用程序從數(shù)據(jù)庫斷開連接時(shí)，會(huì)發(fā)生什么？當(dāng)重新連接到數(shù)據(jù)庫時(shí)，前一個(gè)連接中的最后一個(gè)要放置數(shù)據(jù)的日志文件將被截?cái)啵顾拇笮〉扔谖募袛?shù)據(jù)的大小。這會(huì)除去可用空間，并允許根據(jù)上面說明的數(shù)據(jù)庫配置參數(shù)精確地分配空間。
日志文件存儲(chǔ)在哪里？
缺省情況下，日志文件存儲(chǔ)在以下目錄中：
在 Windows 上：c:\<instance name>\NODE0000\SQL00001\SQLOGDIR
在 UNIX 上：<instance home directory>/<instance name>/NODE0000/SQL00001/SQLOGDIR
在上述目錄路徑中，對(duì)于所創(chuàng)建的每個(gè)數(shù)據(jù)庫，會(huì)有一個(gè) SQLxxxxx（“xxxxx”是以 0 開頭的數(shù)字）目錄。如果在 DB2 實(shí)例中有多個(gè)物理數(shù)據(jù)庫，就很難知道哪個(gè) SQLxxxxx 目錄屬于哪個(gè)數(shù)據(jù)庫。要解決這個(gè)問題，只要輸入以下 DB2 命令：
db2 "list database directory on c:"
|
其中 c: 是數(shù)據(jù)庫駐留的盤符。
在 UNIX 上，您要指定：
db2 "list database directory on /<instance home directory>"
|
以下是上述命令返回的輸出樣本：
清單 1. DB2 數(shù)據(jù)庫目錄
Database 1 entry:
Database alias = DWCTRLDB
Database name = DWCTRLDB
Database directory = SQL00001
Database release level = 9.00
Comment =
Directory entry type = Home
Catalog node number = 0
Node number = 0
Database 2 entry:
Database alias = SAMPLE
Database name = SAMPLE
Database directory = SQL00002
Database release level = 9.00
Comment =
Directory entry type = Home
Catalog node number = 0
Node number = 0
Database 3 entry:
Database alias = UTFDB
Database name = UTFDB
Database directory = SQL00003
Database release level = 9.00
Comment =
Directory entry type = Home
Catalog node number = 0
Node number = 0
|
正如以上所示，每個(gè) SQLxxxxx 目錄與一個(gè)數(shù)據(jù)庫名稱相關(guān)聯(lián)。當(dāng)然，如果您的數(shù)據(jù)庫沒有創(chuàng)建在缺省目錄中或者您更改了日志文件路徑，您可以檢查數(shù)據(jù)庫配置文件中的“日志文件路徑”或 newlogpath參數(shù)。您也許還要確保正在尋找的數(shù)據(jù)庫駐留在正在搜索的實(shí)例中。
以下是在 Windows 上存儲(chǔ)日志文件的位置的直觀表示（缺省情況下）：
圖 3. 日志文件的 Windows Explorer 視圖
在上圖中，您可以看到一個(gè)名為 SQL0003 的數(shù)據(jù)庫目錄。根據(jù)我們從前面的“list database...”命令的輸出判定，該目錄與 UTFDB 數(shù)據(jù)庫相關(guān)聯(lián)。
事務(wù)性日志記錄會(huì)引起錯(cuò)誤的常見情形
我們已經(jīng)討論了影響日志記錄的數(shù)據(jù)庫配置參數(shù)以及如何分配日志，但現(xiàn)在應(yīng)該討論當(dāng)沒有正確設(shè)置參數(shù)時(shí)您可能遇到的問題。不正確地設(shè)置日志參數(shù)不僅對(duì)發(fā)出長時(shí)間運(yùn)行事務(wù)的用戶造成嚴(yán)重?fù)p害，而且還可能損害共享系統(tǒng)的其它用戶。以下是您可能遇到的一些問題：
- 在 IMPORT 操作期間，突然彈出一條警告，它看起來如下：
清單 2. import 操作的警告示例
C:\data>db2 "import from temp2.ixf of ixf create into temp2"
SQL3150N The H record in the PC/IXF file has product "DB2 02.00", date
"20010910", and time "171430".
SQL3153N The T record in the PC/IXF file has name "temp2.ixf", qualifier "",
and source " ".
SQL3109N The utility is beginning to load data from file "temp2.ixf".
SQL3186W Data was not loaded into the database, because the log was full.
SQLCODE "-964" was returned. A commit will be attempted and the operation
will continue if the commit is successful.
SQL0964C The transaction log for the database is full. SQLSTATE=57011
SQL3221W ...Begin COMMIT WORK. Input Record Count = "78".
SQL3222W ...COMMIT of any database changes was successful.
|
由于 IMPORT 操作實(shí)質(zhì)上是使用 SQL 插入進(jìn)行行移動(dòng)并關(guān)閉了自動(dòng)提交，所以您會(huì)看到上面的警告，說明日志文件已滿并將試圖提交事務(wù)。如果將數(shù)據(jù)庫配置參數(shù) logretain設(shè)置成打開（ON），會(huì)啟用數(shù)據(jù)庫的日志恢復(fù)，并且在 IMPORT 操作可以繼續(xù)之前需要?jiǎng)?chuàng)建新的日志文件。知道您是否需要大日志文件和／或眾多日志文件的組合非常重要，因?yàn)橐〞r(shí)間來分配這些日志文件。如果將 logretain設(shè)置成 OFF，那么將進(jìn)行循環(huán)日志記錄，從而消除了創(chuàng)建新日志文件的必要性。
如果您正將非常多的行導(dǎo)入數(shù)據(jù)庫，在每天系統(tǒng)活動(dòng)較少的時(shí)候更新數(shù)據(jù)庫配置日志記錄參數(shù)也許比較好，這樣分配日志文件不會(huì)給系統(tǒng)帶來過多壓力。DB2 UDB V7.2 允許分配總共 32 GB 的日志空間，而 V8 允許 256 GB 的海量空間。
另一個(gè)考慮事項(xiàng)是使用 LOAD 操作，它允許您對(duì)某個(gè)表使用 NOT LOGGED INITIALLY 選項(xiàng)。顧名思義，當(dāng)執(zhí)行 LOAD 時(shí)，該選項(xiàng)不會(huì)引起日志記錄操作。但它也阻止了表成為可恢復(fù)的，因此在執(zhí)行 LOAD 之后立即備份數(shù)據(jù)庫非常重要。請(qǐng)注意，NOT LOGGED INITIALLY 選項(xiàng)只適合于當(dāng)前命令的執(zhí)行，數(shù)據(jù)庫管理器會(huì)繼續(xù)記錄在 LOAD 操作完成之后發(fā)生的事務(wù)。
-
當(dāng)某個(gè)應(yīng)用程序在一個(gè)工作單元中執(zhí)行許多 INSERT、DELETE 或 UPDATE 語句時(shí)，會(huì)發(fā)生另一種常見情況。自動(dòng)提交被禁用，只有在工作單元完成之后，才會(huì)顯式地執(zhí)行提交。與可以識(shí)別日志文件寫滿情況并執(zhí)行提交的 IMPORT 實(shí)用程序不同，應(yīng)用程序中的邏輯也許還沒有考慮這個(gè)問題，那么它將由于以下錯(cuò)誤而失敗：
SQL0964C The transaction log for the database is full. SQLSTATE=57011
|
因此，如果您的應(yīng)用程序調(diào)用具有罕見長事務(wù)的文件，根據(jù)您的日志設(shè)置包含頻繁的提交操作，或者更新數(shù)據(jù)庫日志記錄參數(shù)，也許是好辦法。
-
當(dāng)對(duì)表執(zhí)行 RUNSTATS 或 REORG 時(shí)，可能出現(xiàn)第三個(gè)問題。當(dāng)?shù)教幰苿?dòng)表數(shù)據(jù)時(shí)，RUNSTATS 和 REORG 實(shí)用程序都使用日志文件。如果遇到 SQL0964C 錯(cuò)誤，就需要增加數(shù)據(jù)庫日志文件參數(shù)的值。
 |
|
V8 的新特性
由于 V8 提供了一些很棒的新特性，所以 DB2 日志記錄也向前邁了一大步。以下是其中的一些新特性：
日志記錄可伸縮性— 對(duì)于那些喜歡使用非常長的事務(wù)的人，DB2 已經(jīng)將最大活動(dòng)日志空間從 32 GB（V7.2）增加到 256 GB。這是 logprimary和 logsecond參數(shù)的總和可能達(dá)到的字節(jié)總數(shù)。
飄浮事務(wù)現(xiàn)在可以超過數(shù)據(jù)庫日志記錄參數(shù)指定的限制，或者如果將 userexit數(shù)據(jù)庫配置參數(shù)設(shè)置成打開，那么它甚至可以超過活動(dòng)日志路徑中的可用磁盤空間。通過將 logsecond更新成 -1（無窮大）來設(shè)置該新特性。其想法是由于在長事務(wù)期間，日志文件將經(jīng)常由 userexit 程序歸檔，在活動(dòng)日志目錄中始終要有新的空間來存放額外的日志文件。在數(shù)據(jù)庫上運(yùn)行的飄浮事務(wù)的大小或數(shù)量沒有限制。但是其缺點(diǎn)是：如果發(fā)生回滾，就可能有性能影響，因?yàn)?userexit 程序?qū)⑿枰獜臍w檔日志路徑中檢索未提交的日志文件。此外，如果將 logsecond設(shè)置成 -1，新的輔助日志分配將不受（ logprimary＋ logsecond）<＝ 256 等式的限制。
DB2_BLOCK_ON_DISK_FULL注冊(cè)表變量將被 BLK_LOG_DSK_FUL 替換。當(dāng)啟用該選項(xiàng)時(shí)，在活動(dòng)日志路徑上發(fā)生磁寫盤滿情況時(shí)正在運(yùn)行的應(yīng)用程序?qū)⒉粫?huì)斷開連接。那樣 DBA 就有時(shí)間刪除文件或擴(kuò)大文件系統(tǒng)，從而允許事務(wù)完成。當(dāng)遇到日志寫滿情況，仍允許對(duì)數(shù)據(jù)庫的讀訪問。
日志文件鏡像— DB2 UDB V7 中的 newlogpath2注冊(cè)表變量被 DB2 UDB V8 中的 mirrorlogpath數(shù)據(jù)庫配置參數(shù)替換。這一變化將允許數(shù)據(jù)庫級(jí)別上的顆粒度，而不是實(shí)例級(jí)別上的顆粒度。 newlogpath2變量和 mirrorlogpath參數(shù)具有相同的作用 — 它們用于實(shí)現(xiàn)雙重或鏡像日志記錄。 mirrorlogpath必須指向全限定路徑名（即，絕對(duì)路徑名）。
日志記錄速度更快— 通過異步日志寫操作提高日志記錄器的性能。這在 SMP 環(huán)境中特別有益，因?yàn)樗鼈兡軌蚶卯惒教幚怼?