パフォーマンス変数

このレジストリー変数に高い値を設定することの潜在的な利点は、バッファー・プールの希望のメモリー量に達するために必要な割り振りの回数が少なくてすむということです。

このレジストリー変数に高い値を設定する際にかかる潜在的な損失は、バッファー・プールが割り振りサイズの倍数で変更されない場合にメモリーが無駄になる点です。 例えば、DB2_ALLOCATION_SIZE の値が 8 MB で、バッファー・プールが 4 MB ずつ削減される場合、8 MB セグメント全体は解放できないので、この 4 MB は無駄になります。

DB2_APM_PERFORMANCE を ON に設定すると、NO PACKAGE LOCK モードも使用可能になります。 このモードは、グローバル照会キャッシュがパッケージ・ロックを使用しないで操作できるようにします。 パッケージ・ロックは、キャッシュされたパッケージ項目が除去されないように保護する内部システム・ロックです。 NO PACKAGE LOCK モードの場合、パフォーマンスはいくらか改善されることがありますが、一部のデータベース操作はできなくなります。 これらの禁止される操作には、パッケージを無効にする操作、パッケージを操作不能にする操作、 PRECOMPILE、BIND、および REBIND が含まれます。

DB2ASSUMEUPDATE レジストリー変数の活動化は、db2start コマンド上では有効です。

バックアップ・イメージおよびロード・コピー・イメージをオペレーティング・システムによってキャッシュに入れるかどうかを指定します。 デフォルト動作の場合、イメージ・ファイルはキャッシュに入れられます。 DB2_BACKUP_USE_DIO が ON に設定されている場合、バックアップ・イメージ・ファイルまたはロード・コピー・イメージ・ファイルは、ファイル・キャッシュをバイパスしてディスクに直接書き込まれます。

     NO_NT_SCATTER = 1

   db2set DB2BPVARS=F:\vars\bpvars.vars

分散読み取りパラメーター

分散読み取りパラメーターは、 それぞれのコンテナー・タイプに対する順次プリフェッチが大量に行われ、 DB2NTNOCACHE をすでに ON に設定したシステムで推奨されます。 Windows プラットフォームでのみ使用可能なこれらのパラメーターは、 NT_SCATTER_DMSFILE、 NT_SCATTER_DMSDEVICE、および NT_SCATTER_SMSです。 NO_NT_SCATTER パラメーターを指定すると、 すべてのコンテナーで分散読み取りを明示的に禁止します。 指定の種類のすべてのコンテナーで分散読み取りをオンに切り替えるには、 特定のパラメーターを使用します。 上記の個々のパラメーターのデフォルトはゼロ (OFF) で、 可能な値はゼロ (OFF) および 1 (ON) です。

DB2_EVALUNCOMMITTED は、currently committed セマンティクスではロック競合の回避に役立たない場合にのみ適用可能です。 この変数が設定されていて、currently committed がスキャンに適用可能な場合、削除済みの行はスキップされず、コミットされていないデータに対しては述部評価が行われません。代わりに、行およびデータの現在コミット済みバージョンが処理されます。

また、 DB2_EVALUNCOMMITTED は、カーソル固定分離レベルまたは読み取り固定分離レベルのいずれかを使用するステートメントにのみ適用できます。 さらに、削除された行は表スキャン・アクセスで無条件にスキップされますが、 索引スキャンでは レジストリー変数 DB2_SKIPDELETED も設定されていない限り、削除されたキーはスキップされません。

DB2_EVALUNCOMMITTED レジストリー変数の活動化は、db2start コマンド上では有効です。 据え置きロッキングを適用可能とするかどうかに関する判断は、ステートメントのコンパイル時またはバインド時に行われます。

• データベースのバージョン: Db2 V9.1
• ロー・デバイスをデータベース・コンテナーに使用する必要があります (ファイル・システム上のコンテナーはサポートされません)。
• ストレージ・サブシステム: Shark DS8000® は、すべての拡張入出力パフォーマンス機能をサポートします。 セットアップおよび前提条件については、Shark DS8000 の資料を参照してください。

HIGH、 MEDIUM、および LOW のデフォルトの入出力優先順位設定は、それぞれ 3、 8、および 12です。これらの設定を変更するには、 DB2_IO_PRIORITY_SETTING レジストリー変数を使用できます。

この変数は、照会パフォーマンスの向上に役立つように、照会オプティマイザーが最適化拡張を使用するかどうかを指定します。 値は、異なる最適化拡張を指定します。 複数の値を指定する場合は、コンマ区切りのリストを使用します。

   INDEX IX2:  dept    ASC
   INDEX IX3:  job     ASC

   WHERE
        dept = :hv1 OR
        (job = :hv2 AND
        years >= :hv3)

OPT_SORTHEAP_EXCEPT_COL value オプションを使用して、 sortheap データベース構成パラメーターの値をオーバーライドできます。 オーバーライド値は、照会最適化だけに影響を与えます。 実行時に使用可能な実際のメモリー量の決定は行いません。 照会が カラム・オーガナイズ 表にアクセスする場合、このオーバーライド値は無視され、照会コンパイラーが sortheap データベース構成パラメーターの現行値を使用できるようになります。

OPT_SORTHEAP_EXCEPT_COL の使用法の 1 つは、シャドー表のためのものです。 シャドー表は、OLTP 環境での分析照会のために BLU Acceleration® を容易にします。 シャドー表は カラム・オーガナイズ 表です。 ソート・ヒープ・メモリーの要件は、OLTP 環境でデータベース用に通常使用する量よりも大きくなります。 OLTP 照会の既存のアクセス・プランに影響を与えることなくソート・ヒープ・メモリーを増やすには、OPT_SORTHEAP_EXCEPT_COL を DB2_EXTENDED_OPTIMIZATION に追加して、sortheap データベース構成パラメーターの値をオーバーライドします。

DB2_EXTENDED_OPTIMIZATION 設定を使用しても、必ずしもすべての環境で照会のパフォーマンスが向上するわけではありません。 それぞれの照会パフォーマンスが向上するかどうかを判別するために、テストを行う必要があります。

この変数が CONNECTION に設定されていると、アプリケーションがトランザクションをロールバックするか、接続がリセットされるまで、表ロックはアプリケーションに対して解放されています。 表ロックはコミット間で保持され続け、表ロックをドロップするアプリケーション要求はデータベースによって無視されます。 表ロックは、アプリケーションに割り振られたままです。 したがって、アプリケーションが表ロックを再び要求するとき、ロックはすでに使用可能です。

この最適化を活用できるアプリケーションのワークロードの場合、パフォーマンスは向上します。 ただし、同時に実行されるその他のアプリケーションのワークロードが、影響を受ける場合があります。 その他のアプリケーションは、並行性が低下する結果となる指定された表へのアクセスをブロックされる可能性があります。 Db2 SQL のカタログ表は、この設定の影響を受けません。 CONNECTION 設定には、ON または TRANSACTION 設定で説明されている動作も含まれます。

このレジストリー変数はステートメントのコンパイル時またはバインド時にチェックされます。

データベース・メモリー (DB) に対してラージ・ページまたはヒュージ・ページを使用する場合、データベース・メモリーの動的削減が制限され、db_mem_thresh 設定は無視されます。 セルフチューニング・メモリー・マネージャー (STMM) は、データベース領域の全体のサイズは調整しません。 しかし、STMM は、構成に従ってデータベース・メモリー領域内の個々の領域をチューニングします。 詳しくは、関連リンク・セクションにある database_memory トピックを参照してください。

集中的なメモリー・アクセスを必要とし、大量の仮想メモリーを使用するアプリケーションでは、このラージ・ページまたはヒュージ・ページの使用によってパフォーマンスを向上できる場合があります。 Db2 データベース・システムでそれらを使用できるようにするには、まずオペレーティング・システムがラージ・ページまたはヒュージ・ページを使用できるように構成する必要があります。

64 ビット Db2 for AIX ( DB2_LARGE_PAGE_MEM=PRIVATE 設定) でエージェント専用メモリー用にラージ・ページを使用可能にするには、オペレーティング・システム上にラージ・ページを構成し、インスタンス所有者が CAP_BYPASS_RAC_VMM および CAP_PROPAGATE 機能を持っていなければなりません。

Linux で、ヒュージ・カーネル・ページが使用可能であることを確認するには、次のコマンドを実行します。

   cat ⁄proc/meminfo

ヒュージ・カーネル・ページが使用可能である場合は、次の 3 行が表示されます (サーバー上に構成されているメモリーの量によって数値は異なります)。

HugePages_Total:   200
HugePages_Free:    200
Hugepagesize:    16384 kB

これらの行が表示されない場合、または HugePages_Total が 0 である場合は、オペレーティング・システムまたはカーネルを構成する必要があります。

Windows では、システムで使用可能なラージ・ページ・メモリーの量は、合計使用可能メモリーよりも少なくなります。 システムがいくらかの時間稼働した後、メモリーをフラグメント化できるようになり、ラージ・ページ・メモリーの量が減少します。 Windows で大容量メモリー・ページを割り振る際に一貫したパフォーマンスを実現するには、 DB2_ALLOCATION_SIZE レジストリー変数を 256 MB などの高い値に設定する必要があります。 (DB2_ALLOCATION_SIZE を使用する場合は、インスタンスを停止してから再始動する必要があります)。

アプリケーションの作業単位に含まれるステートメント数が非常に多い場合や、多数のアプリケーションが並行して実行されている場合は、システム・モニター・ヒープが使い尽くされることがあります。

• ロールアウトなし - OFF を指定した場合
• 即時ロールアウト - IMMEDIATE を指定した場合
• 索引の据え置きクリーンアップ付きのロールアウト - DEFER を指定した場合

表に対して非パーティション化された RID 索引のみ存在する場合には、据え置き索引クリーンアップ・ロールアウトがサポートされます。

DB2MEMDISCLAIM を YES に設定すると、ページング・スペースの所要量が少なくなり、場合によってはページングによるディスク・アクティビティーも少なくなります。 DB2MEMDISCLAIM を NO に設定すると、ページング・スペース所要量が増加し、場合によってはページングによるディスク・アクティビティーも増加します。 ページング・スペースが多い場合や、 ページングが行われないほど実メモリーが十分にある場合などは、 NO を設定してもパフォーマンスはわずかしか向上しません。

この変数が設定されない場合、Db2 データベース・マネージャーは minfree と maxfree の値を、サーバーのメモリー量に基づいて計算します。 instance_memory が限られている環境では、Db2 データベース・マネージャーは minfree と maxfree の値を、instance_memory 設定に基づいて計算します。 セルフチューニング・メモリー・マネージャー (STMM) が有効で database_memory が AUTOMATIC に設定されている場合を除き、この変数を設定しても効果はありません。

バージョン 10.5以降、上記の表の値に含まれている 5% のバッファーが追加されました。 この追加バッファーは、自動調整される STMM 環境で必要な回復力を維持しつつ、より広範な環境でのメモリー要求の揮発性に対応するためのものです。 ただし、5% の追加バッファーは、新たにアクティブになるデータベースで、アクティブ化時のデチューニング (規模縮小) を最小限に抑えるために使用されます。 バージョン 10.5 以降の STMM チューナーが、以前のリリースの STMM チューナー (システム・メモリーを求めて競合しているもの) の存在を検出すると、 バージョン 10.5 以降で実行されているデータベースの計算から追加の 5% バッファーが削除されます。 この 5% の追加バッファーの除外は、前のリリースで実行されているデータベース (空きメモリーのターゲットが低くなる傾向にある) にメモリー割り振りが偏らないようにすることを目的としています。

STMM 環境で minfree, maxfree 設定値を小さくすることで、パフォーマンス向上が達成される場合があります。 ただし、メモリー要求の揮発性によってページングまたはメモリーの使い尽くしが発生しないようにする必要があります。

この変数を変更すると、すべての STMM チューニング操作に対してただちに有効になります。 インスタンスを再始動したり、db2set コマンドに -immediate パラメーターを付けて実行したりする必要はありません。

これらの変数が ON に設定されている場合、Db2 バッファー・プールへのデータの読み込み、およびバッファー・プールからのデータの書き出しはメモリー・マップ I/O を使用して行われ、データは後でファイル・システム・キャッシュから削除されます。 これにより、Db2 データが二重にキャッシュされることを防ぎます。 ただし、ファイル・システム・キャッシュをバイパスするための推奨される方法は、表スペース・レベルで NO FILE SYSTEM CACHING 節を指定し、これらの変数をデフォルト設定の OFFのままにすることです。

これらの変数が ON に設定されている場合、Db2 バッファー・プールへのデータの読み込み、およびバッファー・プールからのデータの書き出しはメモリー・マップ I/O を使用して行われ、データは後でファイル・システム・キャッシュから削除されます。 これにより、Db2 データが二重にキャッシュされることを防ぎます。 ただし、ファイル・システム・キャッシュをバイパスするための推奨される方法は、表スペース・レベルで NO FILE SYSTEM CACHING 節を指定し、これらの変数をデフォルト設定の OFFのままにすることです。

1. 並列 FCM バッファー: デフォルトのサイズ 512 MB (32 ビット・プラットフォーム)、4.5 GB (64 ビット・プラットフォーム)。オーバーライド・オプションは FCM:number_of_bytes です。
2. fenced モード・コミュニケーション: デフォルトのサイズ 80 MB (32 ビット・プラットフォーム)、512 MB (64 ビット・プラットフォーム)。オーバーライド・オプションは APLD:number_of_bytes です。
3. メッセージ照会メモリー: 32 ビットおよび 64 ビット・プラットフォームのデフォルト・サイズは 4 MB です。オーバーライド・オプションは QUE:<number of bytes> です。

db2set DB2NTMEMSIZE=FCM:1073741824;APLD:268435456

db2set DB2NTMEMSIZE=QUE:67108864

Windows では、ファイルは開かれたときにキャッシュに入れられます。これがデフォルトの動作です。 ファイル内の 1 GB ごとに 1 MB がシステム・プールから予約されます。 このレジストリー変数を使用して、キャッシュに関する (文書化されていない) 192 MB 制限をオーバーライドします。 キャッシュの限界に達すると、リソース不足を示すエラーが表示されます。

• NORMAL_PRIORITY_CLASS (デフォルトの優先度クラス)
• REALTIME_PRIORITY_CLASS (R を使って設定)
• HIGH_PRIORITY_CLASS (H を使って設定)

この変数は、個々のスレッド優先順位 ( DB2PRIORITIESを使用して設定) とともに使用され、システム内の他のスレッドに対する Db2 スレッドの絶対優先順位を決定します。

詳細は、Win32 資料の SetPriorityClass() API を参照してください。

DB2NTWORKSET は、構文 DB2NTWORKSET=min, maxを使用して指定します。ここで、 min および max はメガバイトで表されます。

バッファー・プールのすべてまたはサブセットのサイズを一時的に変更して、起動できるようにするために、<entry>[;<entry>...] (<entry> = <buffer pool ID>,<number of pages>) を使用することも可能です。

Linuxでは、このレジストリー変数の変更に加えて、ライブラリー libcap.so.1 も必要になります。

この変数を YES に設定すると、データベース共有メモリーのセルフチューニング (database_memory 構成パラメーターを AUTOMATIC に設定することによって活動化される) を使用可能にできなくなります。

64 ビット環境での HP-UX では、このレジストリー環境を変更する他に、 Db2 インスタンス・グループに MLOCK 特権を与えなければなりません。 これを行うには、ルート・アクセス権限を持つユーザーが以下の処置を実行します。

POWER7® 以降のプロセッサーを搭載した AIX システム、または任意の Linux または Windows システムでは、この変数を AUTOMATICに設定できます。 AUTOMATIC オプションを指定すると、 Db2 データベース・システムはハードウェア・トポロジーを自動的に判別し、ハードウェア・トポロジーに表示される関連リソース (プロセッサーとメモリー) のセットごとにリソース・グループを作成します。 ハードウェア・トポロジーによっては、1 つ以上のリソース・グループが存在し、それぞれに 1 つ以上のリソースが含まれることがあります。

AUTOMATIC 設定は、プロセッサー・アフィニティーを有効にします。これにより、 Db2 データベース・システムは、エンジン・ディスパッチ可能単位 (EDU) を特定のリソース・グループおよびリソースに割り当てます。 また、AUTOMATIC 設定により、メモリーのアフィニティー化を有効にするかどうかも決まります。このプロセスでは、メモリーのアフィニティーを改善するために、EDU が処理の際にローカル・メモリーの割り振りを試行します。 EDU のリソース割り当ては、循環ラウンドロビン方式で行われ、各リソースが同等であると想定しています。 POWER7 以降のプロセッサーを使用するシステムでは、 AUTOMATIC 設定の使用は、リソースの配分がスキューされたり、複数の LPAR を持つシステムなどで変更される可能性がある場合には推奨されません。 AIXを実行する POWER ® システムでは、 lssrad -av コマンドを使用してリソース割り振りを決定できます。 Linuxを実行している POWER システムでは、 numactl -H コマンドを使用してリソース割り振りを判別できます。

この設定は、ハードウェア・トポロジーで複数のリソース・グループやリソースを公開するシステム向けであり、一部のワークロードの照会パフォーマンスを向上させることができます。 パフォーマンスの向上について確認するには、DB2_RESOURCE_POLICY 変数を AUTOMATIC に設定する前と後でワークロードのパフォーマンス分析を実行することが推奨されています。

レジストリー変数を設定して、 Db2 EDU を特定のリソース・グループおよびリソースにバインドするためのポリシーを定義する構成ファイルへのパスを指定することもできます。 これは、AUTOMATIC 設定を使用して目的の構成を取得できない場合に役立ちます。

構成ファイルの例:

例 1: すべての Db2 プロセスを CPU 1 または 3 にバインドします。

<RESOURCE_POLICY>  	
		<GLOBAL_RESOURCE_POLICY>  
			<METHOD>CPU</METHOD> 
			<RESOURCE_BINDING> 
  		<RESOURCE>1</RESOURCE>	
			</RESOURCE_BINDING>
			<RESOURCE_BINDING>
				<RESOURCE>3</RESOURCE>
			</RESOURCE_BINDING>
		</GLOBAL_RESOURCE_POLICY>
	</RESOURCE_POLICY> 

例 2: (AIX のみ) Db2 プロセスを以下のいずれかのリソース・セットにバインドします。 sys/node.03.00000、 sys/node.03.00001、 sys/node.03.00002、 sys/node.03.00003

<RESOURCE_POLICY>
		<GLOBAL_RESOURCE_POLICY> 
			<METHOD>RSET</METHOD> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00000</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00001</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00002</RESOURCE> 
			</RESOURCE_BINDING> 
			<RESOURCE_BINDING> 
				<RESOURCE>sys/node.03.00003</RESOURCE> 
			</RESOURCE_BINDING> 
		</GLOBAL_RESOURCE_POLICY> 
	</RESOURCE_POLICY> 

例 3: (Linux のみ) SAMPLE データベースに関連付けられているバッファー・プール ID 2 および 3 のすべてのメモリーを NUMA ノード 3 にバインドします。 また、NUMA ノード 3 にバインドするために合計データベース・メモリーの 80% を使用し、非バッファー・プール固有のメモリーのためにすべてのノードにストライピングするために 20% を残しておきます。

<RESOURCE_POLICY>
		<DATABASE_RESOURCE_POLICY>
			<DBNAME>sample</DBNAME>
			<METHOD>NODEMASK</METHOD>
			<RESOURCE_BINDING>
				<RESOURCE>3</RESOURCE>
				<DBMEM_PERCENTAGE>80</DBMEM_PERCENTAGE>
				<BUFFERPOOL_BINDING>
					<BUFFERPOOL_ID>2</BUFFERPOOL_ID>
					<BUFFERPOOL_ID>3</BUFFERPOOL_ID>
 			</BUFFERPOOL_BINDING>
			</RESOURCE_BINDING>
		</DATABASE_RESOURCE_POLICY>
	</RESOURCE_POLICY>

例 4: ( Linux および Windows のみ) CPU マスク 0x0F および 0xF0によって指定された 2 つの別個のプロセッサー・セットを定義します。 Db2 プロセスおよびバッファー・プール ID 2 をプロセッサー・セット 0x0F にバインドし、Db2 プロセスおよびバッファー・プール ID 3 をプロセッサー・セット 0xF0 にバインドします。 各プロセッサー・セットで、データベース・メモリー全体の 50 % をバインディングに使用します。

プロセッサーと NUMA ノードとの間でマッピングを行うことが望ましい場合、このリソース・ポリシーが有効です。 例えば、システムに 8 つのプロセッサーと 2 つの NUMA ノードがあるとすれば、プロセッサー 0 から 3 が NUMA ノード 0 に属し、プロセッサー 4 から 7 が NUMA ノード 1 に属する、といった具合になります。 このリソース・ポリシーは、メモリーの局所性 (つまり、CPU メソッドと NODEMASK メソッドのハイブリッド) を暗黙的に維持しながら、プロセッサー・バインディングを可能にします。

 <RESOURCE_POLICY>
   <DATABASE_RESOURCE_POLICY>
     <DBNAME>sample</DBNAME>
     <METHOD>CPUMASK</METHOD>
     <RESOURCE_BINDING>
       <RESOURCE>0x0F</RESOURCE>
       <DBMEM_PERCENTAGE>50</DBMEM_PERCENTAGE>
       <BUFFERPOOL_BINDING>
         <BUFFERPOOL_ID>2</BUFFERPOOL_ID>
       </BUFFERPOOL_BINDING>
     </RESOURCE_BINDING>
     <RESOURCE_BINDING>
       <RESOURCE>0xF0</RESOURCE>
       <DBMEM_PERCENTAGE>50</DBMEM_PERCENTAGE>
       <BUFFERPOOL_BINDING>
         <BUFFERPOOL_ID>3</BUFFERPOOL_ID>
       </BUFFERPOOL_BINDING>
     </RESOURCE_BINDING>
   </DATABASE_RESOURCE_POLICY>
 </RESOURCE_POLICY>

例 5: (AIX オペレーティング・システムのみ) リソース・ポリシー・ファイルでリソース・グループを指定することにより、リソース・グループ認識を手動で有効にすることができます。 RESOURCE_GROUP 要素を使用して、特定のリソース・グループに属するリソースを指定します。 定義されたリソース・グループは、NUMA 境界に位置合わせする必要はありません。 ENV_GET_DB2_EDU_SYSTEM_RESOURCES 表関数の RESOURCE_GROUP 列は、EDU が関連付けられるリソース・グループを示しています。

<RESOURCE_POLICY>
  <GLOBAL_RESOURCE_POLICY>

    <METHOD>SRAD</METHOD>

    <RESOURCE_GROUP>
      <RESOURCE_GROUP_NAME>TESTGROUP1</RESOURCE_GROUP_NAME>

      <RESOURCE_BINDING>
        <RESOURCE>0</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>1</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>2</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>3</RESOURCE>
      </RESOURCE_BINDING>

    </RESOURCE_GROUP>

    <RESOURCE_GROUP>
      <RESOURCE_GROUP_NAME>TESTGROUP2</RESOURCE_GROUP_NAME>

      <RESOURCE_BINDING>
        <RESOURCE>4</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>5</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>6</RESOURCE>
      </RESOURCE_BINDING>

      <RESOURCE_BINDING>
        <RESOURCE>7</RESOURCE>
      </RESOURCE_BINDING>

    </RESOURCE_GROUP>

  </GLOBAL_RESOURCE_POLICY>
</RESOURCE_POLICY>

あるいは、レジストリー変数 DB2PRIORITIES および DB2NTPRICLASS を使用して、オペレーティング・システムのスケジューリング・ポリシーを制御し、 Db2 エージェントの優先順位を設定することができます。 なお、リソース・ポリシー構成ファイル内の SCHEDULING_POLICY 要素の仕様上、スケジューリング・ポリシーとそれに関連したエージェントの優先順位の両方を 1 つの場所で指定する必要があります。

例 1: Db2 ログ書き込みプロセスおよびリーダー・プロセスの優先順位を上げる AIX SCHED_FIFO2 スケジューリング・ポリシーの選択。

	<RESOURCE_POLICY> 
		<SCHEDULING_POLICY>
			<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
			<PRIORITY_VALUE>60</PRIORITY_VALUE>

			<EDU_PRIORITY>
				<EDU_NAME>db2loggr</EDU_NAME>
				<PRIORITY_VALUE>56</PRIORITY_VALUE>
			</EDU_PRIORITY>

			<EDU_PRIORITY>
				<EDU_NAME>db2loggw</EDU_NAME>
				<PRIORITY_VALUE>56</PRIORITY_VALUE>
			</EDU_PRIORITY>
		</SCHEDULING_POLICY>
	</RESOURCE_POLICY>

例 2: Windows での DB2NTPRICLASS=H の置換。

	<RESOURCE_POLICY> 
		<SCHEDULING_POLICY>
			<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
		</SCHEDULING_POLICY>
	</RESOURCE_POLICY>

パーティション内並列処理が使用可能である場合には、このレジストリー変数はサポートされません。

この変数に対する変更は、db2set コマンドに -immediate パラメーターを指定して発行すると、その後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_SKIPDELETED は、currently committed セマンティクスではロック競合の回避に役立たない場合にのみ適用可能です。 この変数が設定されていて、currently committed がスキャンに適用可能な場合、削除された行はスキップされません。代わりに、それらの行の現在コミット済みバージョンが処理されます。

このレジストリー変数は Db2 カタログ表上のカーソルの動作には影響を与えません。

このレジストリー変数は、db2start コマンドによって活動化されます。

currently committed セマンティクスが使用されている場合、このレジストリー変数の効果はありません。 つまり、DB2_SKIPINSERTED が OFF に設定されていても、currently committed 動作が有効になっていれば、挿入されてもコミットされていない行はスキップされます。

DB2_SMP_INDEX_CREATE は、ゼロ以外の値が設定されるときにのみ有効です。 索引データをスキャンおよびソートするのに使用されるエージェント数が増加するとき、データベース構成パラメーター sortheap および sheapthres_shr が適切に設定されていることを確認することが重要です。 ソートに多くのメモリーが使用可能であればあるほど (sheapthres_shr パラメーターによって指定される)、索引データのソートがシステムの TEMPORARY 表スペースに一時結果を書き込むことが必要になる可能性は低くなります。 ソートはディスクにスピルしない場合、さらに速くなります。 さらに、ソートに参加している各エージェントが同量のメモリーを取得するようにするには、sortheap パラメーターが sheapthres_shr/n 以下の値に設定される必要があります。 ここで、n は索引表をスキャンおよびソートするのに使用されるエージェント数です。

この変数のデフォルト設定値は -2 です。 つまり、予備 SMS 一時オブジェクトのうち、そのサイズが「1 エクステント * コンテナー数」以下のオブジェクトに関しては、不要なファイル・システム・アクセスが生じないという意味です。 これより大きい一時オブジェクトは、切り捨てられて 0 エクステントになります。

この変数が 0 に設定されている場合、特殊しきい値処理は実行されません。 その代わり、一時表が不要になると、 そのファイルは切り捨てられて 0 エクステントになります。 この変数の値を 0 より大きくすると、より大きなファイルが保持されるようになります。 しきい値よりも大きいオブジェクトは、切り捨てられてしきい値のサイズになります。 これにより、一時表が使用されるごとのファイルのドロップおよび再作成に関係するシステム・オーバーヘッドが若干減少します。

この変数が -1 に設定されている場合は、ファイルが切り捨てられることはなく、ファイルはシステム・リソースによる制限を除いて 無制限に増大します。

DB2_SORT_AFTER_TQ=NO の場合、 オプティマイザーは送信終了時には行のソートを、受信終了時には行のマージを行う傾向があります。

DB2_SORT_AFTER_TQ=YES の場合、 オプティマイザーはソートをしないで行を送信し、 すべての行を受信した後の受信終了時にもマージを行わない傾向があります。

この変数に対する変更は、db2set コマンドに -immediate パラメーターを指定して発行すると、その後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

SQL 作業スペースには、SQL の実行の割り振りが、セクションの形式で含まれています。 アプリケーションに代わって実行される各 SQL ステートメント (静的または動的) は、そのステートメントが実行される間、セクションの固有のコピーを SQL 作業スペースに保持する必要があります。 ステートメントの実行が完了した後、セクションは非アクティブになります。非アクティブ・セクションと関連付けられているメモリー割り振りは、解放することも、SQL 作業スペースのキャッシュに入れたままにすることもできます。 いずれかの接続から同じ SQL ステートメントを新たに実行したときに、前回の実行で残された SQL 作業スペースのセクションのキャッシュ・コピーをそのステートメントが見つけると、セクションの新規コピーの割り振りと初期化に関連したコストを省くことができます。 このように、SQL 作業スペースには、アクティブ・セクション (現時点で実行されている SQL に対応するもの) とキャッシュ・セクション (現時点では実行されていないもの) の両方が含まれます。

DB2_TRUST_MDC_BLOCK_FULL_HINT 変数が設定されている場合、 Db2 は、複合ブロック索引の Full_Block ビットでマークされているブロック内のフリー・スペースの検索をスキップします。 この Full_Block ビットは、ブロック全体が削除されたとき、および REORG コマンドを使用して複合ブロック索引が再作成されたときにのみクリアされるため、ヒントにすぎません。 トレードオフとは、ロールアウト削除によってブロックを完全に空にするのと対照的に、それらを部分的に空にする削除が実行される場合に、いくつかのフリー・スペースが浪費される可能性があるということです。 ロールアウト削除について詳しくは、『MDC 表の最適化ストラテジー』のトピックの『ロールバック削除』を参照してください。

この変数が使用可能になっていると、組み込み unfenced ストアード・プロシージャー内に含まれる SQL および XQuery ステートメントのバインド中に外部 SQLDA フォーマットから内部 Db2 フォーマットへの変換は行われません。 これにより、組み込み SQL および XQuery ステートメントの処理速度が増します。

この変数が使用可能になっている場合、以下のデータ・タイプは組み込み unfenced ストアード・プロシージャーでサポートされません。

• SQL_TYP_DATE
• SQL_TYP_TIME
• SQL_TYP_STAMP
• SQL_TYP_CGSTR
• SQL_TYP_BLOB
• SQL_TYP_CLOB
• SQL_TYP_DBCLOB
• SQL_TYP_CSTR
• SQL_TYP_LSTR
• SQL_TYP_BLOB_LOCATOR
• SQL_TYP_CLOB_LOCATOR
• SQL_TYP_DCLOB_LOCATOR
• SQL_TYP_BLOB_FILE
• SQL_TYP_CLOB_FILE
• SQL_TYP_DCLOB_FILE
• SQL_TYP_BLOB_FILE_OBSOLETE
• SQL_TYP_CLOB_FILE_OBSOLETE
• SQL_TYP_DCLOB_FILE_OBSOLETE

これらのデータ・タイプが見つかると、SQLCODE -804、SQLSTATE 07002 エラーが戻されます。

高速事前割り振りを使用不可にするには、DB2_USE_FAST_PREALLOCATION を OFF に設定します。 これにより、実行時のパフォーマンスが向上する可能性がありますが、同じ表スペースで大量の挿入と選択が行われる場合は、一部のオペレーティング・システム (特に AIX) では、表スペースの作成とデータベースのリストアにかかる時間が長くなります。 高速事前割り振りを無効に設定した場合はデータベースを再始動する必要があるので注意してください。

ログの高速事前割り振りを使用可能にするには、DB2_USE_FAST_LOG_PREALLOCATION を ON に設定します。

• 直接ディスク (ロー) アクセスが構成されているデータベース管理 (DMS) 表スペースを使用することはサポートされません。
• NO FILESYSTEM CACHING で構成されているシステム管理 (SMS) 表スペースの使用はサポートされていません。
• ワークロードの特性によっては、ラージ・オブジェクト (LOB) データへのアクセスのパフォーマンスが低下する可能性があります。
• 4 KB セクターのサポートを有効にする前に作成したバックアップ・イメージまたはロード・コピー・ファイルは、それぞれリストアまたは処理するときに、パフォーマンスが低下する可能性があります。
• バックアップ・イメージとロード・コピー・ファイルのサイズが多少大きくなります。
• この機能は、 pureScale® インスタンスではサポートされていません。