アクティブ・ログ・データ・セットのストレージ要件

機能レベル500 以上 が有効化される前は、最大データセットサイズは4GBです。 3390 ボリュームを使用する場合は、DEFINE CLUSTER コマンドで、アクティブ・ログ全体を保持するのに十分な大きさの 1 次数量を使用してデータ・セットを定義し、2 次量の 0 を定義してください。 各アクティブ・ログ・データ・セットの割り振りが以下の値を超えていないことを確認してください。

3390-9 ボリュームの場合:

• 87375 トラック (トラック単位の割り振りの場合)
• 5825 シリンダー (シリンダー単位の割り振りの場合)

3390-A ボリュームの場合:

• 5817 シリンダー。 3390-A ボリュームは、拡張アドレス・ボリューム (EAV) です。このボリュームは、スペース割り振り単位を 1 シリンダーではなく 21 シリンダーにすることができます。 詳細は DEFINE CLUSTERコマンドを参照。

ファンクション・レベル500 以上を有効にすると、最大データ・セット・サイズは768GBになる。 ほとんどの場合、最適なデータ・セット・サイズは、768 GB より大幅に小さいサイズです。 4 GB より大きいデータ・セットを定義する場合、SMS データ・クラス定義で拡張フォーマット (EF) を指定する必要があります。

各アーカイブ・ログ・データ・セットが、少なくともアクティブ・ログ・データ・セットと同じサイズであることも確認する必要があります。 Db2 12 では、サブシステムパラメータALCUNITが削除され、PRIQTYとSECQTYのサブシステムパラメータの割り当て単位は常にシリンダーであるため、これらの値を調整する必要があるかもしれません。 アーカイブ・ログを拡張してアクティブ・ログを含めることができるように、サブシステム・パラメーター PRIQTY および SECQTY を設定します。 アクティブ・ログのデータ・セット・サイズが 4 GB より大きい場合、アーカイブ・ログ・データ・セットの SMS データ・クラス定義で、拡張アドレス可能度を指定する必要があります。 これを行うことで、データ・セット・タイプが BASIC または LARGE である場合は 16 である各ボリュームの最大エクステント数が 123 になります。 SMSデータクラス属性の「Override Space」が「YES」に設定されている場合、データクラススペースの設定が Db2 サブシステムパラメータの設定を上書きすることがあります。 そのような場合、データ・クラスに対して指定するスペース量でアーカイブ・ログにアクティブ・ログを含めることができるかを確認する必要があります。

アーカイブログがテープに書き込まれる場合、大きなデータセットは1本ではなく2本のテープを必要とするかもしれない。 実磁気テープの場合、テープ上のスペースが無駄になる可能性もあります。 そのため、実磁気テープまたは仮想テープのサイズに基づいてデータ・セットのサイズを調整する必要があります。 ほとんどのテープ製品では圧縮が使用されます。 また、DFSMS を使用してアーカイブ・ログ・データ・セットを圧縮することもできます。

Db2が 1 つのアクティブ・ログ・データ・セットをいっぱいにすると、ログ・データをアーカイブ・ログ・データ・セットにオフロードする必要があります。 同時に、Db2は次のアクティブ・ログ・データ・セットへの書き込みを開始します。 Db2が最後のアクティブ・ログ・データ・セットに達すると、最初のアクティブ・ログ・データ・セットから再度開始されます。 ただし、アプリケーションがオフロード・プロセスに追い付いた場合には、オフロード・プロセスで次のアクティブ・ログ・データ・セットの書き込みが完了するまで、アプリケーションは中断状態になります。 以下のような状態が原因で、このようなアプリケーション中断がよく発生します。

• データを挿入、更新、または削除する大規模なバッチ・ジョブ。
• 頻繁な挿入。
• 大きな LOB のロギング。
• オフロード操作が遅すぎる。

このようなアプリケーション中断を防止するには、以下の方法を使用できます。

• 高速オフロード操作を有効にします。 例えば、高速なチャネルがあるディスク装置にアーカイブ・ログ・データ・セットを配置できます。 (後でデータ・セットをテープに移動することができます。)
• 挿入、更新、削除アクティビティーの持続的なバーストをサポートするために、大量のアクティブ・ログ・スペースを割り振ります。

  Db2 12 でファンクション・レベル500 以上をアクティブにした後、 Db2 は、それぞれ最大768GBのサイズで、93個ものアクティブなログ・データ・セットをサポートする。 この制限により、最大71424GBのアクティブ・ログ容量が提供される。

  重複ロギング用には、スペース計算を倍にする必要があります。 多くの場合、最大数よりも少ないデータ・セットを使用できます。 2 つのデータ・セットで十分な場合もあります。 ただし、ログ・スペースをより多く割り振るほど、挿入/更新/削除操作の大規模な集中が発生してもパフォーマンス上の問題につながらない可能性が大きくなります。

  始動時に、Db2は、BSDS データ・セット、すべてのアクティブ・ログ・データ・セット、および重複ロギングが使用される場合のすべての 2 次ログ・データ・セットを割り振ります。 データ共用グループ内では、Db2は、実行中に必要に応じて対等 BSDS データ・セットおよびアクティブ・ログ・データ・セットを割り振ります。 Db2 システム・サービス・アドレス空間（ssnmMSTR ）用の MVS タスクI/Oテーブル（TIOT）のスペースを使い果たすと、 Db2 が失敗する可能性があるため、これを回避するには、以下の操作を実行する：

  1. ALLOCxx PARMLIBメンバーで、 MVS TIOTサイズを 64K。
  2. MVS DEVSUPxx PARMLIBメンバにNON_VSAM_XTIOT=YESを指定すると、オフロード・データ・セットの割り当て時に Db2 、拡張タスクI/Oテーブル（XTIOT）を使用できるようになります。
  3. Db2BSDS、アクティブ・ログ、または 2 次ログ・データ・セットの割り振りに使用される SMS データ・セット・クラスには、0 の動的ボリューム・カウント (DVC) を指定します。
  4. 0 より大きい DVC を使用して割り振られた既存の BSDS、アクティブ・ログ、または 2 次ログ・データ・セットを再割り振りします。

また、アーカイブ・ログ・データ・セットがディスクに保管されている場合でも、原則として、アーカイブ・ログ・データ・セットの読み取りよりもアクティブ・ログ・データ・セットの読み取りの方が高速です。 (ただしアーカイブ・ログに DFSMS 圧縮を使用する場合は、例外的にこの原則が当てはまらない可能性があります。) リカバリーのパフォーマンスがログ読み取り速度に依存している場合、可能な限りアクティブ・ログ・データ・セットを増やすことで、リカバリー・パフォーマンスが改善される可能性があります。

書き込みとアーカイブが行われる、1 日のログ・データの量を考慮してください。 例えば、48 時間前の時点までデータベースをリストアして、過去 48 時間のログ・レコードを良好なパフォーマンスで適用できるようにする必要があるとします。 この場合、48 時間分のログ・データをディスクに保持する必要があります。 アプリケーションが 1 日あたり 100 GB のログ・データを生成する場合、2 日分のログ・レコードをディスクから適用するには 200 GB のログ・スペースがディスク上に必要です。 十分なスペースを割り振ると、200 GB 全体をアクティブ・ログ・データ・セットに保存できます。 十分なスペースを割り振らない場合、ログ・データの残りの部分をアーカイブ・ログ・データ・セットから読み取る必要があります。

データベース・リカバリーの管理の計画と、アーカイブ・ログ・データ・セットの管理は互いに密接に関連しています。 (仮想テープ、実磁気テープのどちらであるかに関わらず) テープ上にアーカイブ・ログ・データ・セットが保管される場合、2 つのリカバリー・ジョブで同時に同じテープを割り振ることはできません。 1 つのテープに複数のデータ・セットが保管される場合、より大きな競合が発生します。 この理由で、多くの場合、テープではなく実ディスク装置にアーカイブ・ログを保管するのが適切です。

ただし、以下に示す代替的な手法を使って、アーカイブ・ログの保管コストを減らすことができます。

• 高価でないニアライン・ドライブをアーカイブ・ログ用に使用する。
• アーカイブ・ログ・データ・セットをテープに保管し、リカバリー・ジョブをサブミットする前にテープからディスクにアーカイブ・ログ・データ・セットをリコールする。
• 低速なリカバリーを許容する。

ただし、Db2ログの管理を計画しているときには、Db2データベースをリカバリーする必要があるときにアプローチを変更するには遅すぎるということを覚えておいてください。