DB2_FORCE_FCM_BP レジストリー変数を使用可能にする場合、他の使用、特にデータベース・バッファー・プールに使用可能な共用メモリー・セグメントは、1 つ少なくなります。DB2_FORCE_FCM_BP レジストリー変数を使用可能にすると、こうしてデータベース・バッファー・プールの最大サイズが削減されます。64 ビット環境で使用可能な共用メモリー・セグメントの数は非常に多いため、共用メモリー・セグメント数の削減は、32 ビット環境でのみ問題となることに注意してください。
| | |表が最初に作成されると、システム・カタログ統計は -1 に設定され、表に統計がないことを示します。統計が収集されるまで、DB2 UDB は SQL ステートメントのコンパイルおよび最適化にデフォルト値を使用します。新しい値がデフォルト値と矛盾すると、表または索引の統計の更新が失敗することがあります。 |したがって、手動で表または索引の統計を更新する前に、どちらについても runstats コマンドを実行してください。
| | |SQL エラー・メッセージ SQL1169N に、Explain 表の列が小さすぎることを示す新規の理由コード 5 があります。 |
|以下の文章は、「管理ガイド: パフォーマンス」の第 6 章『SQL コンパイラーについて』に加えられた更新です。
|DELETE ステートメントに WHERE 文節が存在するかどうかに関係なく、RID 索引が最適化計画の一部であっても、MDC ロールアウトが使用されることがあります。 |その結果、ロールアウトを許可し、行を削除するためのより効率的な方法の使用を許可するために満たされるべき条件のリスト時に、「DELETE ステートメントに WHERE 文節がない場合を除き、削除される行を検索するためにオプティマイザーが RID 索引を選択しなかった」という条件を除去する必要があります。
|さらに、db2expln 出力が 『Cell Delete』 という句を示しているため、MDC ロールアウトが有効かどうかを通知することができます。db2exfmt はこの情報を表示しないことに注意してください。
|以下の文章は、 付録 A『DB2 レジストリー変数と環境変数』に加えられた更新です。
|「DELETE ステートメントに WHERE 文節がない場合を除き、削除される行を検索するためにオプティマイザーが RID 索引を選択しなかった」という条件がリストから除去されるように、DB2_MDC_ROLLOUT の記述を変更する必要があります。
| | |DB2 UDB Enterprise Server Edition 環境で newlogpath、mirrorpath、または overflowlogpath 構成パラメーター値を更新する場合、システム上のノードの数に関係なく、パス名にノード番号が追加されます。これは、DB2 UDB Enterprise Server Edition 環境の単一パーティションおよび複数パーティション両方のシステムに適用されます。
| | |DB2_COLLECT_TS_REC_INFO のデフォルト値は ON です。DB2 UDB V 8.1 フィックスパック 7 では、DB2_COLLECT_TS_REC_INFO レジストリー変数のデフォルト値が ON に変更されました。現行の資料では、この変数のデフォルトを OFF としていますが、これは誤りです。
ガバナー・インスタンスは、 フロントエンド・ユーティリティーおよび 1 つ以上のデーモンで構成されています。 開始するガバナーの各インスタンスは、 データベース・マネージャーのインスタンスに特定のものです。 デフォルトでは、ガバナーを開始すると、 パーティション・データベースの各パーティションでガバナー・デーモンが開始します。 ただし、モニターしたい単一のパーティションでデーモンが開始するように指定することもできます。
それぞれのガバナー・デーモンは、 データベースに対して実行しているアプリケーションについての情報を収集します。 そしてガバナー・デーモンはその情報を、 このデータベースについてガバナー構成ファイルで指定した規則と比較して検査します。
インプレース表再編成 (従来の表の再編成ではなく) を検討するときは、インプレース表再編成のほうが、必要なログ・スペースが増えることに注意してください。
予期しない障害が起きた場合のリカバリーを可能にするために、 インプレース表再編成はアクティビティーをログに記録します。 このため、従来の再編成よりも大きなログ・スペースを必要とします。
インプレース再編成が、 再編成後の表の何倍にも及ぶログ・スペースを必要とすることもあります。 必要なスペースは、移動される行数、 および表の索引の数やサイズに応じて異なります。
推奨: 最小保守ウィンドウで 24x7 操作を行う場合、 インプレース表再編成を使用してください。
DMS 表のオンライン表再編成では、再編成を実行しながら、表が置かれている表スペースのオンライン・バックアップ操作を行うことができます。 切り捨て段階で、再編成操作のロック待機が生じることがあります。
これらの表再編成方式の実行方法について、 詳しくは REORG TABLE 構文の説明を参照してください。
AIX(R) 5L 64 ビットで、DB2_LARGE_PAGE_MEM レジストリー変数はキーワード FCM をサポートするようになりました。
デフォルトでは、AIX(R) 5L(TM) 64 ビット上の FCM メモリーは DBMS メモリー・セット内にあります。 ただし、レジストリー変数 DB2_FORCE_FCM_BP を有効にすると、FCM メモリーは自身のメモリー・セット内に入ります。 AIX 5L(TM) 64 ビットでは、DB2_LARGE_PAGE_MEM は、DBMS メモリー・セットの指定をサポートします。 FCM メモリーが DBMS メモリー・セット内にあって、そのメモリー・セットに対してラージ・ページのサポートが有効であると、FCM メモリーはラージ・ページに入ります。 FCM メモリーが自身のメモリー・セット内にある場合、DB2_LARGE_PAGE_MEM レジストリー変数の値に FCM キーワードを追加して、FCM メモリー用のラージ・ページを有効にする必要があります。
DB2 Universal Database(TM) (UDB) バージョン 8.2.2 (バージョン 8.1 フィックスパック 9 と同等) 以降では、DB2_RESOURCE_POLICY レジストリー変数で指定された構成ファイルは、SCHEDULING_POLICY エレメントを受け入れます。 SCHEDULING_POLICY エレメントは、幾つかのプラットフォームにおいて、以下を選択するために使用できます。
レジストリー変数 DB2PRIORITIES および DB2NTPRICLASS は、オペレーティング・システム・スケジューリング・ポリシーのコントロールと DB2 エージェント優先順位の設定のために別々に使用することができます。
ただし、リソース・ポリシー構成ファイルで SCHEDULING_POLICY エレメントを指定すると、スケジューリング・ポリシーと関連したエージェント優先順位の両方を指定する単一の場所が提供されます。
AIX SCHED_FIFO2 スケジューリング・ポリシーを、DB2 ログ書き込みおよび読み取りプロセスの優先順位格上げと共に選択。
<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>Windows での DB2NTPRICLASS=H の置き換え。
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>DB2_MAPPED_BASE および DB2DBMSADDR システム環境変数がフィックスパック 8 で追加されました。
これらのレジストリー変数の使用は、上級ユーザーにのみお勧めします。
DB2 UDB は、この変数が設定されていない場合、共用ライブラリーを仮想アドレス 0x10000000 に再配置しようとします。
レジストリー変数は、31 および 32 ビットのアドレス・スペースの範囲内で任意の仮想アドレスに (16 進で) 設定することもできます。
db2set DB2_MAPPED_BASE=
この変更は論理ノードごとに 1 回必要であるため、以下のメッセージが db2diag.log ファイルに複数回出力されることがあります。
ADM0506I DB2 has automatically updated the "mapped_base" kernel parameter from "0x40000000(hex) 1073741824(dec)" to the recommended value "0x10000000(hex) 268435456(dec)".
このメッセージは、レジストリー変数が正常に設定された場合にのみ出力され、共用ライブラリーが再配置される先のアドレスが含まれます。
db2set DB2DBMSADDR=
この変数は、DB2_MAPPED_BASE とともに設定するかまたは単独で設定して、DB2 UDB プロセスのアドレス・スペース・レイアウトを調整することができます。この変数により、インスタンスの共用メモリーのロケーションが仮想アドレス 0x20000000 の現在のロケーションから指定された新規の値に変更されます。
バージョン 8.2 で DB2TCP_CLIENT_RCVTIMEOUT レジストリー変数が追加されました。
バージョン 8.2 で DB2_LARGE_PAGE_MEM パフォーマンス変数が追加されました。
| 変数名 | オペレーティング・システム | 値 |
|---|---|---|
| 説明 | ||
| DB2_LARGE_PAGE_MEM |
AIX(R) 5.x 64 ビットのみ Linux |
デフォルト = NULL
該当するすべてのメモリー領域がラージ・ページ・メモリーを使用すべき場合は * を使用します。それ以外の場合は、ラージ・ページ・メモリーを使用すべき特定のメモリー領域をコンマで区切られたリストで指定します。 使用可能な領域はオペレーティング・システムによって異なります。 AIX 5.x 64 ビット上では、DB、DBMS、または PRIVATE の領域を指定できます。 Linux 上では、DB の領域を指定できます。 |
|
ラージ・ページ・メモリーは、DB2 Universal Database (UDB) for AIX 5L(TM) 64 ビット版、および DB2 UDB for Linux でのみサポートされます。 DB2_LARGE_PAGE_MEM レジストリー変数は、AIX 5.x または適切なカーネル・サポートを備えた Linux アーキテクチャー上で実行する場合に、ラージ・ページ・サポートを使用可能にするために使用します。 このレジストリー変数により、DB2_LGPAGE_BP レジストリー変数は推奨されないものとなります。DB2_LGPAGE_BP レジストリー変数は、データベース共用メモリー領域のラージ・ページ・メモリーを使用可能にするためにしか使用できません。 これは DB2_LARGE_PAGE_MEM=DB と設定することによって使用可能になります。 DB2_LGPAGE_BP レジストリー変数を使ってラージ・ページを使用可能にするという記述がいずれかの資料にあった場合、それは DB2_LARGE_PAGE_MEM=DB を設定することと同じ意味に受け取ることができます。 ラージ・ページの使用は主に、高性能コンピューティング・アプリケーションのパフォーマンスの向上を意図したものです。 集中的なメモリー・アクセスを必要とし、大量の仮想メモリーを使用するアプリケーションでは、このラージ・ページの使用によってパフォーマンスを向上できる場合があります。 DB2 UDB でラージ・ページを使用できるようにするには、まずオペレーティング・システムがラージ・ページを使用できるように構成する必要があります。 ラージ専用ページを使用可能にすると、DB2 UDB のメモリー使用量がかなり増加します。各 DB2 UDB エージェントが最低 1 つの物理メモリー・ラージ・ページ (16MB) を消費するためです。 64 ビット DB2 UDB for AIX 上でエージェント専用メモリー用にラージ・ページを使用可能にするには (DB2_LARGE_PAGE_MEM=PRIVATE 設定)、オペレーティング・システム上でラージ・ページを構成することに加えて、以下の条件を満たさなければなりません。
64 ビット DB2 UDB for AIX では、この変数を使用可能にすると、データベース・メモリーをバッキングする共用メモリー・セグメントのサイズが必要最小量に減少します。 デフォルトでは 64GB セグメントが作成されます。詳細については、データベース共用メモリー・サイズ (database_memory) データベース構成パラメーターを参照してください。 こうして、使用される可能性のある量以上の共用メモリーが RAM 内に滞留するのを防ぐことができます。 この変数セットを使用することによって、 全体的なデータベース共用メモリー構成を動的に増やす機能 (例えばバッファー・プールのサイズを増やす機能) が制限されます。 Linux では、libcap.so ライブラリーの可用性に関する追加の要件があります。 このオプションを有効にするためには、このライブラリーがインストールされていなければなりません。 このオプションがオンになっていて、このライブラリーがシステム上にない場合、DB2 UDB は大容量のカーネル・ページを使用不可にして、以前と同様に機能し続けます。 Linux では、大容量カーネル・ページが使用可能かどうかを検査するために、次のコマンドを発行します。 cat /proc/meminfo 使用可能である場合は、次の 3 行が表示されます (マシン上に構成されているメモリーの量によって数値は異なります)。 HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
これらの行が表示されない場合、または HugePages_Total が 0 である場合は、オペレーティング・システムまたはカーネルの構成が必要です。 |
||
以下の更新が「管理ガイド: パフォーマンス」の付録 A 『DB2 レジストリー変数と環境変数』の『SQL コンパイラー変数』のトピックに適用されます。
DB2 コンパイラー変数 DB2_MINIMIZE_LISTPREFETCH および DB2_INLIST_TO_NLJN の両方またはいずれかが ON に設定されると、REOPT(ONCE) が指定されていても、アクティブ状態のままになります。
以下に構成パラメーター・ドキュメンテーションの更新情報を示します。
認証タイプ (authentication) データベース・マネージャー構成パラメーターは、以下の値も受け入れます。
サーバーは、暗号化された SERVER 認証スキーマおよびユーザー・データの暗号化を受け入れます。 認証は SERVER_ENCRYPT の場合とまったく同じように機能します。
この認証タイプを使用するとき、以下のユーザー・データが暗号化されます。
サーバーは、暗号化された SERVER 認証スキーマおよびユーザー・データの暗号化を受け入れます。 さらに、この認証タイプでは DATA_ENCRYPT 認証タイプをサポートしない前の製品との互換性があります。 これらの製品は、SERVER_ENCRYPT 認証タイプを使って、 暗号化ユーザー・データがない状態での接続を許可されます。 新しい認証タイプをサポートしている製品は、これを使用する必要があります。 この認証タイプは、サーバーのデータベース・マネージャー構成ファイル内のみで有効であり、CATALOG DATABASE コマンドで使用するときには無効です。
DB2 Universal Database バージョン 8.2 から、インスタンス影響ポリシー (util_impact_lim) データベース・マネージャー構成パラメーターのデフォルト値が 100 から 10 に変更されました。
以下のデータベース・マネージャー構成パラメーターはすべて、すべてのプラットフォームで 30 バイト以下のグループ名を受け入れることができます。
『データベース・マネージャー構成パラメーター・サマリー』トピックの表には、これらのデータベース・マネージャー構成パラメーターについて誤ったデータ・タイプが記載されています。 すべての場合において、正しい値は char(30) です。
Windows(R) ベース・プラットフォームの拡張ストレージ・メモリー・セグメント・サイズ・データベース (estore_seg_size) 構成パラメーターの最大サイズは、16 777 216 です。
HADR タイムアウト値 (hadr_timeout) データベース構成パラメーターの正しい上限は、4 294 967 295 です。
ロック・リストの最大ストレージ (locklist) データベース構成パラメーターのドキュメンテーションには、ローカル・クライアントのみをサービスする Windows 64 ビットおよび 32 ビット・サーバーの最大値は 60 000 と記載されています。この値は誤りで、524 288 とする必要があります。
データベース・バックアップ数 (num_db_backups) データベース構成パラメーターの値の範囲は誤りです。正しい範囲は、0 から 32 767 です。
DB2 Universal Database (UDB) をバージョン 8.1 からバージョン 8.2 に移行すると、DB2 UDB は SQLDBCONF という新規の 16KB データベース構成パラメーター・ファイルを使用します (バージョン 8.1 では、データベース構成パラメーター・ファイルは 4KB のみで、名前は SQLDBCON です)。
バージョン 8.1 では、レジストリー変数 DB2_HASH_JOIN はデフォルトで ON になっています。
ハッシュ結合変数は使用すべきですが、最高のパフォーマンスを得るには調整する必要があります。
ハッシュ・ループとディスクへのオーバーフローを避けることができれば、 ハッシュ結合のパフォーマンスが最高になります。 ハッシュ結合のパフォーマンスを調整するには、sheapthres パラメーターに使用可能なメモリーの最大量を見積もってから、sortheap パラメーターを調整します。可能な限りハッシュ・ループとディスク・オーバーフローを避けられるところまで値を大きくします。ただし sheapthres パラメーターで指定した制限に達しないようにします。
詳しくは、マニュアル「管理ガイド: パフォーマンス」の結合メソッドに関するトピックを参照してください。
以前に DB2NTNOCACHE によって実行されていた機能は、CREATE TABLESPACE または ALTER TABLESPACE 文に NO FILE SYSTEM CACHING 節を指定することによって、表スペース・レベルで実行できます。 使用法の詳細については、「SQL リファレンス」を参照してください。 DB2NTNOCACHE レジストリー変数は、将来のリリースで除去されます。
Explain 表は、複数のユーザーに共通にすることができます。 ただし、Explain 表は、1 人のユーザーに対して定義して、それぞれの追加ユーザーに対しては、その定義済みの表を指すために同じ名前を使用して、別名を定義することができます。 またはその代わりに、Explain 表を SYSTOOLS スキーマ下で定義することもできます。 ユーザーのセッション ID (動的 SQL の場合)、またはステートメント許可 ID (静的 SQL の場合) の下に他の Explain 表または別名がない場合、Explain 機能のデフォルトは SYSTOOLS スキーマになります。 共通の Explain 表を共用する各ユーザーには、それらの表に対する挿入権限が必要です。 共通 Explain 表の読み取り許可も、通常は Explain 情報を分析するユーザーに限定するべきです。
Explain データがキャプチャーされるのは、SQL ステートメントがコンパイルされるときに Explain データを要求する場合です。 Explain データを要求するときに、キャプチャーした情報を使用する方法を考慮してください。
次のいずれかの場合、Explain 表情報がキャプチャーされます。
照合情報パラメーターを表示できるのは、db2CfgGet API を使用した場合のみです。 コマンド行プロセッサーやコントロール・センターでは表示できません。
このパラメーターは、260 バイトのデータベース照合情報を提供します。 最初の 256 バイトでデータベース照合シーケンスを指定するのに対して、バイト「n」には、データベースのコード・ページで基本 10 進表記が「n」になっている、コード・ポイントのソートに対する重みづけが入ります。
最後の 4 バイトには、照合シーケンスのタイプについての内部情報が入ります。 collate_info の最後の 4 バイトは整数です。 整数は、プラットフォームのエンディアン順序に依存しています。 使用できる値は次のとおりです。
この内部タイプ情報を使用する場合は、別のプラットフォームにあるデータベースに関する情報を検索するときに、バイト反転を考慮する必要があります。
照合シーケンスは、データベース作成時に指定できます。
DB2 Universal Database (UDB) バージョン 8.2 から、表スペースに AUTOMATIC プリフェッチ・サイズを使用できます。DB2 UDB は、表スペースのコンテナー数が変更されると、プリフェッチ・サイズを自動的に更新します。
DB2_PARALLEL_IO レジストリー変数の構文は、さまざまな入出力並列処理特性を持つコンテナーを認識するために拡張されています。拡張構文により、異なる表スペースのコンテナーは異なる入出力並列処理特性を持つことができます。各表スペースの入出力並列処理特性は、表スペースに AUTOMATIC のプリフェッチ・サイズが指定されている場合に使用されます。 DB2_PARALLEL_IO レジストリー変数が使用可能であるが、表スペースの特定の入出力並列処理特性を識別する拡張構文が使用されない場合は、デフォルトの並列処理レベルが想定されます。デフォルトのレベルは RAID 5 (6+1) です。
オプティマイザーで使用されるプリフェッチ・サイズ情報は、表スペースのプリフェッチ・サイズを変更するか、またはコンテナー数を変更する ALTER TABLESPACE ステートメント (ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET を使用) が発行されたときのみリフレッシュされます。コンテナー・レジストリー設定ごとの物理ディスク数が変更される場合は、ALTER TABLESPACE<table space name> PREFETCHSIZE AUTOMATIC ステートメントを発行して、オプティマイザー情報をリフレッシュする必要があります (オプティマイザー情報をリフレッシュする ALTER TABLESPACE ステートメントがまだ発行されていない場合)。
別の数のコンテナーを使用するよう表スペースをリダイレクトまたは復元する場合は、ALTER TABLESPACE <table space name> PREFETCHSIZE AUTOMATIC ステートメントを発行してオプティマイザー情報をリフレッシュします。 表スペース内に複数のストライプ・セットがある場合、ストライプ・セット間の最大コンテナー数がプリフェッチ・サイズの計算に使用されます。 計算されたプリフェッチ・サイズが最大サイズ (32 767 ページ) を超えると、最大値未満のコンテナー数の一番大きい倍数がプリフェッチ・サイズとして使用されます。
DB2 UDB Enterprise Server Edition 環境では、表スペースが AUTOMATIC プリフェッチ・サイズを使用する場合、プリフェッチ・サイズはデータベース・パーティションにより異なる場合があります。この状況は、データベース・パーティションが異なるとプリフェッチ・サイズの計算に使用するコンテナー数が異なる場合があるため発生します。照会アクセス・プランを生成する場合、オプティマイザーは、データベース・パーティション・グループの最初のパーティションのプリフェッチ・サイズを使用します。
[ ページのトップ |前ページ | 次ページ | 目次 ]