汎用レジストリー変数
汎用レジストリー変数を設定して、連続した接続再試行の時間間隔など、データベースの動作を制御します。 いくつかのレジストリー変数は、特定のオペレーティング・システム環境にのみ適用されます。
- DB2ACCOUNT
- オペレーティング・システム: すべて
- デフォルト: NULL
- この変数は、リモート・ホストに送信されるアカウンティング・ストリングを定義します。 詳しくは、「 Db2 Connect ユーザーズ・ガイド 」を参照してください。
- DB2BIDI
- オペレーティング・システム: すべて
- デフォルト: NO。値: YES または NO
- この変数は双方向言語サポートを有効にし、使用するコード・ページを宣言するために DB2CODEPAGE 変数が使用されます。
- DB2_BYPASS_DEFAULT_ISOLATION_APPS
- オペレーション・システム: すべて
- デフォルト: NULL。値: コロンまたはセミコロンで区切られた 1 つ以上のアプリケーション。 アプリケーション名には大/小文字の区別があります。
- この動的レジストリー変数を使用して、DB2_DEFAULT_ISOLATION_VALUE で指定された値を初期値として設定しない接続を指定できます。 それらの接続は従来どおりに動作します。つまり、最初はパッケージの分離レベルを使用します。これは、SET ISOLATION ステートメントが発行されたりするまで使用され続けます。
- 接続を指定するときには、接続の確立時に DB2 に渡すプログラム名を、指定するリスト内の値と対応させます。
使用例:
DBA は、DB2_DEFAULT_ISOLATION_VALUE を使用して設定された新しいデフォルトの分離レベルを、特定のアプリケーションにバイパスさせて、パッケージの分離値を無視しないようにすることができます。 管理者は、DB2 に渡すアプリケーション名でアプリケーションを指定できます。
次のように db2set を使用して DB2_BYPASS_DEFAULT_ISOLATION_APPS レジストリー変数を設定すると、プログラム ID が「APPN」または「APPM」の接続に、接続確立時に CURRENT ISOLATION レジスター値を UR に設定しないことを許可できます。db2set DB2_BYPASS_DEFAULT_ISOLATION_APPS=“APPN:APPM”
- DB2_BYPASS_DEFAULT_ISOLATION_GROUPS
- オペレーティング・システム: すべて
- デフォルト: NULL。値: コロンまたはセミコロンで区切られた 1 つ以上のグループ許可 ID。 各グループ許可 ID を大文字で指定する必要があります。
- この変数を使用して、DB2_DEFAULT_ISOLATION_VALUE で指定された値を初期値として設定しない接続を指定できます。 それらの接続は従来どおりに動作します。つまり、最初はパッケージの分離レベルを使用します。これは、SET ISOLATION ステートメントが発行されたりするまで使用され続けます。
- 接続を指定するときには、接続時に SESSION_USER 特殊レジスターの現行値に関連付けられるグループ許可 ID を、指定するリスト内の値と対応させます。
使用例:
DBA は、DB2_DEFAULT_ISOLATION_VALUE レジストリー変数で設定された新しいデフォルトの分離レベルを、特定のアプリケーションにバイパスさせて、パッケージの分離値を無視しないようにすることができます。
管理者は、使用されているグループ許可 ID でアプリケーションを指定できます。
次のように db2set を使用して DB2_BYPASS_DEFAULT_ISOLATION_GROUPS レジストリー変数を設定すると、セッション・グループのグループ許可 ID が「DB2GROUP」の接続に、接続確立時に CURRENT ISOLATION レジスターの値を UR に設定しないことを許可できます。db2set DB2_BYPASS_DEFAULT_ISOLATION_GROUPS=“DB2GROUP”
- DB2_BYPASS_DEFAULT_ISOLATION_USERS
- オペレーティング・システム: すべて
- デフォルト: NULL。値: コロンまたはセミコロンで区切られた 1 つ以上のユーザー許可 ID。 各ユーザー許可 ID を大文字で指定する必要があります。
- この動的レジストリー変数を使用して、DB2_DEFAULT_ISOLATION_VALUE で指定された値を初期値として設定しない接続を指定できます。 それらの接続は従来どおりに動作します。つまり、最初はパッケージの分離レベルを使用します。これは、SET ISOLATION ステートメントが発行されたりするまで使用され続けます。
- 接続を指定するときには、接続時に SESSION_USER 特殊レジスター内に存在する DB2 許可 ID を、指定するリスト内の値と対応させます。
使用例:
DBA は、DB2_DEFAULT_ISOLATION_VALUE レジストリー変数で設定されたデフォルトの分離レベルを、特定のアプリケーションにバイパスさせて、パッケージの分離値を無視しないようにすることができます。
管理者は、使用されているユーザー許可 ID でアプリケーションを指定できます。
次のように db2set を使用して DB2_BYPASS_DEFAULT_ISOLATION_USERS レジストリー変数を設定すると、セッション許可 ID が「SVINC」、「TRICE」、 または「KLOW」の接続に、接続確立時に CURRENT ISOLATION レジスターの値を UR に設定しないことを許可できます。db2set DB2_BYPASS_DEFAULT_ISOLATION_USERS=“SVINCE:TRICE:KLOW”
- DB2_CAPTURE_LOCKTIMEOUT
- オペレーティング・システム: すべて
- デフォルト: NULL。値: ON または NULL
- この変数は、ロックのタイムアウトが発生したときに、それに関する記述情報をログに記録するよう指定します。 ログに記録された情報は次のことを識別します。ロック・タイムアウトの原因となったロック競合に関係する主なアプリケーション、ロック・タイムアウト時に実行していたこれらのアプリケーションに関する詳細、および競合を引き起こしたロックに関する詳細。 ロック・リクエスター (ロック・タイムアウト・エラーを受け取ったアプリケーション) および現在のロック所有者の両方についての情報がキャプチャーされます。 テキスト・レポートが書き込まれ、各ロック・タイムアウト時にファイルに保管されます。
ファイルは、 db2locktimeout.par.AGENTID.yyyy-mm-dd-hh-mm-ssという命名規則を使用して作成されます。ここで、 par はデータベース・パーティション番号、 AGENTID はエージェント ID、 yyyy-mm-dd-hh-mm-ss は年、月、日、時、分、秒で構成されるタイム・スタンプです。 非パーティション・データベース環境では、par は
0
に設定されます。ファイルのロケーションは、diagpath データベース構成パラメーターに設定される値に基づきます。 diagpath が設定されない場合、ファイルは次のディレクトリーの 1 つに配置されます。
- Windows 環境の場合:
- DB2INSTPROF 環境変数を設定しない場合、情報は x:\SQLLIB\DB2INSTANCEに書き込まれます。ここで、 x はドライブ参照、 SQLLIB は DB2PATH レジストリー変数に指定したディレクトリー、および DB2INSTANCE はインスタンス所有者の名前です。
- DB2INSTPROF 環境変数を設定すると、情報が x:\DB2INSTPROF\DB2INSTANCEに書き込まれます。ここで、 x はドライブ参照、 DB2INSTPROF はインスタンス・プロファイル・ディレクトリーの名前、 DB2INSTANCE はインスタンス所有者の名前です。
- DB2INSTPROF 環境変数を新しい場所に設定する場合は、インスタンスを実行するための適切なファイルとフォルダーがそこになければなりません。 そのためには、これまでの場所にあるファイルとフォルダーをすべて、新しい場所にコピーしなければならない場合があります。
- Linux® および UNIX 環境の場合: 情報は INSTHOME/sqllib/db2dumpに書き込まれます。ここで、 INSTHOME はインスタンスのホーム・ディレクトリーです。
ロック・タイムアウト・レポート・ファイルが必要なくなったら、これを削除してください。 レポート・ファイルは他の診断ログと同じ場所にあるため、ディレクトリーが満杯になると、 Db2® システムがシャットダウンする可能性があります。 あるロック・タイムアウト・レポート・ファイルを保持する必要がある場合、Db2 ログ・ファイルが保管される場所とは別のディレクトリーまたはフォルダーに、そのファイルを移動してください。
- Windows 環境の場合:
- この変数を変更すると、それはその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動したり、db2set コマンドに -immediate パラメーターを指定して発行したりする必要はありません。
重要: CREATE EVENT MONITOR FOR LOCKING ステートメントを使用してロック・タイムアウト・イベントを収集する新しい方法があるため、この変数は推奨されておらず、将来のリリースで除去される可能性があります。- DB2CODEPAGE
- オペレーティング・システム: すべて
- デフォルト: オペレーティング・システムの指定どおりに言語 ID から得られます。
- この変数は、データベース・クライアント・アプリケーションの Db2 に提示されるデータのコード・ページを指定します。 この変数は、 Db2 資料または IBM サポート担当員によって明示的に指示されない限り、設定しないでください。 オペレーティング・システムでサポートされていない値にこの変数を設定すると、その結果は予測できなくなります。 Db2 はオペレーティング・システムからコード・ページ情報を自動的に派生させるため、通常はこの変数を設定する必要はありません。注: Windows の地域設定では、ANSI コード・ページが報告されます。 したがって、Unicode クライアントとして動作する Windows アプリケーションを実行する場合は、 DB2CODEPAGE レジストリー変数を 1208(Unicode コード・ページの値) に設定します。
- DB2_COLLECT_TS_REC_INFO
- オペレーティング・システム: すべて
- デフォルト: ON (HADR データベースの場合は OFF)。値: ON または OFF
- この変数は、影響を受けた表スペースを作成するときに各ログ・ファイルでトラッキングすることを可能にします。 この情報は、後で ROLLFORWARD コマンドを使用して、表スペースに影響を与えたログ・レコードが含まれているログ・ファイルのみを処理する表スペース・リカバリーを行う場合に役に立ちます。 これにより、リカバリー時間を大幅に短縮できます (特に、あまり変更されない表スペースの場合)。 詳しくは、「表スペースでの変更のロールフォワード」を参照してください。
- DB2_CONNRETRIES_INTERVAL
- オペレーティング・システム: すべて
- デフォルト: 設定なし。値: 秒数 (整数)
- この変数は、自動クライアント・リルート機能での接続の連続再試行間のスリープ時間を秒単位で指定します。 この変数と DB2_MAX_CLIENT CONNRETRIES を組み合わせて使用すると、自動クライアント・リルートの再試行動作を構成できます。
DB2_MAX_CLIENT_CONNRETRIES が設定されて DB2_CONNRETRIES_INTERVAL が設定されない場合、DB2_CONNRETRIES_INTERVAL はデフォルトで 30 になります。 DB2_MAX_CLIENT_CONNRETRIES が設定されないで DB2_CONNRETRIES_INTERVAL が設定された場合、DB2_MAX_CLIENT_CONNRETRIES はデフォルトで 10 になります。 DB2_MAX_CLIENT_CONNRETRIES も DB2_CONNRETRIES_INTERVAL も設定されない場合、自動クライアント・リルート・フィーチャーはデフォルトの動作に戻り、最大 10 分間、データベースへの接続を繰り返し再試行します。
- DB2CONSOLECP
- オペレーティング・システム: Windows
- デフォルト: NULL。値: すべての有効なコード・ページ値
- Db2 メッセージ・テキストを表示するためのコード・ページを指定します。 指定すると、この値はオペレーティング・システムのコード・ページ設定より優先されます。
- DB2DBDFT
- オペレーティング・システム: すべて
- デフォルト: NULL
- この変数では、暗黙接続で使用するデータベースのデータベース別名を指定します。 アプリケーションがデータベースに接続していないが SQL または XQuery ステートメントが発行されている場合、デフォルト・データベースで DB2DBDFT 環境変数が定義されていれば、暗黙接続が行われます。
- DB2_DEFAULT_ISOLATION_VALUE
- オペレーティング・システム: すべて
- デフォルト: NULL。値: 有効な分離レベル値。 値は、次のセットの
いずれかにできます。
- UR (非コミット読み取り)
- CS (カーソル固定)
- RR (反復可能読み取り)
- RS (読み取り固定)
空白を 2 つ設定することもできます。
この変数を使用して、これ以降の新規接続の CURRENT ISOLATION 特殊レジスターの初期値を、指定した値に設定できます。 これは、SET ISOLATION ステートメントと同じ方法で設定され、同じ結果をもたらします。 この値は、SET ISOLATION ステートメントを使用して接続内でオーバーライドできます。
このレジストリー変数を設定すると、SET ISOLATION RESET ステートメントが発行されるまで、また、発行されない限り、それらの接続内で PREPARE された動的 SQL ではパッケージの分離値が無視されます。
使用上の注意:
DB2 がアクティブで、データベースが複数のアプリケーションによって現在使用されています。
データベース管理者が、db2set を使用して、この新しいレジストリー変数に分離値 UR を動的に設定します。
db2set DB2_DEFAULT_ISOLATION_VALUE=UR
この操作によって、すべての新規接続の CURRENT ISOLATION 特殊レジスターが自動的に UR に設定されます。 それらの接続内で PREPARE された動的 SQL ではパッケージの分離値は無視されます。DB2_DEFAULT_ISOLATION_VALUE can also be reset to " " (two blanks) : db2set DB2_DEFAULT_ISOLATION_VALUE=" "
制約事項および制限事項:
このレジストリー変数には、次の制約事項と制限事項が確認されています。- DB2_DEFAULT_ISOLATION_VALUE レジストリー変数は、インスタンス下のすべてのデータベースのすべての接続に影響を与えます。
- DB2_DEFAULT_ISOLATION_VALUE は、静的 SQL ステートメント (実行時に追加バインドおよび再最適化処理の一部として コンパイルされたものを含む) に使用される分離レベルには影響を与えません。
- DB2_DEFAULT_ISOLATION_VALUE レジストリー変数は、CURRENT ISOLATION 特殊レジスターの自動設定として機能します。 この値は、通常の方法で次のいずれかによってオーバーライドできます。
- ステートメントの分離節 (isolation-clause) の使用
- SQL コンパイラー (ステートメントの整合性を維持するため)
- DB2_DEFAULT_ISOLATION_VALUE は、CLP での CHANGE ISOLATION LEVEL コマンドの使用をオーバーライドし、 ODBC と JCC のアプリケーションでの分離の変更を効果的に防止します。 CLP の場合、 データベースへの接続が確立された直後に SET CURRENT ISOLATION RESET を発行することで、 CHANGE ISOLATION LEVEL コマンドを再び使用することができます。
- DB2_DEFAULT_ISOLATION_VALUE の値に対する変更は、その変更が行われた後に確立された接続にのみ適用されます。
- パーティション・データベースでは、DB2_DEFAULT_ISOLATION_VALUE 動的レジストリー変数の値は、 コーディネーター・パーティションでのみ有効です。これは、コーディネーター・パーティションが 動的 SQL コンパイルが実行される場所であるためです。
- DB2DISCOVERYTIME
- オペレーティング・システム: Windows
- デフォルト: 40 秒、最小: 20 秒
- この変数は、SEARCH ディスカバリーが Db2 システムを探索する時間を指定します。
- DB2_ENFORCE_MEMBER_SYNTAX
- オペレーティング・システム: すべて
- デフォルト: OFF 。値: OFF または ON
- この変数を使用すると、SQL ステートメント、 Db2 コマンド、および API の構文が、代わりに MEMBER キーワードを使用する必要があるかどうかを判別するために、データベース・パーティション・キーワードの正しい使用法について検査されるかどうかを制御できます。 Db2 pureScale® 環境では、デフォルトの動作では、操作が Db2 メンバーをターゲットとしている場合でも、データベース・パーティションに固有のキーワード (DBPARTITIONNUM や DATABASE PARTITION など) の使用を許容します。
- ただし、 DB2_ENFORCE_MEMBER_SYNTAX が ONに設定されている場合は、MEMBER キーワードを正しく指定する必要があります。そうしないと、 SQL1538N が戻されます。 この変数の設定は無視され、 Db2 pureScale 環境の外部では効果がありません。
- DB2_EXPRESSION_RULES
- オペレーティング・システム: すべて
- デフォルト: 空。値: RAISE_ERROR_PERMIT_SKIP または RAISE_ERROR_PERMIT_DROP
- DB2_EXPRESSION_RULES レジストリー変数の設定は、 Db2 Optimizer が RAISE_ERROR 関数を含む照会のアクセス・プランを決定する方法を制御します。 RAISE_ERROR 関数のデフォルト動作では、この関数を含む式を越えてフィルタリングをプッシュすることはできません。 その結果、表へのアクセス時に述部が適用されない可能性があり、その場合、式が過剰に計算されたり、ロックが過剰に行われたり、照会のパフォーマンスが低下したりすることがあります。場合によっては、これは過度に制限的な動作です。アプリケーションの特定のビジネス要件によっては、RAISE_ERROR の適用前に述部と結合が適用されるかどうかは問題とならない場合があります。 例えば、行レベルでのセキュリティー実装のコンテキストにおいては、以下に示す形式の式が一般的です。
アプリケーションでは、照会によって選択された行 に対するアクセスを妥当性検査することのみが必要であり、表にあるすべての行に対するアクセスの妥当性検査は不要な場合があります。 したがって、基本表へのアクセスで述部を適用し、すべてのフィルタリングを実行してから RAISE_ERROR を含む式を実行すればよいことになります。 このようなケースでは、DB2_EXPRESSION_RULES=RAISE_ERROR_PERMIT_SKIP の値が適切でしょう。CASE WHEN <conditions for validatin access to this row> THEN NULL ELSE RAISE_ERROR(...) END
別のケースとして、COLUMN LEVEL セキュリティーのコンテキストにおけるものがあります。 このケースでは、以下に示す形式の式が一般的です。
このケースでは、アプリケーションでエラーを発生させる必要があるのは、ユーザーによる取得が許可されていない値を含む特定の行および列のデータを、ユーザーが受信しようとする場合に限られるでしょう。 このケースでは、DB2_EXPRESSION_RULES=RAISE_ERROR_PERMIT_DROP を設定すると、RAISE_ERROR 関数を含む式の評価が以下の場合に限定されます。すなわち、述部または列関数で特定の列が使用される場合、または照会による出力として特定の列が返される場合です。CASE WHEN <conditions for validating access to this row and column> THEN <table.column> ELSE RAISE_ERROR(...) END
- DB2FODC
- オペレーティング・システム: すべて
- デフォルト: すべての FODC パラメーターの連結 (以下のリストを参照)
- Linux および UNIX の場合: "CORELIMIT=val DUMPCORE=ON DUMPDIR=diagpath"
- Windows の場合: "DUMPDIR=diagpath"
- このレジストリー変数は、FODC (First Occurrence Data Collection) で使用されるトラブルシューティング関連の一連のパラメーターを制御します。 DB2FODC を使用して、停止状態でのデータ収集のさまざまな側面を制御します。 DB2FODC レジストリー変数は、インスタンス・レベルでのみ設定する必要があります。このレジストリー変数は、Db2 インスタンスの始動時に 1 回読み取られます。 FODC パラメーターのオンライン更新を実行するには、db2pdcfg ツールを使用します。 各リブート時の構成が同じになるようにするには、DB2FODC レジストリー変数を使用します。 パラメーターをすべて指定する必要はありません。また、パラメーターを特定の順序で指定する必要もありません。 指定していないパラメーターには、デフォルト値が割り当てられます。 例えば、コア・ファイルはダンプしない、しかし他のパラメーターについてはデフォルト動作が必要である、という場合は、次のコマンドを発行します。パラメーター:
db2set DB2FODC="DUMPCORE=OFF"
- CORELIMIT
- オペレーティング・システム: Linux および UNIX
- デフォルト: 現在の ulimit 設定。値: 0 から unlimited
- このオプションは、作成されるコア・ファイルの最大サイズをバイト単位で指定します。 この値は現在のコア・ファイル・サイズの制限設定をオーバーライドします。 コア・ファイルは非常に大きくなる可能性があるため、使用可能なファイル・システム・スペースを考慮する必要があります。 サイズは、問題発生時の Db2 の構成およびプロセスの状態によって異なります。
CORELIMIT が設定されている場合、Db2 はこの値を使用して、現在のユーザー・コア制限 (ulimit) 設定をオーバーライドしてコア・ファイルを生成します。
CORELIMIT が設定されていない場合、Db2 はコア・ファイルのサイズを、現在の ulimit 設定と同じ値に設定します。注: ユーザー・コア制限または CORELIMIT に対する変更は、 Db2 インスタンスの次回のリサイクルまで有効になりません。
- COS
- オペレーティング・システム: すべて
- デフォルト: ON。値: ON または OFF
- このオプションは、db2cos スクリプトを使用可能にするかどうかを指定します。 このパラメーターと一緒に以下のパラメーターを使用できます。
- COS_SLEEP
- デフォルト: 3。値: 0 以上 (上限なし)
- このオプションは、生成される出力ファイルのサイズを調べる間スリープになる時間を秒単位で指定します。
- COS_TIMEOUT
- デフォルト: 30。値: 0 以上 (上限なし)
- このオプションは、スクリプトが完了するまでの待機時間を秒単位で指定します。
- COS_COUNT
- デフォルト: 255。値: 0 から 255
- このオプションは、データベース・マネージャーがトラップするときに db2cos を実行する回数を指定します。
- COS_SQLO_SIG_DUMP
- デフォルト: ON。値: ON または OFF
- このオプションは、 SQLO_SIG_DUMP シグナルの受信時に db2cos を使用可能にするかどうかを指定します。
- DUMPCORE
- オペレーティング・システム: Linux、 AIX®
- デフォルト: AUTO。値: AUTO、ON、または OFF
- このオプションは、コア・ファイルの生成を行うかどうかを指定します。 問題判別に使用され、diagpath ディレクトリーに作成されるコア・ファイルには、Db2 終了プロセスのプロセス・イメージ全体が含まれています。 ただし、コア・ファイル・ダンプが実際に行われるかどうかは、現在の ulimit の設定および CORELIMIT パラメーターの値によります。 また、一部のオペレーティング・システムにはコア・ダンプの構成設定もあります。これはアプリケーション・コア・ダンプの動作を指示することがあります。 AUTO に設定すると、DB2RESILIENCE レジストリー変数が ON に設定されていて、トラップが維持できないときに、コア・ファイルが生成されます。 DUMPCORE=ON に設定すると、DB2RESILIENCE レジストリー変数の設定がオーバーライドされ、常にコア・ファイルが生成されます。
コア・ファイル・ダンプを使用不可にする推奨される方法は、DUMPCORE を OFF に設定することです。
- DUMPDIR
- オペレーティング・システム: すべて
- デフォルト: diagpath ディレクトリー。diagpath が定義されていない場合はデフォルトの診断ディレクトリー。値: ディレクトリーへのパス
- このオプションは、コア・ファイル作成用のディレクトリーの絶対パス名を指定します。
- FODCPATH
- オペレーティング・システム: すべて
- デフォルト: DIAGPATH データベース・マネージャー構成パラメーターで定義されるパス。 値: fodc_path_name
- このオプションは、FODC パッケージの送り先となる絶対パス名を指定します。 fodc_path_name は既存のディレクトリーでなければならず、それが設定されるメンバーによる書き込み、およびそれらのメンバーで実行される fmp プロセスによる書き込みが可能でなければなりません。 インスタンス全体のイベントのために生成されない FODC パッケージの場合、 FODCPATH 設定に関係なく、FODC パッケージは DIAGPATH に送信されます。
- SERVICELEVEL
- オペレーティング・システム: すべて
- デフォルト: AUTOMATIC ulimit 設定。値: AUTOMATIC、BASIC、または FULL
- このオプションで、データ破損を示唆するパニック、トラップ、またはエラー
が発生しているときのデータ収集方法を指定します。 Db2 は、構成と問題のコンテキストに適した診断を生成するように設計されています。 例えば、トラップが続いている場合、トランザクションをロールバックして、
できる限り早くアプリケーションに応答するために、最低限必要な診断のみを生成します。
そうすることで、ほかのアプリケーションが使用を待機しているかもしれないリソースを
解放することができます。 トラップが持続しない場合は、 Db2 pureScale 構成での可用性を優先して、 db2cos データ収集スクリプトやコア・ダンプなどの診断が制限される可能性があります。 診断を生成する際のデフォルト動作は、SERVICELEVEL 設定の AUTOMATIC で表されています。このパラメーターでは、以下のオプションがサポートされています。
- 自動 (Automatic)
- この設定は、有効な SERVICELEVEL 設定 (つまり、 BASIC または FULL) が、 CF プロセスの実行時、 メンバー、および開始時に選択されることを指定します。 現時点では、 BASIC が選択されるのは、複数の メンバー を持つ Db2 pureScale 環境の場合と、トラップの回復力の場合のみです。
- BASIC
- この SERVICELEVEL 設定では、ダンプ出力される FODC データの最小量を指定します。 コア・ダンプ処理はデフォルトで無効になっており (ただし、COREDUMP 設定によりオーバーライドできます)、診断は影響を受けるスレッドのみに限定され、コールアウト・スクリプトは無効になっています。
- FULL
- この SERVICELEVEL 設定では、ダンプ出力される FODC データの最大量を指定します。 これには、コア・ダンプ、関連付けられているすべてのコンポーネント・ダンプ、およびコールアウト・スクリプトの呼び出しが含まれます。 また、トラップの維持は試行されません。
- DB2_FORCE_APP_ON_MAX_LOG
- オペレーティング・システム: すべて
- デフォルト: TRUE。値: TRUE または FALSE
- max_log 構成パラメーター値を超過したときの反応を指定します。 TRUE に設定すると、アプリケーションはデータベースを強制終了し、
作業単位をロールバックします。
FALSE に設定すると、現行のステートメントは失敗します。 アプリケーションは、 作業単位内のそれ以前のステートメントで完了した作業をコミットできます。 または、作業をロールバックして作業単位を取り消すこともできます。
注: この Db2 レジストリー変数は、ログ・フル状態からリカバリーするインポート・ユーティリティーの機能に影響します。 DB2_FORCE_APP_ON_MAX_LOG が TRUE に設定されている場合に、 COMMITCOUNT コマンド・オプションを指定して IMPORT コマンドを発行すると、インポート・ユーティリティーは、アクティブ・ログ・スペースが不足するのを回避するためにコミットを実行できなくなります。 SQL0964C (トランザクション・ログが満杯) のエラー・コードを受け取ると、インポート・ユーティリティーはデータベースから強制的に切断され、現行の作業単位はロールバックされます。 - この変数を変更すると、それはその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動したり、db2set コマンドに -immediate パラメーターを指定して発行したりする必要はありません。
- DB2_WLM_SETTINGS
- オペレーティング・システム: すべて
- この変数を変更すると、それはその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動したり、-immediate パラメーターを指定して db2set コマンドを発行したりする必要はありません。
- パラメーター:
- ENABLE_HWMS
- デフォルト: TRUE
- 値: TRUE、FALSE
- HWM 値の収集は、大規模なトランザクション・システムのスケーラビリティーに影響を与える可能性があります。 このオプションを FALSE に設定すると、一部の HWM 値は維持されなくなります。
- DB2GRAPHICUNICODESERVER
- オペレーティング・システム: すべて
- デフォルト: OFF。値: ON または OFF
- このレジストリー変数は、GRAPHIC データを Unicode データベースに挿入する ために作成された既存のアプリケーションを受け入れるために使用されます。 このレジストリー変数を使用する必要があるのは、sqldbchar (GRAPHIC) データをクライアントのコード・ページではなく Unicode で送信するアプリケーションの場合のみです。 (sqldbchar は、単一の 2 バイト文字 を保持できる C および C++ の SQL データ・タイプでサポートされています。) ON に設定すると、データベースに対して、GRAPHIC データが Unicode で 送信されてくることを伝え、アプリケーションは GRAPHIC データを Unicode で 受信することを期待します。
- DB2INCLUDE
- オペレーティング・システム: すべて
- デフォルト: 設定なし
- DB PREP 処理において、 SQL INCLUDE テキスト・ファイル・ステートメントの処理時に使用されるパスを指定します。 これによって、INCLUDE ファイルが検出されるディレクトリーのリストが提供されます。 さまざまなプリコンパイル済み言語で DB2INCLUDE がどのように使用されるかについては、 組み込み SQL アプリケーションの開発 を参照してください。
- 明示的に設定されない場合、SQL INCLUDE テキスト・ファイル・ステートメントは現行ディレクトリーでテキスト・ファイルを検索します。
- DB2INSTDEF
- オペレーティング・システム: Windows
- デフォルト: Db2 (Windows)
- この変数は、 DB2INSTANCE が定義されていない場合に使用される値を設定します。 UNIX のサポートはこのリリースで非推奨になりました。
- DB2INSTOWNER
- オペレーティング・システム: Windows
- デフォルト: NULL
- インスタンスの初回作成時に Db2 プロファイル登録で作成されるレジストリー変数。 この変数は、インスタンスを所有するマシンの名前に設定されます。
- DB2_LIC_STAT_SIZE
- オペレーティング・システム: すべて
- デフォルト: NULL。範囲: 0 から 32767
- この変数は、システムのライセンス統計が入っているファイルの最大サイズ (MB 単位) を決定します。 値がゼロの場合、ライセンスの統計収集はオフになります。 この変数は、認識または定義されていない場合、デフォルト (無制限) に設定されます。 統計は、ライセンス・センターを使って表示されます。
- DB2LOCALE
- オペレーティング・システム: すべて
- デフォルト: NO。値: YES または NO
- この変数は、
Db2 を呼び出した後にデフォルトの「C」プロセス・ロケールがデフォルトの「C」ロケールにリストアされるかどうか、および Db2 関数を呼び出した後にプロセス・ロケールをリストアして元の「C」に戻すかどうかを指定します。 元のロケールが「C」ではない場合、このレジストリー変数は無視されます。注: ロケールは、言語、国、地域、およびコードの固有の組み合わせです。 「C」ロケールでは、
allchar
データ型は 1 バイトであり、その値は常に 256 文字未満であると想定されます。 特定のアプリケーションについて「C」ロケールを変更またはリストアするには、setlocale 関数を呼び出します。
ロケールを別のリージョンに変更することもできます。 例えば、"en-US" です。setlocale (LC_ALL, "C");
現在のロケールの名前は、NULL を使用して照会できます。setlocale( LC_ALL, "en-US" );
current_locale = setlocale (LC_ALL, NULL);
- DB2_MAX_CLIENT_CONNRETRIES
- オペレーティング・システム: すべて
- デフォルト: 設定なし。値: 接続再試行の最大回数 (整数)
- この変数は、自動クライアント・リルート機能が試みる接続再試行の最大回数を指定します。 この変数と DB2_CONNRETRIES_INTERVAL を組み合わせて使用すると、自動クライアント・リルートの再試行動作を構成できます。
DB2_MAX_CLIENT_CONNRETRIES が設定されて DB2_CONNRETRIES_INTERVAL が設定されない場合、DB2_CONNRETRIES_INTERVAL はデフォルトで 30 になります。 DB2_MAX_CLIENT_CONNRETRIES が設定されないで DB2_CONNRETRIES_INTERVAL が設定された場合、DB2_MAX_CLIENT_CONNRETRIES はデフォルトで 10 になります。 DB2_MAX_CLIENT_CONNRETRIES も DB2_CONNRETRIES_INTERVAL も設定されない場合、自動クライアント・リルート・フィーチャーはデフォルトの動作に戻り、最大 10 分間、データベースへの接続を繰り返し再試行します。
- DB2_MAX_GLOBAL_SNAPSHOT_SIZE
- オペレーティング・システム: すべて
- デフォルト: 設定なし。値: 0 から、スナップショットの最大サイズまで。
- この変数は、スナップショットのバイト数、またはスナップショットの見積もりバイト数を指定します。 この変数を使用すると、大きなグローバル・スナップショットにより、性能低下とシステム・ハングの原因となり得るメモリー使用量のスパイクが引き起こされるのを防げます。
デフォルトでは DB2_MAX_GLOBAL_SNAPSHOT_SIZE は設定されません。つまり、スナップショットの最大サイズの制限 (2 GB - 512 バイト) が有効です。 この変数は動的で、パーティション・データベース環境にのみ当てはまります。
- DB2_OBJECT_TABLE_ENTRIES
- オペレーティング・システム: すべて
- デフォルト: 0。値: 0 - 65532
ご使用のシステムで実際に可能な最大値は、ページ・サイズとエクステント・サイズによって異なります。ただし、65532 を超えることはできません。
- この変数は、1 つの表スペースに入ることが予想されるオブジェクトの数を指定します。 DMS 表スペースに大量のオブジェクト (例えば、1000 以上) が作成されることが分かっている場合は、表スペースを作成する前に、このレジストリー変数を適切な数値に設定します。 これにより、表スペースの作成時のオブジェクト・メタデータ用に
連続するストレージが予約されます。 連続するストレージを予約すると、メタデータ内の項目を更新する操作 (例えば、CREATE INDEX、 IMPORT REPLACE) がオンライン・バックアップによってブロックされる可能性が低くなります。 また、表スペースの開始時にメタデータが保管されるため、表スペースのサイズ変更が容易になります。
表スペースの初期サイズが十分でないために連続するストレージを予約できない場合は、 追加スペースの予約を指定せずに表スペース作成が続行します。
- DB2_SRVLSTLOG_LEVEL
- オペレーティング・システム: すべて
- デフォルト: 1。値: 0 から 4
- ワークロード・バランシング (WLB) および自動クライアント・リルート (ACR) に関係するサーバー・リスト・イベントのロギング・レベルを指定します。 この情報を (通常は IBM® サービスの指導の下で) 使用して、問題判別データを収集することができます。 ログに記録されるエントリーはすべて通知です。 このレジストリー変数の有効な値は、以下のとおりです。
- 0: ログに記録されるものはありません。
- 1: 重要性が高いメッセージのみログに記録されます。
- 2: 重要性が高いメッセージと中程度のメッセージのみログに記録されます。
- 3: 重要性が高いメッセージ、中程度のメッセージ、低いメッセージのみログに記録されます。
- 4: すべてのメッセージがログに記録されます。
diagpath データベース・マネージャー構成パラメーターは、サーバー・リスト・ログ・ファイルが保管される場所を指定します。 これらのログ・ファイルは循環しており、 db2srvlst.0.log、 db2srvlst.1.log、 db2srvlst.N.logという命名規則を使用します。 DB2_SRVLSTLOG_LEVEL を変更するには、新しい値を有効にする前にクライアント・アプリケーションを再始動する必要があります。
- DB2_SYSTEM_MONITOR_SETTINGS
- オペレーティング・システム: すべて
- この変数を変更すると、それはその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動したり、db2set コマンドに -immediate パラメーターを指定して発行したりする必要はありません。
- このレジストリー変数は、 Db2 モニターのさまざまな側面の動作を変更できる 2 つのパラメーターのセットを制御します。 各パラメーターは、次の例のように、セミコロンで区切ります。
DB2_SYSTEM_MONITOR_SETTINGSを設定するたびに、各パラメーターを明示的に設定する必要があります。 この変数を設定するときに指定されなかったパラメーターは、デフォルト値に戻ります。 したがって、次の例の場合、db2set DB2_SYSTEM_MONITOR_SETTINGS=OLD_CPU_USAGE:TRUE; DISABLE_CPU_USAGE:TRUE
OLD_CPU_USAGE はデフォルト設定に戻ります。db2set DB2_SYSTEM_MONITOR_SETTINGS=DISABLE_CPU_USAGE:TRUE
注: 現在、このレジストリー変数の 2 つのパラメーター設定は Linuxにのみ影響します。その他のオペレーティング・システムの設定は、将来のリリースで追加される可能性があります。 - パラメーター:
- 「OLD_CPU_USAGE」
- オペレーティング・システム: Linux
- 値: TRUE/ON、FALSE/OFF
- RHEL4 および SLES9 でのデフォルト値: TRUE (注: OLD_CPU_USAGE に FALSE を設定すると、無視されて以前の動作のみが使用されます。)
- RHEL5、SLES10、およびその他でのデフォルト値: FALSE
- このパラメーターは、 Linux プラットフォームでインスタンスが CPU 使用時間を取得する方法を制御します。 TRUE に設定すると、以前の CPU 使用時間取得方式が使用されます。 この方式では、システム使用時間とユーザー CPU 使用時間の両方が返されますが、そのために CPU 消費が増加します (つまり、オーバーヘッドが大きくなります)。 FALSE に設定すると、新しい CPU 使用状況取得方式が使用されます。 この方式は、ユーザーの CPU 使用状況の値だけを返しますが、オーバーヘッドが小さいので高速です。
- 使用不可に設定された CPU 使用率
- オペレーティング・システム: Linux
- 値: TRUE/ON、FALSE/OFF
- RHEL4 および SLES9 でのデフォルト値: TRUE
- RHEL5、SLES10、およびその他でのデフォルト値: FALSE
- このパラメーターで、CPU 使用状況を読み取るかどうかを決定できます。 DISABLE_CPU_USAGE を有効 (TRUE に設定) すると、CPU 使用状況は読み取られないので、CPU 使用状況の取得時に発生することがあるオーバーヘッドを回避できます。
- DB2TERRITORY
- オペレーティング・システム: すべて
- デフォルト: オペレーティング・システムの指定どおりに言語 ID から得られます。
- この変数は、クライアント・アプリケーションの region および territory コードを指定します。これは、日付と時刻の形式に影響します。
- DB2_VIEW_REOPT_VALUES
- オペレーティング・システム: すべて
- デフォルト: NO。値: YES、NO
- この変数を使用すると、すべてのユーザーは、ステートメントを EXPLAIN するときに、 再最適化された SQL または XQuery ステートメントのキャッシュされた値を EXPLAIN_PREDICATE 表に保管できます。 この変数を NO に設定すると、これらの値を EXPLAIN_PREDICATE 表に保管できるのは、DBADM だけになります。
- DB2_ONLINERECOVERY
- オペレーティング・システム: すべて
- デフォルト: NO。値: YES、NO
- この変数は、データベース接続をクラッシュ・リカバリーのバックワード・フェーズ (トランザクションの取り消しフェーズ) 中に許可するかどうかを指定します。 詳細については、クラッシュ・リカバリーまたは HADR テークオーバーのバックワード・フェーズでのデータベース・アクセスを参照してください。
- この変数の変更にデータベース・インスタンスの再始動は必要ありません。
- DB2_ONLINERECOVERY_WITH_UR_ACCESS
- オペレーティング・システム: すべて
- デフォルト: YES (DB2_WORKLOAD=SAP の場合は NO)。値: YES、NO
- データベースがクラッシュ・リカバリーのバックワード・フェーズ中の接続を許可するように構成されている場合 (DB2_ONLINERECOVERY が YES に設定されている場合)、この変数はクラッシュ・リカバリー中の表のアクセス可能性を制御します。 この変数が YES に設定されている場合、クラッシュ・リカバリーに関係している表は UR 分離レベルの SQL 照会でアクセスできることがあります。 この変数が NO に設定されている場合、クラッシュ・リカバリーに関係している表は SQL 照会でアクセスできません。 クラッシュ・リカバリーに関係しない表は、どの分離レベルの SQL 照会でもアクセスできます。 詳しくは、「クラッシュ・リカバリーまたは HADR テークオーバーのバックワード・フェーズ中のデータベースのアクセス可能性」を参照してください。
- この変数の変更にデータベース・インスタンスの再始動は必要ありません。