DB2的兩種日誌模式及備份和歸檔的設定

guyuanli發表於2012-09-14

[db2inst1@seagull ~]$ db2sampl

Creating database "SAMPLE"...

Connecting to database "SAMPLE"...

Creating tables and data in schema "DB2INST1"...

'db2sampl' processing complete.[@more@]

[db2inst1@seagull ~]$ db2 connect to sample

Database Connection Information

Database server = DB2/LINUX 9.1.0

SQL authorization ID = DB2INST1

Local database alias = SAMPLE

[db2inst1@seagull ~]$ db2 get db cfg|grep LOG

Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*4)

Log buffer size (4KB) (LOGBUFSZ) = 8

Log file size (4KB) (LOGFILSIZ) = 1000

Number of primary log files (LOGPRIMARY) = 3

Number of secondary log files (LOGSECOND) = 2

Changed path to log files (NEWLOGPATH) =

Path to log files = /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

Overflow log path (OVERFLOWLOGPATH) =

Mirror log path (MIRRORLOGPATH) =

Block log on disk full (BLK_LOG_DSK_FUL) = NO

Percent max primary log space by transaction (MAX_LOG) = 0

Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0

Log retain for recovery enabled (LOGRETAIN) = OFF

First log archive method (LOGARCHMETH1) = OFF

Options for logarchmeth1 (LOGARCHOPT1) =

Second log archive method (LOGARCHMETH2) = OFF

Options for logarchmeth2 (LOGARCHOPT2) =

Log pages during index build (LOGINDEXBUILD) = OFF

[db2inst1@seagull ~]$ db2 update db cfg for sample using LOGFILSIZ 100

DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.

[db2inst1@seagull ~]$ db2 connect reset

SQL1024N A database connection does not exist. SQLSTATE=08003

[db2inst1@seagull ~]$ db2 connect to sample

Database Connection Information

Database server = DB2/LINUX 9.1.0

SQL authorization ID = DB2INST1

Local database alias = SAMPLE

[db2inst1@seagull ~]$ db2 get db cfg|grep LOGFILSIZ

Log file size (4KB) (LOGFILSIZ) = 100

1.2 修改logarchmeth1引數,且備份資料庫

[db2inst1@seagull archive]$ db2 update db cfg for sample using LOGARCHMETH1 DISK:/db2home/db2inst1/archive

DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.

SQL1363W One or more of the parameters submitted for immediate modification

were not changed dynamically. For these configuration parameters, all

applications must disconnect from this database before the changes become

effective.

[db2inst1@seagull archive]$ db2 connect reset #特別注意,這裡一定要重新連線,否則更改不起作用,我第一次試驗就是因為沒有重聯,結果就是發現歸檔老是沒有成功。

DB20000I The SQL command completed successfully.

[db2inst1@seagull archive]$ db2 connect to sample

SQL1116N A connection to or activation of database "SAMPLE" cannot be made

because of BACKUP PENDING. SQLSTATE=57019

[db2inst1@seagull archive]$ db2 backup database sample to /db2home/db2inst1/backup/

Backup successful. The timestamp for this backup image is : 20080121234435

[db2inst1@seagull archive]$ db2 connect to sample

Database Connection Information

Database server = DB2/LINUX 9.1.0

SQL authorization ID = DB2INST1

Local database alias = SAMPLE

[db2inst1@seagull archive]$ db2 get db cfg|grep LOG

Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*4)

Log buffer size (4KB) (LOGBUFSZ) = 8

Log file size (4KB) (LOGFILSIZ) = 100

Number of primary log files (LOGPRIMARY) = 3

Number of secondary log files (LOGSECOND) = 2

Changed path to log files (NEWLOGPATH) =

Path to log files = /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

Overflow log path (OVERFLOWLOGPATH) =

Mirror log path (MIRRORLOGPATH) =

First active log file = S0000000.LOG

Block log on disk full (BLK_LOG_DSK_FUL) = NO

Percent max primary log space by transaction (MAX_LOG) = 0

Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0

Log retain for recovery enabled (LOGRETAIN) = OFF

First log archive method (LOGARCHMETH1) = DISK:/db2home/db2inst1/archive/

Options for logarchmeth1 (LOGARCHOPT1) =

Second log archive method (LOGARCHMETH2) = OFF

Options for logarchmeth2 (LOGARCHOPT2) =

Log pages during index build (LOGINDEXBUILD) = OFF

[db2inst1@seagull archive]$

1.3 模擬事務,測試是否會歸檔

[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

S0000000.LOG S0000001.LOG S0000002.LOG

[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"

DB20000I The SQL command completed successfully.

...重複執行該語句,直到報SQL0964C錯誤

[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"

DB21034E The command was processed as an SQL statement because it was not a

valid Command Line Processor command. During SQL processing it returned:

SQL0964C The transaction log for the database is full. SQLSTATE=57011

#活動日誌目錄裡面先前的日誌檔案不見了,只剩下了first active ->currentlog,個數正好小於等於logprimary(3) + logseconday(2)

[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

S0000007.LOG S0000008.LOG S0000009.LOG S0000010.LOG S0000011.LOG

[db2inst1@seagull C0000000]$ db2 get db cfg|grep "First active log file"

First active log file = S0000007.LOG

#可以看到歸檔目錄下已經有了歸檔檔案,且活動日誌目錄裡面的檔案被歸檔後就刪除了,歸檔設定成功!

[db2inst1@seagull C0000000]$ ls

S0000000.LOG S0000001.LOG S0000002.LOG S0000003.LOG S0000004.LOG S0000005.LOG S0000006.LOG

此時的LOGRETAIN引數實際還是OFF的,也可以歸檔,我覺得原因是db2有兩種設定歸檔模式的方法:

1)一種是設定USEREXIT=ON,此時對應的LOGRETAIN必須為ON,歸檔由USEREXIT指定的使用者程式來執行歸檔

2)另外一種是設定LOGARCHMETH1引數(還有一些相關引數,參考後續介紹),此引數可取值如下

a.OFF :表示非歸檔

b.LOGRETAIN:等價於將 LOGRETAIN 配置引數設定為 RECOVERY,如果指定此值,將自動更新LOGRETAIN引數

c.USEREXIT :且等價於將 USEREXIT 配置引數設定為 ON,如果指定此值,將自動更新USEREXIT引數

d.DISK :日誌檔案將在其中歸檔,

e.TSM :將日誌檔案歸檔在本地 TSM 伺服器上

f.VENDOR :指定將使用供應商庫來歸檔日誌檔案。此值後必須緊跟冒號(:)和庫的名稱

結論:

1)我的試驗裡,設定了LOGARCHMETH1=DISK:/xx/xx,就可以歸檔了,LOGRETAIN=OFF或者RECOVERY無所謂

2)如果執行db2 update db cfg for sample using LOGRETAIN=ON,則相應的LOGARCHMETH1DISK:/xx/xx自動

變成了LOGRETAIN,而不管其原值是什麼,此時不會自動歸檔,必須設定USEREXIT,或者再更新LOGARCHMETH1引數為DISK:/xx/xx

3)更改db cfg後,一定要connect reset,否則可能不起作用

4)不用模擬事務,可以利用db2 archive log for db sample 命令來強制歸檔,同樣可以看到歸檔是否生效

2.db2 事務日誌和歸檔的管理

2.1 DB2 事務日誌摘要

事務是邏輯工作單元。每一個事務在事務日記檔案中都儲存有相應的日誌記錄。每個事務都有一個相應的 Redo Log 條目。Redo Log 條目將寫入當前的活動日誌檔案。當活動日誌檔案變滿時,它將被標記為 unavailable。此時,DB2將接著此活動日誌檔案另外建立一個日誌檔案,並繼續在其中寫入日誌條目。當前活動日誌檔案變滿時,DB2 將重複這一迴圈過程。當事務完成後(發起 COMMIT ROLLBACK 語句),相應的日誌條目將被釋放,因為不再需要將它們用於恢復資料庫。

  DB2 將一直嘗試將日誌條目寫入主要日誌檔案集,也就是資料庫活動時間自動分配的日誌檔案。如果某個事務將所有主要日誌檔案消耗怠盡(所有主要日誌檔案都被標記為 unavailable),則資料庫管理員將分配一個次要日誌檔案。當這個檔案變滿時,資料庫管理員將再次檢查主要日誌檔案的狀態是否為 unavailable。如果是,則再分配一個次要日誌檔案並繼續在其中寫入條目。該過程將不斷重複,直到所有次要日誌檔案都分配並寫滿。如果沒有主要日誌檔案可供寫入 Redo 條目,並且已經分配最大數量的次要日誌檔案,則應用程式將收到以下錯誤訊息:

  SQL0964C The transaction log for the database is full.

  希望您曾經遇到過這種錯誤。但是,如果遇到此錯誤,則應該根據需要增加主要和次要日誌檔案(或者它們的大小)的數量。在理想情況下,主要日誌檔案的數量或大小應該足夠儲存最大的事務。分配次要日誌檔案相當消耗資源,因為它將在執行時執行。因此,我們應該將需要在高峰工作負荷期間分配的次要日誌檔案數量降到最低。要更新主要或次要日誌檔案的數量,可以發起以下命令:

  UPDATE DB CFG FOR db_name USING LOGPRIMARY value

  UPDATE DB CFG FOR db_name USING LOGSECOND value

  注意:如果出現此問題,則應該分析造成整個日誌檔案空間變滿的原因是什麼。它可能是由失控查詢或使用者錯誤造成的,因此增加日誌檔案的數量或大小隻能在表面上解決問題。比如說,假設某個使用者發起了一個 DELETE FROM tab1 語句,且 TAB1 是一個相當大的表。雖然這一語句看上去沒什麼問題,每行生成一條刪除日記記錄,但是如果未經過配置處理它可以輕易地將日誌空間填滿。

2.2 迴圈日誌

  當迴圈日誌生效時,事務資料將透過迴圈的方式寫入主要日誌檔案。當儲存於某個日誌檔案中的所有記錄都不再需要用於恢復時,該日誌檔案將被重用,並且可以在以後再次成為活動日誌檔案。這意味著在迴圈日誌模式中,日誌檔案的內容最終將被新日誌條目重寫。由於日誌檔案的內容被重寫覆蓋了,因此我們只能將資料庫恢復到最後一次完整的資料庫備份。不能使用迴圈日誌執行時間點(point-in-time)恢復。

2.3 歸檔日誌

  在歸檔日誌模式中,redo log 條目將寫入主要日誌檔案。但是,與迴圈日誌不同,這些日誌檔案永遠都不可重用。當儲存於某個日誌檔案中的所有記錄都不再需要用於恢復時,該日誌檔案將被標記為非活動 而不是可重用。這意味著它的內容永遠都不會被覆蓋。當第一個主要日誌檔案變滿時,系統將分配一個新的日誌檔案,這樣主要日誌檔案的配置數量(LOGPRIMARY 資料庫引數)將一直可用。

  與單個事務相關的所有條目必須在活動日誌空間中保持一致。如果長時間執行的事務所需要的日誌空間大於主要日誌檔案可以提供的空間,則可能會分配並使用次要日誌檔案。在歸檔日誌模式中,透過結合使用資料庫備份映像和日誌檔案,我們可以將資料庫恢復到具體的時間點。有關此流程的詳細描述請參見下文。

設定了歸檔模式後,資料庫將支援前滾恢復。此時,系統中將會存在三種型別的日誌檔案:

•  活動日誌:該日誌包含尚未提交或回滾的事務單元的相關資訊,以及已提交但尚未寫入資料庫檔案的事務的資訊。

•  聯機存檔日誌:活動日誌中所有改動對正常處理已不需要,即該日誌中所記錄的事務都已提交併寫入資料庫檔案時,該活動日誌轉換為聯機存檔日誌。稱之為聯機,是由於它們與活動日誌存放在同一個目錄下。

•  離線存檔日誌:將聯機存檔日誌從活動日誌目錄下Copy到另外的地方存檔,就稱為離線存檔日誌。這些日誌可能在資料庫前滾恢復的時候仍然需要。

2.4如何修改日誌模式

2.4.1方法一

  建立新的 DB2 資料庫時,預設的日誌模式為迴圈日誌 。如果希望將日誌模式從迴圈修改為歸檔,可以執行以下步驟:

  在磁碟上建立一個資料夾(比如說 e:db_namearchive),磁碟上必須有足夠的空間儲存歸檔日誌檔案。保證歸檔檔案目標資料夾與活動日誌檔案目標資料夾分開。

  終止與資料庫的連線:

  TERMINATE

  更新歸檔日誌檔案目標資料夾(為歸檔日誌檔案指定路徑可以將歸檔日誌模式開啟)

  UPDATE DB CFG FOR db_name USING LOGARCHMETH1 "Disk:e:db_namearchive"

  重新連線到資料庫:

  CONNECT TO db_name

  連線失敗並顯示以下錯誤訊息:

  SQL1116N A connection to or activation of database db_name cannot be made because of backup pending: SQLSTATE=57019

  出現錯誤訊息的原因是,日誌模式已經從迴圈更改為歸檔,並且需要執行完全資料庫備份。資料庫處於迴圈日誌模式時執行的備份並不充分,因此當切換模式後需要執行新備份。

  使用以下命令執行完全資料庫備份:

  BACKUP DATABASE db_name TO d:db_namebackup

  嘗試再次連線到資料庫。這次應該能夠成功。

  CONNECT TO db_name

參考:

2.4.1方法二

設定LOGRETAIN=ON,LOGARCHMETH1=USEREXIT,同時USEREXIT=ON,並且要建立好一個名為db2uext2的可執行檔案,具體方法略

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7490392/viewspace-1059424/,如需轉載,請註明出處,否則將追究法律責任。

相關文章