DB2 でのディスク I/O 競合の最小化

IBM DB2 データベースでのディスク I/O の競合を最小限に抑えるには、データベースのコンポーネントをファイル システムに適切に分散させます。データベース管理者は最終的に、I/O リクエストを完了するためにプロセスが他のプロセスを待機するという状況を減らさなければなりません。これは、よく「I/O 待ち」と呼ばれます。

次に、ディスク I/Oの競合を避けるのに役立つヒントを紹介します。

• 一時的なユーザ用の表スペースには SMS を使用し、他のすべての表スペースには DMS を使用

  DB2 には、SMS（システム管理スペース）と DMS（データベース管理スペース）という 2 種類の表スペースの格納モデルがあります。ユーザの一時表領域には SMS 表領域を使用し、他の表領域には、特にデータが定期的に増加することが予想される場合は、パフォーマンスを考慮して、DMS 表領域を使用することが推奨されます。

  注意:

  DB2 9 では、DB2 のグローバル一時テーブル（DECLARE GLOBAL TEMPORARY TABLE）が必要です。DB2 のドキュメントに記載されているように、グローバル一時テーブルを宣言するには、「SYSADM または DBADM 権限のどちらか」、または「USER TEMPORARY 表スペースの USE 特権」が必要です。

  DB2 9 では、データベースの 自動ストレージ機能の使用と、表スペースの 自動サイズ変更を設定することを検討する必要があります。DB2 9 では、DMS 表スペースに、物理的に必要になったとき追加の格納をプロビジョニングする機能があります。

• バッファ プールの設定

  バッファ プールの設定は、パフォーマンスにとってきわめて重要です。デフォルトでは、DB2 は IBMDEFAULTBP という名前のバッファ プールを 1 つ提供します。DB2 9 のデフォルトでは、IBMDEFAULTBP バッファ プールが自動的にサイズ設定されます。データベース管理者は、作業負荷に応じてこのバッファ プールを調整します。

  表スペースごとにバッファ プールを個別に作成する必要があります。データベースのスナップショットを取得して、buffer pool physical read 値を確認します。バッファ プールは、マップの再描画時の物理読み取りの数を少なく保つのに十分なサイズに設定する必要があります。バッファ プールの効率を確認するには、そのバッファ プール ヒット率（BPHR）を計算します。BPHR は、可能であれば 90% 以上であることが理想的です。ヒット率を求める式は次のとおりです。

  BPHR (%) = (1 - (("Buffer pool data physical reads" 
  + "Buffer pool index physical reads")
   / ("Buffer pool data logical reads" 
  + "Buffer pool index logical reads"))) * 100

  バッファ プール ヒット率を確認する別の方法としては、SYSIBMADM.BP_HITRATIO 管理者ビューを使用します。このビューは、すべてのバッファ プールの合計ヒット率、データ ヒット率、XDA ヒット率、インデックス ヒット率などのヒット率を返します。

  SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, 	
  SUBSTR(BP_NAME,1,140) AS BP_NAME,
  TOTAL_HIT_RATIO_PERCENT, 
  DATA_HIT_RATIO_PERCENT, 	
  INDEX_HIT_RATIO_PERCENT, 
  XDA_HIT_RATIO_PERCENT, DBPARTITIONNUM
  FROM SYSIBMADM.BP_HITRATIO
  ORDER BY DBPARTITIONNUM
  

• テーブル サイズの閾値の設定

  原則として、小さいテーブルは同じ表スペースにまとめ、大きいテーブルには独自の表スペースを割り当てます。独自の表スペースが必要となるテーブルの大きさをどれくらいにするか決定します。一般に、この閾値を決定する際には、最大コンテナ サイズも考慮に入れます。最大コンテナ サイズがいっぱいになるようなテーブルは、独自の表スペースに格納する必要があります。また、この制限に達しそうなテーブルについても検討する必要があります。インデックスについても、同じ原則に従います。独自の表スペースを必要とするテーブルやインデックスと、グループにまとめるテーブルやインデックスを別にします。大きいテーブルやアクセス頻度の高いテーブルとそれらのインデックスを同じ表スペースに格納しないでください。DB2 9 を使用している場合、表スペースに 自動ストレージを設定することを検討する必要があります。

• アクセス頻度に応じた小さいテーブルとインデックスの格納

  同じ表スペースにまとめて格納する小さいテーブルをどれにするかは、予想されるアクセス頻度に基づいて決定します。アクセス頻度の高いテーブルとアクセス頻度の低いテーブルは、別々の表スペースに格納します。これにより、アクセス頻度の高い表スペースのコンテナとアクセス頻度の低いコンテナを同じディスク上に配置できるようになります。インデックスにも同じルールが適用されます。つまり、インデックスもアクセス頻度に応じて分割する必要があります。DB2 のログがインデックスやデータとは独立した別のディスクに配置することをお勧めします。オペレーティング システムのカーネル パラメータ MAXUPROC 値にはデフォルトよりも大きい値を設定することをお勧めします。そうすれば、ArcSDE と DB2 インスタンス ユーザが所有するすべてのプロセスを呼び出し時に実行できるようになります。

• AIX オペレーティング システムでは、db2set DB2_MMAP_READ と db2set DB2_MMAP_WRITEを無効化

  パフォーマンスを向上させるために、次の変数をオフにすることが推奨されます。これらの変数は、DB2 で I/O の代わりに MMAP（Multifunction, Multiservice Access Platform）を使用できるようにするために、組み合わせて使用されます。MMAP は、複数のプロセスが同じファイルの異なるセクションに書き込みを行う際、オペレーティング システムのロックを防ぐために使用され、デフォルトでオンになっています。

  db2set DB2_MMAP_READ=OFF
  db2set DB2_MMAP_WRITE=OFF
  

• バージョン対応編集を大規模に行う場合は、ArcSDE システム テーブル STATES、STATE_LINEAGES、MVTABLES_MODIFIED とそれらのインデックスの表スペースを分離

  ArcSDE システム テーブルには、ArcSDE の sdesetup コマンドによって作成される ArcSDE システム テーブルとジオデータベース システム テーブルおよびインデックスが格納されます。表スペースの数や配置は、ArcSDE データベースをどのように使用するかによって異なります。これらのテーブルとインデックスの配置は、DBTUNE の DATA_DICTIONARY コンフィグレーション キーワードの格納パラメータによって制御されます。DATA_DICTIONARY キーワードは、ArcSDE および ジオデータベース システム テーブルの作成にのみ使用されます。ArcGIS アプリケーションをサポートするバージョン対応のデータベースには、きわめてアクティブなステート ツリーがあります。ステート ツリーは、バージョン対応登録されているテーブルで発生したすべての編集操作の状態（ステート）を管理します。ArcSDE には、バージョン対応データベースのステート ツリーのトランザクション情報を管理する 4 つのシステム テーブル（STATES、STATE_LINEAGES、MVTABLES_MODIFIED、VERSIONS）があります。アクティブなバージョン対応データベースでは、STATES_LINEAGE テーブルのレコード数がすぐに 100 万件を超えてしまい、26MB 以上の表スペースを消費する可能性があります。STATES テーブルはかなり小さく、約 5,000 件のレコードを格納し、およそ 2MB の表スペースを消費します。MVTABLES_MODIFIED テーブルは、一般に約 50,000 件のレコードを格納し、およそ 1MB の表スペースを消費します。VERSIONS テーブルは、通常はレコード数が 100 件に満たないきわめて小さなテーブルで、およそ 64KB の表スペースを消費します。編集頻度の高い ArcGIS アプリケーションでは、ディスク I/O の競合を最小限に抑えるために、STATES、STATE_LINEAGES、MVTABLES_MODIFIED テーブルとそれらのインデックスを別の表スペースに作成し、ファイル システムを分けて配置する必要があります。

  注意:

  バージョン対応データベースを使用しない場合、STATE_LINEAGES、STATES、MVTABLES_MODIFIED テーブルとそれらのインデックスのサイズは 40KB まで減ります。テーブル用とインデックス用に 5MB の表スペースを 2 つ作成し、別々のディスク ドライブに配置します。

• ラスタ テーブルに十分な大きさの表スペースを作成し、BLK（ラスタ ブロック テーブル）用に別の表スペースを作成

  ラスタ ブロック テーブルは、かなり大きくなる場合があります。このテーブルを格納するための大きな表スペースを別に作成する必要があります。残りのラスタ テーブルを格納するために別の表スペースを作成することができます。ラスタ ブロック テーブルの表スペースを作成する際には、エクステント サイズとして 64KB、ページ サイズとして 32KB を使用することが推奨されます。エクステント サイズは、次のコンテナに進む前にコンテナに書き込まれるページの数を指定します。

  注意:

  エクステント サイズは、表スペースの作成時に定義され、後から簡単に変更することはできません。

• 大量のデータ（ラスタ データなど）を読み込む際には、データベースで循環ログを使用するように設定

  循環ログは、ログ ファイルの輪（リング）を使用して、データベースへの変更を記録します。リングの最後のログがいっぱいになると、最初のファイルが再利用されます。トランザクション情報が上書きされる可能性があるので、循環ログを使用する際には、ロールフォワード復旧を使用することは不可能です。ただし一般に、データの読み込み時に復元が必要になることはありません。循環ログは、デフォルトのログ モデルです。ロールフォワード復旧を使用する必要がある場合は、アーカイブ ログを使用します。アーカイブ ログはログ ファイルを上書きせず、新しいログを作成して、最後のバックアップ以降のトランザクションをすべて記録します。循環ログのようにログが再利用されないので、アーカイブ ログを使用するには、さらにディスク領域が必要になることに注意してください。

ディスク I/O の競合を減らすようにデータベースをチューニングした後も、デッドロックが発生することがあるかもしれません。デッドロックの詳細については、「DB2 データベースでのデッドロック」をご参照ください。