部内勉強会（ロギング）

運用関連のところを説明するのにバックアップは外せない。 その前にロギングについて理解しておいてもらう必要がある。 今日の勉強会はロギング（ログ）について。

今回も他拠点からの参加者がいるのでWeb会議を利用します。

今日はロギングの種類とログの必要性について説明です。
ロギングとはユーザーやトランザクションによって変更されたデータの更新情報を書き込むことで、
DB2ではデータ格納領域（表スペース）に書き込む前に、まずログファイルに書き込みます。これはWrite-Ahead Logging (WAL)と呼ばれます。例えば突然の電源断など障害が発生してもデータの整合性を保つこと（Commitされた処理は確定されて以前の状態に戻らない、CommitされていなければRollbackすること）を実現するためであります。
また、ロギングによって書き出されたログファイルは、リカバリー時に実施するロールフォワードでも使用します。
ログファイルがあるからこれらのことが実現できるのです。このログファイルが無かったり、誤って削除してしまったりしたら整合性が取れなくなり、そのままではデータベースは使用できなくなってしまいます。このことからもログファイルはとても重要なファイルであります。

ロギングの種類

DB2のロギングには2種類あります。それが循環ロギングとアーカイブロギングです。循環ロギングは、その名の通り更新内容を書き込むログファイルを「循環」して使います。設定したファイル数を繰り返し使います。デフォルトがこちらの設定です。対してアーカイブロギングはログファイルを上書きすることなく増えていきます。ロールフォワードする場合はこちらの設定が必要になります。
ログファイルにはそれぞれ１次ファイル数と２次ファイル数の設定があります。通常は1次ファイル数に設定した数が準備されています。トランザクションにおいてCommitかRollbackが発行されるまでそのトランザクションは未完了状態です。どちらも発行できます。1回の処理（Commitが発行されるまで）の更新内容がログファイルに収まらないとログフルでエラーとなってRollbackされてしまいます。設定した１次ファイル数を使い切ると最大２次ファイル数に設定した数まで追加で増やすことができます。この２次ファイルも使い切るとエラーになってしまうので、頻繁にCommitを入れるように設計するなど充分な検討と見積もりが必要です。
これらに関連する各種設定はDB構成パラメータで設定できます。

循環ロギング

そもそもこの循環ロギングはロールフォワード（オンラインバックアップからのリストア）ができません。
トランザクションがすべてCommitされてディスクに書き出されたログファイルは再利用してくれます。
1次ログファイル数で不足した場合は自動的に2次ログファイルが作成されます。設定数まで自動的に作成してくれます。2次ログファイルは一度作成されるとデータベースが非活動化されるまでそのまま残ります。
ログファイルが使いまわされるので設定数以上のファイルはできません。そのためログが不要な照会データベースや開発環境などでの使用が想定されます。
オフラインバックアップの定期的な取得が必要になります。

アーカイブロギングとファイル退避

アーカイブロギングはロールフォワードでの回復を行う運用の場合にはこちらの設定です。
こちらはオフラインバックアップだけでなくオンラインバックアップも取得可能です。すべてのログが残ります。ログファイルがいっぱいになると、自動的に次のログファイルができあがります。いっぱいになったログファイルはDB構成パラメータで指定した場所に自動的に移動されます（LOGARCHMETH1の設定が必要）。
トランザクションでCommitが発行されなく1次ログファイルをすべて使い切ってしまった場合は、循環ロギングと同様に自動的に2次ログファイルに書き込まれます。この2次ログファイルもすべて使い切ってしまった場合はログフルエラーとなり、Rollbackされます。
LOGARCHMETH1はLOGARCHMETH2と合わせて使用するとログの2重化も可能です（退避先を2つにできる）。
以前のバージョンでは、上記のDB構成パラメータでの設定ではなく、ログを退避させるために各環境において独自の移動プログラム（USEREXIT）を準備していましたが、アクティブログファイルは移動させることが必須となってきているので、製品の方で移動処理が組み込まれるようになった変遷があります。このあたりは手軽な設定になったので管理者としてはありがたいです。
ログフルエラーの場合は　「SQL0964C」が返り、ディスクフルエラーの場合は「SQL0968C」が返されます。
ログフルの場合はDB構成パラメータの、ログファイルサイズを適正サイズに増やすか、ログプライマリやログセカンドのファイル数を適正数に増やしましょう。
ディスクフルの場合はログの書き出し先ファイルシステムなどの領域がいっぱいになってしまったので、領域拡張の必要があります。過去の経験では循環ロギングの場合はログフルエラーが発生しやすかったです。

ログファイルの配置先

ログファイルはとても重要なファイルということとともにアクセスが多いファイルです。配置先としてはデータアクセスが多い表スペースと同じファイルシステムや同じドライブにせずに別けて配置するようにすることが望ましいです。また、ネットワーク・ドライブ先の配置は対障害の観点としてもパフォーマンス観点でも避けるようにしましょう。ユーザーデータ同様に重要なデータだと認識して取り扱うことが望ましいです。

■参考資料■
developerWorksより

DB2 V9.1 運用管理ガイド：ロギング