管理: インプリメンテーション

| | |

自動クライアント転送構成 (DB2_MAX_CLIENT_CONNRETRIES |および DB2_CONNRETRIES_INTERVAL)

|

自動クライアント転送機能は、デフォルトでデータベースへの接続を最高 10 分まで繰り返し再試行します。しかし、以下の 2 つのレジストリー変数のどちらか 1 つ、または両方を使用して、正確な再試行動作を構成することが可能です。

| |

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 の両方が設定されていない場合、自動クライアント転送機能は、前に記述されたデフォルトの動作に復帰します。

|

注:

|

DB2(R) Universal JDBC ドライバーを使ったタイプ 4 接続のユーザーは、以下の 2 つのデータ・ソース・プロパティーを使用して自動クライアント転送を構成することが必要です。

|| | |

DB2TIMEOUT レジストリー変数の説明

|

DB2TIMEOUT レジストリー変数は、もうサポートされていません。この設定は、長い SQL 照会中に Windows(R) 3.x および Macintosh のクライアント用のタイムアウト期間を制御するために使用されていました。この機能は、デフォルトでは使用不可になりました。

| | |

表スペース・コンテナー作成中に作成されるディレクトリー

|

表スペース・コンテナーの作成時、DB2 UDB は存在しないディレクトリー・レベルがあれば作成します。

|

例えば、コンテナーが /project/user_data/container1 として指定され、ディレクトリー /project が存在しない場合、DB2 UDB はディレクトリー /project および /project/user_data を作成します。

|

DB2 UDB V8.2 フィックスパック 4 から、DB2 UDB が作成するすべてのディレクトリーは PERMISSION 700 で作成されます。つまり、読み取り、書き込み、および実行のアクセス権を持つのは所有者だけです。

|

複数インスタンスを作成する場合、以下のシナリオに注目してください。

|
    |
  1. 上記と同じディレクトリー構造を使用しており、ディレクトリー・レベル /project/user_data が存在しないと仮定します。
    2. |
  2. user1 はデフォルトで user1 という名前のインスタンスを作成してから、データベースを作成し、その後そのコンテナーの 1 つとして /project/user_data/container1 というレベルで表スペースを作成します。
    3. |
  3. user2 はデフォルトで user2 という名前のインスタンスを作成してから、データベースを作成し、その後そのコンテナーの 1 つとして /project/user_data/container2 というレベルで表スペースを作成しようとします。
|

|

DB2 UDB が最初の要求から PERMISSION 700 でディレクトリー・レベル /project/user_data を作成したため、user2 はこれらのディレクトリー・レベルにはアクセス権がなく、それらのディレクトリー中に container2 を作成することができません。この場合、CREATE TABLESPACE 操作は失敗します。

|

この矛盾を解決するには 2 つの方法があります。

|
    |
  1. 表スペースの作成前にディレクトリー /project/user_data を作成し、user1 および user2 の両方が表スペースの作成に必要とするすべてのアクセスに対して許可を設定します。表スペース・ディレクトリーのすべてのレベルが存在する場合、DB2 UDB はアクセス権を変更しません。
    2. |
  2. user1 が /project/user_data/container1 を作成した後、user2 が表スペースを作成するのに必要なすべてのアクセスに対して /project/user_data の許可を設定します。

自動ストレージ

コンテナーの名前の形式の変更により、表スペース ID およびコンテナー ID の両方も変更されました。新規の形式は、以下のとおりです。

<storage path>/<instance>/NODE####
/T#######
/C#######.<EXT>

詳細は次のとおりです。

現存の表での生成列の定義

DB2(R) Universal Database バージョン 8.2.2 (バージョン 8.1 フィックスパック 9) 以降、生成列はユニーク索引で使用できます。

生成列は、制約、参照制約、主キー、およびグローバル一時表では使用できません。LIKE およびマテリアライズされたビューで作成された表は生成列のプロパティーを継承しません。

集約レジストリー変数

DB2WORKLOAD=SAP を設定した場合、ユーザー表スペース SYSTOOLSPACE およびユーザー TEMPORARY 表スペース SYSTOOLSTEMPSPACE は自動的には作成されません。これらの表スペースは、以下のウィザード、ユーティリティー、または関数によって自動的に作成される表に使用されます。

SYSTOOLSPACE および SYSTOOLSTEMPSPACE 表スペースがない場合、これらのウィザード、ユーティリティー、または関数は使用できません。

これらのウィザード、ユーティリティー、または関数を使用するには、以下のいずれかを行います。

以上の選択項目のうち少なくとも 1 つを完了後、ユーザー TEMPORARY 表スペースを (DPF 使用の場合、カタログ・ノード上にのみ) 作成します。例えば、次のようにします。

   CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
      IN IBMCATGROUP
      MANAGED BY SYSTEM
      USING ('SYSTOOLSTMPSPACE')

表スペース SYSTOOLSPACE および TEMPORARY 表スペース SYSTOOLSTEMPSPACE がいったん作成されると、前述のウィザード、ユーティリティー、または関数の使用が可能になります。

リモート・クライアントの認証に関する考慮事項

認証タイプ DATA_ENCRYPT_CMP により、データ暗号化をサポートしない前のリリースのクライアントが、DATA_ENCRYPT でなく SERVER_ENCRYPT 認証を使用するサーバーに接続できるようになります。 この認証は、以下の 3 つの条件が当てはまる場合は機能しません。

この場合、クライアントはサーバーに接続できません。接続できるようにするには、クライアントをバージョン 8 にアップグレードするか、またはバージョン 8 フィックスパック 6 以前のゲートウェイ・レベルを使用する必要があります。

直接 I/O (DIO) および並行 I/O (CIO) サポート

直接 I/O (DIO) により、ファイル・システム・レベルでのキャッシュをバイパスするためメモリー・パフォーマンスが向上します。これにより CPU オーバーヘッドが減少し、データベース・インスタンスがより多くのメモリーを使用可能になります。

並行 I/O (CIO) では、DIO の利点の他に、書き込みアクセスのシリアライゼーションも緩和します。

DB2 Universal Database(TM) (UDB) は、AIX(R) で DIO および CIO をサポートし、HP-UX、Solaris オペレーティング環境、Linux(TM)、および Windows(R) では DIO をサポートします。

NO FILE SYSTEM CACHING および FILE SYSTEM CACHING キーワードは、CREATE および ALTER TABLESPACE SQL ステートメントの一部で、DIO または CIO を各表スペースで使用するかどうかを指定できます。NO FILE SYSTEM CACHING が有効な場合、DB2(R) UDB は、可能な限り並行 I/O を使用します。CIO がサポートされない場合 (例えば JFS が使用される場合など) は、代わりに DIO が使用されます。

詳しくは、次の URL にある『Improve database performance on file system containers in IBM(R) DB2 UDB Stinger using Concurrent I/O on AIX』を参照してください。

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/

ディストリビューター・テクノロジーとクライアントの自動転送

以下の説明は、「管理ガイド: インプリメンテーション」付録 B『クライアントの自動転送の使用』の一部です。

Linux、UNIX、(R)および Windows 版 DB2 Universal Database の自動クライアント転送機能を使用するとクライアント・アプリケーションは、クライアントからサーバーへのデータベース接続を自動的に再確立して、サーバーとの通信の消失からリカバリーできるため、アプリケーションは最小限の中断で作業を継続できます。

クライアントのサーバー接続が失敗すると、クライアントの再接続要求は、WebSphere(R) EdgeServer などのディストリビューターまたはディスパッチャーにより定義済みのシステム・セットに配布されます。

ディストリビューター・テクノロジーは以下のような環境で使用できます。

クライアント --> ディストリビューター・テクノロジー --> (DB2 Connect(TM) Server 1 または DB2 Connect Server 2) --> DB2 z/OS(R)

ここで、

ディストリビューター・テクノロジーを使用していずれかの DB2 Connect Servers にアクセスするために、クライアントは DThostname を使用してカタログされます。ディストリビューター・テクノロジーの介入により、GWYhostname1 または GWYhostname2 を使用する決定が行われます。決定されると、クライアントはこれらの 2 つの DB2 Connect ゲートウェイのいずれかに直接ソケット接続します。選択した DB2 Connect サーバーにソケット接続が確立されると、一般的なクライアントから DB2 Connect サーバーから DB2 z/OS の接続が成立します。

例えば、ディストリビューターが GWYhostname2 を選択すると想定します。これにより、次の環境が生成されます。

クライアント --> DB2 Connect Server 2 --> DB2 z/OS

ディストリビューターは、何らかの通信障害があると、接続を再試行しません。このような環境でデータベースの自動クライアント転送機能を使用可能にする場合は、DB2 Connect Server (DB2 Connect Server 1 または DB2 Connect Server 2) の関連データベースの代替サーバーをディストリビューター (DThostname) としてセットアップしておく必要があります。 こうすると、DB2 Connect Server 1 が何らかの理由でロックされた場合に、自動クライアント転送機能がトリガーされて、クライアント接続が 1 次および代替サーバーの両方としてディストリビューターで再試行されます。このオプションにより、DB2 自動クライアント転送機能とディストリビューター機能を結合し、維持できます。また、ディストリビューター・ホスト名以外のホストに代替サーバーを設定すると、クライアントに自動クライアント転送機能が提供されます。ただし、クライアントは定義済み代替サーバーへの直接接続を確立して、ディストリビューター・テクノロジーをバイパスします。これによりディストリビューターとその価値が無効になります。

自動クライアント転送は、以下の sqlcode をインターセプトします。

DB2 Connect サーバー上でのカタログのための自動クライアント転送に関する考慮事項

DB2 Connect サーバーとの代替サーバー接続に関係する、以下の 2 つの項目を考慮してください。

ローカル・システム・アカウント・サポート (Windows)

ローカル・システム・アカウント (LSA) のコンテキストで実行するアプリケーションは、Windows ME 以外のすべての Windows プラットフォームでサポートされます。

2 パーツ・ユーザー ID のサポート

CONNECT 文および ATTACH コマンドは 2 パーツ・ユーザー ID をサポートします。 SAM 互換のユーザー ID の修飾子は、最大 15 文字の NetBIOS スタイル名です。 この機能は、Windows ME ではサポートされていません。

Kerberos 認証の詳細

Kerberos およびクライアントのプリンシパル

UNIX(R) および Linux(TM) オペレーティング・システム上の DB2(R) Universal Database (UDB) によって使用される Kerberos サーバー・プリンシパル名をオーバーライドすることができます。DB2_KRB5_PRINCIPAL 環境変数を希望の完全修飾サーバー・プリンシパル名に設定します。 サーバー・プリンシパル名は db2start の実行後にのみ DB2 UDB によって認識されるため、インスタンスを再始動する必要があります。

Kerberos サポートに関する追加情報

Linux 前提条件

資料では、Linux Kerberos サポートの前提条件に関する報告が不正確です。 提供された DB2 Kerberos セキュリティー・プラグインは、Red Hat Enterprise Linux Advanced Server 3 と IBM Network Authentication Service (NAS) 1.4 クライアントでサポートされます。

zSeries(R) および iSeries 互換性

zSeries および iSeries への接続の場合、データベースは AUTHENTICATION KERBEROS パラメーターを指定してカタログしなければならず、また TARGET PRINCIPAL パラメーター名を明示的に指定する必要があります。

zSeries も iSeries も相互認証をサポートしません。

Windows の問題
[ ページのトップ |前ページ | 次ページ | 目次 ]