自動クライアント・リルートの制約事項

高可用性 Db2 データベース・ソリューションを設計する際には、 Db2® データベース・クライアント・リルートの制約事項を考慮してください。

以下に、Db2 データベース自動クライアント・リルート・フィーチャーの制限をリストします。

スタンバイ・データベースの読み取りを使用可能にすると、ACR 機能は使用できません。
ACR がサポートされるのは、 Db2 データベース・サーバー、または Db2 Connect Serverへの接続に使用される通信プロトコルが TCP/IP または SSL の場合のみです。つまり、TCP/IP または SSL 以外のプロトコルを使って接続している場合、自動クライアント・リルート・フィーチャーは使用できません。 Db2 データベースがループバック用にセットアップされている場合でも、自動クライアント・リルート・フィーチャーに対応するためには、TCP/IP または SSL 通信プロトコルを使用する必要があります。
Db2 Connect クライアントまたはサーバー製品と、ホストまたは System i ® データベース・サーバーとの間で自動転送を使用する場合、以下の状態になると、関連する影響があります。
- リモート・クライアントとローカル・クライアントの両方に代わってホストまたは System I データベースへのアクセスを提供するために Db2 Connect Server を使用すると、システム・データベース・ディレクトリー項目内の代替サーバー接続情報に関して混乱が生じる可能性があります。この混乱を最小限に抑えるために、同じホストまたは System i データベースを表すように、システム・データベースのディレクトリーで 2 つの項目をカタログすることを検討してください。リモート・クライアント用に 1 つの項目、ローカル・クライアント用にもう 1 つの項目をカタログします。
- ターゲット Db2 for z/OS® サーバーから返される SYSPLEX 情報は、 Db2 Connect Serverのキャッシュにのみ保持されます。ディスクに書き込まれる代替サーバーは 1 つのみです。複数の代替サーバーまたは複数のアクティブ・サーバーが存在する場合、その情報はメモリーでのみ維持され、プロセスが終了すると失われます。
代替サーバーのロケーションへの通信が再確立された場合、同じデータベース別名への新しい接続はすべて、代替サーバーのロケーションに接続されます。元のロケーションの問題が修正され、新しい接続を元のロケーションとの間で確立する場合には、以下のいくつかのオプションから選択できます。
- 代替サーバー・ロケーションをオフラインにして、接続が元のサーバーに再びフェイルオーバーするようにします。 (この場合、元のサーバーを代替サーバーのロケーションとして設定するために、 UPDATE ALTERNATE SERVER コマンドを使って元のサーバーがすでにカタログされていることを想定します。)
- 新しい接続によって使用される新しいデータベース別名をカタログすることができます。
- データベース項目をアンカタログして、再びカタログすることができます。
Db2 は、クライアントとサーバーの両方に対して自動クライアント・リルート・フィーチャーをサポートします (クライアントとサーバーの両方がこのフィーチャーをサポートしている場合)。その他の Db2 データベース製品ファミリーは、現時点では、このフィーチャーをサポートしません。
自動クライアント・リルート・フィーチャーの動作と、 Db2 for z/OS シスプレックス環境での自動クライアント・リルートの動作は、多少異なります。異なるのは、主に次の点です。
- 自動クライアント・リルート・フィーチャーでは、1 次サーバーは 1 つの代替サーバーを指定する必要があります。これは、1 次サーバーで発行された UPDATE ALTERNATE SERVER FOR DATABASE または UPDATE ALTERNATE SERVER FOR LDAP DATABASE コマンドを使用して行われます。このコマンドは、ローカル・データベース・ディレクトリーを代替サーバーの情報で更新し、同一のクライアントにある他のアプリケーションがこの情報にアクセスできるようにします。対照的に、 Db2 for z/OS に使用されるデータ共用シスプレックスは、クライアントが接続できる 1 つ以上のサーバーのリストをメモリー内に保持します。通信障害が発生した場合、クライアントはそのサーバーのリストを使用して、適切な代替サーバーのロケーションを判別します。
- 自動クライアント・リルート・フィーチャーでは、特殊レジスターの設定が変更されるたびに、サーバーが特殊レジスターの最新の設定をクライアントに通知します。これによりクライアントは、転送が行われた後ランタイム環境を可能な限り再確立できることになります。対照的に、 Db2 for z/OS に使用されるシスプレックスは、コミット境界で特殊レジスター設定をクライアントに戻すため、転送された作業単位内で変更された特殊レジスターを再生する必要があります。その他はすべて自動的に再生されます。
完全自動クライアント・リルート・サポートは、 Linux®、UNIX、または Windows クライアントと、 Linux、UNIX、または Windows サーバーとの間でのみ使用できます。 Linux、UNIX、または Windows クライアントと Db2 for z/OS Sysplex サーバー (任意のサポート対象バージョン) との間では使用できません。転送機能のみがサポートされます。
代替ホスト・サーバーにインストールされた Db2 データベース・サーバーと元のホスト・サーバーにインストールされた Db2 データベース・インスタンスは同じバージョンでなければなりません (ただし Db2 データベース・サーバーのフィックスパックは Db2 データベース・インスタンスのものより高くても問題ありません)。
クライアント・マシンでデータベース・ディレクトリーを更新する権限があるかどうかにかかわらず、代替サーバー・ロケーション情報は常にメモリーに保持されます。言い換えると、データベース・ディレクトリーの更新権限がない場合 (または、読み取り専用のデータベース・ディレクトリーである場合)、他のサーバーとの間でメモリーが共有されないため、他のアプリケーションは代替サーバー・ロケーションを判別して使用することができません。
すべての代替ロケーションの間で、同じ認証が適用されます。つまり、代替ロケーションの認証タイプが元のロケーションと異なる場合、クライアントはデータベース接続を再確立できません。
通信障害が発生した場合、グローバル一時表、ID、シーケンス、カーソル、フェデレート処理用のサーバー・オプション (SET SERVER OPTION)、および特殊レジスターなど、すべてのセッション・リソースが失われます。処理を続行するためには、アプリケーションがセッション・リソースを再確立しなければなりません。接続が再確立された後、特殊レジスター・ステートメントを実行する必要はありません。通信エラーの前に発行された特殊レジスター・ステートメントを Db2 データベースが再生するからです。ただし、一部の特殊レジスターは再生されません。以下のものが該当します。
- SET ENCRYPTPW
- SET EVENT MONITOR STATE
- SET SESSION AUTHORIZATION
- SET TRANSFORM GROUP
DB2 Connect に問題がある場合は、データ・サーバー上の DB2 Connect 製品に固有の限定された特殊レジスターのリストを参照する必要があります。
通信障害の発生後に接続が再確立され、クライアントが CLI、JCC Type 2 または Type 4 ドライバーを使用している場合は、元のサーバーに対して準備された SQL および XQuery ステートメントは新しいサーバーで暗黙的に再び準備されます。ただし、組み込み SQL ルーチン (例えば SQC または SQX アプリケーション) は、新しいサーバーでは再び準備されません。
クライアント・リルート可能なデータベース別名に対して、高可用性災害時リカバリー (HADR) コマンド (START HADR、STOP HADR、または TAKEOVER HADR) を実行しないでください。 HADR コマンドは、データベース別名を介してターゲット・データベースを識別するようにインプリメントされています。その結果、ターゲット・データベースで代替データベースが定義されていると、HADR コマンドは実際に操作しているデータベースを判別することが困難になります。クライアントはクライアント・リルート可能な別名を使用して接続しなければならない場合がありますが、HADR コマンドは特定のデータベースに対して適用される必要があります。これに対応するため、1 次およびスタンバイ・データベースに固有の別名を定義し、HADR コマンドをこれらの別名に対してのみ実行することができます。
各データベース・サーバーに定義できる代替サーバーは 1 つだけであるため、HADR 複数スタンバイ・セットアップがある場合は、1 次の代替サーバーとして 1 つのスタンバイ・データベース (おそらく、プリンシパル・スタンバイ・データベース) を選択する必要があります。

自動クライアント・リルートをインプリメントする別の方法は、DNS エントリーを使用して、 DNS エントリー用の代替 IP アドレスを指定することです。この基本にある考え方は、2 番目の IP アドレス (代替サーバーのロケーション) を DNS エントリーに指定することです。クライアントは代替サーバーを認識しませんが、接続時に Db2 データベース・システムが DNS エントリー用の複数の IP アドレス間を切り替えます。