web-dev-qa-db-ja.com

DB2：データベースのトランザクションログがいっぱいですが、「最初のアクティブログファイル」がありません

まず、私はDB2の経験がほとんどないことを言いたいと思います。ただし、私は問題とこの問題の解決策を追跡することを任されています。

これはDB2データベースであり、テスターは次のように言っています。

データベースのトランザクションログがいっぱいです。SQLCODE= -964、SQLSTATE = 57011、DRIVER = 4.13.127 SQLコード：-964、SQL状態：57011

LOGPRIMARYの数を「40」に増やしました。ただし、トランザクションログはまだいっぱいのようです。次に、トランザクションログを「整理」することにしました。私が持っている手順は、アクティブなトランザクションログの前にすべてを整理することです。ただし、アクティブログを判別できません。

$ db2 get db config for MyDB | grep -i 'log'
 Log retain for recovery status                          = NO
 User exit for logging status                            = NO
 Catalog cache size (4KB)              (CATALOGCACHE_SZ) = 278
 Log buffer size (4KB)                        (LOGBUFSZ) = 1997
 Log file size (4KB)                         (LOGFILSIZ) = 1024
 Number of primary log files                (LOGPRIMARY) = 40
 Number of secondary log files               (LOGSECOND) = 12
 Changed path to log files                  (NEWLOGPATH) = 
 Path to log files                                       = /home/db2/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/
 Overflow log path                     (OVERFLOWLOGPATH) = 
 Mirror log path                         (MIRRORLOGPATH) = 
 First active log file                                   = 
 Block log on disk full                (BLK_LOG_DSK_FUL) = NO
 Block non logged operations            (BLOCKNONLOGGED) = NO
 Percent max primary log space by transaction  (MAX_LOG) = 0
 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
 Percent log file reclaimed before soft chckpt (SOFTMAX) = 520
 HADR log write synchronization mode     (HADR_SYNCMODE) = NEARSYNC
 HADR spool log data limit (4KB)      (HADR_SPOOL_LIMIT) = 0
 HADR log replay delay (seconds)     (HADR_REPLAY_DELAY) = 0
 First log archive method                 (LOGARCHMETH1) = OFF
 Archive compression for logarchmeth1    (LOGARCHCOMPR1) = OFF
 Options for logarchmeth1                  (LOGARCHOPT1) = 
 Second log archive method                (LOGARCHMETH2) = OFF
 Archive compression for logarchmeth2    (LOGARCHCOMPR2) = OFF
 Options for logarchmeth2                  (LOGARCHOPT2) = 
 Failover log archive path                (FAILARCHPATH) = 
 Number of log archive retries on error   (NUMARCHRETRY) = 5
 Log archive retry Delay (secs)         (ARCHRETRYDELAY) = 20
 Log pages during index build            (LOGINDEXBUILD) = OFF
 Log DDL Statements                      (LOG_DDL_STMTS) = NO
 Log Application Information             (LOG_APPL_INFO) = NO
$

トランザクションログファイルは/ home/db2/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000 /にあることに注意してください。

トランザクションログは正しく設定されていますか？ログを増やすことが答えになるでしょうか？それとも、ユーザーにプッシュバックして、コミットを増やすように促すべきですか？

db2transaction-logdb2-luw
2
user25849

あなたは本当に reading manuals であるべきで、「ログの剪定」ではありません。データベースは循環ロギング用に設定されています。つまり、「プルーニング」するものは何もありません。トランザクションが時々追加のログスペースを必要とする場合は、LOGSECONDの値を増やします。一次ログが多すぎると、事前に割り当てられるため、データベースの起動が遅くなります。セカンダリログは必要に応じて割り当てられ、データベースが再起動されるまでアクティブログディレクトリに残ります。

「プルーニングログ」は、アクティブなログスペースの量には影響しません（後で説明する1つの例外を除きます）。これは、LOGPRIMARYとLOGSECONDの合計にLOGFILSIZを掛けたものによって純粋に決まります。アーカイブログモードを使用している場合は、古いアーカイブログファイルを削除してディスク領域を解放できますが、アクティブなログ領域の量は変わりません。それでも、最初のアクティブなログファイルの前ではなく、前回のバックアップの前に作成されたログを削除します。

アーカイブされたログとアクティブなログが同じファイルシステムを共有している場合のみ（それ自体は良い考えではありません）、アーカイブされたログの制御されていない蓄積により、必要に応じて、アクティブなログスペースが構成された最大サイズまで拡張できない場合があります。

3
mustaccio