データ・アクセス・アプリケーションの管理

これらの管理タスクは基本的に、アプリケーションがバックエンドと接続する手段であるオブジェクトやりソースの構成、および接続要求のボリュームをハンドルするためのリソースの調整で構成されています。

手順

  1. ご使用のアプリケーションに、バックエンドへのアクセスを必要とする Web モジュールまたは EJB モジュールが含まれている場合は、ご使用のエンタープライズ情報システム (EIS) のタイプに応じてリソースを構成してください。
    • リレーショナル・データベースの場合は、『JDBC プロバイダーおよびデータ・ソースの構成』トピックで説明されているステップに従います。 DB2® データベースを使用している場合は、 『pureQuery を使用するようにアプリケーションを構成する』トピックに記載されている内容も選択肢の 1 つです。 IBM Optim PureQuery Runtime は、DB2 データベースにアクセスするための手段として、JDBC の代わりになります。
    • リレーショナル・データベース以外のデータベースの場合や、 顧客情報管理システム (CICS®) といった別のタイプの EIS の場合は、 リソース・アダプターと接続ファクトリーを構成する必要があります。 これらのオブジェクトのセットアップについては、『Java EE コネクター・アーキテクチャーによるデータへのアクセス』トピックで説明しています。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): リソースの Java™ Naming and Directory Interface (JNDI) 名を指定する場合は、以下の要件を付加します。
    • 異なるリソース・タイプにまたがる重複した JNDI 名を割り当てないでください (データ・ソースに対する J2C 接続ファクトリーまたは JMS 接続ファクトリーなど)。
    • 同じ有効範囲の同じタイプの複数のリソースに、重複した JNDI 名を割り当てないでください。
    gotcha
  2. WebSphere® Application Server ではなく、アプリケーション・コードがバックエンドとの接続を認証する場合に限り、新規 Web モジュールのリソースまたは EJB モジュールのリソースの認証別名を構成します。 このセキュリティー構成はコンポーネント管理許可と呼ばれており、 アプリケーション・デプロイメント記述子では res-auth = Application と表されます。

    res-auth = Container で指定されるコンテナー管理許可は、 Application Server がバックエンド接続のサインオンを実行することを表しています。 コンテナー管理認証別名は、アプリケーション・リソース参照に指定する必要があります。 このタスクは、アプリケーション・アセンブリー中またはデプロイメント中に、 データ・ソースまたは接続ファクトリー・リソースへのリソース参照のマッピングとともに行うことができます。 ただし、アプリケーション・デプロイメントの後に管理コンソールを使用してコンテナー管理認証別名を変更することができます。 「アプリケーション」 > 「Websphere エンタープライズ・アプリケーション」 > application_nameとクリックし、適切なマッピング・ページへのリンクを選択します。 例えば、EJB モジュール・リソースの別名を変更する場合は、 「すべての 2.x CMP Bean のデータ・ソースをマップ」をクリックします。Web モジュール・リソースの場合は、「リソース参照」をクリックします。

    リソース認証について詳しくは、『J2EE コネクター・セキュリティー』トピックを参照してください。

  3. ご使用のアプリケーションに、データ・アクセスを必要とするクライアント・モジュールが含まれている場合は、『アプリケーション・クライアントのデータ・アクセスの構成』トピックを参照してください。 この単一の構成プロセスで、コンポーネント管理サインオンまたはコンテナー管理サインオンのいずれかの認証データを定義できます。
  4. 接続プール設定を指定します。
  5. 新規データ・ソースへの接続をテストします。 接続のテストに使用可能なメソッドについては、『テスト接続サービス』の項を参照してください。 この項では、接続テスト結果の正確性に影響する可能性がある、重要なデータ・ソース設定についても記述しています。
  6. JDBC トレース・サービスを設定します。 JDBC トレース・ログ情報は、データ・ソース障害の JVM ログ・データを拡張します。

    管理コンソールを使用してトレースを活動化するには、『サーバー始動時にトレースを使用可能にする』トピックを参照してください。トレース・グループとして WAS.database を指定し、トレース・ストリングとして com.ibm.ws.db2.logwriter を選択します。

  7. JDBC 接続プール・カウンターまたは J2C 接続プール・カウンターを活動化することによって、接続プール統計を収集します。また、Performance Monitoring Infrastructure (PMI) メソッド呼び出しを使用して接続統計を収集することもできます。 『接続および接続プール統計』トピックを参照してください。
  8. [AIX Solaris HP-UX Linux Windows][z/OS]リソースを調整して接続ボリュームを管理します。 『データ・アクセス・チューニング・パラメーター』トピックを参照してください。
  9. [IBM i]接続ボリュームに適応するようにデータベースを調整します。 DB2 UDB for iSeries を使用する場合は、開始点としてまず『DB2 Universal Database のパフォーマンスのヒント』のトピックから参照してください。
[z/OS]

タスクの結果

WebSphere Application Server の複数のプラットフォーム・バージョンにサービスを提供する、DB2 の z/OS® バージョンに、ご使用の z/OS アプリケーションが接続する場合、z/OS アプリケーションによって実行時に EC3 ダンプが発生する場合があります。この問題を解決するには、 分散ワークロードの実行を予定する場合に CMTSTAT パラメーターを INACTIVE に設定します。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): z/OS システム上の DB2 バージョン 7.0 の場合、CMTSTAT のデフォルト値は ACTIVE です。z/OS システム上の DB2 バージョン 9.0 の場合、デフォルトの設定は INACTIVE です。gotcha
分散ワークロードは、 一般に大規模になります。CMTSTAT=INACTIVE 設定によって、DB2 は、 大規模なワークロードによって引き起こされる可能性のあるドレーンを打ち消すために、 リソースを解放します。DB2 は、 スレッドがデータベース・タスクのコミットまたはロールバックに成功してカーソルをリリースした後、 スレッドを非アクティブにします。
CMTSTAT=INACTIVE と設定する場合、 CONDBAT および MAXDBAT パラメーターも調整する必要があります。以下の値の組み合わせを試して、DB2 のパフォーマンスを最大にし、 中断される接続要求を最小にしてください。
  • MAXDBAT を 100 のような小さい数値に設定して、DB2 がアクティブ・スレッド をサポートできるようにします。MAXDBAT は、同時にアクティブになったまま、DB2 でタスクの実行を続行できるスレッドの最大数を示します。
  • CONDBAT を 5000 のように大きい数値に設定します。CONDBAT は、DB2 サーバーが受信できる接続要求スレッドの最大数を示します。CMTSTAT を INACTIVE に設定すると、DB2 は、初期接続要求の完了後に数多くのスレッドを非アクティブにします。 さらに処理を必要とするスレッドの数が MAXDBAT 設定に達すると、DB2 は、 スレッドの処理ができるようになるまで、他のスレッドをキューに入れます。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_daadmin
ファイル名:tdat_daadmin.html