SQL 操作のログ・サイズの制御

アプリケーションのために実行されるロギング量は、 変更されるデータ量により異なります。

強力な SQL ステートメントによるログ・スペースの使用を制御するには、次のようにします。

• 一括削除操作の場合は、セグメント化(非UTS)表スペースまたはユニバーサル表スペースの使用を検討してください。 これらの表スペース・タイプがオプションではなく、表にトリガーが存在しない場合、または、アプリケーションが表に対するトリガーを安全に無視できる場合、表スペースごとに1つの表を作成し、TRUNCATEを使用することができます。
• 大量データの挿入の場合は、SQL INSERT ステートメントを使用する代わりに、LOG(NO) を指定した LOAD ユーティリティーを使用してインライン・コピーを取ってください。
• 更新の場合は、 表の列を定義するときに、ワークロードについて検討してください。
  更新のためにログ記録されるデータの量は、 その行に含まれる列がすべて固定長かどうかによって異なります。 固定長で非圧縮の行の場合、変更は最初の更新された列の先頭から最後の更新された列の末尾までのみ記録されます。 したがって、頻繁に更新される列は、ログの量を減らすために、頻繁にクローズする必要があります。

  可変長の行 (可変長の行には、1 つ以上の可変長の列が含まれています) では、長さが変更されない場合は、最初に変更されたバイトから最後に更新された列の終わりまでのデータがログ記録されます。 ただし、長さが変更される場合 (これがより一般的です) は、最初に変更されたバイトから行の終わりまでのデータがログ記録されます。

  ワークロードが読み取り集中型または更新集中型かを判別するには、 ログ・データ発生率を調べます。 発生率は、ログ統計の LOG RATE FOR 1 LOG (MB/SEC) フィールドにあります。 平均ログ・サイズを調べ、 それを 60 で割って、1 秒当たりに書き込まれるログのバイト数の平均を取得してください。

  • 記録するログが秒当たり 2 MB 未満の場合、ワークロードは読み取り集中型です。
  • 記録するログが秒当たり 20 MB を超える場合、ワークロードは更新集中型です。
  • 毎秒2～20MBの処理量は、読み込みまたは更新のどちらかに集中しているわけではありません。
• 単一のデータベースのためのデータ定義ステートメント (CREATE、ALTER、 DROP) がたくさんある場合、 変更された DBD を各データ定義ステートメントごとにログ記録しないようにするために、 それらのデータ定義ステートメントを単一の作業単位内で出してください。
  ただし、COMMIT が出されるまで DBD はロックされることに注意してください。
• 頻繁な更新が必要な LOB データまたは XML データで、その代わりに LOB データまたは XML データをログからリカバリーできなくなるというトレードオフを受け入れられる場合には、NOT LOGGED オプションを使用してください。 (それでも、LOB 表スペースまたは XML 表スペースで RECOVER ユーティリティーを使用して、LOB 表スペースまたは XML 表スペースに物理的な整合性を持たせるための制御情報をリカバリーすることはできます。)
  NOT LOGGEDとして定義されたLOBおよびXMLテーブルスペースは、 Db2 ログから回復できないため、そのデータについてはリカバリ計画を立てる必要があります。 例えば、バッチ更新を実行した場合は、 更新が完了した後で必ずイメージ・コピーを取るようにしてください。
• 年末処理など特定の期間を除いて頻繁に変更されないデータに対して、 データに短期間に頻繁な変更または大きな変更が発生した場合:
  1. データのイメージ・コピーを作成する。
  2. 表スペースを NOT LOGGED に変更します。
  3. 大量の変更を加えます。
  4. データを更新する他のアクティビティーを停止します。
  5. データのイメージ・コピーを作成する。
  6. 表スペースを LOGGED に変更します。
• マテリアライズ照会表など、伝搬データを含む表への変更では、 データが別の場所に存在するため、NOT LOGGED オプションを使用してください。
  データが損傷を受けた場合、オリジナル・ソースから表全体をリフレッシュできます。