 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DB2 Universal Database のトランザクション・ロギング概要David Kline |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
どのようなデータベース管理システムでも、データの整合性と回復可能性を保証する方式を装備する必要があります。このような重要な特性をすべて保証するために、リレーショナル・データベース・システムによって使用される多くの方式の1つが、トランザクション・ロギングです。この記事では、トランザクション・ロギングの種類を定義して解説します。そして、ログ・ファイルの割り振り方、格納方法、発生する可能性のあるエラーについての詳細を検証します。最後に、DB2を従来にも増してスケーラブルで多用途なものにするバージョン8の新機能について、解説します。 トランザクション・ロギングとは データベース操作をトランザクションと結びつけることは、データ整合性を保証するための解決策の半分です。もう半分は、先書きロギングと呼ばれるデータベース・マネージャー側のインプリメンテーションです。トランザクションは、コミットしたかどうかに関係なく、発生すると同時にログに書き込まれます。バッファー・プールからデータベース構造へデータが書き込まれる前に、トランザクションはログ・バッファーからログ・ファイル
(トランザクション・ロギング) へと移動します。トランザクションの記録に使用されるファイルをトランザクション・ログといいます。
循環ロギング 循環ロギングは、通常、データベースのリカバリー・ニーズが単にデータベース・イメージの復元にすぎないようなデータ・ウェアハウス環境で使用されます。この方式ではロールフォワード・リカバリーが不可能なので、オンライン・トランザクション処理 (OLTP) 環境には適しません。図1は循環ロギングを示しています。 図1. 循環ロギング アーカイブ・ロギング アーカイブ・ロギングでは、データベース・アクティビティーが継続的にログに記録されている間にも、オンライン・データベース・バックアップを取得できます。データベースに障害が起きた場合、データベースは全体バックアップ・イメージを使用してリストアし、続いてアーカイブ・ログを用いてロールフォワード操作を実施して指定時刻の状態まで、あるいは (ログの終わりまでロールフォワードして) 最も新しい整合状態まで戻すことができます。 アーカイブ・ログには次の2つのタイプがあります。
図2は、アーカイブ・ロギングを示しています。 図2. アーカイブ・ロギング
LOGRETAIN このパラメーターを使用すると、アーカイブ・ログはデータベース・ログ・パス・ディレクトリーに保存されます。このパラメーターに「RECOVERY」を指定して有効にすると、データベース・マネージャーはロールフォワード・リカバリー方式を使用できます。logretain構成パラメーターが有効になっているときは、userexitを有効にする必要はありません。ロールフォワード・リカバリーを可能にするには、logretainかuserexitのいずれかを有効にすれば十分です。 logretainを使用するということは、循環ロギング (デフォルト) が上書きされるということです。logretainの有効な値は、次のとおりです。
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構成パラメーターが有効にされた場合、logretainを有効にする必要はありません。ロールフォワード・リカバリー方式を有効にするには、これら2つのパラメーターのいずれか1つを有効にするだけで十分です。 このパラメーターを使用するということは、デフォルトの循環ロギングが上書きされることを意味します。userexitはlogretainを意味しますが、その逆は真ではありません。 userexitまたはlogretain構成パラメーターのいずれかを使用してロールフォワード・リカバリーを有効にする場合、アクティブ・ログ・パスが重要です。userexit構成パラメーターが有効な場合、ユーザー出口が呼び出され、ログ・ファイルをアーカイブしてアクティブ・ログ・パスとは離れたロケーションへ移します。 このパラメーターに有効な値は次のとおりです。
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度に書き込まれるログ・レコード数が増えるので、ロギング・ファイル入出力効率が上がります。
このパラメーターを使用すると、最低数のコミットが実行されるまで、ディスクへのログ・レコードの書き込みを遅らせることができます。この遅延は、ログ・レコードの書き込みに関連したデータベース・マネージャーのオーバーヘッドの削減に役立ちます。そして、1つのデータベースに対して実行するアプリケーションが複数あって、非常に短い時間内にアプリケーションが多くのコミットを要求する場合に、結果的にパフォーマンスを改善します。 このパラメーターの値が1よりも大きい場合と、データベースに接続されたアプリケーションの数がこのパラメーターの値よりも大きい場合にのみ、このようなコミットのグループ化が発生します。コミットのグループ化が実施されると、1秒間と、コミット要求数がこのパラメーターの値と等しくなるまでの時間の、いずれか早い方の時間が経過するまで、アプリケーションのコミット要求は保持されます。
データベース・ログは、SQLOGDIRという、データベース・ディレクトリーのサブディレクトリーに最初は作成されます。この構成パラメーターの値を異なるディレクトリーや異なるデバイスを指すように変更することにより、アクティブ・ログと将来のアクティブ・ログが配置されるロケーションを変更できます。現在データベース・ログ・パス・ディレクトリーに保管されているアーカイブ・ログは、データベースがロールフォワード・リカバリー用に構成されている場合には、新規ロケーションに移動されません。 ログ・パス・ロケーションは変更可能であるため、ロールフォワード・リカバリーに必要なログは、異なるディレクトリーや異なるデバイス上に存在することがあります。複数のロケーションにあるログをアクセスできるように、ロールフォワード処理中にこの構成パラメーターを変更することもできます。 newlogpathの値に対する変更は、データベースが整合状態になるまでは適用されません。通知用のデータベース構成パラメーターdatabase_consistentは、データベースのステータスを示します。 注意: データベース・マネージャーはトランザクション・ログを1度に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コマンドを入力します。
ここで、c:はデータベースが存在するドライブのドライブ文字です。 UNIXでは、次のように指定します。
以下は、上記コマンドの出力例です。 リスト1. DB2データベース・ディレクトリー
この出力例からもわかるように、各SQLxxxxxディレクトリーは、1つのデータベース名に関連付けられます。もちろん、データベースがデフォルト・ディレクトリーに作成されなかったり、ログ・ファイルへのパスを変更した場合は、「ログ・ファイルのロケーション」かnewlogpathパラメーター、あるいはデータベース構成ファイルで調べればわかります。探す対象のデータベースが、探しているインスタンス内に存在することも確認してください。 次の図は、Windows上でログ・ファイルが (デフォルトで) 格納される場所を視覚的に表しています。 図3. ログ・ファイルのWindowsエクスプローラ表示 この特定の例では、SQL0003というデータベース・ディレクトリーが表示されています。このディレクトリーは、前出の「list database
…」コマンドの出力かわわかるように、UTFDBデータベースに関連付けられています。
トランザクション・ロギングがエラーの原因となる一般的シナリオ
バージョン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環境で有益です。
まとめ
David KlineおよびNanda Pilakaは、PartnerWorld for DevelopersのDB2テクニカル・サポート担当者。他の10名のチーム・メンバーと共に、広範囲に及ぶ開発および管理上の問題解決に取り組む独立系ソフトウェア・ベンダー (ISV) を支援している。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
