ArcGIS Server .NET Help - 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 データベースでのデッドロック」をご参照ください。

3/6/2012