この記事は、UNIX®、Linux、およびWindows®上のIBM® DB2® Universal Database™に適用されます。

どのようなデータベース管理システムでも、データの整合性と回復可能性を保証する方式を装備する必要があります。このような重要な特性をすべて保証するために、リレーショナル・データベース・システムによって使用される多くの方式の1つが、トランザクション・ロギングです。この記事では、トランザクション・ロギングの種類を定義して解説します。そして、ログ・ファイルの割り振り方、格納方法、発生する可能性のあるエラーについての詳細を検証します。最後に、DB2を従来にも増してスケーラブルで多用途なものにするバージョン8の新機能について、解説します。

トランザクション・ロギングとは

データベースは、アプリケーションによってアクセスされ処理されるデータを格納します。アプリケーションは、データを挿入、読み取り、更新、あるいは削除します。このようなアクティビティーの各々は、「アプリケーション・プロセス内の回復可能な一連の操作」として定義される1つのトランザクション内で実行されます。「作業単位」とも呼ばれるトランザクションは、コミットされるまではデータベースに影響を与えません。

データベース操作をトランザクションと結びつけることは、データ整合性を保証するための解決策の半分です。もう半分は、先書きロギングと呼ばれるデータベース・マネージャー側のインプリメンテーションです。トランザクションは、コミットしたかどうかに関係なく、発生すると同時にログに書き込まれます。バッファー・プールからデータベース構造へデータが書き込まれる前に、トランザクションはログ・バッファーからログ・ファイル (トランザクション・ロギング) へと移動します。トランザクションの記録に使用されるファイルをトランザクション・ログといいます。

上に戻る

トランザクション・ロギングの種類は複数あるのか?

DB2 UDBでは、循環ロギングとアーカイブ・ロギングという2種類のロギングを使用できます。

循環ロギング
循環ロギングは、データベースに使用されるデフォルトのロギング方式です。この方式では、ログ・ディレクトリー中の最後の1次ログ・ファイルが一杯になった場合に、新規トランザクションは最初のログ・ファイルに書き込まれます。つまり、既存のログ・データを上書きします。このようにして、新規トランザクションは順番に次々と古いログ・ファイルを上書きして行きます。このロギング方式は、コミット済みのすべてのトランザクションに対してデータ整合性を保証して、クラッシュ・リカバリーを可能にします。

循環ロギングは、通常、データベースのリカバリー・ニーズが単にデータベース・イメージの復元にすぎないようなデータ・ウェアハウス環境で使用されます。この方式ではロールフォワード・リカバリーが不可能なので、オンライン・トランザクション処理 (OLTP) 環境には適しません。図1は循環ロギングを示しています。

アーカイブ・ロギング
循環ロギングとは対照的に、アーカイブ・ロギング・プロセスは、最後のログ・ファイルが一杯になると新規ログ・ファイルを作成するため、その後のトランザクションが既存のログ・ファイルを上書きすることはありません。データベースの初期化時に、システムは特定数の1次ログ・ファイルを指定されたサイズでアクティブ・ログ・ディレクトリーに割り振ります。割り振る数は、データベース構成パラメーターによって制御されます (次セクションで解説します)。1次ログ・ファイルがすべて一杯になると、2次ログ・ファイルが (2次ログ・ファイルの最大数に達するまで) 必要に応じて作成されます。最大数に達しても追加のログ・スペースが必要な場合、「使えるログ・ファイルがない」旨のエラーが発行され、すべてのデータベース・アクティビティーが停止します。

アーカイブ・ロギングでは、データベース・アクティビティーが継続的にログに記録されている間にも、オンライン・データベース・バックアップを取得できます。データベースに障害が起きた場合、データベースは全体バックアップ・イメージを使用してリストアし、続いてアーカイブ・ログを用いてロールフォワード操作を実施して指定時刻の状態まで、あるいは (ログの終わりまでロールフォワードして) 最も新しい整合状態まで戻すことができます。

アーカイブ・ログには次の2つのタイプがあります。

• オンライン・アーカイブ・ログ。オンラインのデータベース・ログ・ディレクトリーに存在するログで、通常のデータベース・アクティビティーには不要になりました。
• オフライン・アーカイブ・ログ。データベース・ログ・ディレクトリーからオフラインのストレージ・ロケーション (バックアップ・サーバーなど) に移されたログ・ファイルで、通常のデータベース・アクティビティーには不要です。

図2は、アーカイブ・ロギングを示しています。

上に戻る

ロギングの制御に使用するパラメーター

トランザクション・ロギングは、データベース構成パラメーターを通してデータベース・レベルで制御されます。トランザクション・ロギングに影響するパラメーターを次に示します。

LOGRETAIN

このパラメーターを使用すると、アーカイブ・ログはデータベース・ログ・パス・ディレクトリーに保存されます。このパラメーターに「RECOVERY」を指定して有効にすると、データベース・マネージャーはロールフォワード・リカバリー方式を使用できます。logretain構成パラメーターが有効になっているときは、userexitを有効にする必要はありません。ロールフォワード・リカバリーを可能にするには、logretainかuserexitのいずれかを有効にすれば十分です。

logretainを使用するということは、循環ロギング (デフォルト) が上書きされるということです。logretainの有効な値は、次のとおりです。

• No (デフォルト) - ログは保存されないことを示します。
• Recovery - ログは保存され、順方向リカバリーに使用できることを示します。さらに、データ・レプリケーションを使用している場合、CAPTUREプログラムはログに記録された更新内容を変更表に書き込むことができます。
• Capture - ログを保存する目的が、Captureプログラムが更新内容を変更表に書き込めるようにすることのみであることを示します。ログは、プルーンされていなければ、ロールフォワード・リカバリーにも使えます。注意: Captureという設定値は、通常はデータ・レプリケーション用にデータベースをセットアップする場合のみに使用されます。

logretainが「Recovery」に設定されるかuserexitが「Yes」(下記参照) に設定された場合、アーカイブ・ログ・ファイルが保存され、ロールフォワード・リカバリーで使用するオンライン・アーカイブ・ログになります。これがログ保存ロギングと呼ばれるものです。

logretainが「Recovery」に設定されるかuserexitが「Yes」(下記参照) に設定された後は、データベースの全体バックアップを取得する必要があります。この状態は、backup_pendingフラグ・パラメーターで示されます。

Logretainもuserexitも「No」に設定された場合、データベースにはロールフォワード・リカバリーを使用できず、回復可能性は最後に取得されたデータベース・バックアップに限定されます。

logretainが「Capture」に設定された場合、Captureプログラムは完了時にログ・ファイルを削除するPRUNE LOGFILEコマンドを呼び出します。ログは、プルーンされていない場合は順方向リカバリーに使えますが、データベースに対してロールフォワード・リカバリーを確実に実施できるようにしたい場合は、logretainを「Capture」に設定すべきではありません。

logretainもuserexitも「No」に設定された場合、ログは保存されません。この場合、データベース・マネージャーはlogpath内のすべてのログ・ファイルを (オンライン・アーカイブ・ログも含めて) 削除し、新しいアクティブ・ログ・ファイルを割り振って、循環ロギングに変えます。

logretain構成パラメーターが「RECOVERY」に設定された場合、ログ・ファイルはアクティブ・ログ・パスに留まります。アクティブ・ログ・パスは、データベース構成ファイル中の「ログ・ファイルのロケーション」(logpath) か「データベース・ログ・パスの変更」(newlogpath) の値で決まります。

USEREXIT

このパラメーターを使用すると、データベース・マネージャーはユーザー出口プログラムを呼び出してログのアーカイブおよび取り出しを実施します。userexitが有効にされると、ロールフォワード・リカバリーが可能になります。userexit構成パラメーターが有効にされた場合、logretainを有効にする必要はありません。ロールフォワード・リカバリー方式を有効にするには、これら2つのパラメーターのいずれか1つを有効にするだけで十分です。

このパラメーターを使用するということは、デフォルトの循環ロギングが上書きされることを意味します。userexitはlogretainを意味しますが、その逆は真ではありません。

userexitまたはlogretain構成パラメーターのいずれかを使用してロールフォワード・リカバリーを有効にする場合、アクティブ・ログ・パスが重要です。userexit構成パラメーターが有効な場合、ユーザー出口が呼び出され、ログ・ファイルをアーカイブしてアクティブ・ログ・パスとは離れたロケーションへ移します。

このパラメーターに有効な値は次のとおりです。

• No (デフォルト)
• Yes

userexitパラメーターが有効な場合、logretainパラメーターの設定には無関係に、ログ保存ロギングが実施されます。userexitパラメーターは、ログ・ファイルのアーカイブおよび取り出しにはユーザー出口プログラムが使用されるべきであることも意味します。ログ・ファイルは、データベース・マネージャーがログ・ファイルをクローズするときにアーカイブされ、ROLLFORWARDユーティリティーがデータベースをリストアするために必要とするときに取り出されます。

logretainまたはuserexitパラメーター、あるいはその両方が有効にされた後、データベースの全体バックアップを取得する必要があります。この状態は、backup_pendingフラグ・パラメーターで示されます。

logretainとuserexitの両パラメーターとも選択解除された場合、ログは保存されなくなるので、そのデータベースに対してロールフォワード・リカバリーは使えなくなります。この場合、データベース・マネージャーはlogpathディレクトリーにあるすべてのログ・ファイル (オンライン・アーカイブ・ログ・ファイルを含む) を削除し、新規アクティブ・ログ・ファイルを割り振り、循環ロギングに変えます。

LOGPRIMARY

このパラメーターは、作成される1次ログの数を指定します。

1次ログは、空であっても一杯であっても同量のディスク・スペースを必要とします。したがって、必要以上に構成すると、ディスク・スペースを無駄使いすることになります。1次ログの数が少なすぎる構成にすると、ログが一杯という状態を招きかねません。構成するログの数を選ぶ際、各ログのサイズと、ログ一杯の状況をアプリケーションが処理できるかどうかを考慮する必要があります。

既存データベースをロールフォワード・リカバリー可能にする場合、1次ログの数を現在使用中の1次ログおよび2次ログの合計数に1を加えた値に変更します。ロールフォワード・リカバリーが有効にされたデータベース中のlong varcharおよびLOBフィールドに対しては、追加情報がログに記録されます。

ログ・ファイル・サイズ合計の上限値は、バージョン7.2では32GB、バージョン8.1では256GBです。つまり、ログ・ファイルの数 (LOGPRIMARY + LOGSECOND) に各ログ・ファイルのバイト単位のサイズ (LOGFILSIZ * 4096) を掛け合わせた値は、それぞれ32GBまたは256GB未満でなければなりません。

LOGSECOND

このパラメーターは、リカバリー・ログ・ファイル用に作成され使用される2次ログ・ファイルの数を指定します。ログ・ファイルの合計数は次の不等式で制限されることに注意してください。

logprimary + logsecond <= 128 (DB2 UDB V7.2), 256 (DB2 UDB V8.1)

1次ログ・ファイルが一杯になると、このパラメーターで制御される最大数に達するまで、(サイズがlogfilsizの) 2次ログ・ファイルが必要に応じて1つずつ割り振られます。このパラメーターで設定された上限数よりも多くの2次ログ・ファイルが必要になった場合、エラー・コードが返され、データベースに対するアクティビティーは停止されます。

LOGFILSZ

このパラメーターは、構成される各ログのページ数を決定します。1ページのサイズは4KBです。各1次ログのサイズ (つまりページ数) は、データベース・パフォーマンスに直接関係します。データベースがログを保存するように構成されると、ログが一杯になるたびに、新規ログの割り振りおよび初期化要求が発行されます。ログ・サイズを増やすと、新規ログの割り振りおよび初期化要求の数が削減されます。ただし、ログ・サイズが大きいほど、各ログをフォーマットする時間もかかります。新規ログのフォーマットは、データベースに接続されたアプリケーションには透過的に実施され、データベース・パフォーマンスには影響しません。

LOGBUFSZ

このパラメーターを使用すると、ディスクへ書き込む前のログ・レコード用のバッファーとして使用するデータベース共用メモリーの量を指定できます。ログ・レコードは、次のいずれかが発生するとディスクへ書き込まれます。

• トランザクションのコミット
• ログ・バッファーが一杯
• 他のデータベース・マネージャー内部イベントによって書き込みが発生する

ログ・レコードをバッファリングすると、ログ・レコードがディスクへ書き込まれる頻度は下がって1度に書き込まれるログ・レコード数が増えるので、ロギング・ファイル入出力効率が上がります。

MINCOMMIT

このパラメーターを使用すると、最低数のコミットが実行されるまで、ディスクへのログ・レコードの書き込みを遅らせることができます。この遅延は、ログ・レコードの書き込みに関連したデータベース・マネージャーのオーバーヘッドの削減に役立ちます。そして、1つのデータベースに対して実行するアプリケーションが複数あって、非常に短い時間内にアプリケーションが多くのコミットを要求する場合に、結果的にパフォーマンスを改善します。

このパラメーターの値が1よりも大きい場合と、データベースに接続されたアプリケーションの数がこのパラメーターの値よりも大きい場合にのみ、このようなコミットのグループ化が発生します。コミットのグループ化が実施されると、1秒間と、コミット要求数がこのパラメーターの値と等しくなるまでの時間の、いずれか早い方の時間が経過するまで、アプリケーションのコミット要求は保持されます。

NEWLOGPATH

データベース・ログは、SQLOGDIRという、データベース・ディレクトリーのサブディレクトリーに最初は作成されます。この構成パラメーターの値を異なるディレクトリーや異なるデバイスを指すように変更することにより、アクティブ・ログと将来のアクティブ・ログが配置されるロケーションを変更できます。現在データベース・ログ・パス・ディレクトリーに保管されているアーカイブ・ログは、データベースがロールフォワード・リカバリー用に構成されている場合には、新規ロケーションに移動されません。

ログ・パス・ロケーションは変更可能であるため、ロールフォワード・リカバリーに必要なログは、異なるディレクトリーや異なるデバイス上に存在することがあります。複数のロケーションにあるログをアクセスできるように、ロールフォワード処理中にこの構成パラメーターを変更することもできます。

newlogpathの値に対する変更は、データベースが整合状態になるまでは適用されません。通知用のデータベース構成パラメーターdatabase_consistentは、データベースのステータスを示します。

注意: データベース・マネージャーはトランザクション・ログを1度に1つずつ書き込みます。アクティブ状態であることのできるトランザクションの合計サイズは、次のデータベース構成パラメーターで制限されています。

                
          >= LOGFILSIZ * LOGPRIMARY * 4096 bytes
          <= LOGFILSIZ * (LOGPRIMARY + LOGSECOND) * 4096 bytes <= 32 GB 
          for v7.2 or <= 256 GB for v8.1 
          
      

上に戻る

ログ・ファイルの割り振り方法と格納場所

ログ・ファイルの割り振り方法

前述のセクションで説明したデータベース構成パラメーターのすべてが更新された後、すべてのアプリケーションがデータベースから接続解除されることを確認する必要があります。アプリケーションが再接続するとき、新規設定値が有効になり、ログ・ファイルはディスクに事前割り振りされます。割り振られるログ・ファイルの数は、logprimaryパラメーターの値と、アクティブ・ログ・ディレクトリー内のログ・ファイルの合計数に基づきます。

アーカイブ・ロギングを使用する場合、アクティブ・ログ・ディレクトリーから古いログ・ファイルを移動しないと、古いログ・ファイルは蓄積してアクティブ・ログ・ファイルとディレクトリーを共用します。たとえば、アクティブ・ログ・ディレクトリーに5つのログ・ファイルがあるとします。ログ・ファイルの2つは満杯かつコミット済みであり、3つログ・ファイルが空いています。logprimaryパラメーターを5から8に変更した後で初めてデータベースに接続する際、アクティブ・ログ・ディレクトリーに5つのログ・ファイルが追加で割り振られ、合計で8つの空きログ・ファイル (空き3つ+新規5つ=空き8つ) を保証します。

循環ロギングでは、logretainまたはuserexitパラメーターが「no」に設定されていれば、ログ・ファイルは再利用されます。これは、データベースへの最初の接続時に、1次ログの合計数がアクティブ・ログ・ディレクトリーに存在するログ・ファイルの合計数と等しくなることを意味します。前述の例で、logprimaryパラメーターを5から8に変えると、ログ・ファイルのいくつかが満杯であったとしても、アクティブ・ログ・ディレクトリーには追加で3つだけログ・ファイルが割り振られます (空き5つ+新規3つ=8つ)。

前セクションで述べたように、作成される各ログ・ファイルは、logfilsizパラメーターに基づいてスペースが同じだけ割り振られます。logfilsizパラメーター値が変更された場合、トランザクション・データの入った既存のログ・ファイルは影響を受けませんが、新規ログ・ファイルは新しいサイズ出作成され、空のログ・ファイルは新しいサイズに変更されます。

各ログ・ファイルに反映されるサイズは、ログ・ヘッダー制御文字のいくつかを除いて、ほとんどが事前割り振りされるスペースです。このスペースをログ・ファイルに事前に割り振ることで、データベース・マネージャーは必要になった時点でスペース割り振りを行う必要がなくなります。ハード・ドライブにスペースを割り振るのは時間のかかるリソース集中型の作業なので、スペースが必要になった時点ですぐに使えることがベストです。

logsecondパラメーターはバージョン7.2とバージョン8の間で区別される唯一のパラメーターです。バージョン7.2では、このパラメーターは全アプリケーションの接続解除および再接続が行われた後にのみ、有効になります。バージョン8では、このパラメーターは変更されると即有効になります。これは、データベースへ再接続した後、ログ・ディレクトリー中に突然新しいログ・ファイルが存在するという意味ではありません。このパラメーターは、logprimary値が超えたときだけログ・ファイルの割り振りを発生させるもので、一連の長い未コミット・トランザクションの実行中に発生することがよくあります。

logsecondがログ割り振りに与える影響の例として、logprimaryを5に、logsecondを2に変更したとします (事前割り振りが5つ、必要な時点での割り振りが2つ)。トランザクションが実行され、5つすべての1次ログ・ファイルを使い切りましたが、まだトランザクションをロギングしています。6番目のログ・ファイルが必要になったとき、データベース・マネージャーはlogsecond値を調べ、別のログ・ファイルをログ・ディレクトリーに割り振ります。7番目のログ・ファイルが必要になり、割り振られます。logseondパラメーターではログ・ファイルが2つしか指定されていないため、トランザクションは7番目のログ・ファイルが一杯になる前にコミットする必要があります。そうしないと、エラーが返され、トランザクションはロールバックされます。

それでは、コミット後にログ・ファイルはどうなるのでしょうか? logprimary値を保持するために、前のトランザクションで使用されたログ・ファイルの数に基づいて、データベース・マネージャーは新規ログ・ファイルを割り振ります。たとえば、3つのログ・ファイルが一杯になった場合、別に3つのログ・ファイルが作成され、空きログ・ファイルの合計数がlogprimary値と等しくなることを保証します。

すべてのアプリケーションがデータベースから接続解除した場合はどうなるのでしょうか。データベースへの再接続時、前の接続からのデータが配置された最後のログ・ファイルは、ファイル中のデータのサイズに切り捨てられます。これにより、空きスペースがなくなり、前述のデータベース構成パラメーターに基づいてスペースを正確に割り振ることができます。

ログ・ファイルの格納場所

デフォルトでは、ログ・ファイルは次のディレクトリーに格納されます。

Windowsの場合:c:\<instance name>\NODE0000\SQL00001\SQLOGDIR

UNIXの場合: <instance home directory>/ <instance name> >/NODE0000/SQL00001/SQLOGDIR

上記ディレクトリー・パスには、作成される各データベース用にSQLxxxxx ('xxxxx' は0で始まる番号) ディレクトリーがあります。DB2インスタンス内に複数の物理データベースを持つ場合、どのSQLxxxxxディレクトリーがどのデータベースに属するものかを認識するのは困難です。この問題を解決するには、単に次のdb2コマンドを入力します。

                
db2 "list database directory on c:"

ここで、c:はデータベースが存在するドライブのドライブ文字です。

UNIXでは、次のように指定します。

                
db2 "list database directory on /<instance home directory>"

以下は、上記コマンドの出力例です。

                
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
 

この出力例からもわかるように、各SQLxxxxxディレクトリーは、1つのデータベース名に関連付けられます。もちろん、データベースがデフォルト・ディレクトリーに作成されなかったり、ログ・ファイルへのパスを変更した場合は、「ログ・ファイルのロケーション」かnewlogpathパラメーター、あるいはデータベース構成ファイルで調べればわかります。探す対象のデータベースが、探しているインスタンス内に存在することも確認してください。

次の図は、Windows上でログ・ファイルが (デフォルトで) 格納される場所を視覚的に表しています。

この特定の例では、SQL0003というデータベース・ディレクトリーが表示されています。このディレクトリーは、前出の「list database …」コマンドの出力かわわかるように、UTFDBデータベースに関連付けられています。

上に戻る

トランザクション・ロギングがエラーの原因となる一般的シナリオ

ロギングに影響するデータベース構成パラメーターにはどのようなものがあり、どのように割り振られるかを見てきました。ここでは、パラメーターが正しく設定されていない場合に直面する問題について解説します。ログ関連パラメーターを間違って設定すると、実行時間の長いトランザクションを発行するユーザーのみならず、システムを共用しているその他のユーザーにとっても、大迷惑な事態を招きかねません。直面する可能性のある問題には、次のようなものがあります。

• 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操作は本来、自動コミットをオフにしたSQL insertを用いた行移動なので、「ログ・ファイルが一杯でコミットが試行される」旨のリスト2のような警告が発行されます。データベース構成パラメーターlogretainがONに設定された場合、データベースに対するログ・リカバリーが有効になり、新規ログ・ファイルが作成されない限りIMPORT操作を続行できなくなります。このことは、大規模ログか多数のログ・ファイル (あるいは大規模で多数のログ・ファイル) を必要とする場合、それらログ・ファイルは割り振りに時間がかかるため、知っておくべき重要な点です。logretainがOFFに設定された場合、循環ロギングが行われ、新規ログを作成する必要がなくなります。
  
  非常に多数の行をデータベースにインポートする場合、ログ・ファイルの割り振りがシステムに過剰な負荷をかけないように、日中のアクティビティーの低い時間帯に、データベース構成のログ関連パラメーターを変更することをお勧めします。DB2 UDB V7.2では、最大で合計32GBのログ・スペースを割り振ることができ、V8ではそれが256GBに増えます。
  
  IMPORT操作の代替として検討の余地のある方法に、LOAD操作を使用して、表に対してNOT LOGGED INITIALLYオプションを使えるようにすることがあります。これは文字どおり、LOADが実行されるときはロギングを発生させないオプションです。しかし、このオプションは同時に、表を回復不可能な状態にするので、LOADを実行した直後に、データベースをバックアップしておくことが重要です。NOT LOGGED INITIALLYオプションは、LOADコマンドの現在の実行に効果があるだけで、データベース・マネージャーはLOAD操作完了後に発生するトランザクションを引き続きログに記録することに注意してください。
  
  
• もう1つの一般的な状況は、アプリケーションが1つの作業単位内で多くのINSERT、DELETE、あるいはUPDATEステートメントを実行している場合に発生します。自動コミットがオフにされ、コミットは作業単位が完了した後にのみ、明示的に実行されます。ログ・ファイルが一杯という状況を認識できてコミットを実行するIMPORTユーティリティーとは異なり、アプリケーション中のロジックは、このことを考慮していないことが多く、次のようなエラーで失敗します。
  

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

  
  したがって、実行に異常に時間のかかるトランザクションを持つファイルをアプリケーションが呼び出した場合、ログ設定値に基づいて頻繁なコミットを含めるか、あるいはデータベースのログ関連パラメーターを変更するかを推奨します。
  
  
• 3つ目の問題は、表に対してRUNSTATSまたはREORGを実行する際に発生します。RUNSTATSおよびREORGユーティリティーは両方とも、表データを移動する際にログ・ファイルを使用します。SQL0964Cエラーが発生した場合、データベース・ログ・ファイル関連のパラメーターの値を増やす必要があります。

上に戻る

バージョン8用の新機能

DB2ロギングには、バージョン8でいくつか卓越した新機能が追加され、大きく飛躍しました。その新機能のいくつかを次に紹介します。

ロギングのスケーラビリティー - 極端に長いトランザクションを持つ傾向のあるものについては、DB2は最大アクティブ・ログ・スペースを32GB (V7.2) から256GBに増やしました。これはlogprimaryおよびlogsecondパラメーターの合計値から導かれる合計バイト数です。

未完了トランザクションは、データベース・ロギング・パラメーターで指定される上限、あるいはuserexitデータベース構成パラメーターがオンに設定された場合はアクティブ・ログ・パスで利用可能なディスク・スペースをも、超えることができるようになりました。この新機能は、logsecondを-1 (無限) に変更することにより設定されます。基本的な考え方は、ログ・ファイルは、長いトランザクション中にuserexitプログラムによって定常的にアーカイブされ、アクティブ・ログ・ディレクトリーには常に追加ログ・ファイル用の新たなスペースがあるというものです。データベース上で稼動する未完了トランザクションのサイズや数には制限はありません。ただし、ロールバックが発生すると、userexitプログラムはアーカイブ・ログ・パスから未コミット・ログ・ファイルを取り出す必要があるため、パフォーマンスの影響があります。さらに、logsecondが-1に設定された場合、2次ログの新たな割り振りは不等式(logprimary + logsecond) <= 256には制限されません。

DB2_BLOCK_ON_DISK_FULLレジストリー変数は、BLK_LOG_DSK_FULによって置き換えられます。このオプションが有効な場合、アクティブ・ログ・パスでディスクが一杯という状態が発生したときに稼動中のアプリケーションは、接続解除されません。DBAはファイルを削除するかファイル・システムを拡大する時間があるため、トランザクションを完了できます。ログが一杯という状況が発生した場合でも、データベースでは読み取りアクセスは依然として可能です。

ログ・ファイル・ミラーリング - DB2 UDB V7のnewlogpath2レジストリー変数は、DB2 UDB V8のmirrorlogpathデータベース構成パラメーターで置き換えられます。この変更により、細分性がインスタンス・レベルではなく、データベース・レベルになります。newlogpath2変数およびmirrorlogpathパラメーターは、両方とも同じ目的のために機能します。すなわち、両方とも二重またはミラー・ロギングの実装に使用されます。mirrorlogpathは完全修飾のパス名、すなわち絶対パス名を指す必要があります。

ロギングの高速化 - ロガーを使用したパフォーマンスは、非同期ログ書き込みによって改善されます。SMP環境では非同期処理を活用できるため、これは特にSMP環境で有益です。

上に戻る

まとめ

この記事では、トランザクション・ロギングとは何か、その制御方法、格納場所と格納方法、発生する可能性のある一般エラーの、バージョン8.1で提供される新機能のいくつかなど、トランザクション・ロギングの多くの局面を解説しました。ロギング・アクティビティーがデータベースやオペレーティング・システムに与える影響が分かれば、ロギング・エラーから生じた問題をうまく効率的にトラブルシューティングできるようになります。

上に戻る

関連DB2トピックへのリンク

• DB2 UDB管理ガイド: ロギングおよびリカバリー
• DB2 UDB管理ガイド: データベース・ディレクトリー
• データベース構成パラメーター
• トランザクションの概念 - IBM DB2 UDB管理ガイド: プランニング, バージョン8

参考文献

• developerWorks Japan: Information Management : Information Managementの日本語技術情報サイトです
  
  
• developerWorks: Information Management(US) : Information Managementの英語の技術情報サイトです
  
  

著者について

アプリケーション開発および管理の両方のDB2認定資格を持つ。現在は主にDBA関連の問題でISVを支援することに従事。

アプリケーション開発および管理の両方で、DB2認定資格を持つ。CおよびJavaプログラムを用いた開発を含むさまざまなDB2の問題に従事。

この記事を評価する

コメント

上に戻る

目次

• トランザクション・ロギングとは
• トランザクション・ロギングの種類は複数あるのか?
• ロギングの制御に使用するパラメーター
• ログ・ファイルの割り振り方法と格納場所
• トランザクション・ロギングがエラーの原因となる一般的シナリオ
• バージョン8用の新機能
• まとめ
• 関連DB2トピックへのリンク
• 参考文献
• 著者について
• コメント