Oracle WebLogic Server JDBCデータ・ソースの構成と管理

12cリリース1 (12.1.1)

B65892-02(原本部品番号:E24367-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- JDBCサンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- WebLogic Server配布キットのJDBCサンプル

- このリリースでのJDBCデータ・ソースの新機能と変更点

- CapacityIncrement属性

- MinCapacity属性

- 致命的エラー・コードの定義

- データ・ソース・プロファイル・ロギング

- アプリケーション・スコープ・ドライバ

- Oracle BIサーバーのサポート

- グローバル・トランザクション後の接続の保持

- セッション・アフィニティ・ポリシー

- RMIドライバ通信の保護

- プロキシ認証

- 接続でのデータベース資格証明の設定

- 接続収集

- 接続のラベリング

- 新しいデバッグ・スコープ

- ONSのデバッグ

2 WebLogic JDBCリソースの構成

- WebLogic ServerにおけるJDBCリソースについて

- 構成されたJDBCリソースの所有権

- データ・ソース構成ファイル

- JDBCシステム・モジュール

- JDBCアプリケーション・モジュール

- EAR/WARファイルへのドライバの追加

- JDBCモジュール・ファイルのネーミング要件

- バージョニングされたアプリケーションのJDBCモジュール

- JDBCスキーマ

- JDBCリソースに対するJMXおよびWLSTのアクセス

- システム・リソース用のJDBC MBean

- Java EE管理モデルにおけるJDBC管理オブジェクト(JSR-77のサポート)

- WLSTを使用したJDBCシステム・リソースの作成

- JDBCリソースの変更およびモニター方法

- WLSTを使用してJDBCリソースを構成する場合のベスト・プラクティス

- 可用性の高いJDBCリソースの作成

3 JDBCデータ・ソースの構成

- JDBCデータ・ソースについて

- WebLogic ServerのJDBCデータ・ソースのタイプ

- JDBCデータ・ソースの作成

- JDBCデータ・ソース・プロパティ

- データ・ソース名

- JNDI名

- データベース・タイプの選択

- JDBCドライバの選択

- トランザクション・オプションの構成

- 接続プロパティの構成

- Oracle BI Serverの接続プロパティの構成

- テスト接続

- データ・ソースのターゲット指定

- 接続プール機能の構成

- JDBCドライバ・レベルの機能の有効化

- 接続ベースのシステム・プロパティの有効化

- SQLコードを使用したデータベース接続の初期化

- 詳細接続プロパティ

- 致命的エラー・コードの定義

- Oracleパラメータの構成

- ONSクライアントの構成

- 汎用データ・ソース接続プールのチューニング

- データベース・セキュリティ資格証明の設定

- データ・ソース・プールの種類

- ユーザー名/パスワードの使用

- 接続時のクライアントIDの設定

- IDベースの接続プーリング

- 異種接続が作成されるプロセス

- グローバル・トランザクションでのIDベースのプールの使用

- LLRでのIDベースのプールの使用

- JDBCデータ・ソース・ファクトリ(非推奨)

4 GridLinkデータ・ソースの使用

- GridLinkデータ・ソースとは

- 高速接続フェイルオーバー

- ランタイム接続ロード・バランシング

- Oracle RAC停止時の正常操作

- Oracle RAC 11.2以前のOracle RAC停止の対処方法

- GridLinkアフィニティ

- セッション・アフィニティ・ポリシー

- XAアフィニティ・ポリシー

- SCANアドレス

- Oracle Walletを使用してセキュアな通信

- GridLinkデータ・ソースの作成

- JDBCデータ・ソース・プロパティ

- データ・ソース名

- JNDI名

- XAまたは非XAドライバの選択

- トランザクション・オプションの構成

- 接続プロパティの構成

- 接続プロパティの入力

- 完全なURLの入力

- テスト接続

- ONSクライアント構成の構成

- セキュアなONSクライアント通信

- ONSクライアント構成のテスト

- データ・ソースのターゲット指定

- ソケット・ダイレクト・プロトコルの使用

- 実行時ロード・バランシングの構成

- 接続プール機能の構成

- JDBCドライバ・レベルの機能の有効化

- 接続ベースのシステム・プロパティの有効化

- SQLコードを使用したデータベース接続の初期化

- Oracleパラメータの構成

- ONSクライアントの構成

- FANイベントの有効化

- 汎用データ・ソース接続テストの構成

- Walletファイルの使用

- Oracleパラメータの構成

- GridLinkデータ・ソース接続プールのチューニング

- データベース・セキュリティ資格証明の設定

- ユーザー名/パスワードの使用

- 接続時のクライアントIDの設定

- GridLink JDBCリソースのモニター

- 実行時の統計の表示

- JDBCOracleDataSourceInstanceRuntimeMBean

- JDBCDataSourceRuntimeMBean

- ONSDaemonRuntimeMBean

- GridLinkデータ・ソースのデバッグ

- JDBCのデバッグ・スコープ

- UCP JDKロギング

- コマンド・ラインを使用してデバッグを有効化する

- GridLinkデータ・ソースのベスト・プラクティス

- 例外の捕捉と処理

5 JDBCマルチ・データ・ソースの構成

- マルチ・データ・ソースの機能

- データベース・ノードの削除

- データベース・ノードの追加

- マルチ・データ・ソースの作成と構成

- マルチ・データ・ソース・アルゴリズムの選択

- フェイルオーバー

- ロード・バランシング

- マルチ・データ・ソースのフェイルオーバーの制限と要件

- 予約時の接続テストによるフェイルオーバーの有効化

- 使用中の接続はフェイルオーバーできない

- マルチ・データ・ソース・フェイルオーバー機能の拡張

- データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張

- マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化

- マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバーの有効化

- コールバックによるマルチ・データ・ソース・フェイルオーバーの制御

- コールバック・ハンドラの要件

- コールバック・ハンドラの構成

- フェイルオーバーのしくみ

- コールバックによるマルチ・データ・ソース・フェイルバックの制御

- フェイルバックのしくみ

- サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ

6 Oracleドライバおよびデータベースの詳細構成

- ドライバのパフォーマンスを向上させるオプション

- Oracleデータベースのプロキシ認証

- プロキシ認証の構成方法

- 接続でのデータベース資格証明の設定

- 接続にデータベース資格証明を設定する際の考慮事項

- 接続収集の構成

- 接続収集の有効化

- 接続の収集可能化

- 収集された接続の回復

- 接続のラベリング

- ラベリング・コールバックの実装

- ラベリング・コールバックの作成

- ラベリング・コールバックの例

- ラベリング・コールバックの登録

- ラベリング・コールバックの削除

- 接続ラベルの適用

- ラベル付き接続の予約

- 一致しないラベルのチェック

- 接続ラベルの削除

7 JDBCデータ・ソースのトランザクション・オプション

- 非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化

- ロギング・ラスト・リソース・トランザクション・オプションについて

- ロギング・ラスト・リソースの最適化を使用する利点

- ロギング・ラスト・リソース・トランザクションの最適化の有効化

- LLRデータ・ソースに関するプログラミング上の考慮事項と制限事項

- LLRデータ・ソースに関する管理上の考慮事項と制限事項

- 「2フェーズ・コミットのエミュレート」トランザクション・オプションについて

- 非XAドライバを使用して2フェーズ・コミットをエミュレートする際の制限およびリスク

- ヒューリスティックな終了とデータの矛盾

- 保留中のトランザクションを回復できない

- 複数サーバー構成における非XAリソースのパフォーマンス低下の可能性

- 複数の非XA登録

8 JDBCデータ・ソースを保護するためのロールおよびポリシーの使用

- JDBCリソースのセキュリティ・ポリシーの設定

- JDBC MBeanのセキュリティ・ロール

- JDBCドメイン構成MBean

- JDBCシステム・モジュールMBean

9 サーバーおよびクラスタへのデータ・ソースのデプロイ

- サーバーおよびクラスタへのデータ・ソースのデプロイ

- レスポンス不能なデータベースによって生じるサーバー起動時のハングの最小化

10 データ・ソース接続プールのチューニング

- 文キャッシュによるパフォーマンスの向上

- 文キャッシュのアルゴリズム

- LRU (最長時間未使用)

- 固定

- 文キャッシュのサイズ

- 文キャッシュに関する制限

- データベース変更後の文の呼出しにおけるエラーの発生

- プリペアド文におけるsetNullの使用

- キャッシュ内の文によるデータベース・カーソルの予約

- データ・ソースの接続テスト・オプション

- データベース接続テスト・セマンティクス

- データベース接続作成時の接続テスト

- 定期的な接続テスト

- 予約済みの接続のテスト

- データベース接続が失われた後の接続テスト遅延の最小化

- 接続テスト失敗後の接続リクエスト遅延の最小化

- DBMS接続が失われた後の接続リクエストの遅延の最小化

- アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化

- データベース接続テストの構成上の推奨事項

- デフォルトのテスト対象の表名

- 接続作成の再試行の有効化

- 接続を待機する接続リクエストの有効化

- 接続予約のタイムアウト

- 待機する接続リクエスト数を制限する

- リークされた接続の自動回復

- 正しい接続数でのサーバー・ロック回避

- 文タイムアウトによる文の処理時間の制限

- Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

- PinnedToThreadを有効にしたときの接続プール管理処理に対する変更

- PinnedToThreadを有効にしたときの追加のデータベース・リソース・コスト

- 未包装データ型オブジェクトの使用方法

- ラッピングの無効化方法

- 管理コンソールによるラッピングの無効化

- WLSTによるラッピングの無効化

11 WebLogic ServerでのOracle RACの使い方

- Oracle Real Application Clustersの概要

- ソフトウェア要件

- JDBCドライバ要件

- ハードウェア要件

- WebLogic Serverクラスタ

- Oracle RACクラスタ

- 共有ストレージ

- WebLogic ServerでOracle RACを使用する場合の構成オプション

- Oracle RACと併用するためのWebLogic Server構成の選択

- Oracle RACでのWebLogic Server使用時の接続の検証

- Oracle RACでのWebLogic Server使用時の追加検討事項

12 WebLogic ServerでのJDBCドライバの使い方

- WebLogic ServerでインストールされるJDBCドライバ

- タイプ4 サード・パーティJDBCドライバに対する環境設定

- Oracle 11g Thin Driverのグローバリゼーション・サポート

- Oracle Thin Driverのデバッグ・モードでの使い方

- SSLを介したOracle Thin Driverの使用

13 WebLogic JDBCリソースのモニター

- 実行時の統計の表示

- データ・ソースの統計

- プリペアド文キャッシュの統計

- プロファイル・ロギング

- プロファイル情報の収集

- プロファイル・タイプ

- 接続使用状況(PROFILE_TYPE_CONN_USAGE_STR)

- 待機中の接続予約(PROFILE_TYPE_CONN_RESV_WAIT_STR)

- 失敗した接続予約(PROFILE_TYPE_CONN_RESV_FAIL_STR)

- 接続リーク(PROFILE_TYPE_CONN_LEAK_STR)

- 接続の最終使用状況(PROFILE_TYPE_CONN_LAST_USAGE_STR)

- マルチスレッド接続使用状況(PROFILE_TYPE_CONN_MT_USAGE_STR)

- 文キャッシュ・エントリ(PROFILE_TYPE_STMT_CACHE_ENTRY_STR)

- 文の使用状況(PROFILE_TYPE_STMT_USAGE_STR)

- 診断データへのアクセス

- ドライバ・レベルの統計をモニターするためのコールバック(非推奨)

- JDBCデータ・ソースのデバッグ

- デバッグの有効化

- コマンド・ラインを使用してデバッグを有効化する

- WebLogic Server管理コンソールを使用してデバッグの有効化

- WebLogic Scripting Toolを使用してデバッグの有効化

- config.xmlファイルへの変更

- JDBCのデバッグ・スコープ

- UCP/ONSのデバッグの設定

- UCPのデバッグ

- ONSのデバッグ

- リクエストの仕分け

14 WebLogic JDBCリソースの管理

- データ・ソースおよびデータベース接続のテスト

- データ・ソースの文キャッシュの管理

- データ・ソースの文キャッシュのクリア

- 単一接続用の文キャッシュをクリアする

- 接続プールの縮小

- 接続プールのリセット

- 接続プールの一時停止

- 接続プールの再開

- データ・ソースの停止

- データ・ソースの起動

- DBMSネットワーク障害の管理

A JDBCアプリケーション・モジュールのデプロイメントの構成

- JDBCモジュールとエンタープライズ・アプリケーションのパッケージ化:主な手順

- パッケージ化JDBCモジュールの作成

- 管理コンソールを使用したJDBCデータ・ソース・モジュールの作成

- JDBCパッケージ化モジュールの要件

- JDBCアプリケーション・モジュールの制限事項

- JDBCデータ・ソース・モジュールの作成

- JDBCマルチ・データ・ソース・モジュールの作成

- JDBCモジュールにおけるデータベース・パスワードの暗号化

- JDBCモジュールを新しいドメインにデプロイする

- パッケージ化されたJDBCモジュールのアプリケーション・スコープ指定

- Java EE記述子ファイルにおけるJDBCモジュールの参照

- weblogic-application.xmlでのパッケージ化JDBCモジュールの参照

- その他の記述子におけるパッケージ化JDBCモジュール参照

- エンタープライズ・アプリケーションとJDBCモジュールのパッケージ化

- エンタープライズ・アプリケーションとJDBCモジュールのデプロイ

- パッケージ化JDBCモジュールからのデータベース接続の取得

B Oracle RACでのマルチ・データ・ソースの使用

- Oracle Real Application Clustersの概要

- WebLogic Serverマルチ・データ・ソースでのOracle RACの拡張性

- WebLogic Serverマルチ・データ・ソースでのOracle RACの可用性

- WebLogic Serverマルチ・データ・ソースでのOracle RACのロード・バランシング

- ソフトウェア要件

- JDBCドライバ要件

- ハードウェア要件

- WebLogic Serverクラスタ

- Oracle RACクラスタ

- 共有ストレージ

- Oracle RACでのマルチ・データ・ソースの構成

- Oracle RACで使用するマルチ・データ・ソースの構成の選択

- Oracle RACで使用するマルチ・データ・ソースの構成

- マルチ・データ・ソースの属性

- フェイルオーバーの構成に関する考慮事項

- マルチ・データ・ソースが管理するフェイルオーバーとロード・バランシング

- フェイルオーバー中の遅延

- グローバル・トランザクションにおける障害処理の段階的な説明

- 各Oracle RACインスタンスのリスナー・プロセスの構成

- リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成

- 構成の追加考慮

- グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用

- グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースのルール

- グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースで必要な属性

- サンプル構成コード

- グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用

- グローバル・トランザクションを利用しないマルチ・データ・ソース内のデータ・ソースの属性

- サンプル構成コード

- Oracle RACノード上のサービスに対する接続の構成

- サービスに接続するためのデータ・ソースの構成

- サービス接続の構成

- ワークロード管理

- ロード・バランシング

- 接続プールのキャパシティ・プランニング

- Oracle RACでマルチ・データ・ソースを使用する場合のXAの考慮事項と制限事項

- マルチ・データ・ソースを使用する場合のOracle RAC XA要件

- マルチ・データ・ソースの使用

- グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了

- Oracle RACクラスタ内で一意のトランザクションIDの使用

- マルチ・データ・ソースでOracle RACを使用する場合の既知制限

- 障害発生時にデータ・デッドロックが発生する可能性

- トランザクションが順序どおりに完了しない可能性

- データベース・サーバーのクラッシュ後に発生する既知の問題

- Oracle RACでのJDBCストアのリカバリ

- Oracle RACと併用するためのJDBCストアの構成

- 自動での再試行

C Oracle RACでの接続時フェイルオーバーの使用(非推奨)

- グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの使用

- グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの構成属性

- サンプル構成コード

D Oracle RACでの高速接続フェイルオーバーの使用

- Oracleの高速接続フェイルオーバーを使用するJDBCドライバ構成

Oracle® Fusion Middleware

Oracle WebLogic Server JDBCデータ・ソースの構成と管理

12cリリース1 (12.1.1)

B65892-02(原本部品番号:E24367-02)

2012年1月

この本には、JDBCデータ・ソース構成および管理情報が含まれます。

Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 12cリリース1 (12.1.1)

B65892-02

Copyright © 2007, 2012, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

ここでは、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この項では、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- JDBCサンプルとチュートリアル

- このリリースでのJDBCデータ・ソースの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、Java Database Connectivity (JDBC) APIを使用するアプリケーションの開発とサポートを行うソフトウェア開発者およびシステム管理者向けに書かれています。また、WebLogic Serverを評価するビジネス・アナリストやシステム設計者にとって有用な情報も掲載しています。このドキュメントのトピックは、ソフトウェア・プロジェクトの評価、設計、開発、本番前、および本番段階に関連しています。

このドキュメントは、特定のJDBCプログラミング・トピックを対象としたものではありません。これらのトピックに関するWebLogic Serverのドキュメントとリソースへのリンクについては、「関連ドキュメント」を参照してください。

このドキュメントは、Java EEおよびJDBCの概念に精通している読者を対象としています。また、WebLogic Serverで提供される付加価値の高い機能を重点的に扱います。

このドキュメントの手引き

- 本章第1章「概要とロードマップ」。このガイドの構成を紹介し、本リリースでの新機能を示します。

- 第2章「WebLogic JDBCリソースの構成」では、WebLogic JDBCリソースの概要を説明します。

- 第3章「JDBCデータ・ソースの構成」では、WebLogic JDBCデータ・ソースの構成について説明します。

- 第4章「GridLinkデータ・ソースの使用」では、WebLogic JDBC GridLinkデータ・ソースの構成を説明します。

- 第5章「JDBCマルチ・データ・ソースの構成」では、WebLogic JDBCマルチ・データ・ソースの構成について説明します。

- 第6章「Oracleドライバおよびデータベースの詳細構成」では、Oracleのドライバおよびデータベースの使用時にデータ・ソースおよびドライバのパフォーマンスを向上させる詳細構成オプションについて説明します。

- 第7章「JDBCデータ・ソースのトランザクション・オプション」では、WebLogicデータ・ソースのXA、XA以外およびグローバル・トランザクションのオプションについて説明します。

- 第8章「JDBCデータ・ソースを保護するためのロールおよびポリシーの使用」では、WebLogic ServerでJDBCデータ・ソースを保護するためにロールおよびポリシーがどのように使用されるかを説明します。

- 第9章「サーバーおよびクラスタへのデータ・ソースのデプロイ」では、サーバーおよびクラスタへのデータ・ソースのデプロイ方法について説明します。

- 第10章「データ・ソース接続プールのチューニング」では、WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を適切にチューニングして、アプリケーションおよびシステムのパフォーマンスを向上させる方法について説明します。

- 第11章「WebLogic ServerでのOracle RACの使い方」では、Oracle Real Application Clustersとともに使用するようWebLogic Serverを構成する方法について説明します。

- 第12章「WebLogic ServerでのJDBCドライバの使い方」ではWebLogic JDBCデータ・ソースの構成で、他のソースからのJDBCドライバを使用する方法について説明します。

- 第13章「WebLogic JDBCリソースのモニター」では、JDBCリソースをモニターし、データベース接続の使用状況に関するプロファイル情報を収集し、JDBCのデバッグを有効化する方法について説明します。

- 第14章「WebLogic JDBCリソースの管理」では、データ・ソースを管理する方法について説明します。

- 付録A「JDBCアプリケーション・モジュールのデプロイメントの構成」では、エンタープライズ・アプリケーションでWebLogic JDBCモジュールをパッケージ化する方法について説明します。

- 付録B「Oracle RACでのマルチ・データ・ソースの使用」では、Oracle Real Application Clustersと併用するために汎用データ・ソースを構成方法を説明します。

関連ドキュメント

このドキュメントには、JDBCデータ・ソース構成および管理情報が含まれます。

WebLogic Serverアプリケーションを開発、デプロイ、およびモニターするための包括的なガイドラインについては、以下のドキュメントを参照してください。

- 『Oracle WebLogic Server JDBCのプログラミング』は、WebLogic ServerでのJDBC APIプログラミングについてのガイドです。

- 『Oracle WebLogic Serverアプリケーションの開発』は、WebLogic Serverアプリケーションの開発用ガイドです。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、開発および本番環境でのWebLogic Serverアプリケーションのデプロイメントについての情報のプライマリ・ソースです。

JDBCサンプルとチュートリアル

このドキュメントの他にも、様々なJDBCコード・サンプルとチュートリアルが用意されています。これらのサンプルとチュートリアルでは、JDBCの構成とAPIの使い方、および主要なJDBC開発タスクを実行する実際的な手順が示されています。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecはWebLogic Server配布キットに含まれており、Windowsマシンの「スタート」メニューからアクセスできます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動します。WL_HOMEは、WebLogic Platformの最上位のインストール・ディレクトリです。

WebLogic Server配布キットのJDBCサンプル

WebLogic Serverでは、必要に応じてAPIサンプル・コードをWL_HOME\samples\server\examples\src\examples,にインストールできます。WL_HOMEはWebLogic Serverの最上位インストール・ディレクトリです。WebLogic Serverのスタート・メニューからサンプル・サーバーを起動して、サンプルとその実行手順に関する情報を確認できます。

このリリースでのJDBCデータ・ソースの新機能と変更点

このリリースには、次の新機能および変更された機能が含まれます。

- CapacityIncrement属性

- MinCapacity属性

- 致命的エラー・コードの定義

- データ・ソース・プロファイル・ロギング

- アプリケーション・スコープ・ドライバ

- Oracle BIサーバーのサポート

- グローバル・トランザクション後の接続の保持

- セッション・アフィニティ・ポリシー

- RMIドライバ通信の保護

- プロキシ認証

- 接続でのデータベース資格証明の設定

- 接続収集

- 接続のラベリング

- 新しいデバッグ・スコープ

- ONSのデバッグ

このリリースで導入された新しいWebLogic Server機能の包括的なリストは、『Oracle WebLogic Serverの新機能』を参照してください。

capacityIncrement属性

WebLogic Server 10.3.1以上のリリースでは、capacityIncrement属性は構成不可になり、1の値に設定されています。

MinCapacity属性

MinCapacity属性は、接続プールの初期化後に接続プール内に存在できる物理接続の最小数を設定します。

InitialCapacity値は、これまではプールの初期容量と最小容量の両方を処理していましたが、2つの属性に分割されました。

- MinCapacityは、設定されていない場合、デフォルトでInitialCapacityになります。InitialCapacityのデフォルトはこれまでどおり1です。

- MinCapacityは、計算を縮小する場合にのみ使用されます。サーバーの起動時に最小接続数が作成されないという点で、これはレイジーです。この機能にはInitialCapacityが使用されます。

- 上位互換性のため、MinCapacityが設定されていなければInitialCapacityが使用されます。

- データ・ソースが中断後に再開された場合、MinCapacityかInitialCapacityのいずれか大きいほうが使用されます。

- 例: InitialCapacityを0に設定してデータベースを起動した後、プール内に常に50以上の接続が保持されるようにInitialCapacityを50に設定したとします。前述のルールに従い、最初はMinCapacityが0として扱われ、以降は常にプール内に50以上の接続が存在するように50として扱われます。

「接続プールの縮小」を参照してください。

致命的エラー・コードの定義

データ・ソースごとに、接続でデータ・ソースの通信相手のバックエンド・データベースにアクセスできなくなったことを示す致命的エラー・コードを定義できます。「致命的エラー・コードの定義」を参照してください。

データ・ソース・プロファイルのロギング

10.3.6より前のWebLogic Serverでは、データ・ソース・プロファイル・レコードはWLDFイベントとして記録されていました。使いやすさとパフォーマンスを向上させるため、WebLogic Serverではイベントの格納にデータ・ソース・プロファイル・ログが使用されるようになりました。「WebLogic JDBCリソースのモニター」を参照してください。

アプリケーション・スコープのドライバ

アプリケーション・スコープのデータ・ソースを含むEAR/WARファイルにデータベース・ドライバを追加できます。これにより、アプリケーションに必要なデータ・ソースとドライバの両方を含む自己包含型EARファイルをデプロイできます。「EAR/WARファイルへのドライバの追加」を参照してください。

Oracle BI Serverのサポート

WebLogic Server 10.3.6.0以上では、Oracle BI Serverをサポートしています。新規の汎用データ・ソースを作成する際は、Oracle BIサーバーと相互運用できるように、データベース・タイプとしてOracle BIサーバーを選択します。「JDBCデータ・ソースの作成」を参照してください。

グローバル・トランザクション後の接続の保持

このリリースでは、「グローバル・トランザクション後の接続を保持」という新しい属性が導入されました。この属性を使用すると、WebLogic Serverでは、グローバル・トランザクションのコミットまたはロールバック時に、論理接続に関連付けられている物理データベース接続を保持できます。Oracle WebLogic Server MBeanリファレンスのKeepConnAfterGlobalTxに関する項を参照してください。

セッション・アフィニティ・ポリシー

WebLogic ServerのGridLinkデータ・ソースでは、セッション・アフィニティ・ポリシーを使用して、サーブレット・セッションのデータベース操作に対してRACクラスタ内の同じRACインスタンスを指定することにより、パフォーマンスを高めています。「GridLinkアフィニティ」を参照してください。

RMIドライバ通信の保護

DataSourceオブジェクトとのRMIドライバ・クライアント通信をサーバー・レベルで保護するには、「RMI JDBCセキュリティ」パラメータを設定します。『Oracle WebLogic Server JDBCのプログラミング』のWebLogic RMIドライバのセキュリティの考慮事項に関する項を参照してください。

プロキシ認証

クライアントがプロキシ・ユーザーとしてのアプリケーション・サーバーを介してOracleデータベースに接続できるように、WebLogicデータ・ソースを構成できます。「Oracleデータベースのプロキシ認証」を参照してください。

接続のデータベース資格証明の設定

Oracleデータベースへの接続時に接続によってデータベース資格証明が設定されるように、WebLogicデータ・ソースを構成できます。「接続のデータベース資格証明の設定」を参照してください。

接続収集

データ・ソースで使用可能な接続が、指定された数に達した場合に解放される予約済接続の数を指定できます。収集は、指定された数の接続が常に使用可能であるようにすることに役立ち、接続の初期化を最小限にすることでパフォーマンスを向上させます。「接続収集の構成」を参照してください。

接続ラベリング

ラベリングにより、アプリケーションは任意の名前と値の組合せを、特定の初期状態にある接続にアタッチできます。これを使用すると、接続の再初期化の時間とコストを最小限に抑えて、アプリケーションのパフォーマンスを向上させることができます。「接続のラベリング」を参照してください。

新しいデバッグ・スコープ

このリリースでは、次の新しいデバッグ・スコープが提供されています。

- weblogic.jdbc.rac.DebugJDBCONS : 低レベルのONSデバッグ

- weblogic.jdbc.rac.DebugJDBCRAC : RACデバッグ

- weblogic.jdbc.rac.DebugJDBCUCP : 低レベルのUCPデバッグ

- weblogic.jdbc.rac.DebugJDBCREPLAY : REPLAYデバッグ

- weblogic.jdbc.transaction.DebugJTAJDBC : トランザクション・デバッグ

「JDBCのデバッグ・スコープ」を参照してください。

ONSのデバッグ

WebLogic Serverリリース10.3.6.0以上では、UCPおよびONSのパッケージ名が再パッケージされなくなりました。これらのコンポーネントは、この影響を受けます。「UCP/ONSのデバッグの設定」を参照してください。

2 WebLogic JDBCリソースの構成

この章では、WebLogic JDBCリソースの概要、構成方法、およびWebLogicドメインへの適用方法について説明します。

- WebLogic ServerにおけるJDBCリソースについて

- 構成されたJDBCリソースの所有権

- データ・ソース構成ファイル

- JDBCリソースに対するJMXおよびWLSTのアクセス

- 可用性の高いJDBCリソースの作成

WebLogic ServerにおけるJDBCリソースについて

WebLogic Serverでは、JDBCデータ・ソースとマルチ・データ・ソースを構成してから、WebLogicドメイン内のサーバーまたはクラスタにJDBCリソースをターゲット指定またはデプロイすることで、データベース接続を構成できます。

構成対象の各データ・ソースにはデータベース接続のプールが含まれます。データベース接続は、データ・ソース・インスタンスの作成時(デプロイ時またはターゲット指定時)に作成されるか、サーバー起動時に作成されます。アプリケーションは、オブジェクトをどのように構成およびデプロイするかに応じて、JNDIツリー上のデータ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のデータ・ソースをルックアップし、その後データベース接続をリクエストします。接続が完了すると、アプリケーションはconnection.close()を呼び出し、これが接続をデータ・ソースの接続プールに戻します。WebLogic Serverにおけるデータ・ソースの詳細は、第3章「JDBCデータ・ソースの構成」を参照してください。

マルチ・データ・ソースはデータ・ソースの選択されたリストを抽象化したものであり、マルチ・データ・ソースに関連付けられているデータ・ソース間でロード・バランシングやフェイルオーバー処理を提供します。マルチ・データ・ソースは、データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースは、そのマルチ・データ・ソースの構成内で選択されるアルゴリズムに応じて、リクエストを満たすためにロード・バランシングとフェイルオーバーのうちどちらのデータ・ソースを使用するかを決定します。マルチ・データ・ソースの詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

構成されたJDBCリソースの所有権

WebLogic JDBCデータ・ソースの構成および管理を理解する上で重要なのは、JDBCリソースの作成者、またはJDBCリソースの作成方法によって、リソースがどのようにデプロイおよび変更されるかが決まるということです。WebLogic管理者とプログラマのどちらでもJDBCリソースを作成できます。

- WebLogic管理者は通常、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、JDBCモジュールの作成およびデプロイ(ターゲット指定)を行います。これらのJDBCモジュールは、システム・モジュールと見なされます。詳細は、「JDBCシステム・モジュール」を参照してください。

- プログラマは、XML記述子ファイルの作成をサポートする開発ツールでモジュールを作成し、次にJDBCモジュールをアプリケーションと一緒にパッケージ化して、そのアプリケーションをWebLogic管理者へデプロイ用に渡します。これらのJDBCモジュールは、アプリケーション・モジュールと見なされます。詳細は、「JDBCアプリケーション・モジュール」を参照してください。

表2-1は、JDBCモジュールの種類と、それらをどのようにして構成および変更できるかを示します。

表2-1 JDBCモジュールの種類、および構成と管理のオプション

モジュールの種類

作成手段

管理コンソールでモジュールを追加/削除

JMXで変更(リモート)

JSR-88で変更(非リモート)

管理コンソールで変更

システム

管理コンソールまたはWLST

はい

はい

いいえ

はい(JMXを介して)

アプリケーション

Oracle Enterprise Pack for Eclipse (OEPE)、Oracle JDeveloper、別のIDE、またはXMLエディタ

いいえ

いいえ

はい(デプロイメント・プランを介して)

はい(デプロイメント・プランを介して)

データ・ソース構成ファイル

WebLogic JDBCデータ・ソースの構成は、jdbc-data-source.xsdスキーマ(http://xmlns.oracle.com/weblogic/jdbc-data-source/1.2/jdbc-data-source.xsdで入手可能)に準拠するXMLドキュメントに格納されます。

JDBCリソースは、システム・モジュールとして、またはアプリケーション・モジュールとして作成および管理されます。JDBCアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションに含めて構成するか、スタンドアロンのモジュールとして構成できます。

JDBCシステム・モジュールとJDBCアプリケーション・モジュールのどちらを使用しているかに関係なく、各JDBCデータ・ソースまたはマルチ・データ・ソースは、XMLファイル(モジュール)によって表現されます。

JDBCシステム・モジュール

管理コンソールまたはWebLogic Scripting Tool (WLST)を使って、JDBCリソース(データ・ソースまたはマルチ・データ・ソース)を作成すると、WebLogic Serverはドメイン・ディレクトリの下位ディレクトリconfig/jdbcにJDBCモジュールを作成し、ドメインのconfig.xmlファイルに、モジュールへの参照を追加します。JDBCモジュールは、jdbc-data-source.xsdスキーマ(http://xmlns.oracle.com/weblogic/jdbc-data-source/1.2/jdbc-data-source.xsdで入手可能)に準拠します。

このようにして構成されるJDBCリソースは、システム・モジュールと見なされます。システム・モジュールは管理者の所有になります。システム・モジュールは管理者の所有になります。管理者はいつでも、リソースの削除や修正を行ったり、同様なリソースを追加したりできます。システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。システム・モジュールはまた、JDBCSystemResourceMBeansとしてJMXからアクセスすることもできます。

データ・ソース・システム・モジュールは、JDBCSystemResource要素として、ドメインのconfig.xmlファイルに含まれており、これには、JDBCモジュール・ファイルの名前と、モジュールのデプロイ先であるターゲット・サーバーおよびクラスタのリストが含まれます。図2-1は、config.xmlファイル内のデータ・ソース・リストと、そのマップ先となるモジュールの例を示します。

図2-1 config.xmlからデータ・ソース・システム・モジュールへの参照

「図2-1 config.xmlからデータ・ソース・システム・モジュールへの参照」の説明

この図では、config.xmlファイルにexamples-demoデータ・ソースがjdbc-system-resource要素としてリストされています。これはdomain\config\jdbcフォルダ内のexamples-demo-jdbc.xmlモジュールにマップされます。

同様に、マルチ・データ・ソース・システム・モジュールは、jdbc-system-resource要素として、ドメインのconfig.xmlファイルに含まれています。マルチ・データ・ソース・モジュールには、マルチ・データ・ソースによって使用されるデータ・ソース・モジュールにマップされるdata-source-listパラメータが含まれます。また、個々のデータ・ソース・モジュールも、config.xmlに含まれています。図2-2は、config.xmlファイル内の要素と、config/jdbcディレクトリ内のシステム・モジュールの関係を示します。

図2-2 config.xmlからマルチ・データ・ソースおよびデータ・ソース・システム・モジュールへの参照

「図2-2 config.xmlからマルチ・データ・ソースおよびデータ・ソース・システム・モジュールへの参照」の説明

この図では、config.xmlファイル内に、3つのJDBCモジュールがリストされています。1つのマルチ・データ・ソースと、そのマルチ・データ・ソースによって使用される2つのデータ・ソースです。この2つのデータ・ソースも、マルチ・データ・ソース・モジュール内にリストされています。アプリケーションは、これらのモジュールのうち任意のものをJNDIツリー上でルックアップして、データベース接続をリクエストできます。マルチ・データ・ソースをルックアップした場合、そのマルチ・データ・ソースは、data-source-listパラメータ内のデータ・ソース、データ・ソースのリスト順、およびalgorithm-typeパラメータで指定されているアルゴリズムに応じて、データベース接続の供給に使用する別のデータ・ソースをどれにするかを決定します。マルチ・データ・ソースの詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

JDBCアプリケーション・モジュール

JDBCリソースは、標準のJava EEモジュールと同様に、アプリケーション・モジュールとしても管理できます。JDBCアプリケーション・モジュールとは単に、jdbc-data-source.xsdスキーマ(http://xmlns.oracle.com/weblogic/jdbc-data-source/1.2/jdbc-data-source.xsdで入手可能)に準拠するXMLファイルで、データ・ソースまたはマルチ・データ・ソースのことを言います。

JDBCモジュールは、パッケージ化されたモジュールとして、エンタープライズ・アプリケーションの一部として含めることができます。パッケージ化されたモジュールは、EARまたは展開されたEARディレクトリにバンドルされ、weblogic-application.xmlやejb-jar.xmlなどすべての適切なデプロイメント記述子内で参照されます。JDBCモジュールはエンタープライズ・アプリケーションと一緒にデプロイされ、同梱されたアプリケーションのみ、またはすべてのアプリケーションで利用できるように構成できます。パッケージ化したモジュールを使用することにより、アプリケーションは必要なリソースに常にアクセスでき、アプリケーションを新しい環境に移動する処理が簡素化されます。パッケージ化されたJDBCモジュールを利用すると、EARファイルを開いたり、データ・ソースの手動による膨大な再構成を行ったりすることなく、アプリケーションと必要なJDBC構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。

システム・リソース・モジュールと対照的に、アプリケーションとパッケージ化されたJDBCモジュールの所有者は、モジュールをデプロイする管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。つまり、パッケージ化されたモジュールに対しては、管理者の制御が及ぶ範囲が、より制限されています。リソース・モジュールをデプロイする際、管理者はモジュールで指定されていたリソース・プロパティを変更できますが、モジュールの追加や削除は行えません(他のJava EEモジュールのように、リソース・モジュールのデプロイ構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません)。

定義により、パッケージ化されたJDBCモジュールは、エンタープライズ・アプリケーションに含まれているため、エンタープライズ・アプリケーションのデプロイ時にデプロイされます。パッケージ化したJDBCモジュールを使用したアプリケーションのデプロイについては、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

JDBCアプリケーション・モジュールは、weblogic.Deployerユーティリティまたは管理コンソールを使用してスタンドアロンのリソースとしてもデプロイでき、通常そのリソースはデプロイメント・プロセスにおいてターゲット指定されたサーバーまたはクラスタで使用できます。このようにしてデプロイされたJDBCリソースは、スタンドアロン・モジュールと呼ばれ、管理コンソールまたはJSR-88対応のツールを使用して再構成できますが、JMXやWLSTを介しては使用できません。

スタンドアロンJDBCモジュールを使用すると、JDBCリソースの共有と移植が容易になります。データ・ソース構成を作成し、他の開発者に配布できます。スタンドアロンJDBCモジュールを使用して、開発ドメインとステージング・ドメインの間など、ドメイン間でデータ・ソース構成の移動もできます。

注意:

JDBCモジュールをスタンドアロン・モジュールとしてデプロイする際、マルチ・データ・ソースのデプロイメント順序は、そのメンバー・データ・ソースのデプロイ順序より大きい数値であることが必要です。

JDBCアプリケーション・モジュールの詳細は、付録A「JDBCアプリケーション・モジュールのデプロイメントの構成」を参照してください。

スタンドアロンJDBCモジュールのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項を参照してください。

EAR/WARファイルへのドライバの追加

WebLogic Server 10.3.6以上のリリースでは、アプリケーション・スコープのデータ・ソースを含むEAR/WARファイルのAPP-INF/libディレクトリにデータベース・ドライバを追加できます。これにより、アプリケーションに必要なデータ・ソースとドライバの両方を含む自己包含型EAR/WARファイルをデプロイできます。

注意:

ドライバの場所を追加するためにマニフェスト・ファイルのクラスパスを更新する必要はありません。

EARには独自のクラスローダーがあり、ネストされた全アプリケーション間で使用できるように共有されます。ドライバ・バージョンの異なる複数のEAR/WARファイルをデプロイできます。ただし、システムのクラスパス内に古いバージョンのドライバがある場合は、アプリケーションとともにパッケージされているドライバ・クラスを使用できるように、web.xmlファイル内でPREFER-WEB-INF-CLASSES=trueを設定します。

JDBCモジュール・ファイルのネーミング要件

WebLogic JDBCモジュール・ファイルはすべて、examples-demo-jdbc.xmlのように、末尾に接尾辞-jdbc.xmlを付ける必要があります。WebLogic Serverは、モジュールのデプロイ時にファイル名をチェックします。ファイル名の末尾が-jdbc.xmlでなかった場合、デプロイメントは失敗し、サーバーは起動しません。

バージョニングされたアプリケーションのJDBCモジュール

本番再デプロイメント(バージョニング)を使用して、パッケージ化されたJDBCモジュールを含むアプリケーションの、あるバージョンをデプロイする場合、WebLogic Serverは次の形式で、JDBCモジュールにおいて定義されたデータ・ソースを識別します。

application_id#version_id@module_name@data_source_name

この名前はデータ・ソース・ランタイムMBeanに使用されるとともに、WebLogic Serverトランザクション・マネージャにデータ・ソース・インスタンスを登録するのに使用されます。

廃止バージョンのアプリケーションにおいてトランザクションがタイムアウトし、その後そのバージョンのアプリケーションがアンデプロイされると、廃止されたバージョンのアプリケーションにおけるデータ・ソース上の保留中または未完了のトランザクションを手動で解決することが必要になる場合があります。データ・ソースが(この場合には、廃止バージョンのアプリケーションとともに)アンデプロイされると、WebLogic Serverトランザクション・マネージャは、保留中または未完了のトランザクションをリカバリできなくなります。

本番再デプロイメントの詳細は、次を参照してください。

- 『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用アプリケーションの開発に関する項

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメントを使用したアプリケーションの更新に関する項

JDBCスキーマ

WebLogic ServerでJDBCリソースのモジュール式デプロイメント・モデルをサポートするため、WebLogic JDBCオブジェクト用のスキーマweblogic-jdbc.xsdが用意されています。JDBCリソース・モジュール(記述子)を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDEなどのツールは、このスキーマに基づいてJDBCリソース・モジュールを検証できます。

このスキーマはhttp://xmlns.oracle.com/weblogic/jdbc-data-source/1.2/jdbc-data-source.xsdにあります。

注意:

パッケージされているデータ・ソースがアプリケーション・スコープである場合、スキーマのjdbc-data-source-params要素内のスコープはApplicationに設定する必要があります。次のものに対して、値Applicationは無効です。

- config/jdbc内のシステム・リソース(汎用データ・ソース、マルチ・データ・ソース、GridLinkデータ・ソースを含む)

- config.xmlファイル内の<app-deployment>要素を使用して動的または静的にデプロイされたスタンドアロンのデータ・ソース

これらのデータ・ソース・タイプに対しては、データ・ソースのスコープを指定するアプリケーションや、関連付けられたモジュールはありません。WebLogic Serverでは、Applicationのスコープは生成されません。WebLogic Server 10.3.6.0より前のリリースでは、これにエラーのフラグが付けられることはなく、コンソールにds0@null@ds0のような無効な名前で表示されます。WebLogic Server 10.3.6.0以上では、この構成エラーに対してErrorメッセージが記録されます。また、システムによりスコープがGlobalに設定され、データ・ソース名がds0として表示されます。将来のリリースでは、このエラーは致命的エラーとして扱われる可能性があります。

JDBCリソースに対するJMXおよびWLSTのアクセス

管理コンソールまたはWLSTを使用してJDBCリソースを作成すると、WebLogic Serverに各リソースのMBean(マネージドBean)が作成されます。その後、JMXまたはWebLogic Scripting Tool (WLST)を使用してMBeanにアクセスできます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』および『Oracle WebLogic Scripting Tool』を参照してください。

- システム・リソース用のJDBC MBean

- Java EE管理モデルにおけるJDBC管理オブジェクト(JSR-77のサポート)

- WLSTを使用したJDBCシステム・リソースの作成

- JDBCリソースの変更およびモニター方法

- WLSTを使用してJDBCリソースを構成する場合のベスト・プラクティス

システム・リソース用のJDBC MBean

図2-3は、WebLogicドメイン内のJDBCオブジェクトに対するMBeanの階層を示します。

図2-3 JDBC Beanツリー

「図2-3 JDBC Beanツリー」の説明

JDBCSystemResourceMBeanは、データ・ソース・モジュールから作成されたJavaBeanのコンテナです。ただし、JDBCデータ・ソースに対するJMXのアクセスは、すべてJDBCSystemResourceMBean経由で行われます。データ・ソース・モジュールから作成された個々のJavaBeanに直接アクセスすることはできません。

Java EE管理モデルにおけるJDBC管理オブジェクト(JSR-77のサポート)

WebLogic Server JDBCはJava EE管理モデルを定義するJSR-77をサポートしています。Java EE管理モデルは、Java EE Webアプリケーション・サーバーおよびそのリソースの実行時状態をモニターするのに使用されます。Java EE管理モデルにアクセスして、WebLogic JDBCシステム全体、メモリーにロードされたJDBCドライバ、JDBCデータ・ソースなどのリソースをモニターできます。

仕様に準拠するため、WebLogic JDBCサブシステムには次の実行時MBeanタイプが追加されています。

- JDBCServiceRuntimeMBean - JDBCサブシステムを表し、現在システムで使用可能なJDBCDriverRuntimeMBeansおよびJDBCDataSourceRuntimeMBeansのリストにアクセスするためのメソッドを提供します。

- JDBCDriverRuntimeMBean - サーバーがメモリーにロードしたJDBCドライバを表します。

- JDBCDataSourceRuntimeMBeans - サーバーまたはクラスタにデプロイされたJDBCデータ・ソースを表します。

注意:

WebLogic JDBCランタイムMBeanは、JSR-77で指定されている任意の統計プロバイダを実装していません。

WebLogic ServerでのJava EE管理モデルの使用については、『Oracle WebLogic Server Java EE管理APIによるモニタリングと管理』を参照してください。

WLSTを使用したJDBCシステム・リソースの作成

WLSTを使用してJDBCリソースを作成するには、以下のタスクを実行する必要があります。

- 編集セッションを開始します。

- JDBCシステム・リソース(プール、データ・ソース、マルチ・データ・ソース、JDBCドライバなど)を含むJDBCシステム・モジュールを作成します。

- JDBCシステム・モジュールをターゲット指定します。

例2-1 JDBCリソースを作成するWLSTスクリプト

#----------------------------------------------------------------------
# Create JDBC Resources
#----------------------------------------------------------------------

import sys
from java.lang import System

print "@@@ Starting the script ..."
global props

url = sys.argv[1]
usr = sys.argv[2]
password = sys.argv[3]

connect(usr,password, url)
edit()
startEdit()

servermb=getMBean("Servers/examplesServer")
if servermb is None:
print '@@@ No server MBean found'
else:
def addJDBC(prefix):

print("")
print("*** Creating JDBC resources with property prefix " + prefix)

# Create the Connection Pool.  The system resource will have
# generated name of <PoolName>+"-jdbc"

myResourceName = props.getProperty(prefix+"PoolName")
print("Here is the Resource Name: " + myResourceName)

jdbcSystemResource = wl.create(myResourceName,"JDBCSystemResource")
myFile = jdbcSystemResource.getDescriptorFileName()
print ("HERE IS THE JDBC FILE NAME: " + myFile)

jdbcResource = jdbcSystemResource.getJDBCResource()
jdbcResource.setName(props.getProperty(prefix+"PoolName"))

# Create the DataSource Params
dpBean = jdbcResource.getJDBCDataSourceParams()
myName=props.getProperty(prefix+"JNDIName")
dpBean.setJNDINames([myName])

# Create the Driver Params
drBean = jdbcResource.getJDBCDriverParams()
drBean.setPassword(props.getProperty(prefix+"Password"))
drBean.setUrl(props.getProperty(prefix+"URLName"))
drBean.setDriverName(props.getProperty(prefix+"DriverName"))

propBean = drBean.getProperties()
driverProps = Properties()
driverProps.setProperty("user",props.getProperty(prefix+"UserName"))

e = driverProps.propertyNames()
while e.hasMoreElements() :
propName = e.nextElement()
myBean = propBean.createProperty(propName)
myBean.setValue(driverProps.getProperty(propName))

# Create the ConnectionPool Params
ppBean = jdbcResource.getJDBCConnectionPoolParams()
ppBean.setInitialCapacity(int(props.getProperty(prefix+"InitialCapacity")))
ppBean.setMaxCapacity(int(props.getProperty(prefix+"MaxCapacity")))

if not props.getProperty(prefix+"ShrinkPeriodMinutes") == None:
ppBean.setShrinkFrequencySeconds(int(props.getProperty(prefix+"ShrinkPeriodMinutes")))
if not props.getProperty(prefix+"TestTableName") == None:
ppBean.setTestTableName(props.getProperty(prefix+"TestTableName"))

if not props.getProperty(prefix+"LoginDelaySeconds") == None:
ppBean.setLoginDelaySeconds(int(props.getProperty(prefix+"LoginDelaySeconds")))

# Adding KeepXaConnTillTxComplete to help with in-doubt transactions.
xaParams = jdbcResource.getJDBCXAParams()
xaParams.setKeepXaConnTillTxComplete(1)

# Add Target
jdbcSystemResource.addTarget(wl.getMBean("/Servers/examplesServer"))
.
.
.

JDBCリソースの変更およびモニター方法

MBeanから利用できる適切なメソッドを使用すると、JDBCオブジェクトおよび属性を変更したりモニターしたりできます。

- JDBCオブジェクトおよび属性を変更する場合は、set、target、untarget、およびdeleteメソッドを使用します。

- JDBCランタイム・オブジェクトをモニターするにはgetメソッドを使用します。

詳細は、Oracle WebLogic Scripting Tool のMbeanのナビゲート(WLSTオンライン)に関する項を参照してください。

WLSTを使用してJDBCリソースを構成するときのベスト・プラクティス

ここでは、WLSTを使用してJDBCリソースを構成する場合のベスト・プラクティスを示します。

- MBeanオブジェクトを操作する前に、Null MBeanオブジェクト(プール、データ・ソース、ドライバなど)をトラップします。

高可用性JDBCリソースの作成

管理コンソールを使用して、JDBCリソースの可用性やリソース間通信のロード・バランシングを向上させるために、JDBCリソース(汎用データ・ソース、マルチ・データ・ソースまたはGridLinkデータ・ソース)をターゲットに指定したり、クラスタ・メンバーにデプロイできます。ただし、何らかの理由でクラスタ・メンバーが使用不能になった場合、接続のフェイルオーバーは行われません。使用可能なクラスタ・メンバーで必要になると、新しい接続が作成されます。「サーバーおよびクラスタへのデータ・ソースのデプロイ」を参照してください。

注意:

マルチ・データ・ソースで使用できるのは、(同じJVM内の)同じクラスタ・メンバーにデプロイされている汎用データ・ソースのみです。

3 JDBCデータ・ソースの構成

この章では、JDBCデータ・ソースを構成およびチューニングする方法について説明します。

- JDBCデータ・ソースについて

- WebLogic ServerのJDBCデータ・ソースのタイプ

- JDBCデータ・ソースの作成

- 接続プール機能の構成

- 詳細接続プロパティ

- Oracleパラメータの構成

- ONSクライアントの構成

- 汎用データ・ソース接続プールのチューニング

- データベース・セキュリティ資格証明の設定

- JDBCデータ・ソース・ファクトリ(非推奨)

JDBCデータ・ソースについて

WebLogic Serverでデータベース接続を構成するには、データ・ソースをWebLogicドメインに追加します。WebLogic JDBCデータ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。各データ・ソースには、データ・ソース作成時およびサーバー起動時に作成される、データベース接続のプールが含まれています。アプリケーションは、JNDIツリーまたはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップし、次にgetConnection()を呼び出すことで、データ・ソースからのデータベース接続を予約します。接続の使用が終わったら、アプリケーションはできるだけ早くconnection.close()を呼び出して、データベース接続をプールに戻し、他のアプリケーションが使用できるようにする必要があります。

WebLogic ServerのJDBCデータ・ソースのタイプ

WebLogic Serverは、次の3種類のデータ・ソースを提供します。

- 汎用データ・ソース: 汎用データ・ソースとその接続プールによって、システムを効率よく稼働するのに役立つ接続管理プロセスが提供されます。アプリケーションや環境に合うようにデータ・ソースでオプションを設定できます。

- GridLinkデータ・ソース: Oracle RACインスタンスで状態の変化に順応して応答するイベント・ベースのデータ・ソース。「GridLinkデータ・ソースの使用」を参照してください。

- マルチ・データ・ソース: マルチ・データ・ソースとは、ロード・バランシングやフェイルオーバー処理を提供する汎用データ・ソースのグループに関する抽象化です。「JDBCマルチ・データ・ソースの構成」を参照してください。

JDBCデータ・ソースの作成

管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、WebLogicドメインにJDBCデータ・ソースが作成できます。

- Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの作成に関する項。

- サンプルWLSTスクリプトSAMPLES_HOME\server\examples\src\examples\wlst\online\jdbc_data_source_creation.py(SAMPLES_HOMEはWebLogic Serverインストールの主要なサンプル・ディレクトリを示します)。『Oracle WebLogic Scripting Tool』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

次の項では、管理コンソールでデータ・ソースを作成するためのデータ・ソース構成ウィザードで実行する基本手順の概要を示します。

- JDBCデータ・ソース・プロパティ

- トランザクション・オプションの構成

- 接続プロパティの構成

- テスト接続

- データ・ソースのターゲット指定

JDBCデータ・ソース・プロパティ

JDBCデータ・ソース・プロパティには、データ・ソースのアイデンティティを定義するオプション、およびデータベース接続でのデータ処理方法が含まれます。

データ・ソース名

JDBCデータ・ソース名は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、名前はデータ・ソースやマルチ・データ・ソースを含む他のすべてのJDBCシステム・リソースを通じて一意であることが必要です。名前の競合を避けるため、データ・ソース名はサーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど、他の構成オブジェクト名の中でも一意であることが必要です。アプリケーションをスコープとするJDBCアプリケーション・モジュールの場合、データ・ソース名は同様のスコープを持つJDBCデータ・ソースとマルチ・データ・ソースを通じて一意であることが必要です。

JNDI名

単一または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成できます。1つのJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数のJNDI名を持つデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIのプログラミング』を参照してください。

データベース・タイプの選択

DBMSを選択します。サポートされているデータベースの詳細は、『Oracle WebLogic Serverの新機能』のサポートされている構成に関する項を参照してください。

JDBCドライバの選択

管理コンソールを使用してJDBCデータ・ソースを作成する際、JDBCドライバ・クラスを選択するよう求められます。管理コンソールでは大部分の一般的なドライバ・クラス名が表示され、ほとんどの場合、ドライバに必要なURLの作成も支援されます。ただし、コンソールにURLのテストをリクエストする前に、URLが適切であることを確認してください。選択するドライバは、データ・ソースのデプロイ先のすべてのサーバーのクラスパスに存在している必要があります。ただし、管理コンソールで一覧表示されるすべてのJDBCドライバがWebLogic Serverに付属している(または、クラスパスにすでに存在している)わけではありません。

- Oracle Thin Driver

- Oracle Thin Driver XA

- Oracle Thin Driver非XA

- Oracle BI Serverのドライバ(タイプ4): すべて

- サード・パーティのJDBCドライバ(第12章「WebLogic ServerでのJDBCドライバの使い方」を参照) :

- MySQL (非XA)

- 次のデータベース管理システム用のWebLogic DataDirectドライバ(WebLogic DataDirectドライバの使用に関する項を参照) :

- DB2

- Informix

- Microsoft SQL Server

- Sybase

これらのドライバはすべて、weblogic.jarマニフェスト・ファイルによって参照され、サーバーのクラスパスで明示的に定義される必要はありません。

データベースへの接続に使用するJDBCドライバを決定する際には、環境内で様々なベンダーのドライバを試してみることが必要です。通常、JDBCドライバのパフォーマンスは、アプリケーションで使用するSQLコード、JDBCドライバの実装など、様々な要因によって左右されます。

サポートされているJDBCドライバの詳細は、『Oracle WebLogic Serverの新機能』のサポートされている構成に関する項を参照してください。

注意:

データ・ソースの作成時に管理コンソールにリストされるJDBCドライバは、必ずしもWebLogic Serverで使用する認定を受けているとはかぎりません。JDBCドライバは、多数の使用可能なデータベース管理システムへの接続を作成するのに役立つ便利情報としてリストされています。

データ・ソースでJDBCドライバを使用してデータベース接続を作成するには、データ・ソースをデプロイする各サーバーにJDBCドライバをインストールする必要があります。ドライバは、データ・ソースの構成に役立つ既知の必須構成オプションと共に管理コンソールにリスト表示されます。一覧にあるJDBCドライバが必ずしもインストールされているとは限りません。ドライバのインストールでは、システム・パス、クラスパス、その他の環境変数の設定を行う場合もあります。タイプ4サード・パーティJDBCドライバの環境の設定に関する項を参照してください。JDBCドライバが更新されると、構成要件も変更される場合があります。管理コンソールは、WebLogic Serverソフトウェアがリリースされた時点で既知の構成要件を使用します。JDBCドライバの構成オプションが変更されている場合、データ・ソースの作成時、または作成後(データ・ソースのプロパティのページで)、構成オプションを手動でオーバーライドする必要がある場合があります。

トランザクション・オプションの構成

管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に基づき、自動的に特定のトランザクション・オプションを選択します。

- XAドライバの場合、システムは自動的に、グローバル・トランザクション処理のための2フェーズ・コミット・プロトコルを選択します。

- 非XAドライバの場合、ローカル・トランザクションは定義によってサポートされており、WebLogic Serverは以下のオプションを提供します。
「グローバル・トランザクションのサポート」 : (デフォルトで選択) XAドライバを選択していなくても、グローバル・トランザクションでデータ・ソースからの接続を使用する場合には、このオプションを選択します。詳細については、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。

「グローバル・トランザクションのサポート」を選択した場合は、グローバル・トランザクションを処理するときに、WebLogic Serverがトランザクション・ブランチに使用するプロトコルも選択する必要があります。

- 「ロギング・ラスト・リソース」 :このオプションを使用すると、接続が使用されているトランザクション・ブランチが、トランザクションの最後のリソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によって、グローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションでは、「2フェーズ・コミットのエミュレート」よりもパフォーマンス上のメリットとデータの安全性が得られますが、いくつかの制限事項もあります。「ロギング・ラスト・リソース・トランザクション・オプションについて」を参照してください。

注意:

ロギング・ラスト・リソースは、マルチ・データ・ソースで使用されるデータ・ソースについてはサポートされていません。ただし、「LLRデータ・ソースに関する管理上の考慮事項と制限事項」で説明するように、Oracle RACバージョン10Gリリース2 (10GR2)以降と一緒に使用する場合を除きます。

- 2フェーズ・コミットのエミュレート: このオプションを使用すると、接続が使用されているトランザクション・ブランチは、トランザクションの準備フェーズに対して常に成功を戻します。パフォーマンス上のメリットはありますが、いくつかの失敗の状況ではデータにリスクがあります。このオプションは、アプリケーションがヒューリスティックな状況を許容できる場合にのみ選択します。「2フェーズ・コミットのエミュレート・トランザクション・オプションについて」を参照してください。

- 1フェーズ・コミット: (デフォルトで選択済み)このオプションを使用すると、データ・ソースからの接続がグローバル・トランザクションの唯一の参加者となることができ、トランザクションは1フェーズ・コミットの最適化を使用して完了します。トランザクションに複数のリソースが参加している場合、トランザクション・マネージャが1PCリソースに対してXAResource.prepareを呼び出すと、例外がスローされます。

データ・ソースのトランザクション・サポートの構成の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください。

接続プロパティの構成

接続プロパティは、データ・ソースおよびDBMS間の接続の構成に使用されます。通常の属性は、データベース名、ホスト名、ポート番号、ユーザー名およびパスワードです。

注意:

ホスト名を表すために単一クライアント・アクセス名(SCAN)アドレスを使用できます。Oracle RAC 11.2以上を使用する場合は、次の点を考慮してください。

- データ・ソースの接続先のOracle RAC REMOTE_LISTENERがSCANに設定されている場合、データ・ソース接続URLはSCANアドレスのみを使用できます。

- データ・ソースの接続先のOracle RAC REMOTE_LISTENERがノードVIPのリストに設定されている場合、データ・ソース接続URLはVIPアドレスのリストのみを使用できます。

- データ・ソースの接続先のOracle RAC REMOTE_LISTENERがSCANとノードVIPリストの組合せに設定されている場合、データ・ソース接続URLはSCANアドレスとVIPアドレスの両方を使用できます。

SCANアドレスの使用方法の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の概要に関する項を参照してください。

Oracle BI Serverの接続プロパティの構成

Oracle BI ServerをDBMSとして選択した場合、「接続プロパティ」ページで追加の接続プロパティを構成します(『Oracle Business Intelligence Publisher管理者および開発者ガイド』の接続文字列に関する項を参照)。

テスト接続

「データベース接続のテスト」で、データ・ソースの構成を終了する前に、表名またはSQL文を使用してデータベース接続をテストすることができます。必要であれば、「プロパティ」および「システム・プロパティ」属性を使用して追加構成情報をテストできます。

データ・ソースのターゲット指定

1つ以上のターゲットを選択して新規JDBCデータ・ソースをデプロイできます。ターゲットを選択しない場合、データ・ソースは作成されますがデプロイされません。後でデータ・ソースをデプロイする必要があります。

接続プール機能の構成

各JDBCデータ・ソースには、データ・ソースのデプロイ時またはサーバー起動時に作成される、JDBC接続のプールが含まれています。アプリケーションは、プールから接続を使用し、使用し終わると、プールに戻します。接続をプールすることにより、アプリケーション用にデータベース接続を作成するというコストのかかるタスクがなくなるため、パフォーマンスが向上します。

注意:

一部のOracle JDBC拡張機能や、他のドライバから使用可能な他の非標準メソッドは、接続の動作を(プールされた接続の将来のユーザーが継承するような方法で)永続的に変更する可能性があります。WebLogic Serverは、可能な場合、ある種の呼出しから接続を保護しようとします。

次の項では、JDBCデータ・ソースの接続プールのオプションについて説明します。

- JDBCドライバ・レベルの機能の有効化

- 接続ベースのシステム・プロパティの有効化

- SQLコードを使用したデータベース接続の初期化

- 詳細接続プロパティ

これらのオプションおよびその他の関連オプションの詳細は、次で参照し、設定できます。

- 管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

- JDBCDataSourceBeanの子MBeanである、JDBCConnectionPoolParamsBean

JDBCドライバ・レベルの機能の有効化

WebLogic JDBCデータ・ソースは、JDBCドライバで実装されるjavax.sql.ConnectionPoolDataSourceインタフェースをサポートしています。JDBCデータ・ソース内のProperties属性にプロパティおよびその値を追加して、ドライバ・レベルの機能を有効化できます。Properties属性におけるドライバ・レベルのプロパティは、ドライバのConnectionPoolDataSourceオブジェクトで設定されます。

接続ベースのシステム・プロパティの有効化

WebLogic JDBCデータ・ソースは、システム・プロパティの値によるドライバ・プロパティの設定をサポートします。各プロパティの値は、指定されたシステム・プロパティから実行時に取得されます。データ・ソース構成の「システム・プロパティ」属性を編集することで管理コンソールを使用して、接続ベースのシステム・プロパティを構成できます。

SQLコードを使用したデータベース接続の初期化

WebLogic Serverでは、データ・ソースにおけるデータベース接続の作成時に、自動的にSQLコードを実行して、データベース接続を初期化できます。この機能を有効にするには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性に「SQL」と入力し、その直後にスペース、次に実行するSQLコードを入力します。この属性を空白のままにしておくと(デフォルト)、データベース接続を初期化するコードは実行されません。

サーバーの起動時、接続プールの拡張時、接続のリフレッシュ時など、データ・ソースにおけるデータベース接続の作成時には常にここで指定したコードが実行されます。

この機能を使用して、接続ごとのDBMS固有の動作を設定したり、必要なアクションを実行できるメモリーや権限を接続が確実に備えるようにすることができます。

コードは、「SQL」で開始し、その後にスペースを入れます。例:

SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

または

SQL SET LOCK MODE TO WAIT

InitSQLによって設定できるオプションは、DBMSごとに異なります。

注意:

初期化SQLは、動的な属性ではありません。初期化SQLの値を変更する際には、データ・ソースをアンデプロイしてから再デプロイするか、またはサーバーを再起動する必要があります。

拡張接続プロパティ

WebLogic JDBCデータ・ソースは、システム・プロパティの値によるドライバ・プロパティの設定をサポートします。各プロパティの値は、指定されたシステム・プロパティから実行時に取得されます。データ・ソース構成の「システム・プロパティ」属性を編集することで管理コンソールを使用して、接続ベースのシステム・プロパティを構成できます。

これらのオプションおよびその他の関連オプションの詳細は、次で参照し、設定できます。

- 管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

- JDBCDataSourceBeanの子MBeanである、JDBCConnectionPoolParamsBean

致命的エラー・コードの定義

接続でデータ・ソースの通信相手のバックエンド・データベースにアクセスできなくなったことを示す致命的エラー・コードを定義できます。接続は無効のマークが付けられてプールから取り出されますが、データ・ソースは中断されません。これらのエラーには、サーバーの起動を失敗させるデプロイメント・エラーや、接続を接続プールに戻せなくなる接続エラーなどがあります。

エラーが(sqlException.getErrorCode()によって取得される) SQLException内に例外コードとして指定されている場合、致命的エラーが発生して接続が機能しなくなったため、接続プールから削除されることが示されます。Oracleデータベースの場合、次の致命的エラー・コードがWLS内に事前定義されており、これらのコードを構成ファイル内に指定する必要はありません。

エラー・コード

説明

3113

通信チャネルでend-of-fileが検出されました。

3114

Oracleに接続されていません。

1033

Oracleの初期化または停止が進行中です。

1034

Oracleは使用できません。

1089

即時停止が進行中です。操作は許可されません。

1090

停止が進行中です。接続は許可されません。

17002

I/O例外。

管理コンソールで致命的エラー・コードを定義するには、Oracle WebLogic Server管理コンソール・ヘルプの致命的エラー・コードの定義に関する項を参照してください。

Oracleパラメータの構成

WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上させる属性がいくつか用意されています。詳細は、「Oracleドライバとデータベースの詳細構成」を参照してください。

ONSクライアントの構成

ONSクライアントを構成すると、汎用データ・ソースがGridLinkデータ・ソースに変更されます。構成情報および追加の環境要件の詳細は、GridLinkデータ・ソースの使用に関する項を参照してください。

汎用データ・ソース接続プールのチューニング

WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を正しく構成することで、アプリケーションおよびシステムのパフォーマンスを向上できます。詳細は、「データ・ソースの接続プールのチューニング」を参照してください。

データベース・セキュリティ資格証明の設定

次の項では、セキュリティ資格証明をDBMSに渡す方法についての情報を提供します。

- データ・ソース・プールの種類

- ユーザー名/パスワードの使用

- 接続時のクライアントIDの設定

- IDベースの接続プーリング

データ・ソース・プールの種類

Weblogic Serverでは、セキュリティ権限に基づいて、次の2種類のデータ・ソース・プールが提供されます。

- 同種 - アプリケーションのエンド・ユーザーに関係なく、プール内のすべての接続で同じセキュリティ資格証明を使用してDBMSにアクセスします。

- 異種 - アプリケーションは、様々なDBMS資格証明で物理的な接続をプールすることによって、特定のDBMS資格証明でJDBC接続を使用できます。

ここでは、セキュリティ資格証明をDBMSに渡す方法を比較します。

表3-1 セキュリティ資格証明を渡す方法の比較

方法

接続プールの種類

ユーザー名/パスワードの使用

同種の接続プール

接続時のクライアントIDの設定

同種の接続プール

IDベースの接続プーリング

異種の接続プール

ユーザー名/パスワードの使用

資格証明の最も簡単なタイプの認証情報は、接続プールにDBMSのユーザー・アカウント名およびパスワードを提供することです。そうすると、プール内のすべての接続は、同じ認証情報を使用してDBMSにアクセスします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの作成に関する項を参照してください。

注意:

パスワードは「プロパティ」フィールドに名前と値の組み合わせとして入力すること(本番環境では許可されません)も、「パスワード」フィールドに入力することも可能です。「パスワード」フィールドの値は、物理的なデータベース接続を作成するときにJDBCドライバに渡されるPropertiesで定義されている、いかなるpassword値をもオーバーライドします。プロパティ文字列でパスワード・プロパティのかわりにPassword属性を使用することをお薦めします。なぜなら、Password値は構成ファイル内で暗号化(モジュール・ファイルのjdbc-driver-paramsタグでpassword-encrypted属性として保存)され、管理コンソールでは表示されなくなるからです。

接続時にクライアントIDを設定

データ・ソースで「接続時にクライアントIDを設定」属性が有効になっている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたときに、WebLogic Serverインスタンスが現在のWebLogicユーザーIDを判別し、マップされているデータベースIDを軽量なクライアントIDとして設定します。この場合も、プール内のすべての接続で同じ資格証明を使用してDBMSにアクセスします。基本的な構成手順は次のとおりです。

1. 「接続時にクライアントIDを設定」を選択し、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースに対する接続時に「クライアントIDの設定」の有効化に関する項を参照してください。

注意:

WebLogicユーザーIDおよびデータベースIDをマッピングするための資格証明マッピングは、Oracle Thinドライバを使用するOracleデータベースでのみサポートされます。この機能は、Oracle DMSドライバではサポートされません。

2. WebLogicユーザーIDおよびデータベースIDをマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項を参照してください。

この機能は、JDBCドライバおよびDBMSの機能に依存します。OracleおよびDB2データベースで、ベンダー提供の拡張メソッドを使用する場合にのみサポートされます。

- oracle.jdbc.OracleConnection.setClientIdentifier(String id)

- com.ibm.db2.jcc.DB2Connection.setDB2ClientUser(String user)

注意:

「接続時にクライアントIDを設定」と「IDベースの接続プールを有効化」は相互に排他的です。アプリケーション環境でセキュリティ資格証明を渡すために両方のメカニズムが必要な場合は、別々のデータ・ソースを作成して、一方は「接続時にクライアントIDを設定」を指定し、もう一方は「IDベースの接続プールを有効化」を指定してください。

IDベースの接続プーリング

IDベースの接続プーリングを使用すると、アプリケーションは、様々なDBMS資格証明で物理的な接続をプールすることによって、特定のDBMS資格証明でJDBC接続を使用できます。

データ・ソースで「IDベースの接続プールを有効化」属性が有効になっている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたとき、WebLogic Serverインスタンスは既存の物理的接続を選択するか、またはWebLogicユーザー資格証明とDBMS資格証明のマップに基づき、リクエストされたDBMS IDで新しい物理的接続を作成します。基本的な構成手順は次のとおりです。

1. 「IDベースの接続プールを有効化」を選択し、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのIDベースの接続プールの有効化に関する項を参照してください。

2. WebLogicユーザー資格証明とDBMS資格証明をマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項を参照してください。

注意:

「接続時にクライアントIDを設定」と「IDベースの接続プールを有効化」は相互に排他的です。アプリケーション環境でセキュリティ資格証明を渡すために両方のメカニズムが必要な場合は、別々のデータ・ソースを作成して、一方は「接続時にクライアントIDを設定」を指定し、もう一方は「IDベースの接続プールを有効化」を指定してください。

異種接続が作成されるプロセス

次の項では、異種接続が作成されるプロセスについて説明します。

1. 接続プールの初期化時に、データ・ソースのデフォルトDBMS資格証明で物理的なJDBC接続が作成されます。

2. アプリケーションは、データ・ソースからの接続の取得を試行します。

3. 現在のサーバー・インスタンス資格証明はDBMS資格証明にマップされています。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成を参照してください。

- 一致する資格証明が見つからない場合、デフォルトのDBMS資格証明が使用されます。

注意:

デフォルトのDBMS資格証明は、XAトランザクションを実行したり、接続テスト操作を実行できる最低限のDBMS権限を持つ必要があります。

- 一致する資格証明が見つかった場合、DBMS資格証明に一致する物理的な接続の検出にその資格証明が使用されます。

- 一致する接続が見つかった場合、その接続が予約されてアプリケーションに戻されます。

- 一致する接続が見つからない場合、プールの最大容量に基づいて1つの接続が作成されるか、再利用されます。

- 最大容量にまだ達していない場合、DBMS資格証明で新しい接続が作成され、予約されてから、アプリケーションに戻されます。

- プールが最大容量に達している場合、LRU (Least Recently Used)アルゴリズムに基づいて、物理的な接続がプールから選択され、破棄されます。DBMS資格証明で新しい接続が作成され、予約されてから、アプリケーションに戻されます。

物理的な接続がどのように作成されるかに関係なく、プール内の物理的な各接続は、プールによって維持される独自のDBMS資格証明情報を持ちます。物理的な接続がプールによっていったん予約されると、現在のスレッドがWebLogicユーザーの資格証明を変更しても、そのDBMS資格は変更されず、引き続き同じ接続が使用されます。

グローバル・トランザクションでのIDベースのプーリングの使用

グローバル・トランザクションの中で実行される場合、アプリケーションは現在のスレッド上の資格証明を変更して、別の資格証明に基づき複数のJDBC接続を取得することができます。ただし、IDベースのプール機能では、グローバル・トランザクションの中でのWebLogic JDBCデータ・ソースの複数の論理JDBC接続を、単一の物理JDBC接続にマップします。つまり、WebLogicサーバー・インスタンスに対する1つのWebLogic JDBCデータ・ソースにつき、ただ1つのDBMS資格証明のみが、グローバル・トランザクションについて尊重されるということです。

LLRでのIDベースのプーリングの使用

IDベースのプーリングにおいてロギング・ラスト・リソース(LLR)トランザクション最適化を利用するには、次の変更を行う必要があります。

- 完全修飾LLR表名を使用して、LLRのカスタム・スキーマを構成する必要があります。そうすると、すべてのLLR接続が、LLRトランザクション表へのアクセス時に、デフォルトのスキーマではなく指定されたスキーマを使用するようになります。

- データベース固有の管理ツールを使用して、指定されたLLR表へのアクセス許可を、すべてのユーザーに付与します。デフォルトでは、LLR表はデータ・ソース内で接続に対して構成されたユーザーによって、起動の際に作成されます。ほとんどの場合、データベースはこのユーザーに対してのみアクセスを許可し、マップされたユーザーには許可しません。

JDBCデータ・ソース・ファクトリ(非推奨)

WebLogic Serverのこれまでのリリースでは、アプリケーション・スコープのJDBC接続プールは、デフォルトの接続プールの値を提供するのに、JDBCデータ・ソース・ファクトリを使用していました。JDBCデータ・ソース・ファクトリはWebLogic Server 9.2では非推奨となっており、本リリースでは下位互換性のみを目的としています。アプリケーション・スコープのJDBC接続プールの代わりとして、JDBCアプリケーション・モジュールが使用されます。詳細は、「パッケージ化されたJDBCモジュールのアプリケーション・スコープ指定」を参照してください。

このページ上のスクリプト・コンテンツはナビゲーションのみを目的としており、これによってコンテンツが変更されることはありません。

4 GridLinkデータ・ソースの使用

この章では、GridLinkデータ・ソースを構成およびチューニングする方法について説明します。

- GridLinkデータ・ソースとは

- GridLinkデータ・ソースの作成

- ソケット・ダイレクト・プロトコルの使用

- 接続プール機能の構成

- Oracleパラメータの構成

- ONSクライアントの構成

- Oracleパラメータの構成

- GridLinkデータ・ソース接続プールのチューニング

- データベース・セキュリティ資格証明の設定

- GridLink JDBCリソースのモニター

- GridLinkデータ・ソースのベスト・プラクティス

GridLinkデータ・ソースとは

単一のGridLinkデータ・ソースが、WebLogic ServerとOracle Databaseサービスの間の接続を提供します。これには、複数のOracle RACクラスタが含まれることがあります。脚注 1  Oracle RACインスタンスの状態変更に適応的に対処するために、Oracle Notification Service (ONS)が使用されます。Oracle Databaseサービスは、共通属性を持つ作業負荷を表します。これにより、管理者は単一のエンティティとして作業負荷を管理できます。クラスタ内のノード数に関係なく、データベース内のサービス数が増加するに従い、GridLinkデータ・ソース数をスケールします。

図4-1 GridLinkデータ・ソースの接続性

GridLinkデータ・ソースには、汎用データ・ソースと次に示すOracle RACサポートの機能が含まれます。

- 高速接続フェイルオーバー

- ランタイム接続ロード・バランシング

- Oracle RAC停止時の正常操作

- GridLinkアフィニティ

- SCANアドレス

- Oracle Walletを使用してセキュアな通信

高速接続フェイルオーバー

GridLinkデータ・ソースは、高速接続フェイルオーバーを使用して、ONSでOracle RACイベントに応答します。これにより、GridLinkデータ・ソースの接続プールには、接続をポーリングまたはテストする必要がない、有効な接続(予約済接続を含む)が含まれることになります。

図4-2 高速接続フェイルオーバー

GridLinkデータ・ソースは高速接続フェイルオーバーを次の処理に使用します。

- 高速障害検出の実現

- 接続プールから無効な接続の中断・削除

- 予定内外のOracle RACノード停止時の正常終了。「Oracle RAC停止時の正常操作」を参照してください。

- トポロジ変更(ノードの追加や削除など)への適応

- クラスタに再参加するインスタンスを含めて、すべてのアクティブなOracle RACインスタンスへのランタイム・ワーク・リクエストの分配

注意:

GridLinkデータ・ソースでは、非推奨になったFastConnectionFailoverEnabled接続プロパティをサポートしていません。このプロパティの高速接続フェイルオーバーのドライバ実装ではXA接続がサポートされていないため、このプロパティを有効にしてXA接続を作成しようとすると、java.sql.SQLException: 接続キャッシングが有効になっている場合は、getXAConnection()を使用できません。という例外が発生します。

実行時接続ロード・バランシング

GridLinkデータ・ソースで、XAや非XA環境でロード・バランシングが可能になります。GridLinkデータ・ソースは、ランタイム接続ロード・バランシング(RCLB)を使用して、データベースから発行されたOracle FANイベントに基づいて、Oracle RACインスタンスに接続を分配します。これにより、データ・ソースの構成が簡素化し、データ・ベースが、データベース・トポロジと独立して、GridLinkデータ・ソースを通じて接続のロード・バランシングを行うため、パフォーマンスが向上します。

ランタイム接続ロード・バランシングにより、WebLogic Serverで次の処理が可能になります。

- CPU、可用性、およびレスポンス時間など、バックエンドのノード・キャパシティによる作業分配の調整

- Oracle RACトポロジの変更への対応

- 高いパフォーマンスとスケーラビリティを実現するためのプール接続の管理

図4-3 実行時接続ロード・バランシング

FANが無効の場合、GridLinkデータ・ソースは、ラウンドロビン・ロード・バランシング・アルゴリズムで、Oracle RACノードに接続を割り当てます。

注意:

GridLinkデータ・ソースで接続が定期的に停止されることがあります。様々なRACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザリの実行時ロード・バランシングの割合に対応していない場合、超過しているインスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトで30秒ごとに行われます。

この動作は、weblogic.jdbc.gravitationShrinkFrequencySecondsシステム・プロパティを使用してチューニングできます。このプロパティは、システムが接続のリバランスを行うまでの待機時間を秒数で指定します。-1の値を指定すると、リバランス・プロセスが無効になります。

Oracle RAC停止時の正常操作

GridLinkデータ・ソースは、Oracle RACサービスの予定内外のシャットダウン時に正常な処置を行います。

- 計画的停止の場合、データ・ソースは接続を閉じる前に処理中のトランザクションを完了できます。新しいリクエストが、アクティブなOracle RACインスタンスにロードバランスされます。

- 予定外のシャットダウンでは、データ・ソースは、処理中のトランザクションを戻し、接続を切断します。新しいリクエストが、アクティブなOracle RACインスタンスにロードバランスされます。

Oracle RAC 11.2以前のOracle RAC停止の対処方法

Oracle RAC 11.2以前のリリースでは、最初に対応するサービスを停止せずに、Oracle RACインスタンスを手動で停止すると、予定外のシャットダウンにつながります。

GridLinkアフィニティ

WebLogic ServerのGridLinkアフィニティ・ポリシーは、RACクラスタを最大活用することによりアプリケーションのパフォーマンスを高めるように設計されています。GridLinkデータ・ソースは、AffEnabled属性を使用してRACクラスタでRACアフィニティが有効になっているかどうかを判別することにより、RACロード・バランシング・アドバイザリ(LBA)をモニターします。ランタイム接続ロード・バランシング(RCLB)を使用して最初の接続リクエストのロード・バランシングが行われ、そのリクエストがアフィニティ・コンテキストに割り当てられます。後続の接続リクエストはすべて、セッションが終了するか、トランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して同じOracle RACインスタンスにルーティングされます。次を参照:

- セッション・アフィニティ・ポリシー

- XAアフィニティ・ポリシー

セッション・アフィニティ・ポリシー

ユーザー・セッションで連続的なオンライン・トランザクション処理(OLTP)を行うWebアプリケーションのほうが、同じRACインスタンスで同じレコード・セットに対する操作を繰り返し行うよりも、パフォーマンスがよくなります。このパターンの典型的な例は、オンライン・ショッピングやオンライン・バンキングなどのビジネス・アプリケーションです。

GridLinkデータ・ソースでは、Webセッションのすべてのデータベース操作(トランザクションを含む)でRACクラスタの同じOracle RACインスタンスが使用されるように、セッション・アフィニティ・ポリシーを使用します。

注意:

コンテキストはHTTPセッションに格納されます。(1つのブラウザ内で、または複数のブラウザにわたって)ウィンドウがどのようにHTTPセッションにマップされるかは、アプリケーションにより決定されます。

セッション・アフィニティ・ポリシーを使用するGridLinkデータ・ソースがWebセッションのコンテキスト外部からアクセスされると、アフィニティ・ポリシーはXAアフィニティ・ポリシーに変わります。「XAアフィニティ・ポリシー」を参照してください。

図4-4 セッション・アフィニティ

GridLinkデータ・ソースのセッション・アフィニティ・ポリシーはデフォルトでは常に有効になっていますが、次の場合、セッション・アフィニティに対してWebセッションがアクティブになります。

- Oracle RACが有効かつアクティブであり、サービスのRCLBが有効になっている場合。サービスGOAL (NOT CLB_GOAL)がSERVICE_TIMEかTHROUGHPUTのいずれかに設定されている場合、そのサービスのRCLBは有効です。

- データベースによって、クラスタの待機時間に十分なパフォーマンス改善があると判断され、ペイロード内のアフィニティ・フラグがTRUEに設定された場合。

(データベースの可用性状況が高い場合など、)データベースによってセッション・アフィニティを実装してもメリットがないと判断された場合、データベース・ロード・バランシング・アルゴリズムはそのデフォルトの処理割当てポリシーに戻り、ペイロード内のアフィニティ・フラグがFALSEに設定されます。

XAアフィニティ・ポリシー

グローバル・トランザクションのXAアフィニティでは、Oracle RACクラスタで実行するグローバル・トランザクションのデータベース操作は、同じOracle RACインスタンスが対象となります。

図4-5 XAアフィニティ

SCANアドレス

単一クライアント・アクセス名(SCAN)アドレスで、WebLogicコンソールのTNSリスナーおよびONSリスナー双方のホストとポートを指定します。Oracle RACノードを追加・削除する場合、SCANアドレスを含むGridLinkデータ・ソースは変更する必要はありません。環境に応じて適切に構成されたSCANのURLについては、ネットワーク管理者にお問い合せください。

注意:

Oracle RAC 11.2以上を使用する場合は、次の点を考慮してください。

- Oracle RACリスナーがSCANに設定されている場合、GridLinkデータ・ソース構成はSCANアドレスのみを使用できます。

- Oracle RACリスナーがノードVIPのリストに設定されている場合、GridLinkデータ・ソース構成はVIPアドレスのリストのみを使用できます。

- Oracle RACリスナーがSCANとノードVIPリストの組合せに設定されている場合、GridLinkデータ・ソース構成はSCANアドレスとVIPアドレスの両方を使用できます。

SCANアドレスの使用方法の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の概要に関する項およびhttp://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdfを参照してください。

Oracle Walletを使用してセキュアな通信

この機能により、Oracle Walletを使用してONSリスナーとのセキュアな通信を構成できます。「セキュアなONSクライアント通信」を参照してください。

GridLinkデータ・ソースの作成

WebLogicドメインにGridLinkデータ・ソースを作成するには、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用できます。

詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・ヘルプのJDBC GridLinkデータ・ソースの作成に関する項。

- サンプルWLSTスクリプトSAMPLES_HOME\server\examples\src\examples\wlst\online\jdbc_data_source_creation.py(SAMPLES_HOMEはWebLogic Serverインストールの主要なサンプル・ディレクトリを示します)。この例では、汎用データ・ソースが作成されます。『Oracle WebLogic Scripting Tool』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

次の項では、管理コンソールでデータ・ソースを作成するためのデータ・ソース構成ウィザードで実行する基本手順の概要を示します。

- JDBCデータ・ソース・プロパティ

- トランザクション・オプションの構成

- 接続プロパティの構成

- テスト接続

- ONSクライアント構成の構成

- ONSクライアント構成のテスト

- データ・ソースのターゲット指定

JDBCデータ・ソース・プロパティ

JDBCデータ・ソース・プロパティには、データ・ソースのアイデンティティを定義するオプション、およびデータベース接続でのデータ処理方法が含まれます。

データ・ソース名

JDBCデータ・ソース名は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、名前はデータ・ソースやマルチ・データ・ソースを含む他のすべてのJDBCシステム・リソースを通じて一意であることが必要です。名前の競合を避けるため、データ・ソース名はサーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど、他の構成オブジェクト名の中でも一意であることが必要です。アプリケーションをスコープとするJDBCアプリケーション・モジュールの場合、データ・ソース名は同様のスコープを持つJDBCデータ・ソースとマルチ・データ・ソースを通じて一意であることが必要です。

JNDI名

単一または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成できます。1つのJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数のJNDI名を持つデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIのプログラミング』を参照してください。

XAまたは非XAドライバの選択

データ・ソースによるグローバル・トランザクションの対処方法を指定します。

トランザクション・オプションの構成

管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に基づき、自動的に特定のトランザクション・オプションを選択します。

- XAドライバの場合、システムは自動的に、グローバル・トランザクション処理のための2フェーズ・コミット・プロトコルを選択します。

- 非XAドライバの場合、ローカル・トランザクションは定義によってサポートされており、WebLogic Serverは以下のオプションを提供します。
「グローバル・トランザクションのサポート」 : (デフォルトで選択) XAドライバを選択していなくても、グローバル・トランザクションでデータ・ソースからの接続を使用する場合には、このオプションを選択します。詳細については、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。

「グローバル・トランザクションのサポート」を選択した場合は、グローバル・トランザクションを処理するときに、WebLogic Serverがトランザクション・ブランチに使用するプロトコルも選択する必要があります。

- 「ロギング・ラスト・リソース」 :このオプションを使用すると、接続が使用されているトランザクション・ブランチが、トランザクションの最後のリソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によって、グローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションでは、「2フェーズ・コミットのエミュレート」よりもパフォーマンス上のメリットとデータの安全性が得られますが、いくつかの制限事項もあります。「ロギング・ラスト・リソース・トランザクション・オプションについて」を参照してください。

- 2フェーズ・コミットのエミュレート: このオプションを使用すると、接続が使用されているトランザクション・ブランチは、トランザクションの準備フェーズに対して常に成功を戻します。パフォーマンス上のメリットはありますが、いくつかの失敗の状況ではデータにリスクがあります。このオプションは、アプリケーションがヒューリスティックな状況を許容できる場合にのみ選択します。「2フェーズ・コミットのエミュレート・トランザクション・オプションについて」を参照してください。

- 1フェーズ・コミット: (デフォルトで選択済み)このオプションを使用すると、データ・ソースからの接続がグローバル・トランザクションの唯一の参加者となることができ、トランザクションは1フェーズ・コミットの最適化を使用して完了します。トランザクションに複数のリソースが参加している場合、トランザクション・マネージャが1PCリソースに対してXAResource.prepareを呼び出すと、例外がスローされます。

データ・ソースのトランザクション・サポートの構成の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください。

接続プロパティの構成

接続プロパティは、データ・ソースおよびDBMS間の接続の構成に使用されます。通常属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名、およびパスワードがあります。

注意:

サービス名を使用する際は、次の点を考慮してください。

- データベース・ドメインを使用する場合、サービス名に接尾辞としてドメイン名を付ける必要があります。たとえば、データベース名がdb.us.oracle.comの場合、サービス名myserviceはmyservice.us.oracle.comとして入力する必要があります。

- サービス名に大文字を使用することはできません。

コンソールを使用することで、次のいずれかの方法で接続プロパティを入力できます。

- 接続プロパティの入力

- 完全なURLの入力

接続プロパティの入力

「GridLinkデータ・ソース接続プロパティのオプション」のページで、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。接続プロパティを入力します。例:

- 「サービス名」にmyServiceを入力します。

- 「ホストとポート」に、left:1234、center:1234、right:1234を入力します。各リスナーのホストとポートをコロンで区別します。

- 「データベース・ユーザー名」にmyDataBaseを入力します。

- 「パスワード」にmyPassword1を入力します。

- 必要に応じて、「プロトコル」をSDPに設定します。

コンソールは自動的に完全なJDBC URLを生成します。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

完全なURLの入力

「GridLinkデータ・ソース接続プロパティのオプション」のページで、「完全なJDBC URLの入力」を選択し、「次へ」をクリックします。接続プロパティを入力します。例:

- 「完全なJDBC URL」に、JDBCのURLを入力します。例:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

SCANアドレスも使用可能です。たとえば: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyScanAddr-scn.myCompany.com)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

- 「データベース・ユーザー名」にmyDataBaseを入力します。

- 「パスワード」にmyPassword1を入力します。

- 必要に応じて、「プロトコル」をSDPに設定します。

テスト接続

「データベース接続のテスト」で、データ・ソースの構成を終了する前に、表名またはSQL文を使用してデータベース接続をテストすることができます。必要であれば、「プロパティ」および「システム・プロパティ」属性を使用して追加構成情報をテストできます。

ONSクライアント構成の構成

「ONSクライアント構成」で、データ・ソースはOracle FANイベントに登録し、イベントを処理できるようにします。ONSクライアントを設定するには:

- 「FANの有効化」を選択します。

- 「ONSホストとポート」では、ONSベースのFANイベントを受信するためのONSデーモン・リスニング・アドレスおよびポートのカンマ区切りのリストを入力します。FAN通知へのアクセスには、単一クライアント・アクセス名(SCAN)アドレスを使用できます。

- オプションで、SSLを使用してセキュアなONSクライアント通信を構成します。「セキュアなONSクライアント通信」を参照してください。

セキュアなONSクライアント通信

WebLogic ServerでOracle Walletファイルを使用するには、次の処理が必要です。

- WebLogic Serverのクラスパスに次のファイルを追加します。

- $MW_HOME/modules/com.oracle.osdt_cert_1.0.0.0.jar

- $MW_HOME/modules/com.oracle.osdt_core_1.0.0.0.jar

- $MW_HOME/modules/com.oracle.oraclepki_1.0.0.0.jar

- GridLinkデータ・ソースの構成を更新し、SSL証明書とONS Walletパスワードが格納されるOracle Walletファイルのディレクトリを含めます。Oracle WebLogic Server管理コンソール・ヘルプのOracle WalletによるセキュアなONSリスナーに関する項を参照してください。

- Oracle Walletの詳細は、『Database Advanced Security管理者ガイド』を参照してください。

ONSクライアント構成のテスト

「ONSクライアント構成のテスト」で、データ・ソースの構成が決定される前にデータベース接続をテストできます。

データ・ソースのターゲット指定

1つ以上のターゲットを選択して新規JDBC GridLinkデータ・ソースをデプロイできます。ターゲットを選択しない場合、データ・ソースは作成されますがデプロイされません。後でデータ・ソースをデプロイする必要があります。

ソケット・ダイレクト・プロトコルの使用

ソケット・ダイレクト・プロトコル(SDP)を使用するためには、データベース・ネットワークをInfinibandを使用できるように構成する必要があります。SDPではSCANアドレスをサポートしていません。『Oracle Database Net Services管理者ガイド』のInfiniBand接続のためのSDPサポートの構成に関する項を参照してください。

実行時ロード・バランシングの構成

SDP接続間のロード・バランシングを構成するには、すべてのノードでTNSNAMES.ORAファイルを編集し、SDPエンドポイントをLISTENER_IBLOCALエントリに追加する必要があります。

注意:

TNSNAMES.ORAファイルは、インスタンスの起動時またはALTER SYSTEM SET LISTENER_NETWORKS="listener address"コマンドの使用時にのみ読み取られます。TNSNAMES.ORAファイルの更新後、すべてのインスタンスを再起動するか、すべてのネットワークに対してALTER SYSTEM SET LISTENER_NETWORKSコマンドを実行します。

例:

LISTENER_IBLOCAL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =

sclcgdb02ibvip.us.oracle.com)(PORT=1522))
(ADDRESS = (PROTOCOL = SDP)(HOST =
sclcgdb02-bvip.us.oracle.com)(PORT=1522))
)
)

次に、次のURLを使用して、LISTERNER_IBネットワークに接続を分配する必要があります。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=SDP)  (HOST=sclcgdb01-bvip.us.oracle.com)(PORT=1522))(ADDRESS=(PROTOCOL=SDP)  (HOST=sclcgdb02-ibvip.us.oracle.com)(PORT=1522)))(CONNECT_DATA=(SERVICE_NAME=elservice)))

接続プール機能の構成

各JDBCデータ・ソースには、データ・ソースのデプロイ時またはサーバー起動時に作成される、JDBC接続のプールが含まれています。アプリケーションは、プールから接続を使用し、使用し終わると、プールに戻します。接続をプールすることにより、アプリケーション用にデータベース接続を作成するというコストのかかるタスクがなくなるため、パフォーマンスが向上します。

注意:

一部のOracle JDBC拡張機能や、他のドライバから使用可能な他の非標準メソッドは、接続の動作を(プールされた接続の将来のユーザーが継承するような方法で)永続的に変更する可能性があります。WebLogic Serverは、可能な場合、ある種の呼出しから接続を保護しようとします。

次の項では、JDBCデータ・ソースの接続プールのオプションについて説明します。

- JDBCドライバ・レベルの機能の有効化

- 接続ベースのシステム・プロパティの有効化

- SQLコードを使用したデータベース接続の初期化

これらのオプションおよびその他の関連オプションの詳細は、次で参照し、設定できます。

- 管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

- JDBCDataSourceBeanの子MBeanである、JDBCConnectionPoolParamsBean

JDBCドライバ・レベルの機能の有効化

WebLogic JDBCデータ・ソースは、JDBCドライバで実装されるjavax.sql.ConnectionPoolDataSourceインタフェースをサポートしています。JDBCデータ・ソース内のProperties属性にプロパティおよびその値を追加して、ドライバ・レベルの機能を有効化できます。Properties属性におけるドライバ・レベルのプロパティは、ドライバのConnectionPoolDataSourceオブジェクトで設定されます。

注意:

JDBCデータ・ソース内のProperties属性で、ドライバ・レベルのプロパティとしてFastConnectionFailoverEnabled、ConnectionCachingEnabledまたはConnectionCacheNameを使用しないでください。

接続ベースのシステム・プロパティの有効化

WebLogic JDBCデータ・ソースは、システム・プロパティの値によるドライバ・プロパティの設定をサポートします。各プロパティの値は、指定されたシステム・プロパティから実行時に取得されます。データ・ソース構成の「システム・プロパティ」属性を編集することで管理コンソールを使用して、接続ベースのシステム・プロパティを構成できます。

注意:

WebLogic Serverの起動時にJavaシステム・プロパティとしてoracle.jdbc.FastConnectionFailoverを指定しないでください。

SQLコードを使用したデータベース接続の初期化

WebLogic Serverでは、データ・ソースにおけるデータベース接続の作成時に、自動的にSQLコードを実行して、データベース接続を初期化できます。この機能を有効にするには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性に「SQL」と入力し、その直後にスペース、次に実行するSQLコードを入力します。この属性を空白のままにしておくと(デフォルト)、データベース接続を初期化するコードは実行されません。

サーバーの起動時、接続プールの拡張時、接続のリフレッシュ時など、データ・ソースにおけるデータベース接続の作成時には常にここで指定したコードが実行されます。

この機能を使用して、接続ごとのDBMS固有の動作を設定したり、必要なアクションを実行できるメモリーや権限を接続が確実に備えるようにすることができます。

コードは、「SQL」で開始し、その後にスペースを入れます。例:

SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

または

SQL SET LOCK MODE TO WAIT

InitSQLによって設定できるオプションは、DBMSごとに異なります。

注意:

初期化SQLは、動的な属性ではありません。初期化SQLの値を変更する際には、データ・ソースをアンデプロイしてから再デプロイするか、またはサーバーを再起動する必要があります。

Oracleパラメータの構成

WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上させる属性がいくつか用意されています。詳細は、「Oracleドライバとデータベースの詳細構成」を参照してください。

ONSクライアントの構成

次の項では、ONSクライアントの構成方法について説明します。

- FANイベントの有効化

- 汎用データ・ソース接続テストの構成

- Walletファイルの使用

FANイベントの有効化

Oracle高速アプリケーション通知(FAN)イベントに登録し、イベントを処理するためにデータ・ソースを有効にします。

1. 「FANの有効化」を選択します

2. ONSベースのFANイベントを受信するためのONSデーモン・リスニング・アドレスおよびポートのカンマ区切りのリストを指定します。FAN通知へのアクセスには、単一クライアント・アクセス名(SCAN)アドレスを使用できます。

『Oracle WebLogic Server管理コンソールのヘルプ』のONSクライアント・パラメータの構成に関する項を参照してください。

汎用データ・ソース接続テストの構成

通常、FANイベントが有効になっている場合は、予約時のテストを有効にする必要はありません。ただし、ONSサーバーが停止している場合や通常の状態でない場合は、「FANの有効化」を無効にし、予約時のテストを有効にすることができます。詳細は、「データ・ソースの接続テスト・オプション」を参照してください。

Walletファイルの使用

SSLでONSデーモンと通信するためには、walletファイルを使用する必要があります。「セキュアなONSクライアント通信」を参照してください。

Oracleパラメータの構成

WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上させる属性がいくつか用意されています。詳細は、「Oracleドライバとデータベースの詳細構成」を参照してください。

GridLinkデータ・ソース接続プールのチューニング

WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を正しく構成することで、アプリケーションおよびシステムのパフォーマンスを向上できます。詳細は、「データ・ソースの接続プールのチューニング」を参照してください。

データベース・セキュリティ資格証明の設定

次の項では、セキュリティ資格証明をDBMSに渡す方法についての情報を提供します。

- ユーザー名/パスワードの使用

- 接続時のクライアントIDの設定

注意:

GridLinkデータ・ソースは、識別ベースの接続プールをサポートしません。

ユーザー名/パスワードの使用

資格証明の最も簡単なタイプの認証情報は、接続プールにDBMSのユーザー・アカウント名およびパスワードを提供することです。そうすると、プール内のすべての接続は、同じ認証情報を使用してDBMSにアクセスします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの作成に関する項を参照してください。

注意:

パスワードは「プロパティ」フィールドに名前と値の組み合わせとして入力すること(本番環境では許可されません)も、「パスワード」フィールドに入力することも可能です。「パスワード」フィールドの値は、物理的なデータベース接続を作成するときにJDBCドライバに渡されるPropertiesで定義されている、いかなるpassword値をもオーバーライドします。プロパティ文字列でパスワード・プロパティのかわりにPassword属性を使用することをお薦めします。なぜなら、Password値は構成ファイル内で暗号化(モジュール・ファイルのjdbc-driver-paramsタグでpassword-encrypted属性として保存)され、管理コンソールでは表示されなくなるからです。

接続時にクライアントIDを設定

データ・ソースで「接続時にクライアントIDを設定」属性が有効になっている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたときに、WebLogic Serverインスタンスが現在のWebLogicユーザーIDを判別し、マップされているデータベースIDを軽量なクライアントIDとして設定します。この場合も、プール内のすべての接続で同じ資格証明を使用してDBMSにアクセスします。基本的な構成手順は次のとおりです。

1. 「接続時にクライアントIDを設定」を選択し、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースに対する接続時に「クライアントIDの設定」の有効化に関する項を参照してください。

注意:

WebLogicユーザーIDおよびデータベースIDをマッピングするための資格証明マッピングは、Oracle Thinドライバを使用するOracleデータベースでのみサポートされます。この機能は、Oracle DMSドライバではサポートされません。

2. WebLogicユーザーIDおよびデータベースIDをマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項を参照してください。

この機能は、JDBCドライバおよびDBMSの機能に依存します。OracleおよびDB2データベースで、ベンダー提供の拡張メソッドを使用する場合にのみサポートされます。

- oracle.jdbc.OracleConnection.setClientIdentifier(String id)

- com.ibm.db2.jcc.DB2Connection.setDB2ClientUser(String user)

注意:

「接続時にクライアントIDを設定」と「IDベースの接続プールを有効化」は相互に排他的です。アプリケーション環境でセキュリティ資格証明を渡すために両方のメカニズムが必要な場合は、別々のデータ・ソースを作成して、一方は「接続時にクライアントIDを設定」を指定し、もう一方は「IDベースの接続プールを有効化」を指定してください。

GridLink JDBCリソースのモニター

次の項では、GridLink JDBCオブジェクトのモニターについて詳細に説明します。

- 実行時の統計の表示

- GridLinkデータ・ソースのデバッグ

JDBC監視の詳細は、「WebLogic JDBCリソースのモニター」を参照してください。

実行時の統計の表示

管理コンソールまたは関連するランタイムMBeansを通じてGridLinkデータ・ソースのランタイム統計を参照できます。

JDBCOracleDataSourceInstanceRuntimeMBean

JDBCOracleDataSourceInstanceRuntimeMBeanは、データ・ソース・インスタンスの現在の状態を得る方法を提供します。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceInstanceRuntimeMBeanを参照してください。

JDBCDataSourceRuntimeMBean

JDBCDataSourceRuntimeMBeanは、データ・ソース・インスタンスの現在の状態を得る方法を提供します。JDBCDataSourceRuntimeMBeanは、データ・ソースの現在の状態およびアクティブな平均接続数、現在のアクティブな接続数および最大アクティブ接続数など、データ・ソースの統計データの取得方法を提供します。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanを参照してください。

ONSDaemonRuntimeMBean

ONSDaemonRuntimeMBeanは、GridLinkデータ・ソースと関連付けられたONSクライアント構成を監視する方法を提供します。詳細は、Oracle WebLogic Server MBeanリファレンスのONSDaemonRuntimeMBeanに関する項を参照してください。

GridLinkデータ・ソースのデバッグ

WebLogic Serverのデバッグ機能をアクティブにして、アプリケーション内の特定の問題を追跡できます。

JDBCのデバッグ・スコープ

次に、JDBCの登録されたデバッグ・スコープを示します。

- DebugJDBCRAC (スコープweblogic.jdbc.racl): GridLinkデータ・ソースのライフ・サイクル、UCPコールバックおよび接続情報を印刷します。

- DebugJDBCONS (スコープweblogic.jdbc.connection): LBAイベント本体を含むONSクライアント情報を追跡します。

UCP JDKロギング

http://download.oracle.com/docs/cd/B28359_01/java.111/e10788/get_started.htm#sthref67の指示に従って、UPC JDKロギングを有効にできます。

コマンド・ラインを使用してデバッグを有効化する

コマンド・ラインで適切なGridLinkデータ・ソース・デバッギング・プロパティを指定します。例:

-Dweblogic.debug.DebugJDBCRAC=true
-Dweblogic.debug.DebugJDBCONS=true
-Dweblogic.debug.DebugJDBCUCP=true

この方法は静的なものであり、サーバーの起動時にのみ使用できます。

GridLinkデータ・ソースのベスト・プラクティス

次の項では、GridLinkデータ・ソースを使用するためのベスト・プラクティスについて説明します。

- 例外の捕捉と処理

例外の捕捉と処理

アプリケーションは、すべての例外を捕捉して処理する必要があります。GridLinkデータ・ソースを使用するアプリケーションは、借りている接続でJDBC操作を実行する際にIOソケット読取りエラーなどの例外を想定する必要があります。ベスト・プラクティスは、接続の有効性をチェックし、必要に応じて再接続することです。接続の例外は、ドライバがFANイベントの到着よりも早く停止を検出した場合や、接続プールのクリーン・アップの結果として発生します。予定外の停止イベントが発生すると、接続プールは、停止の影響を受ける借りている接続をすべて中止します。

脚注凡例
脚注 1: F: たとえば、Oracle Data Guardなどです。

5 JDBCマルチ・データ・ソースの構成

この章では、マルチ・データ・ソースを構成および使用して、接続リクエスト時に、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する方法について説明します。

マルチ・データ・ソースとは、データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされるデータ・ソースのグループ周辺を抽象化したものです。アプリケーションは、データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースは、そのマルチ・データ・ソースの構成内で選択されるアルゴリズムに応じて、リクエストを満たすためにロード・バランシングとフェイルオーバーのうちどちらのデータ・ソースを使用するかを決定します。

この項は、次の情報を含みます。

- マルチ・データ・ソースの機能

- マルチ・データ・ソースの作成と構成

- マルチ・データ・ソース・アルゴリズムの選択

- マルチ・データ・ソースのフェイルオーバーの制限と要件

- マルチ・データ・ソース・フェイルオーバー機能の拡張

- サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ

マルチ・データ・ソースの機能

マルチ・データ・ソースは、データ・ソースのプールであると捉えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーまたはロード・バランシングに最適です。

マルチ・データ・ソースのデータ・ソース・メンバー・リストは、動的な更新をサポートしています。これによって、Oracle RACなどを使用する環境で、再デプロイメントすることなく、データベース・ノードと対応するデータ・ソースを追加および削除でき、次のことができます。

- スループットに応じてOracle RACクラスタを拡大および縮小します。「データベース・ノードの追加」を参照してください。

- メンテナンスのためOracle RACノードを停止します。「データベース・ノードの削除」を参照してください。

「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

注意:

マルチ・データ・ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Serverの外部で適切に処理されることが前提となっています。

データベース・ノードの削除

再デプロイメントせずに、データベース・ノードと対応するデータ・ソースを削除することができます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。以下の手順に従って、データベース・ノードを停止します。

注意:

これらの手順に失敗した場合、トランザクションがロールバックされる場合があります。

1. データ・ソースをマルチ・データ・ソースから削除します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。

2. すべてのトランザクションの終了後、データ・ソースを一時停止します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの一時停止に関する項を参照してください。

3. すべてのトランザクションの終了後、データ・ソースを停止します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの停止に関する項を参照してください。

4. データベース・ノードを停止します。

データベース・ノードの追加

再デプロイメントせずに、データベース・ノードと対応するデータ・ソースを追加することができます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。次のハイレベルの手順に従って、データベース・ノードを追加します。

1. データベース・ノードを再起動します。

2. データ・ソースを再起動します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの開始に関する項を参照してください。

3. データ・ソースを再度マルチ・データ・ソースに追加します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。

マルチ・データ・ソースの作成と構成

マルチ・データ・ソースを作成するには、まずデータ・ソースを作成し、次に管理コンソールまたはWebLogic Scripting Toolでマルチ・データ・ソースを作成して、その後データ・ソースをマルチ・データ・ソースに割り当てます。

マルチ・データ・ソースの作成方法は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソースの構成に関する項を参照してください。

マルチ・データ・ソースの構成時に作成される構成ファイルについては、「WebLogic ServerにおけるJDBCリソースについて」を参照してください。また、「JDBCマルチ・データ・ソース・モジュールの作成」も参照してください。

マルチ・データ・ソース・アルゴリズムの選択

マルチ・データ・ソースを設定する前に、その主要な目的、つまりフェイルオーバーまたはロード・バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズにあわせて選択できます。

フェイルオーバー

フェイルオーバー・アルゴリズムは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。

注意:

このアルゴリズムでは、データ・ソースの「予約時に接続のテスト」(TestConnectionsOnReserve)を有効化する必要があります。有効になっている場合、最初のデータ・ソース内の接続をテストして、データ・ソースが正常であるかどうかを確認します。テストに失敗した場合、マルチ・データ・ソースにリストされている次のデータ・ソースの接続が使用されます。TestConnectionsOnReserveの構成については、「データ・ソースの接続テスト・オプション」を参照してください。

JDBCは、クライアントとDBMS間の高度にステートフルなプロトコルです。JDBCでは、DBMS接続とトランザクション状態が、DBMSプロセスとクライアント(ドライバ)の間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバーはサポートされません。

ロード・バランシング

ロード・バランシング・マルチ・データ・ソースへの接続リクエストは、リスト内の任意のデータ・ソースから処理されます。マルチ・データ・ソースは、ラウンドロビン方式で接続リクエストに応じるためのデータ・ソースを選択します。マルチ・データ・ソースは接続を提供する際、最後に使用されたデータ・ソースの直後にリストされているデータ・ソースからの接続を選択します。ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースも、データベース接続テストが失敗して接続を置き換えられない場合、またはデータ・ソースが中断されている場合、リスト内の次のデータ・ソースにフェイルオーバーされます。

マルチ・データ・ソースのフェイルオーバーの制限と要件

WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、データ・ソースで障害(データベース管理システムのクラッシュなど)が発生しても、システムをそのまま稼働させることができます。ただし、システムを構成する際は、以下の制限と要件を考慮する必要があります。

予約時の接続テストによるフェイルオーバーの有効化

データ・ソースは、「予約時に接続のテスト」(TestConnectionsOnReserve)機能に依存して、いつデータベース接続が失われるかを確認します。マルチ・データ・ソース内のデータ・ソースの「予約時に接続のテスト」機能を有効化する必要があります。各接続をアプリケーションに渡す前にWebLogic Serverでテストします。フェイルオーバー・アルゴリズムを使用して、マルチ・データ・ソースは接続テストの結果によって、マルチ・データ・ソース内の次のデータ・ソースにフェイルオーバーするタイミングを決定します。テストに失敗した場合、データ・ソースは、接続を再試行します。それにも失敗した場合、マルチ・データ・ソースは次のデータ・ソースにフェイルオーバーします。

使用中の接続はフェイルオーバーできない

予約後に接続が失敗する可能性もありますが、これについてはアプリケーションで処理する必要があります。WebLogic Serverでは、アプリケーションで使用中に失敗した接続をフェイルオーバーさせることはできません。接続の使用中に障害が発生した場合、アプリケーション・コードでは、障害が発生した接続を閉じて、新しい接続でトランザクションを最初から再起動する必要があります。

マルチ・データ・ソース・フェイルオーバー機能の拡張

次の拡張により、マルチ・データ・ソースのフェイルオーバー処理が向上します。

- 接続リクエストのルーティングを拡張し、マルチ・データ・ソース内の自動的に無効化された(失効した)データ・ソースからの接続のリクエストを回避します。「データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張」を参照してください。

- マルチ・データ・ソース内の障害の発生したデータ・ソースがリカバリした場合の自動的なフェイルバック。「マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化」を参照してください。

- マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバー。「マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバーの有効化」を参照してください。

- フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースに対するフェイルオーバーのコールバック。「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

- いずれかのアルゴリズムを使用するマルチ・データ・ソースに対するフェイルバックのコールバック。「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。

データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張

マルチ・データ・ソース内のデータ・ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Serverはプールされた接続が接続テストで失敗すると、データ・ソースを自動的に無効化します。データ・ソースが無効化されると、アプリケーションからそのデータ・ソースに接続リクエストがルーティングされなくなります。その代わり、マルチ・データ・ソース内にリストされた次の利用可能なデータ・ソースに接続リクエストがルーティングされます。

この機能を使用するには、データ・ソース・テスト・オプション(特に「表名のテスト」および「予約時に接続のテスト」)がマルチ・データ・ソース内のすべてのデータ・ソースに対して構成されていることが必要です。「データ・ソースの接続テスト・オプション」を参照してください。

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、リスト内の次のデータ・ソースにフェイルオーバーされます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化

接続に失敗してデータ・ソースが自動的に無効になった場合、マルチ・データ・ソースは、無効になったデータ・ソースからの接続を定期的にテストし、データ・ソース(または基礎となるデータベース)がいつ再度有効になるかを決定します。データ・ソースが使用可能になると、マルチ・データ・ソースがデータ・ソースを自動的に再有効化し、マルチ・データ・ソース・アルゴリズムおよび含まれるデータ・ソース・リスト内のデータ・ソースの位置によって、データ・ソースにルーティングする接続リクエストを再開します。これらのテストの頻度は、マルチ・データ・ソースの「テスト間隔」属性によって制御されます。テスト頻度のデフォルト値は120秒なので、特にこのオプションの値を設定しない場合は、マルチ・データ・ソースは無効化されたデータ・ソースを120秒おきにテストします。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCマルチ・データ・ソース: 構成: 一般」を参照してください。

手動で無効化したデータ・ソースに対してはテストも自動的な再有効化も行われません。自動的に無効化されたデータ・ソースだけがテストされます。

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、データ・ソースの再有効化が行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。

マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバーの有効化

デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在のデータ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。

現在のデータ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、管理コンソールの「JDBCマルチ・データ・ソース:構成:全般」ページで「ビジー時はリクエストをフェイルオーバー」オプションを有効にします。(JDBCDataSourceParamsBeanのFailoverRequestIfBusy属性でも設定できます。)有効(trueに設定されている場合、現在のデータ・ソース内のすべての接続が使用中のとき、アプリケーションの接続リクエストはマルチ・データ・ソース内の次に使用可能なデータ・ソースにルーティングされます。無効(デフォルトのfalse)に設定すると、接続リクエストのフェイルオーバーは行われません。

マルチ・データ・ソースの構成にConnectionPoolFailoverCallbackHandlerが含まれている場合、コールバック・ハンドラが呼び出されてから、フェイルオーバーが行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

コールバックによるマルチ・データ・ソース・フェイルオーバーの制御

WebLogic Serverには、フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースが、どのタイミングでマルチ・データ・ソース内の、あるJDBCデータ・ソースからの接続リクエストを、リスト内の次のデータ・ソースにフェイルオーバーするかを制御する、コールバック・ハンドラを登録することができます。

コールバック・ハンドラを使用すると、フェイルオーバーを行うかどうか、またはフェイルオーバーを行う時期を制御できるので、フェイルオーバーの前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。

コールバック・ハンドラは、マルチ・データ・ソースの「フェイルオーバーのコールバック・ハンドラ」属性を介して、マルチ・データ・ソースごとに登録されます。コールバック・ハンドラを適用する各マルチ・データ・ソースに、コールバック・ハンドラを登録する必要があります。また、ドメイン内の各マルチ・データ・ソースについて、別々のコールバック・ハンドラを登録することができます。

コールバック・ハンドラの要件

マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースの実装が含まれていなければなりません。マルチ・データ・ソースでリスト内の次のデータ・ソースにフェイルオーバーする必要がある場合や、以前に無効化されたデータ・ソースが利用可能になった場合、ConnectionPoolFailoverCallbackインタフェースのallowPoolFailover()メソッドが呼び出され、以下に定義されている3つのパラメータ(currPool、nextPool、およびopcode)の値が渡されます。コールバック・ハンドラからの戻り値を待機してからタスクが完了されます。

アプリケーションは、以下に定義されているOK、RETRY_CURRENT、またはDONOT_FAILOVERを戻す必要があります。アプリケーションはフェイルオーバーおよびフェイルバックの個々の状況を処理しなければなりません。

詳細は、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースのJavadocを参照してください。

注意:

フェイルオーバーのコールバック・ハンドラは、任意指定です。マルチ・データ・ソースの構成にコールバック・ハンドラが指定されていなければ、WebLogic Serverは操作(フェイルオーバーまたは無効化されたデータ・ソースの再有効化)を続行します。

コールバック・ハンドラの構成

フェイルオーバーおよびフェイルバック機能に関連付けられたマルチ・データ・ソースの構成属性は2つあります。

- フェイルオーバーのコールバック・ハンドラ(ConnectionPoolFailoverCallbackHandler) - マルチ・データ・ソースのフェイルオーバーのコールバック・ハンドラを登録するには、マルチ・データ・ソースの構成にその属性の値を追加します。値には、com.bea.samples.wls.jdbc.MultiDataSourceFailoverCallbackApplicationなどの絶対名を指定する必要があります。管理コンソールを使用してフェイルオーバーのコールバック・ハンドラを設定できます。(Oracle WebLogic Server管理コンソール・ヘルプのフェイルオーバーのコールバック・ハンドラの登録に関する項を参照)またはWLSTを使用したマルチ・データ・ソース用のJDBCDataSourceParamsBean上に設定できます。

- テスト頻度 (TestFrequencySeconds) - マルチ・データ・ソースによる、無効化された(レスポンスのない)データ・ソースが利用可能になったかどうかのチェック頻度を制御します。詳細は、「マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化」を参照してください。

フェイルオーバーの仕組み

WebLogic Serverは、現在のデータ・ソースで接続テストが失敗した場合や、FailoverRequestIfBusyが有効化されているときに現在のデータ・ソース内のすべての接続が使用中である場合に、接続リクエストをリスト内の次のデータ・ソースにフェイルオーバーしようとします。

コールバック機能を有効化するには、マルチ・データ・ソースの構成で「フェイルオーバーのコールバック・ハンドラ」を使用して、コールバック・ハンドラをWebLogic Serverに登録します。

フェイルオーバー・アルゴリズムを使用する場合、接続リクエストはリスト内の最初のデータ・ソースから処理されます。データ・ソースからの接続が接続テストに失敗すると、WebLogic Serverはそのデータ・ソースを「レスポンスなし」としてマーク付けし、無効にします。コールバック・ハンドラが登録されている場合、WebLogic Serverは以下の情報を渡してコールバック・ハンドラを呼び出し、戻り値を待機します。

- currPool - フェイルオーバーの場合、データベース接続の提供に現在使用されているデータ・ソースの名前です。これは、「フェイルオーバー元」のデータ・ソースです。

- nextPool - マルチ・データ・ソース内にリストされた次の利用可能なデータ・ソースの名前。フェイルオーバーの場合、これは「フェイルオーバー先」のデータ・ソースです。

- opcode - 呼出しの理由を示すコード。

- OPCODE_CURR_POOL_DEAD - WebLogic Serverは、現在のデータ・ソースが失効したと判断し、無効化しました。

- OPCODE_CURR_POOL_BUSY - データ・ソース内のすべてのデータベース接続が使用中です。(マルチ・データ・ソースの構成に、FailoverIfBusy=trueが必要です。「マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバーの有効化」を参照してください。)

フェイルオーバーは接続リクエストと同期します。フェイルオーバーは、WebLogic Serverが接続リクエストに応じようとする場合にのみ発生します。

コールバック・ハンドラからの戻り値は、以下の3種類のオプションのいずれかを示します。

- OK - 処理を続行します。この場合、リスト内の次のデータ・ソースにフェイルオーバーすることを意味します。

- RETRY_CURRENT - 接続リクエストを現在のデータ・ソースで再試行します。

- DONOT_FAILOVER - 現在の接続リクエストを再試行せず、かつ、フェイルオーバーも行いません。WebLogic Serverによってweblogic.jdbc.extensions.PoolUnavailableSQLExceptionがスローされます。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

2番目のデータ・ソースで障害が発生すると、先のフェイルオーバーと同様、マルチ・データ・ソース内の次の利用可能なデータ・ソースにフェイルオーバーしようと再びコールバック・ハンドラが呼び出されます(データ・ソースが存在している場合)。

注意:

データ・ソースを手動で無効化した場合、WebLogic Serverはコールバック・ハンドラを呼び出しません。

ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースの場合、WebLogic Serverではデータ・ソースが無効化されても、コールバック・ハンドラは呼び出されません。ただし、無効化されたデータ・ソースを再有効化しようとする場合にはコールバック・ハンドラが呼び出されます。詳細は、次の項を参照してください。

コールバックによるマルチ・データ・ソース・フェイルバックの制御

マルチ・データ・ソースに対してフェイルオーバーのコールバック・ハンドラが登録されている場合、WebLogic Serverでは、自動的に無効化されたデータ・ソースを再有効化するときに同じコールバック・ハンドラが呼び出されます。コールバックを使用すると、無効化されたデータ・ソースを再有効化するかどうか、または再有効化を行う時期を制御できるので、データ・ソースを再有効化する前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。

コールバック・ハンドラの詳細は、次の項を参照してください。

- コールバック・ハンドラの要件

- コールバック・ハンドラの構成

フェイルバックの仕組み

WebLogic Serverでは、マルチ・データ・ソース内の自動的に無効化されたデータ・ソースのステータスが定期的にチェックされます( 「マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化」 を参照)。(マルチ・データ・ソース内で失敗したデータ・ソースのリカバリ後の自動再有効化を参照してください。)無効化されたデータ・ソースが利用可能になった場合、およびフェイルオーバーのコールバック・ハンドラが登録されている場合、WebLogic Serverは以下の情報を持つコールバック・ハンドラを呼び出して、戻り値を待機します。

- currPool - フェイルバックの場合、以前に無効化されて現在は再有効化が可能になっているデータ・ソースの名前です。

- nextPool - フェイルバックの場合、nullです。

- opcode - 呼出しの理由を示すコード。フェイルバックの場合、コードは常にOPCODE_REENABLE_CURR_POOLであり、currPoolに名前のあるデータ・ソースが現在利用可能であることを示します。

フェイルバック(つまり、無効化されたデータ・ソースを自動的に再有効化すること)は、フェイルオーバーが接続リクエストと同期しているものの、フェイルバックは接続リクエストと非同期しているという点でフェイルオーバーとは異なります。

コールバック・ハンドラは、以下の値のいずれかを戻す可能性があります。

- OK - 処理を続行します。この場合、示されたデータ・ソースを再有効化することを意味します。マルチ・データ・ソースのアルゴリズムとリスト内のデータ・ソースの位置に応じてそのデータ・ソースに対する接続リクエストのルーティングが再開されます。

- DONOT_FAILOVER - currPoolデータ・ソースを再有効化しません。使用中のデータ・ソースで接続リクエストを処理し続けます。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

コールバック・ハンドラがDONOT_FAILOVERを返した場合、WebLogic Serverはマルチ・データ・ソースの構成のTestFrequencySeconds属性で決められている設定に従って次のテスト・サイクル中にデータ・ソースを再有効化しようとし、そのプロセスの一部としてコールバック・ハンドラを呼び出します。

マルチ・データ・ソース内でのデータ・ソースのリスト順は、非常に重要です。フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースは常に、マルチ・データ・ソース内のデータ・ソース・リストで最初に利用可能なデータ・ソースからの接続リクエストを処理しようとします。次のシナリオを検討してください。

1. フェイルオーバー・アルゴリズムを使用するMultiDataSource_1には、登録されたConnectionPoolFailoverCallbackHandlerがあり、DS1、DS2、およびDS3という順序でリストされている3つのデータ・ソースが含まれています。

2. DS1が無効化されると、MultiDataSource_1では接続リクエストがDS2にフェイルオーバーされます。

3. DS2が無効化されると、MultiDataSource_1では接続リクエストがDS3にフェイルオーバーされます。

4. しばらく経つと、DS1が再び利用可能になり、コールバック・ハンドラによってWebLogic Serverによるデータ・ソースの再有効化が許可されます。DS1はマルチ・データ・ソース内にリストされた最初のデータ・ソースなので、以降の接続リクエストは、DS1によって処理されます。

5. 続いてDS2が利用可能になり、コールバック・ハンドラによってWebLogic Serverによるデータ・ソースの再有効化が許可されても、データ・ソースのリストでDS1はDS2の前にリストされているので、接続リクエストは引続きDS1によって処理されます。

サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ

接続リクエストに応じるためにマルチ・データ・ソースで使用されているデータ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされているデータ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイメント・ターゲットとして選択します。サーバーにマルチ・データ・ソースをデプロイする場合、そのサーバー上にマルチ・データ・ソースのインスタンスが作成されます。クラスタにマルチ・データ・ソースをデプロイする場合、クラスタ内の各サーバー上にマルチ・データ・ソースのインスタンスが作成されます。

手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイに関する項を参照してください。

6 Oracleドライバおよびデータベースの詳細構成

この章では、Oracleのドライバおよびデータベースの使用時にデータ・ソースおよびドライバのパフォーマンスを向上させる詳細構成オプションについて説明します。オプションには、プロキシ認証、接続の資格証明の設定、接続収集、および接続のラベリングがあります。

- ドライバのパフォーマンスを向上させるオプション

- Oracleデータベースのプロキシ認証

- 接続でのデータベース資格証明の設定

- 接続収集の構成

- 接続のラベリング

ドライバ・パフォーマンスを向上させるためのオプション

WebLogic Serverは、Oracleドライバ使用時にデータ・ソース・パフォーマンスを向上させるいくつかの属性を提供します。これには次が含まれます。

- Oracle Enable JavaNet Fastpath: Oracle JDBC JavaNet Fastpathを有効化して、データ・コピーおよびフラグメンテーションを低減させます。

- Oracle Optimize UTF8 Conversion: 「Oracle JDBC Optimize UTF8 Conversion」オプションを有効化します。

ご使用の環境でこれらの属性がサポートされている場合、Oracle WebLogic Server管理コンソール・ヘルプのOracleパラメータの構成に関する項を参照してください。

Oracleデータベースのプロキシ認証

プロキシ認証により、1つのJDBC接続をOracleデータベースへの他のJDBC接続のプロキシとして使用できます。クライアントがプロキシ・ユーザーとしてのアプリケーション・サーバーを介してデータベースに接続できるように、WebLogicデータ・ソースを構成できます。クライアントはアプリケーション・サーバーへの認証を行い、アプリケーション・サーバーはOracleデータベースへの認証を行います。これにより、データベースとの接続でクライアントのユーザー名を管理できます。

プロキシ認証の構成方法

Oracleデータベースへのプロキシ認証を構成する手順は、次のとおりです。

1. 必要なWebLogic Serverおよびデータベース・ユーザーを作成します(まだ作成していない場合)。

2. Oracleデータベースで、CONNECT THROUGH権限を付与します。
例:

SQL> ALTER USER wlsuser GRANT CONNECT THROUGH dbuser;

wlsuserはWebLogic Serverユーザーで、dbuserはOracleデータベース・ユーザーです。

3. WebLogic Serverインスタンスに対して、次の手順を実行します。

1. 汎用データ・ソースまたはGridLinkデータ・ソースを作成し、ユーザーをdbuserの値に設定します。

2. wlsuserの値をdbuserの値にマップします。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成を参照してください。

3. データ・ソースを再デプロイします。

4. wlsuserの値を使用して、WebLogic Serverインスタンスにログオンします。

5. プロキシ認証を有効にします。Oracle WebLogic Server管理コンソール・ヘルプのOracleパラメータの構成に関する項を参照してください。
プールで接続がリクエストされるたびに、アプリケーション認証されるユーザーに対する接続でプロキシ・セッションが開かれます。接続がプールに戻されると、プロキシ・セッションが閉じられます。

注意:

プロキシ・セッションを開くか閉じる場合:

- 元の接続から既存の文(結果セットを含む)を閉じます。

- WebLogic Serverの文キャッシュをクリアします。

- 接続に対するWebLogic Serverのテスト文は、プロキシ・セッションごとに再作成されます。

これらの動作は、インスタンス間で接続を共有し、ある状態が接続に関連付けられていると想定するアプリケーションに影響を及ぼす可能性があります。

接続のデータベース資格証明の設定

Oracleデータベースへの接続時に接続によってデータベース資格証明が設定されるように、WebLogicデータ・ソースを構成できます。構成した場合、getConnection(username, password)でデータベース・ユーザーとパスワードを指定して作成した接続に対して、プロキシ・セッションが開かれます。これにより、多数のユーザーを認証するための簡単かつ軽量なメカニズムが提供されます。データベース・ユーザーごとに資格証明マッピングを指定する必要はありません。

Oracleデータベースへの接続に対してデータベース資格証明のプロキシ認証を構成する手順は、次のとおりです。

1. 必要なデータベース・ユーザーを作成します(まだ作成していない場合)。

2. Oracleデータベースで、CONNECT THROUGH権限を付与します。
例:

SQL> ALTER USER connectionuser GRANT CONNECT THROUGH dbuser;

connectionuserは認証を受けるアプリケーション・ユーザーの名前で、dbuserはOracleデータベース・ユーザーです。

3. WebLogic Serverインスタンスで、汎用データ・ソースまたはGridLinkデータ・ソースを作成し、ユーザーをdbuserの値に設定します。

4. 「データベース資格証明の使用」を有効にします。Oracle WebLogic Server管理コンソール・ヘルプのOracleパラメータの構成に関する項を参照してください。
プールで接続がリクエストされるたびに、アプリケーション認証されるユーザーに対する接続でプロキシ・セッションが開かれます。接続がプールに戻されると、プロキシ・セッションが閉じられます。

注意:

プロキシ・セッションを開くか閉じる場合:

- 元の接続から既存の文(結果セットを含む)を閉じます。

- WebLogic Serverの文キャッシュをクリアします。

- 接続に対するWebLogic Serverのテスト文は、プロキシ・セッションごとに再作成されます。

これらの動作は、インスタンス間で接続を共有し、ある状態が接続に関連付けられていると想定するアプリケーションに影響を及ぼす可能性があります。

5. getConnection(username, password)を使用して接続を開きます。

注意:

「データベース資格証明の使用」が有効になっておらず、connectionuserの値がWebLogic Serverユーザーでない場合、getConnectionは失敗します。

接続にデータベース資格証明を設定する際の考慮事項

トランザクションに参加する接続に対してデータベース資格証明を設定する際は、次の点を考慮してください。

- グローバル・トランザクションでXA以外のLLRまたは1PC (JTSドライバ)が構成されているデータ・ソースとともにgetConnection(username, password)を使用する場合、そのトランザクション内で最初に取得される接続は、指定したusername/passwordの値にかかわらず、後続のgetConnection()リクエストで戻されます。LLRまたは1PCの使用時には、この接続をすべてのユーザー間で共有する必要があるため、この接続では最初のgetConnection()リクエストからのプロキシ・ユーザー・セッション情報を使用する必要があります。

- XAデータ・ソースの場合は、接続をトランザクション・コンテキストとともに特定のJVMに格納し、後続のgetConnection()リクエストで前のgetConnection()リクエストのプロキシ・ユーザーとの接続を戻すことがあります。この機能をグローバル・トランザクションで使用する際は、単一データベース・ユーザー名を指定することをお薦めします。

接続収集の構成

データ・ソースで使用可能な接続が、指定された数に達した場合に解放される予約済接続の数を指定できます。収集は、指定された数の接続が常に使用可能であるようにすることに役立ち、接続の初期化を最小限にすることでパフォーマンスを向上させます。

接続収集は、アプリケーションで接続ハンドルがキャッシュされる場合に特に有用です。キャッシングは一般に、パフォーマンス上の理由で行われます。接続がトランザクションに参加するために必要な状態の初期化を最小限に抑えることができるためです。たとえば、接続はデータ・ソースから予約され、必要なセッション状態に初期化されてから、コンテキスト・オブジェクトに格納されます。この方法で接続を保留すると、接続プール内の使用可能な接続が不足することがあります。接続収集により、予約済の接続が適宜再要求され、接続の再利用が可能になります。

アプリケーションで接続収集を使用する手順は、次のとおりです。

1. 接続収集の有効化

2. 接続の収集可能化

3. 収集された接続の回復

接続収集の有効化

接続収集を有効化し、接続収集をトリガーするしきい値を指定するには、データ・ソース構成の「接続収集トリガー数」属性を使用します。たとえば、「接続収集トリガー数」を10に設定した場合、接続収集が有効になり、使用可能な接続数が10まで低下すると、データ・ソースで予約済の接続の収集が開始されます。-1の値を指定すると、接続収集が無効になります。

接続収集がトリガーされると、「接続収集最大数」により、プールに戻すことができる予約済の接続数が指定されます。実際に収集される接続数の範囲は、1から「接続収集最大数」の値までです。

Oracle WebLogic Server管理コンソール・ヘルプの接続プールの接続収集の構成に関する項を参照してください。

接続の収集可能化

接続収集が有効になると、すべての接続が収集可能になります。接続を収集可能にしない場合は、oracle.ucp.jdbc.HarvestableConnectionインタフェース内のsetConnectionHarvestable(boolean)メソッドを引数値falseで呼び出し、その接続を収集不可として明示的にマークする必要があります。

たとえば、トランザクションがトランザクション内部で使用されている場合に収集を行わないようにする場合は、次の文を使用します。

.  . .
Connection conn = datasource.getConnection();
((HarvestableConnection) conn).setConnectionHarvestable(false);
. . .

トランザクションの完了後に、setConnectionHarvestable(true)を設定して接続を収集可能としてマークすることができます。このようにして、必要に応じて接続を収集できます。接続の収集可能ステータスを調べるには、isConnectionHarvestable()を呼び出します。

収集された接続の回復

接続が収集されると、アプリケーション・コールバックが実行されて接続がクリーン・アップされます(コールバックが登録されている場合)。各接続に対して一意のコールバックを生成する必要があります。一般に、コールバックは接続オブジェクトを使用して初期化する必要があります。例:

import java.sql.Connection;
. . .
public myHarvestingCallback implements ConnectionHarvestingCallback {
private Connection conn;
mycallback(Connection conn) {
this.conn = conn;
}
public boolean cleanup() {
try {
conn.close();
} catch (Exception ignore) {
return false;
}
return true;
}
}
. . .
Connection conn = ds.getConnection();
try {
(HarvestableConnection)conn).registerConnectionHarvestingCallback(
new myHarvestingCallback(conn));
(HarvestableConnection)conn).setConnectionHarvestable(true);
} catch (Exception exception) {
// This can't be from registration – setConnectionHarvestable must have failed.
// That most likely means that the connection has already been harvested.
// Do whatever logic is necessary to clean up here and start over.
throw new Exception("Need to get a new connection");
}
. . .

注意:

次の点を考慮してください。

- 接続の収集後、アプリケーションはConnection.closeを呼び出すことができるのみです。

- アプリケーションにより接続が閉じられない場合、リーク・プロファイリングが有効になっていれば、接続が強制的に閉じられたことを示す警告が記録されます。

- コールバックで例外がスローされると、メッセージが記録され、例外は無視されます。JDBCCONNデバッグを使用すると、スタック・トレース全部を取得できます。

- クリーン・アップ・メソッドの戻り値は無視されます。

- 収集は、データ・ソース・メンテナンス処理の一部として行われます。データ・ソース・メンテナンスの間隔は、デフォルトでSecurityCacheTimeoutSecondsの値に固定されています。

接続のラベリング

アプリケーションは、接続を使用する前に、接続プールから取得した接続を初期化することがあります。初期化は様々に異なり、アプリケーション・コード内部のメソッド呼出しを必要とする単純な状態再初期化が行われる場合や、ネットワーク上のラウンド・トリップを必要とするデータベース操作が実行される場合があります。このような初期化のコストは非常に大きくなる場合があります。

接続のラベリングにより、アプリケーションは名前と値の任意の組合せを接続にアタッチできます。アプリケーションは、必要なラベルが付いた接続を接続プールからリクエストできます。特定のラベルを特定の接続状態に関連付けることにより、アプリケーションは、すでに初期化された接続をプールから取得でき、再初期化の時間とコストを節約できます。接続ラベリング機能がユーザー定義のキーまたは値に意味を与えることはありません。ユーザー定義のキーおよび値の意味は、アプリケーションによってのみ定義されます。

接続ラベリングの例として、ロール、NLS言語設定、トランザクション分離レベル、ストアド・プロシージャ・コールや、リソースによる処理の前に接続に対して実行する必要のある、コストのかかる状態初期化などがあります。

接続ラベリングはアプリケーションドリブンであり、次のインタフェースが必要です。

- oracle.ucp.jdbc.LabelableConnectionインタフェースは、接続ラベルを適用および削除したり、接続に設定されているラベルを検索する場合に使用します。

- oracle.ucp.ConnectionLabelingCallbackインタフェースは、リクエストされたラベルの付いた接続が存在するかどうかを判別するラベリング・コールバックを作成する場合に使用します。接続が存在しない場合、このインタフェースでは必要に応じて現在の接続を構成できます。

- トランザクション後も接続が保持されるようにデータ・ソースを構成する場合は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソース:構成:トランザクションに関する項を参照してください。

ラベリング・コールバックの実装

ラベリング・コールバックを使用すると、接続プールでラベル付きの接続を選択し、その接続をアプリケーションに戻す前に構成する方法を定義できます。接続ラベリング機能を使用するアプリケーションは、コールバック実装を提供する必要があります。

ラベリング・コールバックは、ラベル付きの接続がリクエストされたが、リクエストされたラベルと一致する接続がプール内に存在しない場合に使用されます。このコールバックにより、リクエストされたラベルと一致させるための再構成に必要な処理量が最も少ない接続が判別され、その接続をアプリケーションに戻す前に接続のラベルが更新されます。

注意:

接続ラベリングは、RMIを使用するクライアント・アプリケーションからはサポートされません。『Oracle WebLogic Server JDBCのプログラミング』のWebLogic RMIドライバの使用(非推奨)に関する項を参照してください。

ラベリング・コールバックの作成

ラベリング・コールバックを作成するには、アプリケーションにoracle.ucp.ConnectionLabelingCallbackインタフェースを実装します。各接続プールにつき1つのコールバックが作成されます。このインタフェースには、次に示す2つのメソッドが用意されています。

public int cost(Properties requestedLabels, Properties currentLabels);

public boolean configure(Properties requestedLabels, Connection conn);

接続プールは、プール内の使用可能な各接続に対して繰り返します。接続のたびに、costメソッドが呼び出されます。costメソッドの結果は、接続を必要な状態に再構成するために必要な見積りコストを表す整数です。値が大きいほど、接続の再構成にかかるコストは高くなります。接続プールは常に、コスト値が最も低い接続を戻します。アルゴリズムは次のとおりです。

- コスト・メソッドが接続に対して0を戻す場合、接続は一致しています(requestedLabelsとcurrentLabelsが一致しているとは限りませんので注意してください)。接続プールは見つかった接続に対してconfigureを呼び出さず、単にその接続を戻します。

- コスト・メソッドが0以外(負または正の整数)を戻す場合、接続プールは、コスト値が0の接続が見つかるか、使用可能な接続が足りなくなるまで繰り返します。

- プールがすべての使用可能な接続に対して繰り返しても、接続の最小コストがInteger.MAX_VALUE (デフォルトは2147483647)である場合、接続リクエストに適合する接続はプール内に存在しないということです。プールは新しい接続を作成し、その接続でconfigureメソッドを呼び出して、この新しい接続を戻します。プールが最大プール・サイズに達した場合(新しい接続を作成できない場合)、プールはSQL例外をスローするか、接続待機タイムアウト属性が指定されていれば待機します。

- プールがすべての使用可能な接続に対して繰り返しても、接続の最小コストがInteger.MAX_VALUEである場合、その接続でconfigureメソッドが呼び出されてから、接続が戻されます。接続数がInteger.MAX_VALUEより少ない場合、最もコストの低い接続が戻されます。

また、さらにgetRequestLabels()メソッドも含まれる拡張コールバック・インタフェースoracle.ucp.jdbc.ConnectionLabelingCallbackもあります。リクエスト・ラベルが指定されておらず、インスタンスが登録されている場合、getConnection()時にgetRequestedLabelsが呼び出されます。これは、標準のjava.sql.Datasource getConnection()メソッドが使用され、getConnection()コールでラベル情報が指定されない場合に行われます。

ラベリング・コールバックの例

次のコードは、costメソッドとconfigureメソッドの両方を実装する簡単なラベリング・コールバック実装の例を示しています。このコールバックは、特定のトランザクション分離レベルで初期化されたラベル付き接続を見つけるために使用されています。

例6-1 ラベリング・コールバック

import oracle.ucp.jdbc.ConnectionLabelingCallback;
import oracle.ucp.jdbc.LabelableConnection;
import java.util.Properties;
import java.util.Map;
import java.util.Set;
import weblogic.jdbc.extensions.WLDataSource;
class MyConnectionLabelingCallback implements ConnectionLabelingCallback {

public MyConnectionLabelingCallback()  {
}
public int cost(Properties reqLabels, Properties currentLabels)  {
// Case 1: exact match
if (reqLabels.equals(currentLabels)) {
System.out.println("## Exact match found!! ##");
return 0;
}

// Case 2: some labels match with no unmatched labels
String iso1 = (String) reqLabels.get("TRANSACTION_ISOLATION");
String iso2 = (String) currentLabels.get("TRANSACTION_ISOLATION");
boolean match =
(iso1 != null && iso2 != null && iso1.equalsIgnoreCase(iso2));
Set rKeys = reqLabels.keySet();
Set cKeys = currentLabels.keySet();
if (match && rKeys.containsAll(cKeys)) {
System.out.println("## Partial match found!! ##");
return 10;

}
// No label matches to application's preference.
// Do not choose this connection.
System.out.println("## No match found!! ##");
return Integer.MAX_VALUE;
}

public boolean configure(Properties reqLabels, Object conn)  {
try {
String isoStr = (String) reqLabels.get("TRANSACTION_ISOLATION");
((Connection)conn).setTransactionIsolation(Integer.valueOf(isoStr));
LabelableConnection lconn = (LabelableConnection) conn;

// Find the unmatched labels on this connection
Properties unmatchedLabels =
lconn.getUnmatchedConnectionLabels(reqLabels);
// Apply each label <key,value> in unmatchedLabels to conn

for (Map.Entry<Object, Object> label : unmatchedLabels.entrySet())  {
String key = (String) label.getKey();
String value = (String) label.getValue();

lconn.applyConnectionLabel(key, value);

}
} catch (Exception exc) {
return false;
}
return true;
}

public java.util.Properties getRequestedLabels() {
Properties props = new Properties();

// Set based on some application state that might be on a thread-local, http session info, etc.
String value = "value";

props.put("TRANSACTION_ISOLATION", value);

return props;
}
}

ラベリング・コールバックの登録

WLSデータ・ソースには、ラベリング・コールバックを登録するためのregisterConnectionLabelingCallback(ConnectionLabelingCallback callback)メソッドが用意されています。各接続プールに対して1つのコールバックのみを登録できます。次のコードは、MyConnectionLabelingCallbackクラス内に実装されているラベリング・コールバックを登録する方法の例を示しています。

. . .
import weblogic.jdbc.extensions.WLDataSource;
. . .
MyConnectionLabelingCallback callback = new MyConnectionLabelingCallback();
((WLDataSource)ds).registerConnectionLabelingCallback( callback );
. . .

また、管理コンソールを使用してコールバックを登録することもできます。Oracle WebLogic Server管理コンソール・ヘルプの接続ラベリング・コールバック・クラスの構成に関する項を参照してください。

ラベリング・コールバックの削除

次のいずれかの方法を使用して、ラベリング・コールバックを削除できます。

- プログラムによってコールバックを設定した場合は、次の例に示すようにremoveConnectionLabelingCallback()メソッドを使用します。

. . .
import weblogic.jdbc.extensions.WLDataSource;
. . .
((WLDataSource)ds).removeConnectionLabelingCallback( callback );
. . .

- 管理コンソールからコールバックを構成した場合は、データ・ソース構成からコールバックを削除します。Oracle WebLogic Server管理コンソール・ヘルプの接続ラベリング・コールバック・クラスの構成に関する項を参照してください。

注意:

アプリケーションでコールバックの登録および削除を行う場合、両方のメソッドではなくいずれか一方を使用する必要があります。たとえば、registerConnectionLabelingCallback(callback)を使用して接続にコールバックを登録した場合、このコールバックを削除するにはremoveConnectionLabelingCallback()を使用する必要があります。

接続ラベルの適用

予約済の接続に対してラベルを適用するには、LabelableConnectionインタフェースからのapplyConnectionLabelメソッドを使用します。1つの予約済の接続に対して、任意の数のラベルを累積的に適用できます。ラベルが接続に適用されるたびに、指定したキーと値の組合せが既存のラベル・コレクションに追加されます。いずれのキーに対しても、最後に適用された値のみが保持されます。

注意:

予約済の接続にラベルを適用する前に、ラベリング・コールバックを接続プールに登録しておく必要があります。そうしない場合、ラベリングは無視されます。第6章「ラベリング・コールバックの作成」を参照してください。

次の例は、トランザクション分離レベルで接続を初期化して、その接続にラベルを適用する方法を示しています。

. . .
String pname = "property1";
String pvalue = "value";
Connection conn = ds.getConnection();
// initialize the connection as required.
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
((LabelableConnection) conn).applyConnectionLabel(pname, pvalue);
. . .

ラベル付き接続の予約

WLSデータ・ソースには2つのgetConnectionメソッドが用意されています。これらは、プールからラベル付き接続を予約するために使用されます。これらのメソッドを次に示します。

public Connection getConnection(java.util.Properties labels) throws SQLException;

public Connection getConnection(String user, String password, java.util.Properties labels) throws SQLException;

これらのメソッドでは、ラベルがPropertiesオブジェクトとしてgetConnectionメソッドに渡される必要があります。次の例は、property1値のラベルが付いた接続を取得する方法を示しています。

. . .
import weblogic.jdbc.extensions.WLDataSource;
. . .
String pname = "property1";
String pvalue = "value";
Properties label = new Properties();
label.setProperty(pname, pvalue);
. . .
Connection conn = ((WLDataSource)ds).getConnection(label);
. . .

標準のjava.sql.Datasource getConnection()メソッドを使用することも可能です。この場合、getConnection()コールにラベル情報は提供されません。インタフェースoracle.ucp.jdbc.ConnectionLabelingCallbackが使用されます。

java.util.Properties getRequestedLabels();

リクエストされたラベルが指定されておらず、インスタンスが登録されている場合、getConnection()時にgetRequestedLabelsが呼び出されます。

一致しないラベルのチェック

1つの接続に複数のラベルがあり、それぞれが必要な基準に基づいて接続を一意に識別していることがあります。リクエストされたラベルと一致した接続ラベルおよび一致しなかった接続ラベルを確認するために、getUnmatchedConnectionLabelsメソッドが使用されます。このメソッドは、複数のラベルを持つ接続が接続プールから予約された後に使用されます。通常は、ラベリング・コールバックによって使用されます。次のコードは、一致しないラベルをチェックする例を示しています。

. . .
String pname = "property1";
String pvalue = "value";
Properties label = new Properties();
label.setProperty(pname, pvalue);
. . .
Connecion conn = ((WLDataSource)ds).getConnection(label);
Properties unmatched =
((LabelableConnection)connection).getUnmatchedConnectionLabels (label);
. . .

接続ラベルの削除

接続からラベルを削除するために、removeConnectionLabelメソッドが使用されます。このメソッドは、ラベル付き接続が接続プールから予約された後に使用されます。次のコードは、接続ラベルを削除する例を示しています。

. . .
String pname = "property1";
String pvalue = "value";
Properties label = new Properties();
label.setProperty(pname, pvalue);
Connection conn = ((WLDataSource)ds).getConnection(label);
. . .
((LabelableConnection) conn).removeConnectionLabel(pname);
. . .

7 JDBCデータ・ソースのトランザクション・オプション

この章では、WebLogicデータ・ソースのXA、XA以外およびグローバル・トランザクションのオプションについて説明します。

管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に基づき、自動的に特定のトランザクション・オプションを選択します。

- XAドライバの場合、システムは自動的に、グローバル・トランザクション処理のための2フェーズ・コミット・プロトコルを選択します。

- 非XAドライバの場合、ローカル・トランザクションは定義によってサポートされており、WebLogic Serverは以下のオプションを提供します。
「グローバル・トランザクションのサポート」 : (デフォルトで選択) XAドライバを選択していなくても、グローバル・トランザクションでデータ・ソースからの接続を使用する場合には、このオプションを選択します。詳細については、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。

「グローバル・トランザクションのサポート」を選択した場合は、グローバル・トランザクションを処理するときに、WebLogic Serverがトランザクション・ブランチに使用するプロトコルも選択する必要があります。

- 「ロギング・ラスト・リソース」 :このオプションを使用すると、接続が使用されているトランザクション・ブランチが、トランザクションの最後のリソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によって、グローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションでは、「2フェーズ・コミットのエミュレート」よりもパフォーマンス上のメリットとデータの安全性が得られますが、いくつかの制限事項もあります。「ロギング・ラスト・リソース・トランザクション・オプションについて」を参照してください。

注意:

ロギング・ラスト・リソースは、マルチ・データ・ソースで使用されるデータ・ソースについてはサポートされていません。ただし、「LLRデータ・ソースに関する管理上の考慮事項と制限事項」で説明するように、Oracle RACバージョン10Gリリース2 (10GR2)以降と一緒に使用する場合を除きます。

- 2フェーズ・コミットのエミュレート: このオプションを使用すると、接続が使用されているトランザクション・ブランチは、トランザクションの準備フェーズに対して常に成功を戻します。パフォーマンス上のメリットはありますが、いくつかの失敗の状況ではデータにリスクがあります。このオプションは、アプリケーションがヒューリスティックな状況を許容できる場合にのみ選択します。「2フェーズ・コミットのエミュレート・トランザクション・オプションについて」を参照してください。

- 1フェーズ・コミット: (デフォルトで選択済み)このオプションを使用すると、データ・ソースからの接続がグローバル・トランザクションの唯一の参加者となることができ、トランザクションは1フェーズ・コミットの最適化を使用して完了します。トランザクションに複数のリソースが参加している場合、トランザクション・マネージャが1PCリソースに対してXAResource.prepareを呼び出すと、例外がスローされます。

この項は、次の情報を含みます。

- 非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化

- ロギング・ラスト・リソース・トランザクション・オプションについて

- 「2フェーズ・コミットのエミュレート」トランザクション・オプションについて

非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化

アプリケーションでグローバル・トランザクションを使用する場合、JDBCデータ・ソース内にデータベース接続を作成するのにXA JDBCドライバを使用する必要があります。XAドライバが使用できないデータベースの場合、またはXAドライバを使用しないことを選択した場合は、データ・ソース内でグローバル・トランザクションのサポートを有効化する必要があります。また、アプリケーションが、以下の条件に適合する場合も、グローバル・トランザクションのサポートを有効化する必要があります。

- トランザクションの管理にWebLogic ServerのEJBコンテナを使用します。

- 1回のトランザクション中に複数のデータベース更新を含みます。

- トランザクション中にデータベース、Java Messaging Service (JMS)など複数のリソースにアクセスします。

- 複数のサーバー(クラスタリングされた、または、クラスタリングされていない)上で同一のデータ・ソースを使用します。

EJBアーキテクチャでは、データベース処理を行っている複数のEJBが単一のトランザクションの一部として呼び出されるのは、よくあることです。XAがない場合、これを行う唯一の方法は、すべてのトランザクション参加者がまったく同じデータベース接続を使用することです。グローバル・トランザクションを有効化して、「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」のどちらかを選択すると、WebLogic Serverは内部的にJTSドライバを使用して、EJB間で接続を明示的に渡さなくても、すべてのEJBが同じトランザクション・コンテキスト内で確実に同じデータベース接続を使用するようにします。

複数のEJBが1つのトランザクションに参加しており、かつ、データベース接続にXA JDBCドライバを使用しない場合は、以下のオプションを使用してデータ・ソースを構成します。

- 「グローバル・トランザクションのサポート」を選択

- 「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」が選択されています

このように構成することによって、同じトランザクション内のすべてのデータベース作業で同じデータベース接続を内部的に使用することがJTSドライバに強制されます。

XA (XAドライバが必須)では、EJBはトランザクションの各部分に対して、別々のデータベース接続を使用できます。WebLogic Serverは、2フェーズ・コミット・プロトコルを使用してトランザクションを調整します。それにより、トランザクションがすべて完了するか、まったく完了しないかであることが保証されます。

ロギング・ラスト・リソース・トランザクション・オプションについて

WebLogic Serverでは、JDBCデータ・ソースを通じてのロギング・ラスト・リソース(LLR)トランザクションの最適化をサポートしています。LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。LLRは、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLRリソースは、トランザクション処理にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。

LLRの最適化により、次のようにしてパフォーマンスが向上します。

- XA JDBCドライバがデータベースに接続する必要がなくなります。XA JDBCドライバは、一般的に、非XA JDBCドライバに比べて効率が低くなります。

- トランザクションを完了させるまでの処理手順の数が少なくなり、それによりネットワーク・トラフィックとディスクI/O数も減少します。

- データベース・レベルでのXA処理の必要性がなくなります。

LLR用に構成されたデータ・ソースからの接続が、2フェーズ・コミット(2PC)グローバル・トランザクションに参加している場合、WebLogic Serverトランザクション・マネージャは次の処理によって、トランザクションを完了させます。

- 他のすべての(XA対応の)トランザクション参加リソースに対するprepareの呼出し。

- (ファイル・ベースのトランザクション・ログではなく) LLR参加リソースの表へのコミット・レコードの挿入。

- LLR参加リソースのローカル・トランザクション(トランザクション・コミット・レコードの挿入とアプリケーションのSQL処理の双方を含む)のコミット。

- その他すべてのトランザクション参加リソースに対するcommitの呼出し。

1フェーズ・コミット(1PC)のグローバル・トランザクションの場合、LLRはローカル・トランザクションを使用してデータベース操作を完了させることによって、XAオーバーヘッドを排除しますが、2PCトランザクション・レコードはデータベースへ書き込まれません。

ロギング・ラスト・リソースの最適化により、LLR参加リソースに対するコミット・レコードが書き込まれ、データの整合性が維持されます。ローカル・トランザクション・コミットの最中にトランザクションが失敗した場合、WebLogic Serverトランザクション・マネージャは、他のすべてのトランザクション参加リソースに対してトランザクションをロールバックします。失敗からリカバリするため、WebLogic Serverトランザクション・マネージャはデフォルトのストアにある他のトランザクション・ログ・ファイルと一緒にLLRリソース上のトランザクション・ログを読み取り、必要なすべてのトランザクション処理を完了させます。XA参加リソースと関連付けられた処理は、コミット・レコードが存在すればコミットされます。そうでなければ、処理はロールバックされます。

LLR対応のJDBCデータ・ソースを作成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。ロギング・ラスト・リソース・トランザクション処理の詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。

ロギング・ラスト・リソース最適化を使用する利点

使用している環境によっては、パフォーマンス上の利点を得るために、トランザクション処理用として、2フェーズ・コミット・プロトコルのかわりにLLRトランザクション・プロトコルを検討する必要があります。LLRトランザクション・プロトコルには、次の利点があります。

- 非XA JDBCドライバ、そしてXA対応でないデータベースも、2フェーズ・コミット・トランザクションに安全に参加できるようになります。

- XAプロトコルがデータベースで使用されなくなります。

- JDBC XA接続よりもパフォーマンスが向上します。

- データベースの行ロックが保持される時間が短縮されます。

- 他のXA作業より常に先に、データベース作業をコミットします。XAトランザクションでは、これらの操作は並列にコミットされます。したがって、たとえばJMS送信がトランザクションに参加している場合、JMSメッセージはデータベース処理のコミット前に配信されます。LLRでは、ローカル・トランザクションにおけるデータベース処理は、他のすべてのトランザクション処理より前に完了されます。

- JDBCデータ・ソースの「2フェーズ・コミットのエミュレート」オプションと異なり、ヒューリスティック障害のリスクが増大しません。

注意:

LLR最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLRでの読取り操作では、XAでの読取り操作と比べて、若干パフォーマンスが低下します。

LLRパフォーマンス・チューニングの詳細は、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。

ロギング・ラスト・リソース・トランザクション最適化の有効化

LLRトランザクション最適化を有効化するには、JDBCデータ・ソースをロギング・ラスト・リソース・トランザクション・プロトコルで作成して、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。

Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。

LLRデータ・ソースに関するプログラミング上の考慮事項と制限事項

アプリケーションで、LLRを利用可能なデータ・ソースからのJDBC接続を、その他の任意のデータ・ソースからのJDBC接続と同じように使用します。トランザクションの開始後、JNDIツリーでデータ・ソースをルックアップし、その後データ・ソースからの接続をリクエストします。ただし、LLR最適化が行われていると、WebLogic Serverは接続のリクエストを内部で管理し、トランザクション処理をXAトランザクションとは異なったやり方で扱います。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。

次に注意してください。

- LLRデータ・ソースでプログラミングを行う場合は、LLRデータ・ソースに対してgetConnectionを呼び出す前に、グローバル・トランザクションを開始する必要があります。グローバル・トランザクションを開始する前にgetConnectionを呼び出した場合、接続は独立したものとなり、その後で開始されるグローバル・トランザクションに関連付けされません。接続はautoCommit(true)モードで動作します。このモードでは、すべての更新がそのまま自動的にコミットされます。アプリケーション・コードでautoCommitの状態を明示的にfalseに設定して、独自のローカル・トランザクションを明示的に管理しない限り、更新をロールバックする方法はありません。

- 1つのトランザクションには、1つの内部JDBC LLR接続しか予約されません。その接続が、トランザクション処理全体を通して使用されます。

- 予約済みの接続は、常にトランザクションのコーディネータ・サーバーにホストされています。データ・ソースのターゲットには、必ずコーディネートしているサーバーまたはクラスタを指定してください。また、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。

- 同一名のデータ・ソースからのトランザクションでの追加のJDBC接続リクエストについては、後続の接続リクエストが、データ・ソースの別のインスタンス(つまり、最初のリクエストに対する接続を供給した元のデータ・ソースとは異なるサーバー上にデプロイされているデータ・ソース)に対して行われていたとしても、操作は予約された接続から元の接続リクエストにルーティングされます。次に注意してください。

- ルーティングされたLLR接続は、ローカルでホストされているXA接続よりも、機能やパフォーマンスの点で劣ります。(「複数サーバー構成における非XAリソースのパフォーマンス低下の可能性」を参照)。

- 接続リクエストをルーティングすると、同時トランザクションの数が制限されます。同時LLRトランザクションの最大数は、コーディネータのJDBC LLRデータ・ソースの構成済サイズ(MaxCapacity)と同じです。

- ルーティングされた接続は、ローカル接続より機能が低下しており、その結果、失敗する可能性があります。特に、問合せResultSet内のシリアライズできないカスタム・データ型は失敗する可能性があります。

- 単一LLRデータ・ソースのインスタンスのみが、特定のトランザクションに参加できます。単一LLRデータ・ソースは、複数のWebLogicサーバーに対してインスタンスを持つ場合があり、2つのデータ・ソースは、構成された名前が同じ場合、同一とみなされます。複数のLLRデータ・ソース・インスタンスが検出され、それらが同じデータ・ソースのインスタンスでない場合、トランザクション・マネージャはトランザクションをロールバックします。

- weblogic.transaction.nonxa.NonXAResourceインタフェースを実装するリソース・アダプタ(コネクタ)は、LLRリソースもまた参加しているグローバル・トランザクションには参加できません。どちらも、トランザクションの最後のリソースである必要があるからです。双方のリソース・タイプが同じトランザクションに参加している場合、競合が検出されると、トランザクションのcommit()メソッドが、javax.transaction.RollbackExceptionをスローします。

- LLR接続では、データベース処理に別個のローカル・トランザクションを使用するため、XA接続を使用して同じデータベースに加えられた変更(および保持されるロック)はすべて、全処理が同じグローバル・トランザクション内で発生するとしても、LLR処理の最中には認識されません。場合によっては、これによりデータベースにデッドロックが発生します。単一のグローバル・トランザクションにおいて、同一データベース内でXA処理とLLR処理を組み合わせることはできません。

- LLRデータ・ソースからの接続は、リモート・オブジェクト・リクエスト・ブローカやTuxedoによって開始されたトランザクションなど、外部トランザクション・マネージャが調整するトランザクションには参加できません。

- グローバル・トランザクションは、LLRデータ・ソースと同じ名前のデータ・ソースを含む別の従来ドメインまで及ぶようにはできません。

- JDBC LLR 2PCトランザクションでは、トランザクション・データがLLR表内に収まるには大きすぎる場合、トランザクションはコミット中にロールバック例外がスローされて失敗します。これが起こり得るのは、アプリケーションがトランザクション処理中に多くのトランザクション・プロパティを追加した場合です。(『Oracle WebLogic Server JTAのプログラミング』のOracle WebLogic JTAの拡張に関する項を参照してください)。これが起こった場合、データベース管理者はより大規模な列を持つ表を手動で作成できます。

LLRデータ・ソースに関する管理上の考慮事項と制限事項

LLR対応のJDBCデータ・ソースを構成する際は、次の要件と制限を考慮してください。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。

- 1つのサーバーにつき、LLR表は1つです。

- 複数のLLRデータ・ソースが1つの表を共有することがあります。

- 表が見つからない場合、WebLogic Serverは自動的に表を作成します。

- デフォルト名はWL_LLR_SERVERNAMEです。表名を構成するには、管理コンソールの詳細オプションの「サーバー」>「構成」>「一般」を選択してください。Oracle WebLogic Server管理コンソール・ヘルプの「サーバー」:「構成」:「一般」を参照してください。

- データベースが停止している場合や、起動中にLLR表にアクセスできない場合、サーバーは起動しません。

- 複数のサーバーが同じLLR表を共有することは許されません。起動の際には、ドメインおよびサーバーの名前が、作成された時点の表に格納されたドメインおよびサーバーの名前と一致するかどうかが確認されます。WebLogic Serverは、複数のサーバーが同じLLR表を共有していることを検出すると、1つまたは複数のサーバーを停止します。

- LLRでは、サーバー移行およびトランザクション・リカバリ・サービス移行がサポートされます。トランザクション・リカバリ・サービス移行を使用するには、各LLRリソースが、クラスタまたはクラスタ内の候補サーバーのセットに対してターゲット指定されている必要があります。『Oracle WebLogic Server JTAのプログラミング』の失敗したクラスタ化サーバーのトランザクションのリカバリに関する項を参照してください。

- LLRトランザクション・オプションは、JDBCアプリケーション・モジュールでは使用できません。

- マルチ・データ・ソースを使用する場合は、LLRトランザクション・オプションはOracle RACバージョン10Gリリース2 (10GR2)以降で、次の設定でのみ使用できます。

- すべてのWebLogicアプリケーション・データベースのJDBCの対話でREAD_COMMITTEDトランザクション分離レベル(デフォルト)を使用する必要があります。

- Oracle RACのMAX_COMMIT_PROPAGATION_DELAYの値は0 (デフォルト)に設定する必要があります。

マルチ・データ・ソースでのLLRの使用はOracle RACでのみサポートされます。それ以外のマルチ・データ・ソース構成ではLLRはサポートされません。

- LLRデータ・ソース上で資格証明マッピングを使用する場合、マップされるユーザーはすべて、LLR表への書込み権限を持っている必要があります。

- JDBC XAドライバを使用して、JDBC LLRデータ・ソース内にデータベース接続を作成することはできません。JDBC LLRデータ・ソースで使用されるJDBCドライバがXAをサポートしている場合、警告メッセージがログに記録され、データ・ソースはLLRリソースではなく、完全なXAリソースとして、トランザクションに参加します。

- LLRリソース用トランザクション統計は、「NonXAResource」の下に記録されます。Oracle WebLogic Server管理コンソール・ヘルプの非XAリソース用トランザクション統計の表示に関する項を参照してください。

- Sybase DBMSでLLRを使用する場合、SybaseのJDBCドライバでは、標準のJDBCメタデータ・メソッドを実装するために、特定のJDBCストアド・プロシージャをDBMSにインストールする必要があります。詳細は、Sybase jConnectのドキュメントを参照してください。

2フェーズ・コミットのエミュレート・トランザクション・オプションについて

JDBCデータ・ソースで分散トランザクションのサポートが必要であるにもかかわらず、DBMSで利用できるXA対応のドライバがない場合は、データ・ソースに対して非XAドライバ用の2フェーズ・コミットのエミュレートオプションを選択することにより、データ・ソースからの接続が参加しているトランザクションについて、データ・ソースが2フェーズ・コミットをエミュレートするようになります。このオプションは、データ・ソース構成の「構成」>「全般」タブの詳細オプションです。

「2フェーズ・コミットのエミュレート」が選択されている(EnableTwoPhaseCommitがtrueに設定されている)場合、非XA JDBCリソースはXAResource.prepare()メソッド呼出し中に常にXA_OKを返します。リソースは、後続のXAResource.commit()またはXAResource.rollback()の呼出しに応答して、ローカル・トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック失敗の結果、アプリケーション・データは矛盾した状態のまま残される場合があります。

「2フェーズ・コミットのエミュレート」オプションが管理コンソールで選択されていない(EnableTwoPhaseCommitがfalseに設定されている)場合、非XA JDBCリソースにより、XAResource.prepare()が失敗します。トランザクションに参加するリソースが1つだけの場合、1フェーズの最適化がXAResource.prepare()をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットされます。

注意:

「非XAドライバ用の2フェーズ・コミットのエミュレート」オプションを使用していると、データの整合性が損なわれるおそれがあります。「2フェーズ・コミットのエミュレート」オプションを使用するかわりに、XA対応のJDBCドライバ、または「ロギング・ラスト・リソース」オプションを使用することをお薦めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。

この非XAのJDBCドライバのサポートは、WebLogic Serverがその機能をサポートするために内部的にWebLogic JTSドライバを使用するので、多くの場合、「JTSドライバ」と呼ばれます。WebLogic JTSドライバの詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogic JTSドライバの使用に関する項を参照してください。

非XAドライバを使用して2フェーズ・コミットをエミュレートする際の制限およびリスク

WebLogic Serverでは、「2フェーズ・コミットのエミュレート」データ・ソース・トランザクション・オプションで非XA JDBCリソースのグローバル・トランザクションへの参加をサポートしていますが、このリソースを使用するためにアプリケーションを設計する際に考慮すべき制限事項があります。非XAドライバはXA/2PCに従わず、1フェーズのコミットおよびロールバック処理のみをサポートするため、WebLogic Serverは(JTSドライバを介して)、トランザクション・マネージャによって制御されるトランザクションにリソースが参加できるように、譲歩する必要があります。

「2フェーズ・コミットのエミュレート」オプションを使用する前に、以下の制限およびリスクを考慮してください。

ヒューリスティックな終了とデータの矛盾

非XAリソースで2フェーズ・コミットのエミュレートを選択する場合(enableTwoPhaseCommit = true)、非XAリソースに対するトランザクションの準備フェーズは常に成功します。したがって、非XAリソースは2フェーズ・コミット(2PC)プロトコルに実際には参加していないため、失敗しやすくなります。準備フェーズ後に非XAリソースで失敗が発生した場合、XAトランザクションの参加コンポーネントがトランザクションをコミットする一方で、非XAリソースはトランザクションをロールバックする可能性があり、ヒューリスティックな終了とデータの矛盾を招きます。

データの整合性が失われるおそれがあるため、2フェーズ・コミットのエミュレートのオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。

保留中のトランザクションを回復できない

非XAドライバはローカル・データベースのトランザクションのみを操作するため、外部トランザクション・マネージャに関して、トランザクションがデータベース内で保留中の状態にあるという概念はありません。非XAリソースのXAResource.recover()が呼び出されると、コミットまたはロールバックする必要のあるトランザクションが存在する場合でも、常にXid (トランザクションID)の空のセットが返されます。そのため、グローバル・トランザクションで非XAリソースを使用するアプリケーションは、システムの障害から回復してデータの整合性を維持することができません。

複数サーバー構成における非XAリソースのパフォーマンス低下の可能性

WebLogic Serverは特定のJDBC接続に関連付けられたデータベース・ローカル・トランザクションに依存して、非XAリソースのグローバル・トランザクションへの参加をサポートしているため、同じJDBCデータ・ソースが、複数のWebLogic Serverインスタンス上にグローバル・トランザクション・コンテキストを持つアプリケーションからアクセスされる場合、JTSドライバは常に、トランザクション内のアプリケーションによって確立される最初の接続にJDBCの処理をルーティングします。たとえば、あるサーバーでアプリケーションがトランザクションを開始して非XA JDBCリソースにアクセスし、別のサーバーにRMI (Remote Method Invocation)呼出しを行って、同じ基底のJDBCドライバを使用するデータ・ソースにアクセスすると、JTSドライバは、そのリソースには別のサーバー上のトランザクションに関連付けられた接続があることを認識して、RMIのリダイレクトを最初のサーバーの実際の接続に設定します。接続に対するすべての操作は、最初のサーバーで確立された1つの接続上で行われます。この動作では、リモート接続を設定してRMI呼出しを物理的な接続に対して行うことに関するオーバーヘッドが生じるため、パフォーマンスが低下する可能性があります。

複数の非XA登録

グローバル・トランザクションで1つ以上の非XAリソースを使用する場合、非アトミック出力ではJTA SystemExceptionsが確認される可能性があります。非アトミック出力およびSystemExceptionsの確率は、2フェーズ・エミュレートのデータ・ソース登録数によって上昇する傾向があります。

注意:

異なるバージョンのドメインにわたってJTAトランザクションで2フェーズ・エミュレートのデータ・ソースを使用することは、サポートされていません。

8 JDBCデータ・ソースを保護するためのロールおよびポリシーの使用

この章では、WebLogic ServerでJDBCデータ・ソースを保護するためにロールおよびポリシーがどのように使用されるかを説明します。

- JDBCリソースのセキュリティ・ポリシーの設定

- JDBC MBeanのセキュリティ・ロール

JDBCリソースのセキュリティ・ポリシーの設定

オプションで、JDBCデータ・ソースへのアクセスを制限できます。WebLogic Serverでは、WebLogicリソースに誰がアクセスできるかはキュリティ・ポリシーによって決まります。WebLogicリソースとユーザー・グループまたはロールの間に関連付けを定義すると、セキュリティ・ポリシーが作成されます。WebLogicリソースにセキュリティ・ポリシーが割り当てられている場合、それに保護が設定されます。すべてのWebLogic Serverリソースのセキュリティの設定方法については、Oracle WebLogic Server管理コンソール・ヘルプのロールとポリシーを使用したリソースの保護に関する項を参照してください。サーバー・リソースのセキュリティについては、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースのセキュリティ」に関する項を参照してください。

管理者がJDBCデータ・ソースに対して実行できるアクションを制限できる管理者用メソッドを割り当てることによって、JDBCリソース操作を保護できます。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のJavaデータベースの接続性(JDBC)リソースに関する項を参照してください。

JDBC MBeanのセキュリティ・ロール

JDBC MBeanで許容されるロールはAdminとDeployerのみです。以下の節では、JDBC MBeanに定義されるセキュリティ・ロールに関する情報が提供されます。

- JDBCドメイン構成MBean

- JDBCシステム・モジュールMBean

WebLogic Serverのデフォルトのセキュリティ設定の詳細は、Oracle WebLogic Server MBeanリファレンスのMBeanのデフォルトのセキュリティ・ポリシーに関する項を参照してください。

JDBCドメイン構成MBean

次のドメイン構成JDBC MBeanには、デフォルトのセキュリティ設定をオーバーライドする設定があります。

- JDBCConnectionPoolMBean (非推奨)

- JDBCDataSourceFactoryMBean (非推奨)

- JDBCDataSourceMBean (非推奨)

- JDBCMultiPoolMBean (非推奨)

- JDBCSystemResourceMBean

- JDBCTxDataSourceMBean (非推奨)

Oracle WebLogic Server MBeanリファレンスのドメイン構成MBeanに関する項を参照してください。

JDBCシステム・モジュールMBean

次のシステム・モジュールJDBC MBeanには、デフォルトのセキュリティ設定をオーバーライドする設定があります。

- JDBCConnectionPoolParamsBean

- JDBCDataSourceBean

- JDBCDataSourceParamsBean

- JDBCDriverParamsBean

- JDBCPropertiesBean

- JDBCPropertyBean

- JDBCXAParamsBean

Oracle WebLogic Server MBeanリファレンスのシステム・モジュールMBeanに関する項を参照してください。

9 サーバーおよびクラスタへのデータ・ソースのデプロイ

この章では、サーバーおよびクラスタにデータ・ソースをデプロイする方法について説明します。

- サーバーおよびクラスタへのデータ・ソースのデプロイ

- レスポンス不能なデータベースによって生じるサーバー起動時のハングの最小化

サーバーおよびクラスタへのデータ・ソースのデプロイ

データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイメント・ターゲットとして選択します。データ・ソースがサーバーにデプロイされると、WebLogic Serverはデータ・ソース内のデータベース接続のプールを含む、サーバー上のデータ・ソースのインスタンスを作成します。クラスタにデータ・ソースをデプロイする場合、クラスタ内の各サーバー上にデータ・ソースのインスタンスが作成されます。

手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのターゲット指定に関する項を参照してください。

応答しないデータベースによって生じるサーバー起動時のハングの最小化

サーバー起動時に、WebLogic Serverはサーバーにデプロイされたデータ・ソース内にデータベース接続を作成しようとします。データベースにアクセスできない場合、サーバーの起動は、長時間に渡ってSTANDBY状態でハングする可能性があります。これはWebLogic Serverスレッドが、JDBCドライバ・コード内部でデータベース・サーバーからの応答を待機しながらハングすることに起因しています。ハングの継続時間は、WebLogic Serverマシン上のJDBCドライバおよびTCP/IPタイムアウトの設定に左右されます。

この問題を回避するため、WebLogic ServerではServerMBean上のJDBCLoginTimeoutSeconds属性を用意しています。この属性の値を指定すると、値はjava.sql.DriverManager.setLoginTimeout()に渡されます。データベース接続の作成に使用されているJDBCドライバがsetLoginTimeoutメソッドを実装している場合、データベース接続作成が試行されるまでの待機時間は、指定されたタイムアウトの長さのみとなります。

10 データ・ソース接続プールのチューニング

この章では、アプリケーションおよびシステムのパフォーマンスを向上させるために、WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を適切にチューニングする方法について説明します。

以下の節では、JDBCデータ・ソースの接続プールのチューニング・オプションについて説明します。

- 文キャッシュによるパフォーマンスの向上

- データ・ソースの接続テスト・オプション

- 接続作成の再試行の有効化

- 接続を待機する接続リクエストの有効化

- リークされた接続の自動回復

- 正しい接続数でのサーバー・ロック回避

- 文タイムアウトによる文の処理時間の制限

- Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

- 未包装データ型オブジェクトの使用方法

文キャッシュによるパフォーマンスの向上

アプリケーションまたはEJBでプリペアド文や呼出し可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信およびデータベース・サーバー自体においてかなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Serverではアプリケーションで使用するプリペアド文および呼出し可能文をキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリペアド文や呼出し可能文を再利用することで、データベース・サーバーのCPUの使用率が下がり、現在の文のパフォーマンスが向上するため、CPUサイクルを他のタスクに割り当てることができます。

データ・ソースの各接続には、接続に使用するプリペアド文および呼出し可能文のキャッシュが個別に備わっています。しかし、文キャッシュの構成は、データ・ソースごとに行います。つまり、データ・ソース内の各接続の文キャッシュは、そのデータ・ソースについて指定された文キャッシュ・オプションを使用しますが、各接続は、独自に文をキャッシュします。文キャッシュの構成オプションには、次のようなものがあります。

- 「文キャッシュの種類」 - 文キャッシュ内に格納する文を決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください。

- 文キャッシュ・サイズ - 各接続のキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください。

管理コンソールを使用してデータ・ソース用の文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの文キャッシュの構成を参照してください。

文キャッシュのアルゴリズム

文キャッシュのタイプ(つまりアルゴリズム)は、データ・ソースの各接続のキャッシュに格納するプリペアド文と呼出し可能文を決定します。次のオプションから選択できます。

- LRU (最長時間未使用)

- 固定

LRU (最長時間未使用)

「LRU」 (Least Recently Used、デフォルト)を文キャッシュのタイプとして選択すると、WebLogic Serverは接続で使用されるプリペアド文および呼出し可能文を、文キャッシュ・サイズに到達するまでキャッシュします。アプリケーションがConnection.prepareStatement()を呼び出すと、WebLogic Serverはその文が文キャッシュに格納されているかどうかを確認します。格納されている場合、WebLogic Serverはキャッシュされていた文を(それがすでに使用されていない場合)戻します。文がキャッシュ内に存在せず、キャッシュが満杯(キャッシュ内の文の数 = 文キャッシュ・サイズ)の場合、WebLogic Serverはキャッシュ内で最近の使用頻度が最も低い既存の文を特定し、キャッシュ内のその文を新しい文と入れ替えます。

WebLogic ServerのLRU文キャッシュ・アルゴリズムは、近似LRU方式を使用します。

固定

「固定」を文キャッシュのタイプとして選択すると、WebLogic Serverは接続で使用されるプリペアド文および呼出し可能文を、文キャッシュのサイズに到達するまでキャッシュします。追加の文が使用された場合、これらはキャッシュされません。

この文キャッシュ・アルゴリズムでは、ほとんど使われない文を意図せずキャッシュしてしまうことがあります。多くの場合、LRUアルゴリズムが使用されます。ほとんど使われない文が、キャッシュ内で最終的には頻繁に使われる文に置き換えられるからです。

文キャッシュ・サイズ

「文キャッシュ・サイズ」属性は、データ・ソースの各インスタンスの各接続にキャッシュするプリペアド文と呼出し可能文の総数を決定します。文をキャッシュすることで、システムのパフォーマンスが向上します。ただし、DBMSでオープンなプリペアド文と呼出し可能文がどのように処理されるかを考慮する必要があります。多くの場合、DBMSは開いている各文について、カーソルを保持します。これは、文キャッシュ内のプリペアド文および呼出し可能文に対して適用されます。キャッシュされた文の数が多すぎると、データベース・サーバー上のオープン・カーソル数の上限を超えてしまうことがあります。

たとえば、10個の接続があるデータ・ソースが2つのサーバーにデプロイされている場合、「文キャッシュ・サイズ」を10 (デフォルト値)に設定すると、キャッシュされた文に対してデータベース・サーバー上で200個(10 x 2 x 10)のカーソルを開く可能性があります。

文キャッシュに関する制限

文キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。文キャッシュを使用する場合は、以下の制限に留意してください。

ここに示す以外にも、文のキャッシングに関連した問題が存在する可能性があります。プリペアド文または呼出し可能文に関連するシステムでエラーが見つかった場合は、文キャッシュのサイズを0に設定して文のキャッシングをオフにし、問題がプリペアド文のキャッシングに起因するものかどうかをテストする必要があります。

データベース変更後の文の呼出しにおけるエラーの発生

キャッシュ内に格納されたプリペアド文は、プリペアド文のキャッシュ時に特定のデータベース・オブジェクトを参照します。キャッシュに格納されたプリペアド文で参照されるデータベース・オブジェクトに対して、何らかのDDL (データ定義言語)処理を実行すると、それらの文は次に実行したときに失敗する可能性があります。たとえば、select * from empなどの文をキャッシュしてから、emp表を削除して再作成した場合、その文が準備されたときに存在したemp表はなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。

同様に、プリペアド文は、キャッシュされた時点でデータベース内の表の各列のデータ型にバインドされます。表の列を追加、削除、または再配列すると、キャッシュに格納されているプリペアド文は、再び実行されたときに失敗するおそれがあります。

これらの制限は、DBMSの動作に依存します。

プリペアド文におけるsetNullの使用

setNullバインド変数を使用するプリペアド文をキャッシュする場合、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、null以外の値で実行したときにデータが切り捨てられたり、文が失敗したりするおそれがあります。

java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)

かわりに、次を使用します。

if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)

キャッシュ内の文によるデータベース・カーソルの予約

WebLogic Serverでキャッシュされたプリペアド文または呼出し可能文は、データベースのカーソルを開くことができます。キャッシュされた文の数が多すぎると、接続のためのオープン・カーソル数の上限を超えてしまうことがあります。接続のためのオープン・カーソル数の上限を超えないようにするには、データベース管理システムの上限を変更するか、またはデータ・ソースの文キャッシュのサイズを低減します。

データ・ソースの接続テスト・オプション

データ・ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Serverには、2種類の基本的なテスト方法があります。

- WebLogic Serverがデータベース接続の正常な状態を確認できるよう、データ・ソースのオプションで構成する、自動テスト。

- データ・ソースのトラブルシューティング用に行える、手動テスト。

次の節では、自動接続テストのオプションについて説明します。手動接続テストの詳細については、「データ・ソースおよびデータベース接続のテスト」を参照してください。

データ・ソースの自動テスト・オプションを構成するには、JDBCConnectionPoolParamsBeanを使用してWLSTから、または管理コンソールから次のオプションを設定します。

- 「テスト頻度」: (JDBCConnectionPoolParamsBeanのTestFrequencySeconds)この属性では、未使用の接続がテストされる秒間隔を指定します。WebLogic Serverは未使用の接続をテストし、フォルトのある接続を閉じ、別の接続に置き換えます。「テスト対象の表名」も設定しておく必要があります。

- Test Reserved Connections: (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve)このオプションを有効にすると、クライアントに与える前に各接続をテストできます。これにより、リクエストに多少の遅延が発生する場合がありますが、接続が正常であることは保証します。「テスト対象の表名」も設定する必要があります。

- 「テスト対象の表名」: (JDBCConnectionPoolParamsBeanのTestTableName)この属性では、接続テストで使用される表名を指定します。標準的なテストのかわりに、テストとして実行するSQLコードを指定することもできます。「SQL」と入力し、その直後にスペース、次に実行するSQLコードを入力します。「テスト対象の表名」は、データベース接続のテストを有効にするための必須の属性です。

- 「アイドル・プール接続を信頼する秒数」: (JDBCConnectionPoolParamsBeanのSecondsToTrustAnIdlePoolConnection)このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であるとWebLogic Serverが信頼し、接続テストをスキップしてもよいと証明されてからの秒数を指定するのに使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。

接続のテスト・オプションの設定に関する指示については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。

データベース接続テストのセマンティクス

WebLogic Serverはデータ・ソースのデータベース接続をテストする際、データ・ソースからの接続を予約し、接続に対して小さな問合せを実行し、その後データ・ソースのプールに接続を戻します。サーバー・インスタンスは、プールのステータスに関する統計情報(接続テストの所要時間、接続を待機している接続数、テストされた接続数など)を追跡します。最近実施された接続動作テストの履歴は、接続テストが失敗したとサーバー・インスタンスが判断するまでの待機時間を計算するために使用されます。

スレッドの接続に通常よりも時間がかかっている場合、サーバー・インスタンスはそのテストが完了するまで、他のスレッドのテストを遅延させる場合があります。接続テスト中(デフォルトでは10秒)のスレッドのハングが長すぎる場合、プールはDBMSの接続失敗を宣言して自身を無効にし、予約されてない接続も、アプリケーションが使用中の接続も、すべての接続を強制終了します。

これは非常にまれなケースですが、ネットワーク・ケーブルの切断によって引き起こされる無限のハング状態や、ソケット読取りで呼出しを行っているJVMスレッドがロックされ、OSのTCP制限(通常は10分間)に達するまでJVMが解除されなくなるような問題を解決することを意図しています。この方法でプールが自身を無効化した場合、プールは定期的に(デフォルトでは5秒おきに)DBMSに再接続しようとします。新しい接続を作成できた場合、プールは自身を再び有効にして、以降の接続リクエストは通常通りに処理します(プールは負荷の必要性に応じて再び接続を格納します)。

テストで使用する問合せは、「テスト対象の表名」の値によって決定されます。値が表名の場合、問合せはselect 1 from table_nameとなります。「テスト対象の表名」に、先頭がSQLで直後にスペースと問合せが続く完全な問合せが含まれていれば、WebLogic Serverはデータベース接続のテスト時に、その問合せを使用します。

接続がテストに失敗すると、WebLogic Serverは接続を閉じて再作成し、その後、新しい接続をテストします。

接続テストのセマンティクスの詳細については、以下の節で説明しています。

- データベース接続作成時の接続テスト

- 定期的な接続テスト

- 予約済みの接続のテスト

- データベース接続が失われた後の接続テスト遅延の最小化

- 接続テスト失敗後の接続リクエスト遅延の最小化

- DBMS接続が失われた後の接続リクエストの遅延の最小化

- アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化

データベース接続作成時の接続テスト

データ・ソース内に接続が作成されると、WebLogic Serverは「テスト対象の表名」の値で定義された問合せを使用して、各接続をテストします。接続の作成は、サーバー起動時かデータ・ソース作成時にデータ・ソースがデプロイされる場合、接続のリクエストを満たすために容量を増大させる場合、または接続テストに失敗した接続を再作成する場合に、行われます。

このテストの目的は、アプリケーションが接続をリクエストしたときに、必ず新しい有効な接続がすぐに使用できるようにしておくことです。

定期的な接続テスト

「テスト頻度」が0より大きい場合、WebLogic Serverは現在アプリケーションで予約されていないプール済みの接続を定期的にテストします。テストは、「テスト対象の表名」で定義された問合せに基づいています。接続がテストに失敗した場合、WebLogic Serverは接続を閉じ、接続を再作成し、新しい接続をテストしてから、その接続をプールに戻します。

予約済みの接続のテスト

「予約時に接続をテスト」が有効になっているとき、アプリケーションにデータ・ソースからの接続がリクエストされると、WebLogic Serverはアプリケーションに接続を与える前に「テスト対象の表名」に指定された問合せを使用して接続をテストします。デフォルト値は「無効」です。

「予約された接続のテスト」は、接続リクエストに応じるにあたり遅延を生じさせる可能性がありますが、アプリケーションが接続を取得した時点で、その接続は確実に有効です。「アイドル・プール接続を信頼する秒数」をチューニングすることで、「予約された接続のテス」トの影響を最小限に抑えることができます。「アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。

データベース接続が失われた後の接続テスト遅延の最小化

DBMSへの接続がたとえ一瞬でも失われると、通常、データ・ソースにおけるJDBC接続の一部またはすべてが切断されます。データ・ソースが予約時の接続テストを行うように構成されている場合、あるアプリケーションによってデータベース接続がリクエストされると、WebLogic Serverはその接続をテストし、その接続が切断されていることが分かると、リクエストに応えるため、新しい接続と置き換えようとします。通常、DBMSがオンラインに復帰すると、リフレッシュ・プロセスが引き継がれます。ただし、場合によっては、いくつかの障害モードで、切断された接続のテストによって長い遅延状態になる可能性があります。

この遅延を最小限に抑えるため、WebLogicデータ・ソースには、何度か連続してテストが失敗すると、データ・ソース内のすべての接続を切断されているものと見なして閉じるロジックが含まれています。すべての接続が閉じられた後に、アプリケーションが接続をリクエストすると、データ・ソースは先に切断された接続のテストを行うことなく、接続を作成します。この動作によって、データ・ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小化されます。

WebLogic Serverは、データ・ソースの「テスト頻度」の設定に基づいてすべての接続を閉じるまでのテストの失敗回数を決定します。

- 「テスト頻度」が0より大きければ、すべての接続を閉じるまでのテスト失敗回数は2に設定されます。

- 「テスト頻度」が0に設定されている(定期テストが無効化されている)場合、すべての接続を閉じるまでのテスト失敗回数は、データ・ソースの「最大容量」の25%に設定されます。

接続テスト失敗後の接続リクエスト遅延の最小化

DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。

この遅延を最小限に抑えるため、WebLogicデータ・ソースには、2回連続して失敗が生じたらデータ・ソースを無効化して、切断されている接続を置き換えるロジックが含まれています。アプリケーションが、無効化されたデータ・ソースから接続をリクエストすると、即座にPoolDisabledSQLExceptionがスローされ、接続が使用できないことがクライアントに知らされます。

この方法で無効化されたデータ・ソースについては、定期的にリフレッシュ・プロセスが実行されます。リフレッシュ・プロセスでは、次のことが実行されます。

- サーバー・インスタンスによる、データベース・サーバーに対する5秒ごとのヘルス・チェック。この設定は構成できません。

- サーバー・インスタンスは、データベースが回復されたことを認識すると、新しいデータベース接続を作成してデータ・ソースを有効化します。

また、管理コンソールを使用して手動でデータ・ソースを有効化することもできます。

DBMS接続が失われた後の接続リクエストの遅延の最小化

DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断されたデータベース接続をテストして、無駄に置き換えようとすると、場合によってはOSネットワーク・タイムアウト(分単位)と同程度の時間がかかり、予期される失敗メッセージを取得するまでにクライアントで長時間の遅延を引き起こす可能性があります。

注意:

データ・ソースをマルチ・データ・ソースに追加している場合は、マルチ・データ・ソースがデータ・ソースの無効化と再有効化を引き継ぎます。デフォルトでは、マルチ・データ・ソースは2分おきにチェックして(この時間は構成可能)、接続を再確立できるデータ・ソースがあれば再有効化します。

アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化

DBMS接続を非常に短いサイクルで使用するアプリケーションの場合(例:reserve-do_one_query-close)、データ・ソースの接続のテストは各使用サイクルに大量のオーバーヘッドをもたらす可能性があります。接続テストの影響を最小化するには、JDBCデータ・ソース構成の「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用またはテストしたデータベース接続を信頼して接続テストをスキップします。

データ・ソース上で「予約時に接続をテスト」が有効化されている場合、アプリケーションがデータベース接続をリクエストすると、WebLogic Serverはアプリケーションに渡す前にその接続をテストします。接続がテストされるかアプリケーションで正常に使用されてから、「アイドル・プール接続を信頼する秒数」に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。

データ・ソースに対する「テスト頻度」が0より多い(定期テストが有効化されている)場合も、WebLogic Serverは接続が正常に使用されて、「アイドル・プール接続を信頼する秒数」で指定した時間内にデータ・ソースに戻されていれば、接続テストをスキップします。

アイドル・プール接続を信頼する秒数の設定方法については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。

「アイドル・プール接続を信頼する秒数」は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などには、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。

データベース接続テストの構成上の推奨事項

接続テストの属性は、環境に最もよく適合するように設定する必要があります。たとえば、アプリケーションがデータベース接続の失敗を許容できない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して確実に「予約時に接続をテスト」を有効化しておき、WebLogic Serverが接続をアプリケーションに渡す前に、毎回その接続のテストを行うようにします。アプリケーションがデータ・ソースから接続を取得する際の遅延に影響を受けやすく、切断された接続の使用によるアプリケーション失敗の可能性を許容できるのであれば、「アイドル・プール接続を信頼する秒数」をより高い数値に、「テスト頻度」を低い数値に設定し、「予約時に接続をテスト」を有効化する必要があります。

これらの設定によりアプリケーションは、アプリケーションが接続をリクエストしたときよりも、プール内の接続が使用されていないときのデータ・ソースの接続テストに依存するようになります。

注意:

結局は、WebLogicが最善を尽くした場合でも、WebLogicが接続を正常にテストした後で、アプリケーションがその接続を使用する前に、接続が失敗する可能性はあります。したがって、どのアプリケーションも、切断された接続から予期しない例外が発生した場合に適切に対応するように記述しておく必要があります。

デフォルトのテスト対象の表名

管理コンソールを使用してデータ・ソースを作成する場合、管理コンソールは、選択したDBMSに基づき、データ・ソースの「テスト対象の表名」属性を自動的に設定します。「テスト対象の表名」属性は接続テストで使用されます。接続テストは必要に応じて、テスト・オプションの構成により定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、データ・ソースのデータベース接続を作成するユーザーが、該当するデータベース表にアクセスできる必要があります。アクセスできない場合には、DBMSを使用してそのユーザーにアクセスを付与するか、WebLogic Server管理コンソールを使用して「テスト対象の表名」属性をユーザーがアクセスを持つ表の名前に変更する必要があります。

「テスト対象の表名」はオーバーロードされるパラメータです。最も単純な形式は、WLSが接続のテストを要求する表を指定することです。Oracleの場合の「DUAL」など、任意の表に設定すると、データ・ソースは「select count(*) from DUAL」のような問合せを実行することになります。このモードで使用する場合は、小さく、頻繁には更新されない表(DUALのような擬似表が望ましい)を選ぶことをお薦めします。

このパラメータを定義するときの2番目の方法は、特定のSQL文字列に接続のテストを実行させることです。この方法を使用するには、パラメータとして、「SQL」 に必要なSQL文字列を加えたもの設定します。たとえば、SQLServerの場合は「SQL select 1」が使用できます(定数を選択する問合せに表を含める必要はありません)。この方法は、WLSのプール接続テストにDBMS側の制御を加えて、テストをできる限り速く行うには便利です。

表10-1 DBMSによる、デフォルトのテスト対象の表名

DBMS

デフォルトのテスト対象の表名(問合せ)

Adabas for z/OS

SQL call shadow_adabas('select * from employees')

Cloudscape

SQL SELECT 1

DB2

SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES

FirstSQL

SQL SELECT 1

IMS/TM for z/OS

SQL call shadow_ims('otm','/dis','cctl')

Informix

SQL SELECT COUNT(*) FROM SYSTABLES

Microsoft SQL Server

SQL SELECT 1

MySQL

SQL SELECT 1

Oracle

SQL SELECT 1 FROM DUAL

PostgreSQL

SQL SELECT 1

Progress

SQL SELECT COUNT(*) FROM SYSTABLES

Sybase

SQL SELECT 1

接続作成の再試行の有効化

WebLogic JDBCデータ・ソースには、データベースへの接続確立を試行する間隔の秒数を指定するのに使用できる、「接続作成の再試行間隔」オプション(JDBCConnectionPoolParamsBeanのConnectionCreationRetryFrequencySeconds)があります。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、WebLogic Serverは指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで継続します。このオプションは、サーバー起動時にデータ・ソースが作成されたとき、データ・ソースがデプロイされたとき、または初期容量が増大されたときに作成される接続に適用されます。プールを拡張したり、プール内の機能しない接続を置き換えたりする場合に作成される接続には適用されません。

デフォルトでは、「接続作成の再試行間隔(秒)」は0秒です。この値を0に設定すると、接続作成の再試行は無効化され、データベースが使用できなければデータ・ソースの作成は失敗します。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。

接続を待機する接続リクエストの有効化

JDBCデータ・ソースには、データ・ソースからの接続を待機する接続リクエストを有効化するために設定できる、2つの属性があります。「接続予約のタイムアウト」 (ConnectionReserveTimeoutSeconds)および「接続の最大待機数」 (HighestNumWaiters)です。これら2つの属性を一緒に使うと、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。

また、管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化に関する項も参照してください。

接続予約のタイムアウト

アプリケーションがデータ・ソースからの接続をリクエストしたときにデータ・ソース内の接続がすべて使用中であり、かつデータ・ソースが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可SQL例外を受け取ります。これを避けるために、接続が利用できるようになるまで接続リクエストが待機するよう、「接続予約のタイムアウト」の値(秒単位)を構成することができます。「接続予約のタイムアウト」の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションはPoolLimitSQLException例外を受け取ります。

「接続予約のタイムアウト」を-1に設定すると、利用できる接続がなかった場合、接続リクエストは直ちにタイムアウトします。「接続予約のタイムアウト」を0に設定すると、接続リクエストは無期限に待機します。デフォルト値は、10秒です。

Oracle WebLogic Server管理コンソール・ヘルプの接続を待機する接続リクエストの有効化に関する項を参照してください。

待機する接続リクエスト数を制限する

接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを回避するには、「接続の最大待機数」 (HighestNumWaiters)属性を設定して、同時に接続を待機できる接続リクエスト数を制限します。

「接続の最大待機数」 (HighestNumWaiters)をMAX-INT (デフォルト)に設定すると、事実上、接続を待機できる接続リクエストに制限はなくなります。「接続の最大待機数」を0に設定すると、接続リクエストは接続を待機できなくなります。最大リクエスト数に到達した場合、アプリケーションが接続をリクエストするとSQLExceptionがスローされます。

リークされた接続の自動回復

リークされた接続とは、適切にデータ・ソースの接続プールに戻されなかった接続のことです。リークされた接続を自動的に回復するには、管理コンソールの「JDBCデータ・ソース」>「構成」>「接続プール」ページで「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」に値を指定すると、予約された接続に対して指定した秒数間アクティビティがない場合、WebLogic Serverは強制的に接続をデータ・ソースに戻します。0 (デフォルト値)に設定すると、この機能は無効になります。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。

実際のタイムアウト時間は、「非アクティブ接続タイムアウト」に構成した値より長くなります。内部のデータ・ソース保守スレッドは5秒ごとに実行されます。「非アクティブ接続タイムアウト」値(たとえば30秒)が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は2回チェックを受けることになっています。2回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的にデータ・ソースに返されます。タイムアウト時間は、構成した値より、平均して約50%遅延します。

正しい接続数でのサーバー・ロック回避

アプリケーションで、データ・ソースから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外がスローされます。このエラーを避けるには、データ・ソースのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。データ・ソース内の使用できる接続の最大数を増やすには、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページでデータ・ソースの「最大容量」の値を増やします。

文タイムアウトによる文の処理時間の制限

JDBCデータ・ソースで「文タイムアウト」オプションを使用すると、データ・ソースからの予約されたデータベース接続に対する文の実行にかかる時間を制限できます。「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間をJDBCドライバに渡します。WebLogic Serverが呼出しを行い、ドライバが例外をスローした場合は、この値は無視されます。場合によっては、ドライバは暗黙的にこの呼出しをサポートしていないか、制限されたサポートがドキュメントに記載されていることがあります。ドライバのドキュメントを確認して、予期しないエラーを検証することをお薦めします。

「文タイムアウト」を -1 (デフォルト値)に設定した場合には、文はタイムアウトしません。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース」:「構成」:「接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。

Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。

Pinned-To-Threadが有効化されている場合、WebLogic Serverでは、データ・ソースから実行スレッドまでのデータベース接続が固定されます。これは、アプリケーションでそのスレッドが接続の予約のために最初に使用されるときに実行されます。また、アプリケーションでその接続を利用し終えてconnection.close()が呼び出されたときに、実行スレッドとの接続が保持され、接続はデータ・ソースに返されませんそして、アプリケーションが引続き同じ実行スレッドを使用して接続をリクエストしたときに、すでにそのスレッドで予約されている接続が提供されます。このような方法を取ると、複数のスレッドが同時に接続の予約を試行したときに起こる、データ・ソースでのロックの競合が発生しなくなります。また、限られた数のデータベース接続から同じ接続を予約しようとするスレッド間に競合が発生することもありません。

注意:

このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。

Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

PinnedToThreadを有効にしたときの接続プール管理処理に対する変更

PinnedToThreadを有効にすると接続プーリングの動作の性質が変更されるため、一部の接続プールの属性や機能は、動作の変更に適合するように、通常と異なる動作をしたり、無効化されたりします。

- 最大容量が無視されます。接続プール内の接続の数は、接続プールから予約されている接続の数または初期容量のいずれか大きな方の値に等しくなります。

- 接続が接続プールに返されないため、PinnedToThreadが有効化されている場合、縮小は接続プールに適用されません。接続は、効率上、常に予約されます。

- 接続プールをリセットすると、接続プールからリセットされた接続は、「テストが必要」とマークされます。次に各接続が予約されるときに、その接続は必要に応じてテストおよび再作成されます。接続は、接続プールのリセット時に同期的にテストされません。この機能は、「予約時に接続のテスト」を有効化し、「表名のテスト」または問合せを指定しておく必要があります。

PinnedToThreadを有効にしたときの追加のデータベース・リソース・コスト

PinnedToThreadを有効にすると、接続プールの最大容量(接続プールに作成されるデータベース接続の最大数)は、接続のリクエストに使われる実行スレッドの数に、各スレッドによって予約される同時接続の数を乗じた数になります。この数は、接続プールに指定された「最大容量」を超える場合があります。システム設計では接続のこの大きな数を考慮し、オープン・カーソルなど、追加の関連リソースについてデータベースで許容されるようにすべき場合があります。

また、接続が接続プールに返されない点にも注意する必要があります - これは、接続プールを縮小して、使用される関連リソースおよび接続の数を減らすことができないことを意味します。このコストは、追加のドライバ・パラメータonePinnedConnectionOnlyを設定することによって最小限に抑えることができます。onePinnedConnectionOnly=trueの場合、リクエストされた最初の接続のみがスレッドに固定されます。スレッドで必要なその他の接続はすべて、必要に応じて接続プールから取得されたり、接続プールに返されます。次に示すように、Properties属性を使用してonePinnedConnectionOnlyを設定します。

Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"

システムで追加のリソース要件を処理できる場合、PinnedToThreadオプションを使ってパフォーマンスを向上させることをお薦めします。

現在のシステムでは追加のリソース要件を処理できない、またはPinnedToThreadを有効化するとデータベース・リソースでエラーが発生する場合は、PinnedToThreadは使用しないでください。

未包装データ型オブジェクトの使用方法

WebLogic Serverから戻されるドライバからのJDBCオブジェクトのいくつかは、デフォルトでラップされています。データ・ソース・オブジェクトをラップすると、WebLogic Serverは次のことができるようになります。

- すべてのメソッド呼出しからデバッグ出力を作成します。

- 接続の適切なタイムアウトのために接続の使用を追跡します。

- 透明な自動トランザクション登録とセキュリティ認証を提供します。

WebLogic Serverでは、ラッピングを無効にすることが可能です。そのメリットは次のとおりです。

- WebLogic Serverは、ラッパーを通して表示するインタフェースを実装するベンダー・メソッドのダイナミック・プロキシを生成しますが、一部インタフェースを実装しないデータ型もあります。たとえば、Oracleデータ型のArray、Blob、Clob、NClob、Ref、SQLXML、およびStructは、インタフェースを実装しないクラスです。ラッピングを無効に設定すると、アプリケーションはネイティブ・ドライバ・オブジェクトを直接使用できるようになります。

- ラッピング・オーバーヘッドの削除により、パフォーマンスを著しく向上できます。

ラッピングが無効(wrap-types要素がfalse)の場合、次のデータ型はラップされません。

- Array

- Blob

- Clob

- NClob

- Ref

- SQLXML

- Struct

- ParameterMetaData

- 接続テストが実行されません。

- ResultSetMetaData

- 接続テストが実行されません。

- 結果セット・テストが実行されません。

- JDBC MTプロファイリングが実行されません。

ラッピングの無効化方法

管理コンソールやWLSTを使用して、データ型のラッピングを無効にできます。

管理コンソールによるラッピングの無効化

JDBCデータ型オブジェクトのラッピングを無効にするには:

1. まだそうしていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで「サービス」を展開し、「データ・ソース」を選択します。

3. 「データ・ソースのサマリー」ページでデータ・ソース名をクリックします。

4. 構成: 接続プールタブを選択します。

5. 画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。

6. Wrap Data Typesで、ラップを無効にするチェックボックスを選択解除します。

7. 「保存」をクリックします。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
この変更はすぐには反映されません。データ・ソースの再デプロイやサーバーの再起動が必要です。

WLSTによるラッピングの無効化

データ型ラッピングを無効にするWLSTコードの抜粋を次に示します。

. . .
jdbcSR = create(dsname,"JDBCSystemResource");
theJDBCResource = jdbcSR.getJDBCResource();
poolParams = theJDBCResource.getJDBCConnectionPoolParams();
poolParams.setWrapTypes(false);
. . .

この変更はすぐには反映されません。データ・ソースの再デプロイやサーバーの再起動が必要です。

11 WebLogic ServerでのOracle RACの使い方

この章では、WebLogic ServerでOracle Real Application Clusters (Oracle RAC)を使用する場合の要件および構成タスクについて説明します。

Oracle WebLogic Serverは、Oracleデータベース11gのOracle Real Application Clusters (RAC)機能に関する強力なサポートを提供し、接続パフォーマンスと可用性の両方を最大化する豊富なプーリング管理機能への透過的アクセスを許可する一方で、データベース・アクセス時間を最小化します。

- Oracle Real Application Clustersの概要

- ソフトウェア要件

- JDBCドライバ要件

- ハードウェア要件

- WebLogic ServerでOracle RACを使用する場合の構成オプション

Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを一緒に使用するには、クラスタリング・ソフトウェアおよび共有ストレージ・ソリューションに加え、両方のシステム上での固有の構成が必要になります。このドキュメントでは、要求される構成について概要レベルで説明します。Oracle RAC、使用しているクラスタリング・ソフトウェア、使用しているオペレーティング・システム、および使用しているストレージ・ソリューションの構成に関する詳細は、それぞれのベンダーが提供するドキュメントを参照してください。

Oracle Real Application Clustersの概要

Oracle Real Application Clusters (Oracle RAC)は、複数のマシンのユーザーが単一のデータベースに高いパフォーマンスでアクセスすることを可能にする高可用性ソリューションに追加できるソフトウェア・コンポーネントです。Oracle RACは、複数のクラスタ化マシン上で実行され、クラスタ技術によって共有ストレージ・デバイスにアクセスする複数のOracleデータベース・インスタンスで構成されます。このアーキテクチャをサポートするため、データベース・インスタンスをホストするマシンは高速のインターコネクトでリンクされて、クラスタを形成します。インターコネクトとは、クラスタのノード間の通信手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサード・パーティのクラスタリング・ソフトウェアによって提供されます。

インストールされているOracle RACは、単一の標準的なOracleデータベースのように見え、同じツールと実行方法で管理されます。クラスタのすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACにより各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、Oracle RACノード、ストレージ、またはその両方を追加することで、処理とリクエストの増加に伴い、データベース層を水平方向に拡張できます。

ソフトウェア要件

WebLogic ServerをOracle RACで使用するには、各Oracle RACノードに次のソフトウェアをインストールする必要があります。

- Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleが提供するリリース・ノートを参照してください。

- Oracle 11gデータベース管理システム。『Oracle® Fusion Middlewareライセンス情報』を参照してください。

- 使用しているオペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアおよびクラスタ構成については、Oracleのドキュメントを参照してください。

- Veritas Cluster File Systemなどの共有ストレージ・ソフトウェア。一部のクラスタリングソフトウェアには、ファイル・ストレージ・ソリューションが含まれています。その場合は、共有ストレージ・ソフトウェアは必要ありません。

注意:

最新のWebLogic Serverハードウェア・プラットフォームおよびオペレーティング・システムのサポート、およびWebLogic Serverのバージョンおよびサービス・パックでサポートされるOracle RACバージョンについては、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。Oracle RACソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracleのドキュメントを参照してください。

JDBCドライバ要件

WebLogic ServerをOracle RACとともに使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thin Driver 11gを使用して、データベース接続を作成する必要があります。

ハードウェア要件

WebLogic ServerおよびOracle RACの標準的なシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが含まれます。

WebLogic Serverクラスタ

WebLogic Serverクラスタは、さまざまハードウェア・オプションを使用して多くの方法で構成できます。WebLogic Serverクラスタの構成については、『Oracle WebLogic Serverクラスタの使用』を参照してください。

Oracle RACクラスタ

Oracle RACに関する最新のハードウェア要件については、Oracle RACのドキュメントを参照してください。ただし、WebLogic ServerでOracle RACを使用するには、堅牢な製品レベル品質のハードウェア上でOracle RACインスタンスを実行する必要があります。Oracle RACの構成では、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースのレスポンスが著しく遅れると、データベースのフェイルオーバー処理の間に予期しない動作が生じるおそれがあります。

共有ストレージ

Oracle RACの構成では、データ・ファイル、制御ファイル、およびパラメータ・ファイルはすべて、各Oracle RACインスタンスで共有されて使用されます。次のいずれかのアーキテクチャを使用するHAストレージ・ソリューションをお薦めします。

- デュアル・ポート・ディスク配列などのダイレクト・アタッチド・ストレージ(DAS)またはストレージ・エリア・ネットワーク(SAN)

- ネットワーク・アタッチド・ストレージ(NAS)

サポートされているストレージ・ソリューションの全リストについては、Oracleのドキュメントを参照してください。

WebLogic ServerでOracle RACを使用する場合の構成オプション

Oracle RACでWebLogic Serverを使用する場合、Oracle RACインスタンスと対話でき、期待どおりに動作するようにWebLogicドメインを構成する必要があります。次の項では、構成のオプションと要件について説明します。

- Oracle RACと併用するためのWebLogic Server構成の選択

- Oracle RACでのWebLogic Server使用時の接続の検証

- Oracle RACでのWebLogic Server使用時の追加検討事項

Oracle RACと併用するためのWebLogic Server構成の選択

次の代替について考察します。

- GridLinkデータ・ソースの使用に関しては、『Oracle® Fusion Middlewareライセンス情報』を参照してください。

- グローバル・トランザクション(XA)の使用時に複数のOracle RACインスタンスに接続するには、(フェイルオーバーとロード・バランシングをサポートする)トランザクション対応のWebLogic JDBCマルチ・データ・ソースを使用してOracle RACノードに接続することをお薦めします。詳細は、「グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用」を参照してください。

- XAを使用していない場合に複数のOracle RAC 11gインスタンスに接続するには、(非トランザクション対応の)マルチ・データ・ソースを使用してOracle RACノードに接続することをお薦めします。フェイルオーバーとロード・バランシングをサポートする、標準的なマルチ・データ・ソース構成を使用してください。詳細は、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。

以下の表を、特定のアプリケーションに適した構成を判断する際の指標としてご利用ください。

表11-1 Oracle RACと併用するための構成の選択

ロード・バランシングは必要?

フェイルオーバーは必要?

グローバル・トランザクション(XA)は必要?

Oracle RACサービスを使用

次を参照

はい

はい

はい

はい

GridLinkデータ・ソースの使用

はい

はい

はい

いいえ

グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用

はい

はい

はい

はい

Oracle RACノード上のサービスに対する接続の構成

はい

はい

いいえ

はい

Oracle RACノード上のサービスに対する接続の構成

はい

はい

いいえ

いいえ

グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用

Oracle RACでのWebLogic Server使用時の接続の検証

アプリケーションは、JDBC 4.0 Connection.isValid APIを使用して接続の実行可能性を検証できます。

注意:

WebLogic Serverはoracle.ucp.jdbc.ValidConnection.isValid or oracle.ucp.jdbc.ValidConnection.setInvalidをサポートしません。

Oracle RACでのWebLogic Server使用時の追加検討事項

Oracle RACでのGridLinkデータ・ソースまたはマルチ・データ・ソース使用時にトランザクションを調整する場合、分散トランザクション処理(DTP)はサポートされていません。

12 WebLogic ServerでのJDBCドライバの使い方

この章では、WebLogic ServerでJDBCドライバを設定および使用する方法について説明します。

- WebLogic ServerでインストールされるJDBCドライバ

- タイプ4 サード・パーティJDBCドライバに対する環境設定

- Oracle 11g Thin Driverのグローバリゼーション・サポート

- Oracle Thin Driverのデバッグ・モードでの使い方

- SSLを介したOracle Thin Driverの使用

注意:

WebLogic Serverは、以下の機能を提供するJDBCドライバと連携して動作します。

- スレッドセーフ

- 標準のJDBC文を使用してトランザクションの実装が可能

- SerializableインタフェースまたはRemoteインタフェースは実装しないでください。これらはオブジェクトをリモート・クライアント・アプリケーションに渡すことができません。

WebLogic ServerでインストールされるJDBCドライバ

Oracle Thinドライバ(JDK 6向けojdbc6.jar)の11gバージョンが、Oracle WebLogic Serverとともにインストールされます。

注意:

WebLogic DataDirectドライバも、WebLogic Serverとともにインストールされます。詳細は、WebLogic DataDirectドライバの使用に関する項を参照してください。

Oracle Thin Driverに加えて、mySQL 5.0.x (mysql-connector-java-commercial-5.0.x-bin.jar) JDBCドライバがWebLogic Serverとともにインストールされます。

これらのドライバは、weblogic.jarと一緒にWL_HOME\server\libフォルダ(WL_HOMEはWebLogic Serverのインストール先フォルダ)にインストールされます。weblogic.jarのマニフェストには、このファイルがリストされており、weblogic.jarのロード時(サーバーの起動時)にロードできます。したがって、CLASSPATHにこのJDBCドライバを追加する必要はありません。WebLogic Serverでインストールされていないサード・パーティJDBCドライバを使用する予定がある場合は、それらのドライバをインストールする必要があります。インストール作業には、ドライバ・ファイルへのパスでCLASSPATHを更新することが含まれます。また、データベース・クライアント・ファイルへのパスでPATHを更新する場合もあります。『Oracle WebLogic Serverの新機能』のサポートされている構成に関する項を参照してください。

WebLogic Serverでインストールされる別バージョンのドライバを使用する予定がある場合は、WL_HOME\server\lib内のドライバ・ファイルを更新バージョンに置き換えるか、またはCLASSPATHの前に新しいファイルを追加することができます。

WebLogic ServerでインストールされるMySQLおよびOracle Thinドライバのコピーや、その他のサポート・ファイルは、WL_HOME\server\ext\jdbc\にインストールされます。このフォルダには、各DBMS用にサブディレクトリがあります。WebLogic Serverでインストールされたドライバのバージョンに戻す必要がある場合は、ファイルをWL_HOME\server\ext\jdbc\DBMSからWL_HOME\server\libにコピーできます。

注意:

WebLogic Serverでは、WebLogic ServerサンプルとともにインストールされるDerby DBMSのバージョンもWL_HOME\common\derbyのディレクトリに含まれています。DerbyはすべてのJavaのDBMS製品であり、WebLogic Serverサンプルのデモをサポートする目的でのみWebLogic Server配布に含まれています。Derbyの詳細は、http://db.apache.org/derbyを参照してください。

タイプ4サード・パーティJDBCドライバに対する環境設定

WebLogic Serverとともにインストールされないサード・パーティのJDBCドライバを使用する場合は、WebLogic Serverのクラスパスを更新して、JDBCドライバ・クラスの場所を入力する必要があります。WL_HOME/common/bin内のcommEnv.cmd/shスクリプトを編集し、『Oracle WebLogic Serverコマンド・リファレンス』のクラスパスの変更に関する項に記載のとおりクラスを追加します。

Oracle 11g Thin Driverのグローバリゼーション・サポート

11gバージョンのOracle Thin Driverのグローバリゼーション・サポートとして、Oracleではnls_charset.zipに代わるorai18n.jarファイルを提供しています。Oracleのオブジェクト型およびコレクションにおいてCHARおよびNCHAR型のデータに、US7ASCII、WE8DEC、WE8ISO8859P1、およびUTF8以外の文字セットを使用している場合には、CLASSPATHにorai18n.jarおよびorai18n-mapping.jarを含める必要があります。

orai18n.jarおよびorai18n-mapping.jarは、WebLogic Serverのインストール時にWL_HOME\server\ext\jdbc\oracle\11gフォルダに格納されます。このファイルはweblogic.jarマニフェスト・ファイルからは参照されないため、CLASSPATHに追加しなければ使用できません。

Oracle Thin Driverのデバッグ・モードでの使い方

WL_HOME\server\ext\jdbc\oracle\11gフォルダには、ojdbc6_g.jarファイル(JDK 6用)およびojdbc5_g.jarファイル(JDK 5用)が入っています。これは、デバッグおよび追跡をサポートするクラスを備えたバージョンの、Oracle Thin Driverです。Oracle Thin Driverをデバッグ・モードで使用するには、CLASSPATHの先頭にこれらのファイルへのパスを追加します。

SSLを介したOracle Thin Driverの使用

この項では、SSLを介してOracle Thin Driverを使用する場合のWebLogic Serverのデータ・ソースの構成方法について説明します。

WebLogic Serverでデータ・ソースを構成するには、以下の手順を実行します。

1. 管理コンソールのナビゲーション・ペインで、プラス記号をクリックして「サービス」を展開します。

2. プラス記号をクリックして「JDBC」を展開します。

3. 「データ・ソース」を選択します。

4. 「JDBCデータ・ソースの概要」ページで「新規作成」を選択します。

5. 新しいJDBCデータ・ソースの作成ページで、JDBCデータ・ソース名および (オプション) JNDI名を指定します。
データベースの種類としてOracleを選択し、使用するOracleデータベース・ドライバ(Thin XAまたはThin)を選択します。

6. 「次へ」をクリックします。

7. 必要に応じて、トランザクション・オプションを選択します。「次へ」をクリックします。

8. 「接続プロパティ」ページで、「データベース名」、「ホスト名」、「ポート」、および「データベース・ユーザー名」と「パスワード」を入力します。これらの値は、データ・ソースのURLを作成するために使用されます。このURLは次のページで変更しますが、ここでは続行するために値を入力する必要があります。「次へ」をクリックします。

9. 「構成のテスト」ページで、次のように変更します。

1. ドライバ・クラス名がoracle.jdbc.xa.client.OracleXADataSourceまたはoracle.jdbc.OracleDriverであることを確認します。

2. 以下の構文と形式を使用するようにURLを変更します。

URL : jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcps)
(HOST = <hostname>)(PORT = <sslport>))) (CONNECT_DATA = (SERVICE_NAME = <service_name>))
(SECURITY=(SSL_SERVER_CERT_DN=\"CN=<.......>\")))

(SECURITY=(SSL_SERVER_CERT_DN=\"CN=<.....>\"))はオプションであり、サーバーDNの照合にのみに使用されます。

10. 「表名のテスト」を入力します(またはそのまま受け入れます)。

11. 必要に応じて、「構成のテスト」をクリックして構成をテストします。

12. 「完了」をクリックします。

13 WebLogic JDBCリソースのモニター

この章では、実行中のサーバーおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスする方法について説明します。

このデータを基に、サーバーおよびアプリケーションの実行時パフォーマンスを把握できます。また、フォルト発生時に、このデータを使用して、障害を隔離および診断できます。WebLogic JDBCは、このサービスを利用して、実行時の統計、ある一定の期間に渡ってのプロファイル情報、ロギング、およびデバッグの機能を拡張し、WebLogicドメインが円滑に実行され続けるよう支援します。

実行時の統計を使用すると、WebLogicドメインのデータ・ソースをモニターして、問題があるかどうかを確認することができます。問題があれば、プロファイリングによって、問題の原因となっているアプリケーションを判断できます。アプリケーションを絞り込んだら、JDBCデバッグ機能を使用して、そのアプリケーション内の問題点を突き止めます。

次の項では、JDBCオブジェクトのモニターについて詳細に説明します。

- 実行時の統計の表示

- プロファイル・ロギング

- プロファイル情報の収集

- JDBCデータ・ソースのデバッグ

実行時の統計の表示

実行時の統計を表示すると、WebLogicドメインのデータ・ソースをモニターできます。

データ・ソースの統計

管理コンソールまたはJBCDataSourceRuntimeMBeanにより、データ・ソースの実行時統計を表示できます。JDBCDataSourceRuntimeMBeanは、データ・ソースの現在の状態およびアクティブな平均接続数、現在のアクティブな接続数および最大アクティブ接続数など、データ・ソースの統計データの取得方法を提供します。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プリペアド文キャッシュの統計

管理コンソールまたはJBCDataSourceRuntimeMBeanを介してPrepared Statementキャッシュの実行時統計を表示できます。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プロファイル・ロギング

10.3.6より前のWebLogic Serverでは、データ・ソース・プロファイル・レコードはWLDFイベントとして記録されていました。使いやすさとパフォーマンスを向上させるため、WebLogic Serverではイベントの格納にデータ・ソース・プロファイル・ログが使用されるようになりました。プロファイル・ログには次のような利点があります。

- ログ・ローテーション: 標準のWebLogicロギング実装を使用して、古いデータの構成、ローテーションおよびリタイアを行うことができます。Oracle WebLogic Server MBeanリファレンスのDataSourceLogFileMBeanを参照してください。

- データのアクセシビリティ: 一般的なテキスト・エディタ、WLDFデータ・アクセッサまたは管理コンソールを使用できます。「診断データへのアクセス」を参照してください。

データ・ソース・プロファイリングのログの基本的な特性は、次のとおりです。

- すべてのデータ・ソース・プロファイル・タイプに対して単一のログ・ファイルが使用されます。各プロファイル・レコードには、フィルタ処理のためにプロファイル・タイプ名があります。「プロファイル・タイプ」を参照してください。

- サーバー上のすべてのデータ・ソースに対して単一のログ・ファイルが使用されます。各プロファイル・レコードには、フィルタ処理のための修飾されたデータ・ソース名(適用可能な場合、application@module@componentで完全修飾された名前)があります。Oracle WebLogic Server MBeanリファレンスのDataSourceLogFileMBeanを参照してください。

WebLogicロギング・サービスの詳細は、次の資料を参照してください。

- Oracle WebLogic Server管理コンソール・ヘルプのデータ・ソース・プロファイル・ログの有効化と構成に関する項

- 『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogicロギング・サービスに関する項を参照してください。

プロファイル情報の収集

表示されている統計からWebLogic Serverドメインに問題があるとわかった場合は、任意のデータ・ソースを構成して、問題の原因を特定するのに役立つ、プロファイル情報を収集できます。収集されたプロファイル情報は、プロファイル・ログのレコードに格納されます。後述するように、各フィールドには、プロファイル・タイプごとに別の情報が格納されます。

プロファイリングのためにデータ・ソースを構成する際には、プロファイル・データ収集の間隔(「収集間隔(秒)のプロファイル」)を指定する必要があります。間隔を0に設定すると、データ収集は無効化されます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの診断プロファイリングの構成に関する項を参照してください。

プロファイル・タイプ

このドキュメントの後続の項で説明するとおり、データ・ソースおよびプリペアド文キャッシュについて、以下の情報のプロファイリングを選択することができます。

- 接続使用状況(PROFILE_TYPE_CONN_USAGE_STR)

- 待機中の接続予約(PROFILE_TYPE_CONN_RESV_WAIT_STR)

- 失敗した接続予約(PROFILE_TYPE_CONN_RESV_FAIL_STR)

- 接続リーク(PROFILE_TYPE_CONN_LEAK_STR)

- 接続の最終使用状況(PROFILE_TYPE_CONN_LAST_USAGE_STR)

- マルチスレッド接続使用状況(PROFILE_TYPE_CONN_MT_USAGE_STR)

- 文キャッシュ・エントリ(PROFILE_TYPE_STMT_CACHE_ENTRY_STR)

- 文の使用状況(PROFILE_TYPE_STMT_USAGE_STR)

接続使用状況(PROFILE_TYPE_CONN_USAGE_STR)

データ・ソース内の接続のプールからの接続を現在使用しているスレッドに関する情報を収集するには、接続使用状況のプロファイリングを有効化します。このプロファイル情報は、アプリケーションがデータ・ソースからの接続を取得できない原因を特定するのに役立ちます。

注意:

デフォルトでは、接続使用状況のプロファイルを独自に有効化しても、接続を使用しているスレッドのスタック・トレースは得られません。この情報を得るには、接続の有効化に加えて、接続リークのプロファイルを有効化する必要があります。接続リークのプロファイルの詳細は、「接続リーク(PROFILE_TYPE_CONN_LEAK_STR)」を参照してください。

レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - 接続ID

- User - 接続を使用しているスレッドのスタック・トレース

- Timestamp - 接続がいつスレッドに渡されたかを示すタイムスタンプ

待機中の接続予約(PROFILE_TYPE_CONN_RESV_WAIT_STR)

データ・ソースからの接続の予約を現在待機しているスレッドに関する情報を収集するには、待機中の接続予約のプロファイリングを有効化します。このプロファイル情報は、アプリケーションがデータ・ソースからの接続を取得できない、または接続を待機できない原因を特定するのに役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - スレッドID

- User - 接続を待機しているスレッドのスタック・トレース

- Timestamp - スレッドがいつ接続を待機し始めたのかを示すタイムスタンプ

失敗した接続予約(PROFILE_TYPE_CONN_RESV_FAIL_STR)

データ・ソースからの接続を予約しようとして接続の取得に失敗するスレッドに関する情報を収集するには、接続予約失敗のプロファイリングを有効化します。このプロファイル情報は、アプリケーションがデータ・ソースからの接続を、予約後も取得できない原因を特定するのに役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - スレッドID

- User - 接続を待機しているスレッドに加えて、予約リクエストが失敗したときに受け取られる例外のスタック・トレース

- Timestamp - 予約リクエストがいつ失敗したのかを示すタイムスタンプ

接続リーク(PROFILE_TYPE_CONN_LEAK_STR)

データ・ソースからの接続を予約したスレッドと、リークした(接続のプールに正常に戻されなかった)接続の情報を収集するには、接続リークのプロファイリングを有効化します。このプロファイル情報は、JDBC接続を正しく閉じていないアプリケーションを特定するのに役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - 接続ID

- User - 接続を待機しているスレッドのスタック・トレース

- Timestamp - 接続リークがいつ検出されたのかを示すタイムスタンプ

接続の最終使用状況(PROFILE_TYPE_CONN_LAST_USAGE_STR)

最後に接続を使用した以前のスレッドに関する情報を収集するには、接続の最終使用状況のプロファイリングを有効化します。この情報は、接続に対する後続のXA操作の失敗を招く保留中のトランザクションで発生した接続に関する問題をデバッグする際に役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - スローされたXA例外のスタック・トレース

- User - 接続を最後に使用したスレッドのスタック・トレース

- Timestamp - 例外がいつスローされたのかを示すタイムスタンプ

マルチスレッド接続使用状況(PROFILE_TYPE_CONN_MT_USAGE_STR)

別のスレッドによって以前に取得された接続を誤って使用するスレッドに関する情報を収集するには、マルチスレッド接続使用状況のプロファイリングを有効にします。この情報は、接続が複数のスレッドによって同時に使用されていることが原因ではないかと思われる問題をアプリケーションが報告した場合に有用です。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - 接続を使用していることが検出された別のスレッドのスタック・トレース

- User - 接続を予約したスレッドのスタック・トレース

- Timestamp - 複数のスレッドが接続を使用していることがいつ検出されたのかを示すタイムスタンプ

文キャッシュ・エントリ(PROFILE_TYPE_STMT_CACHE_ENTRY_STR)

文キャッシュに追加されたプリペアド文と呼出し可能文、およびキャッシュされた文から発生したスレッドに関する情報を収集するには、文キャッシュ・エントリのプロファイリングを有効にします。この情報は、キャッシュがどのように使われているかを判断するのに役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - 文の文字列表現

- User - 文を使用しているスレッドのスタック・トレース

- Timestamp - 文がいつキャッシュに追加されたかを示すタイムスタンプ

文の使用状況(PROFILE_TYPE_STMT_USAGE_STR)

文キャッシュからのSQL文を現在実行しているスレッドに関する情報を収集するには、文の使用状況のプロファイリングを有効にします。この情報は、文がどのように使われているかを判断するのに役立ちます。レコードには、次の情報が格納されています。

- PoolName - この接続が属するデータ・ソースの名前

- ID - 文を介して実行されているSQL文

- User - 文を使用しているスレッドのスタック・トレース

- Timestamp - 文が実行されている期間

診断データへのアクセス

診断データにアクセスするには、次のいずれかの方法を使用できます。

- WebLogic管理コンソール。次を参照:

- Oracle WebLogic Server管理コンソール・ヘルプのログの表示と構成に関する項

- Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの統計のモニターに関する項

- WebLogic診断フレームワーク(WLDF)のデータ・アクセッサ・コンポーネント。『Oracle WebLogic Server診断フレームワークの構成と使用』のデータ・アクセッサを使用した診断データへのアクセスに関する項

- テキスト・エディタを使用した手動での情報のレビュー。

- DataSourceプロファイリングで実行する場合、デフォルトの収集時間は300秒なので、データが即時に表示されないことがあります。収集時間を小さい値(5秒など)に設定すると、結果を表示しやすくなります。

ドライバ・レベルの統計をモニターするためのコールバック(非推奨)

注意:

この機能はWebLogic Server 10.3.6.0で非推奨となり、将来のリリースでは削除される可能性があります。

WebLogic Serverでは、JDBCドライバに対して呼び出されるメソッドのコールバックを提供しています。これらのコールバックは、実行されているメソッド、任意のスローされた例外、ドライバ・メソッドの実行に費やされた時間など、JDBCドライバの使用状況をモニターおよびプロファイリングするために使用できます。

コールバック機能を有効化するには、JDBCデータ・ソース記述子(モジュール)内のdriver-interceptor要素に対するコールバック・ハンドラの完全修飾パスを指定する必要があります。コールバック・ハンドラはweblogic.jdbc.extensions.DriverInterceptorインタフェースを実装している必要があります。JDBCドライバのコールバックが有効化されていると、WebLogic ServerはJDBCドライバ内の任意のメソッドの呼出し前と呼出し後に、登録されたコールバック・ハンドラのpreInvokeCallback()、postInvokeExceptionCallback()、またはpostInvokeCallback()メソッドを呼び出します。

アプリケーションがJDBCドライバを呼び出すと、必ずそのドライバを実装したクラスにコールバックが送信されます。

JDBCデータ・ソースのデバッグ

特定のアプリケーションに問題があると突き止めたら、WebLogic Serverのデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。

デバッグの有効化

デバッグは、適切なServerDebug構成属性を「true」に設定することで有効化できます。オプションで、サーバーのStdoutSeverityを「Debug」に設定することもできます。

構成属性は、以下のいずれかの方法で変更できます。

コマンド・ラインを使用してデバッグを有効化する

コマンド・ラインで適切なプロパティを設定します。例:

-Dweblogic.debug.DebugJDBCSQL=true
-Dweblogic.log.StdoutSeverity="Debug"

この方法は静的なものであり、サーバーの起動時にのみ使用できます。

WebLogic Server 管理コンソールを使用してデバッグを有効化する

WebLogic Server 管理コンソールを使用して、デバッグ値を設定します。

1. 管理コンソールのチェンジ・センターで「ロックして編集」をクリックします(まだ行っていない場合) (Oracle WebLogic Serverの理解のチェンジ・センターの使用に関する項を参照してください)。

2. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

3. 「サーバーの概要」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

4. 「デバッグ」をクリックします。

5. 「デフォルト」を展開します。

6. 変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。

7. 「有効化」 (または「無効化」)を選択して、チェックを入れたデバッグ・スコープまたは属性を有効化(または無効化)します。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

9. すべての変更がすぐに有効になるわけではありません - いくつかの変更を有効にするには、再起動する必要があります(Oracle WebLogic Serverの理解のチェンジ・センターの使用に関する項を参照してください)。
この方法は動的なものであり、サーバーの実行中にデバッグを有効化するのに使用できます。

WebLogic Scripting Toolを使用してデバッグを有効化する

WebLogic Scripting Tool (WLST)を使用してデバッグ値を設定します。たとえば、次のコマンドでは、debug.pyというデバッグ値を設定するためのプログラムが実行されます。

java weblogic.WLST debug.py

debug.py programプログラムには、次のコードが含まれています。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCSQL','true')
save()
activate()

JavaからもWLSTを使用することができることに注意してください。デバッグ値の設定に使用されるJavaファイルの例を示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJDBCSQL','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLSTの使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。

config.xmlファイルへの変更

コンソール、WLST、またはコマンド・ラインでデバッグ特性を変更すると、その内容がconfig.xmlファイルに反映されます。例13-1を参照してください。

例13-1 JDBCのデバッグ・スタンザのサンプル

.
.
.
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcsql>true</debug-jdbcsql>
</server-debug>
</server>
.
.
.

以下のconfig.xmlのサンプル(抜粋)に、トランザクション・デバッグのスコープ(複数のデバッグ属性)および1つのJDBC属性を示します。

JDBCのデバッグ・スコープ

次に、JDBCの登録されたデバッグ・スコープを示します。

- DebugJDBCSQL (スコープweblogic.jdbc.sql) - 引数と戻り値、スローされた例外など、呼び出されたすべてのJDBCメソッドに関する情報を出力します。

- DebugJDBCConn (スコープweblogic.jdbc.connection) - データ・ソース内のすべての接続予約および解放の操作、ならびに接続を取得したり閉じたりするためのすべてのアプリケーション・リクエストを追跡します。

- DebugJDBCONS (スコープweblogic.jdbc.rac) : 低レベルのONSデバッグをトレースします。

- DebugJDBCRAC (スコープweblogic.jdbc.rac) : RACデバッグをトレースします。

- DebugJDBCUCP (スコープweblogic.jdbc.rac) : 低レベルのUCPデバッグをトレースします。

- DebugJDBCREPLAY (スコープweblogic.jdbc.rac) : REPLAYデバッグをトレースします。

- DebugJDBCRMI (スコープweblogic.jdbc.rmi) - JDBCSQLと同様に、ただしRMIレベルで機能します。これとJDBCSQLを有効にすると、クライアントから呼び出される各操作につき、2セットのデバッグ・メッセージが取得されます。

- DebugJDBCInternal (スコープweblogic.jdbc.internal) - データ・ソース、接続環境、およびデータ・ソース・マネージャに関連するweblogic/jdbc/common/internalにおける低レベルのデバッグ。

- DebugJDBCDriverLogging (スコープweblogic.jdbc.driverlogging) - JDBCドライバ・レベルでのロギングを有効化します(これはServerMBean JDBCLoggingEnabledおよびgetJDBCLogFileNameの代わりとなります)。Oracleでドライバ・レベルのトレースを取得するには、ojdbc6.jarではなくojdbc6_g.jarを使用する必要があります。このデバッグ・スコープの場合、サーバー起動時にコマンド・ラインまたは構成によって一度オンにすることはできますが、(DriverManagerインタフェースがあるため)動的にオンまたはオフにすることはできません。

- DebugJTAJDBC (スコープweblogic.jdbc.transaction) : トランザクション・デバッグをトレースします。

UCP/ONSのデバッグの設定

WebLogic Serverリリース10.3.6.0以上では、UCPおよびONSのパッケージ名が再パッケージされなくなり、これらのコンポーネントのデバッグに影響します。

UCPのデバッグ

次のコマンドを使用して、UCPデバッグを直接設定します。

oracle.ucp.level = FINEST;
oracle.ucp.jdbc.PoolDataSource = WARNING;

ONSのデバッグ

ONSのデバッグを有効にするには、次のコマンドを使用します。

oracle.ons.debug=true

出力するには、次のコールを行います。

oracle.ons.ONS public static void setLogStream(PrintStream ps, PrintStream ps2);

リクエストの仕分け

デバッグの別のオプションとしては、JDBCサブシステムを介して個別の(通常は、「仕分けされた」)アプリケーション・リクエストのフローをのトレースする方法があります。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のDyeInjectionモニターによる仕分けベクトルの構成に関する項を参照してください。

14 WebLogic JDBCリソースの管理

この章では、管理コンソール、コマンドライン、JMXプログラムまたはWebLogic Scripting Tool (WLST)スクリプトを使用してドメイン内のJDBCデータ・ソースを管理する方法について説明します。

- データ・ソースおよびデータベース接続のテスト

- データ・ソースの文キャッシュの管理

- 接続プールの縮小

- 接続プールのリセット

- 接続プールの一時停止

- 接続プールの再開

- データ・ソースの停止

- データ・ソースの起動

- DBMSネットワーク障害の管理

データ・ソースおよびデータベース接続のテスト

JDBCDataSourceRuntimeMBean.testPool

データ・ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Serverでは、2種類の基本的なテストが行われます。データ・ソース上で属性を使って構成する自動テストと、データ・ソースのトラブルシューティングに利用できる手動テストです。

WebLogic Serverがプール接続の整合性を自動的に保てるようにすることで、DBMS接続に関する問題の大半は防げるはずです。自動接続テストの構成の詳細は、「データ・ソースの接続テスト・オプション」を参照してください。

データ・ソースからの接続の手動テストには、管理コンソールの「JDBCデータ・ソース: モニター: テスト」ページの「データ・ソースのテスト」機能(「JDBCデータ・ソースのテスト」を参照)またはJDBCDataSourceRuntimMBeanのtestPool()メソッドを使用できます。データ・ソースからのデータベース接続をテストするには、データ・ソースの構成で予約された接続のテストを有効化し、表名のテストを定義しておく必要があります。どちらも、管理コンソールを使用してデータ・ソースを作成した場合には、デフォルトで定義されます。

データ・ソースをテストする際、WebLogic Serverは接続を予約し、「表名のテスト」で定義した問合せを使用してそれをテストし、その後、接続を解放します。

データ・ソースの文キャッシュの管理

システム内のデータ・ソースにおける各接続について、WebLogic Serverは文キャッシュを作成します。接続でプリペアド文または呼出し可能文が使用されると、WebLogic Serverはその文をキャッシュして、再利用できるようにします。文キャッシュの詳細は、「文キャッシュによるパフォーマンスの向上」を参照してください。

データ・ソースの各接続は固有の文キャッシュを持ちますが、構成の設定はデータ・ソース内のすべての接続に対して行われます。管理コンソールを使用して、データ・ソース内のすべての接続について文キャッシュをクリアすることも、プログラムにより個々の接続について文キャッシュをクリアすることもできます。

データ・ソースの文キャッシュのクリア

JDBCDataSourceRuntimeMBean.clearStatementCache

データ・ソース内のすべての接続について文キャッシュを手動でクリアするには、管理コンソールを使用する(「JDBCデータ・ソース内の文キャッシュのクリア」を参照)か、またはJDBCDataSourceRuntimeMBeanのclearStatementCache()メソッドを使用します。

単一接続用の文キャッシュのクリア

weblogic.jdbc.extensions.WLConnection.clearStatementCache()
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearCallableStatement(java.lang.
String sql,int resType,int resConcurrency)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql)
weblogic.jdbc.extensions.WLConnection.clearPreparedStatement(java.lang.
String sql,int resType,int resConcurrency)

weblogic.jdbc.extensions.WLConnectionインタフェースのメソッドを使用すると、単一の接続用の文キャッシュをクリアするか、キャッシュから個別に文をクリアできます。これらのメソッドは、処理が正常に実行されるとtrueを返し、文が見つからなかったために処理が失敗するとfalseを返します。

プリペアド文と呼出し可能文がキャッシュに格納される場合、これらは正確なSQL文と、必要に応じて結果セット・パラメータ(タイプおよび同時実行性オプション)に基づいて格納(キー化)されます。個々のプリペアド文または呼出し可能文をクリアする場合は、適切な結果セット・パラメータを取るメソッドを使用する必要があります。たとえば、resSetTypeがResultSet.TYPE_SCROLL_INSENSITIVEでresSetConcurrencyがResultSet.CONCUR_READ_ONLYのキャッシュ内に呼出し可能文がある場合は、結果セット・パラメータを取るメソッドを使用することが必要です。

clearCallableStatement(java.lang.String sql,int resSetType,int resSetConcurrency)

パラメータとしてSQL文字列のみを取るメソッドを使用する場合は、メソッドは文を見つけられず、キャッシュからクリアされるものはありません。メソッドはfalseを返します。

現在アプリケーションによって使用中の文をクリアする場合、WebLogic Serverはその文をキャッシュから削除しますが、閉じはしません。現在使用中でない文をクリアする場合、WebLogic Serverはキャッシュからその文を削除して閉じます。

これらのメソッドの詳細は、WLConnectionのJavadocを参照してください。

接続プールの縮小

JDBCDataSourceRuntimeMBean.shrink

データ・ソースは、プール内の接続の初期数、最小数および最大数を定義するプロパティのセット(initialCapacity、minCapacityおよびmaxCapacity)を備えています。すべての接続が使用されている場合、データ・ソースは自動的に1つの接続をプールに追加します。プールがmaxCapacityに達すると、最大数の接続が開かれます。これらの接続は、データ・ソースの自動縮小を有効化するか、shrink()メソッドを使用して手動でデータ・ソースを縮小しない限り、開いたままになります。

ピーク使用期間の終了後、データ・ソースから一部の接続を削除して、WebLogic ServerおよびDBMSのリソースを解放したい場合があります。管理コンソールの「JDBCデータ・ソース」:「制御」ページの「縮小」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソース内の接続プールの縮小に関する項を参照)、または、JDBCDataSourceRuntimeMBeanのshrink()メソッドを使用できます。データ・ソースを縮小すると、WebLogic Serverはプール内の接続の数を、minCapacityと現在使用中の接続数のいずれか大きいほうの数まで削減します。

接続プールのリセット

JDBCDataSourceRuntimeMBean.reset

データ・ソース内のすべての使用可能なデータベース接続を閉じて再作成するには、管理コンソールの「JDBCデータ・ソース」:「制御」ページにある「リセット」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソース内の接続のリセットに関する項を参照)、またはJDBCDataSourceRuntimeMBeanのreset()メソッドを使用できます。これは、たとえば、DBMSの再起動後に必要になる場合があります。通常、データ・ソースの1つの接続に失敗した場合、プールの中のすべての接続が不正になります。

接続プールの一時停止

JDBCDataSourceRuntimeMBean.suspend
JDBCDataSourceRuntimeMBean.forceSuspend

データ・ソースを一時停止するには、管理コンソールの「JDBCデータ・ソース」:「制御」ページの「一時停止」および「強制中断」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの一時停止に関する項を参照)、または、JDBCDataSourceRuntimeMBeanのsuspend()およびforceSuspend()メソッドを使用します。

データ・ソースを一時停止する(強制中断ではない)場合、データ・ソースは無効化されたものとしてマークされ、アプリケーションはプールからの接続を使用できません。一時停止されたときにデータ・ソースからの接続をすでに予約していたアプリケーションは、その接続を使用しようとすると、例外を受け取ります。データ・ソース内のすべての接続は、データ・ソースが一時停止される前の状態のままで保持されます。

データ・ソースを強制的に一時停止すると、すべての接続プールは破棄され、予約接続を使用しようとする後続試行は失敗します。閉じられる接続上のトランザクションはロールバックされます。

接続プールの再開

JDBCDataSourceRuntimeMBean.resume

一時停止したデータ・ソースを再び有効にするには、管理コンソールの「JDBCデータ・ソース」:「制御」ページの「再開」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプの中断されているJDBCデータ・ソースの再開に関する項を参照)、または、JDBCDataSourceRuntimeMBeanのresume()メソッドを使用できます。データ・ソースを再開すると、WebLogic Serverはデータ・ソースを無効としてマークし、データ・ソースからの接続がアプリケーションで使用可能になります。データ・ソースを(強制中断ではなく)一時停止した場合、すべての接続はデータ・ソースの一時停止前と同じ状態に保持されます。データ・ソースの中断前に接続を予約してあったクライアントは、中断した箇所とまったく同じところから処理を続行できます。データ・ソースを強制的に一時停止した場合、クライアントは処理を続行するために新しい接続を確保する必要があります。

注意:

たとえばデータベース・サーバーが利用できない場合などの、正しく起動しなかったデータ・ソースは再開できません。

データ・ソースの停止

JDBCDataSourceRuntimeMBean.shutdown
JDBCDataSourceRuntimeMBean.forceShutdown

データ・ソースを停止するには、管理コンソールの「JDBCデータ・ソース」:「制御」ページの「停止」または「強制停止」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの停止に関する項を参照)、または、JDBCDataSourceRuntimeMBeanのshutdown()およびforceShutdown()メソッドを使用できます。

データ・ソースを停止する(強制停止ではない)場合、WebLogic Serverはデータ・ソース内のデータベース接続を閉じ、データ・ソースを停止します。データ・ソースのいずれかの接続が使用中の場合、この操作は失敗します。

データ・ソースを強制停止する場合、WebLogic Serverはデータ・ソース内のデータベース接続を閉じ、データ・ソースを停止します。現在の接続ユーザーはすべて強制的に切断されます。

データ・ソースの起動

JDBCDataSourceRuntimeMBean.start

データ・ソースの停止後、管理コンソールの「JDBCデータ・ソース」:「制御」ページにある「起動」オプションを使用するか(Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの起動に関する項を参照)、または、JDBCDataSourceRuntimeMBeanのstart()メソッドを使用できます。起動操作を実行すると、データ・ソースが再初期化されて接続が作成され、データ・ソースのヘルス状態が「実行中」になります。

DBMSネットワーク障害の管理

-Dweblogic.resourcepool.max_test_wait_secs=xx

xxは、WebLogic Serverが接続テストが失敗したと見なすまで接続テストを待機する秒数です。デフォルトでは、サーバー・インスタンスに10秒の値が割り当てられています。

このコマンド・ライン・フラグは、接続テストやアプリケーションの長時間のハング(たとえば10分間)を引き起こす可能性があるDBMSネットワーク障害のような障害を管理します。割り当てられた期間を過ぎると、サーバー・インスタンスはプールをパージして無効化し(すべての接続を閉じて、それ以上の予約の試行をブロック)、再接続が可能になり次第、プールを再び有効化します。

10秒という値は、DBMSが一時的にクライアントへのレスポンスを停止してから既存の接続上でサービスを再開する際に、最大のストレス負荷を許容できる合理的な時間です。ただし、待機時間が長すぎる場合や短かすぎる場合は、サーバーの起動に使用されるstartWebLogicスクリプトにフラグを追加して、使用する環境により適した値を指定してください。この時間の値をゼロ(0)秒に設定すると、サーバーはハングしている接続テスト上で無期限に待機します。

A JDBCアプリケーション・モジュールのデプロイメントの構成

この章では、エンタープライズ・アプリケーションをパッケージおよびスコーピングする方法について説明します。

エンタープライズ・アプリケーションをパッケージ化する際には、アーカイブにJDBCモジュールをパッケージ化し、適用可能なすべての記述子ファイルのJDBCモジュールへの参照を追加することにより、アプリケーション内にJDBCリソースを含めることができます。アプリケーションをデプロイする場合、JDBCリソースもデプロイされます。JDBCモジュールをどのように構成するかに応じて、アプリケーションとともにデプロイされるJDBCデータ・ソースは、それが含まれるアプリケーションによる使用のみに制限(アプリケーション・スコープのモジュール)されるか、またはすべてのアプリケーションおよびクライアントで使用可能(グローバル・スコープのモジュール)となるかのいずれかです。

次の項では、パッケージ化されたJDBCモジュールの詳細について説明します。

- JDBCモジュールとエンタープライズ・アプリケーションのパッケージ化:主な手順

- パッケージ化JDBCモジュールの作成

- Java EE記述子ファイルにおけるJDBCモジュールの参照

- エンタープライズ・アプリケーションとJDBCモジュールのパッケージ化

- エンタープライズ・アプリケーションとJDBCモジュールのデプロイ

- パッケージ化JDBCモジュールからのデータベース接続の取得

JDBCモジュールとエンタープライズ・アプリケーションのパッケージ化:主な手順

JDBCモジュールとエンタープライズ・アプリケーションの作成、パッケージ化、およびデプロイにおける主な手順は、以下のとおりです。

1. モジュールを作成します。「パッケージ化JDBCモジュールの作成」を参照してください。

2. すべての適用可能な記述子ファイル内のモジュールへの参照を追加します。「Java EE記述子ファイルにおけるJDBCモジュールの参照」を参照してください。

3. EAR内のすべてのアプリケーション・モジュールをパッケージ化します。「エンタープライズ・アプリケーションとJDBCモジュールのパッケージ化」を参照してください。

4. アプリケーションをデプロイします。「エンタープライズ・アプリケーションとJDBCモジュールのデプロイ」を参照してください。

パッケージ化JDBCモジュールの作成

JDBCアプリケーション・モジュールの作成には、XML記述子ファイルの作成をサポートする任意の開発ツールを使用できます。その後、JDBCモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、管理コンソールなど、JSR 88ベースのツールを使用します。

注意:

管理コンソールを使用してJDBCデータ・ソースを作成した後、アプリケーションで使用するテンプレートとしてモジュールをコピーすることができます。ネームスペース内での名前の競合を避けるため、モジュールをアプリケーションと一緒にデプロイする前に、モジュールのname要素とjndi-name要素を変更する必要があります。

各JDBCモジュールは、データ・ソースまたはマルチ・データ・ソースを表します。データ・ソースを表すモジュールには、そのデータ・ソースの構成パラメータがすべて含まれています。マルチ・データ・ソースを表すモジュールには、そのマルチ・データ・ソースが使用するデータ・ソース・モジュールのリストなどの、マルチ・データ・ソースの構成パラメータが含まれています。

管理コンソールを使用したJDBCデータ・ソース・モジュールの作成

管理コンソールで、アプリケーション・モジュールとして再利用できるデータ・ソース・モジュールを作成するには、以下の手順に従います。

1. 「JDBCデータ・ソースの作成」の説明に従ってデータ・ソースを作成します。データ・ソース・モジュールは、ドメイン・ディレクトリのconfig/jdbcサブディレクトリ内に作成されます。

2. アプリケーション内のサブディレクトリにdata-source-name.xmlファイルをコピーし、そのコピーのファイル名を、new-data-source-name-jdbc.xmlのように接尾辞として -jdbcを含むよう変更します。

3. エディタでファイルを開き、以下の要素を変更します。

- name - nameを、ドメイン内で一意の名前に変更します。

- jndi-name - jndi-nameを、エンタープライズ・アプリケーションでローカル・アプリケーション・コンテキスト内のデータ・ソースのルックアップに使用する名前に変更します。

- scope - 必要に応じて、データ・ソースが、それを含むアプリケーションからのみアクセスされるよう制限するため、モジュールのjdbc-data-source-paramsセクションにscope要素を追加します。たとえば、<scope>Application</scope>となります。「パッケージ化されたJDBCモジュールのアプリケーション・スコープ指定」を参照してください。

4. 続いて、エンタープライズ・アプリケーションの記述子ファイルへの参照を追加します。「Java EE記述子ファイルにおけるJDBCモジュールの参照」を参照してください。

JDBCパッケージ化モジュールの要件

JDBCモジュールは、以下の条件を満たしている必要があります。

- jdbc-data-source.xsdスキーマに準拠しています。このスキーマはhttp://xmlns.oracle.com/weblogic/jdbc-data-source/1.2/jdbc-data-source.xsdにあります。

- -jdbc.xmlで終わるファイル名を使用しています。

- WebLogicドメイン内で一意のname要素が含まれています。

データ・ソースはまた、以下のJDBCドライバ・パラメータを備えている必要があります。

- url

- driver-name

- properties - ユーザー名、パスワードなど、データベース接続を作成するためにJDBCドライバが必要とするすべてのプロパティを含みます。

マルチ・データ・ソース・モジュールはまた、以下のデータ・ソース・パラメータを備えている必要があります。

- data-source-list - これは、アプリケーションからのデータベース接続リクエストに応じるためにマルチ・データ・ソースが使用する、カンマ区切りのデータ・ソース・モジュール・リストです。

注意:

data-source-listにリストされているデータ・ソースはすべて、XAおよびトランザクション・プロトコル設定が同じである必要があります。

その他の構成パラメータはすべて、任意指定であるか、または値が指定されていなければ、WebLogic Serverが使用するデフォルト値となります。ただし、有用なJDBCモジュールを作成するには、アプリケーションおよび環境に必要な追加の構成オプションを指定しなければならない場合があります。

JDBCアプリケーション・モジュールの制限事項

JDBCアプリケーション・モジュールについては、以下の制限事項に留意してください。

- LoggingLastResourceのglobal-transactions-protocolは、JDBCアプリケーション・モジュールでは使用できません。

- 本番でアプリケーション・スコープのJDBCリソースとともにアプリケーションをデプロイする場合、リソースがglobal-transactions-protocolにEmulateTwoPhaseCommitを使用していると、同時に複数バージョンのアプリケーションをデプロイすることはできません。

JDBCデータ・ソース・モジュールの作成

JDBCデータ・ソース・モジュール内の主要なセクションは、以下のとおりです。

- jdbc-driver-paramsには、データベース接続を作成するために使用されるJDBCドライバのエントリ、URL、driver-nameおよび個別ドライバのpropertyエントリが含まれます。その他の有効なエントリについては、jdbc-data-source.xsdスキーマを参照してください。各要素の説明については、Oracle WebLogic Server MBeanリファレンスのJDBCDriverParamsBeanに関する項を参照してください。

- jdbc-connection-pool-params - 接続テスト・オプション、文キャッシュ・オプションなど、接続プールの構成用のエントリを含みます。この要素はまた、initial-capacity、max-capacity、およびプールされたリソースに共通のその他のオプションを含む、weblogic-javaee.xsdスキーマからのconnection-pool-paramsを継承しています。詳細は、次を参照してください。

- Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項

- jdbc-data-source.xsdスキーマ

- jdbc-data-source-paramsには、jndi-name、row-prefetch-sizeおよびglobal-transactions-protocolなどデータ・ソース動作オプションおよびトランザクション処理オプションのエントリが含まれます。その他の有効なエントリについては、jdbc-data-source.xsdスキーマを参照してください。各要素の説明については、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceParamsBeanを参照してください。

- jdbc-xa-paramsには、keep-xa-conn-till-tx-completeおよびxa-transaction-timeoutなどXAデータベース接続処理のオプションに関するエントリが含まれます。各要素の説明は、Oracle WebLogic Server MBeanリファレンスのJDBCXAParamsBeanに関する項を参照してください。

例A-1に、データ・ソースのJDBCモジュールの例を、いくつかの一般的な構成オプションとともに示します。

例A-1 サンプルJDBCデータ・ソース・モジュール

<jdbc-data-source xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/domain.xsd"
xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<name>examples-demoXA-2</name>
<jdbc-driver-params>
<url>jdbc:derby://localhost:1527/examples;create=true</url>
<driver-name>org.apache.derby.jdbc.ClientXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>examples</value>
</property>
<property>
<name>DatabaseName</name>
<value>examples</value>
</property>
</properties>
<password-encrypted>{AES}MEK6bPum8M69KRP4FANx3TG/O0iSWRYu2rZGUwnVo6U=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<max-capacity>100</max-capacity>
<connection-reserve-timeout-seconds>25</connection-reserve-timeout-seconds>
<test-table-name>SQL SELECT 1 FROM SYS.SYSTABLES</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<global-transactions-protocol>TwoPhaseCommit</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>

JDBCマルチ・データ・ソース・モジュールの作成

JDBCマルチ・データ・ソース・モジュールは、データ・ソース・モジュールと比べると非常に単純です。必要とされるメイン・セクションはjdbc-data-source-paramsの1つのみです。マルチ・データ・ソース内のjdbc-data-source-params要素は、データ・ソースの動作オプションではなく、マルチ・データ・ソースの動作オプションを含むという点が異なります。jdbc-data-source-params内の以下のパラメータだけがマルチ・データ・ソースでは有効です。

- jndi-name (必須)

- data-source-list (必須)

- scope

- algorithm-type

- connection-pool-failover-callback-handler

- failover-request-if-busy

各要素の説明については、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceParamsBeanに関する項を参照してください。

例A-2に、データ・ソースのJDBCモジュールの例を、いくつかの一般的な構成オプションとともに示します。

例A-2 JDBCマルチ・データ・ソース・モジュール

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source">
<name>examples-demoXA-multi-data-source</name>
<jdbc-data-source-params>
<jndi-name>examples-demoXA -multi-data-source</jndi-name>
<algorithm-type>Load-Balancing</algorithm-type>
<data-source-list>examples-demoXA,examples-demoXA-2</data-source-list>
</jdbc-data-source-params>
</jdbc-data-source>

JDBCモジュールにおけるデータベース・パスワードの暗号化

データ保護のために、JDBCモジュール内のデータベース・パスワードを暗号化することをお薦めします。データベース・パスワードを暗号化するには、WebLogic Serverの暗号化ユーティリティを使用してパスワードを暗号化します - これにより、暗号化されたパスワードが戻されるので、それをJDBCモジュールにpassword-encrypted要素として入力します。WebLogic Serverの暗号化ユーティリティの使い方の詳細は、WebLogic Scripting Toolコマンド・リファレンスの暗号化に関する項を参照してください。

JDBCモジュールを新しいドメインにデプロイする

アプリケーションを開発から本番に移行するなど、JDBCモジュールを、あるドメインから別のドメインに移動するのは、よく行われることです。しかし、WebLogic Server暗号化ユーティリティによって生成される暗号化キーは、新しいドメインに転送することができません。JDBCモジュールを暗号化されたデータベース・パスワードとともに移動する場合は、以下のいずれかを行う必要があります。

- 特に新しいドメインに対して暗号化されたパスワードを含むデプロイメント計画内の古い暗号化パスワードをオーバーライドします。Oracle WebLogic Server管理コンソール・ヘルプのデプロイメント計画の更新に関する項を参照してください。

- 新しいドメイン用のパスワードを再暗号化します。「JDBCモジュールにおけるデータベース・パスワードの暗号化」を参照してください。

パッケージ化されたJDBCモジュールのアプリケーション・スコープ指定

デフォルトでは、アプリケーションにJDBCモジュールをパッケージ化するとき、JDBCリソースはグローバルにスコープ指定されます。つまり、リソースはグローバルJNDIネームスペースにバインドされ、すべてのアプリケーションおよびクライアントで使用可能です。リソースを、それを包含するアプリケーションのみで使用できるように予約するには、JDBCモジュールのjdbc-data-source-params要素に<scope>Application</scope>パラメータを含める必要があります。これにより、リソースはローカル・アプリケーション・ネームスペースにバインドされます。例:

<jdbc-data-source-params>
<jndi-name>examples-demoXA-2</jndi-name>
<scope>Application</scope>
</jdbc-data-source-params>

アプリケーション・スコープのJDBCモジュールのマルチ・データ・ソース内のデータ・ソースは、やはりアプリケーション・スコープ指定されている必要があります。

Java EE記述子ファイルにおけるJDBCモジュールの参照

JDBCモジュールをエンタープライズ・アプリケーションとパッケージ化する場合、特に以下のものを含む、すべての適用可能な記述子ファイル内のモジュールを参照する必要があります。

- weblogic-application.xml

- ejb-jar.xml

- weblogic-ejb-jar.xml

- web.xml

- weblogic.xml

図A-1は、EJBアプリケーションの様々な記述子ファイルにおけるエントリ間の関係と、それらがアプリケーションとパッケージ化されたJDBCモジュールをどのように参照しているかを示します。

図A-1 エンタープライズ・アプリケーションにおけるJDBCモジュールと記述子の関係

「図A-1 エンタープライズ・アプリケーションにおけるJDBCモジュールと記述子の関係」の説明

weblogic-application.xmlでのパッケージ化JDBCモジュールの参照

エンタープライズ・アプリケーションにJDBCモジュールを含める際には、アプリケーションとパッケージ化されるweblogic-application.xml記述子ファイルにおいて、各JDBCモジュールをJDBC型のmodule要素としてリストする必要があります。例:

<module>
<name>data-source-1</name>
<type>JDBC</type>
<path>datasources/data-source-1-jdbc.xml</path>
</module>

その他の記述子におけるパッケージ化JDBCモジュール参照

エンタープライズ・アプリケーションにおいて、他のアプリケーション・モジュールが、アプリケーションとパッケージ化されるJDBCモジュールを使用できるようにするには、アプリケーション・モジュールとパッケージ化される記述子ファイルに、以下のエントリを追加する必要があります。

- アプリケーション・モジュールとパッケージ化されている標準のJava EE記述子ファイル(EJBの場合はejb-jar.xmlなど)に、resource-ref-name参照を追加し、アプリケーションで使用されているデータ・ソースのJNDI名を指定する必要があります。例:

<resource-ref>
<res-ref-name>my-data-source</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

この例では、my-data-sourceはアプリケーション・モジュールで使用されているデータ・ソース名です。アプリケーションは、次のコードによってデータ・ソースをルックアップします。

javax.sql.DataSource ds =
(javax.sql.DataSource) ctx.lookup("java:comp/env/my-data-source");

- WebLogic固有の記述子ファイル(EJBの場合はweblogic-ejb-jar.xmlなど)においては、データ・ソースのjndi-name要素への各resource-ref-name参照をマップする必要があります。例:

<resource-description>
<res-ref-name>my-data-source</res-ref-name>
<jndi-name>qa-database-1</jndi-name>
</resource-description>

この例では、標準の記述子からのリソース名(<res-ref-name>my-data-source</res-ref-name>)が、JDBCモジュール内のデータ・ソースのJNDI名(<jndi-name>qa-database-1</jndi-name>)にマップされています。

図A-1は、アプリケーション・モジュールで使用されるデータ・ソース名の、JDBCモジュールのJDBCデータ・ソースのJNDI名へのマッピングを示します。

注意:

アプリケーション・スコープのデータ・ソースの場合、記述子ファイルにこれらのエントリを追加しなければ、アプリケーションはデータ・ソースをルックアップしてデータベース接続を取得することができません。

エンタープライズ・アプリケーションとJDBCモジュールのパッケージ化

他のエンタープライズ・アプリケーションの場合と同様、JDBCモジュールではアプリケーションをパッケージ化します。『Oracle WebLogic Serverアプリケーションの開発』のwlpackageを使用したアプリケーションのパッケージ化に関する項を参照してください。

エンタープライズ・アプリケーションとJDBCモジュールのデプロイ

他のエンタープライズ・アプリケーションの場合と同様、JDBCモジュールではアプリケーションをデプロイします。『Oracle WebLogic Serverアプリケーションの開発』のwldeployを使用したアプリケーションのデプロイに関する項を参照してください。

注意:

本番でアプリケーション・スコープのJDBCリソースとともにアプリケーションをデプロイする場合、リソースがglobal-transactions-protocolにEmulateTwoPhaseCommitを使用していると、同時に複数バージョンのアプリケーションをデプロイすることはできません。

パッケージ化JDBCモジュールからのデータベース接続の取得

エンタープライズ・アプリケーションとパッケージ化されたJDBCモジュールからの接続を取得するには、ローカル環境(java:comp/env)またはJNDIツリーのJDBCモジュールで定義されたデータ・ソースまたはマルチ・データ・ソースをルックアップし、その後データ・ソースまたはマルチ・データ・ソースからの接続をリクエストします。例:

javax.sql.DataSource ds =
(javax.sql.DataSource) ctx.lookup("java:comp/env/my-data-source");
java.sql.Connection conn = ds.getConnection();

接続を使い終わったら、必ずその接続を閉じて、データ・ソースの接続プールに戻すようにしてください。

conn.close();

B Oracle RACでのマルチ・データ・ソースの使用

この章では、WebLogic ServerでOracle Real Application Clusters (RAC)を使用する際にマルチ・データ・ソースを構成して使用する方法について説明します。Oracleは、RACを使用したレガシー・アプリケーション環境用のマルチ・データ・ソース構成を引き続きサポートします。

- Oracle Real Application Clustersの概要

- ソフトウェア要件

- JDBCドライバ要件

- ハードウェア要件

- Oracle RACでのマルチ・データ・ソースの構成

- グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用

- グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用

- Oracle RACノード上のサービスに対する接続の構成

- Oracle RACでマルチ・データ・ソースを使用する場合のXAの考慮事項と制限事項

- Oracle RACでのJDBCストアのリカバリ

Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを一緒に使用するには、クラスタリング・ソフトウェアおよび共有ストレージ・ソリューションに加え、両方のシステム上での固有の構成が必要になります。この節では、要求される構成について概要レベルで説明します。Oracle RAC、使用しているクラスタリング・ソフトウェア、使用しているオペレーティング・システム、および使用しているストレージ・ソリューションの構成に関する詳細は、それぞれのベンダーが提供するドキュメントを参照してください。

注意:

新規のOracle RACアプリケーションを開発する場合、レガシー・アプリケーションがマルチ・データ・ソースを使用していない場合、GridLinkデータ・ソースの使用をお薦めします。「WebLogic ServerでのOracle RACの使い方」を参照してください。

Oracle Real Application Clustersの概要

Oracle Real Application Clusters (Oracle RAC)は、複数のマシンのユーザーが単一のデータベースに高いパフォーマンスでアクセスすることを可能にする高可用性ソリューションに追加できるソフトウェア・コンポーネントです。Oracle RACは、複数のクラスタ化マシン上で実行され、クラスタ技術によって共有ストレージ・デバイスにアクセスする複数のOracleデータベース・インスタンスで構成されます。このアーキテクチャをサポートするため、データベース・インスタンスをホストするマシンは高速のインターコネクトでリンクされて、クラスタを形成します。インターコネクトとは、クラスタのノード間の通信手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサード・パーティのクラスタリング・ソフトウェアによって提供されます。図B-1にOracle RACの構成を示します。

図B-1 Oracle Real Application Clustersの構成

「図B-1 Oracle Real Application Clustersの構成」の説明

Oracle RACでは次の領域の機能が提供されます。

- WebLogic Serverマルチ・データ・ソースでのOracle RACの拡張性

- WebLogic Serverマルチ・データ・ソースでのOracle RACの可用性

- WebLogic Serverマルチ・データ・ソースでのOracle RACのロード・バランシング

WebLogic Serverマルチ・データ・ソースでのOracle RACの拡張性

インストールされているOracle RACは、単一の標準的なOracleデータベースのように見え、同じツールと実行方法で管理されます。クラスタのすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACにより各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、Oracle RACノード、ストレージ、またはその両方を追加することで、処理とリクエストの増加に伴い、データベース層を水平方向に拡張できます。

Oracle RAC内のノード数が増加するに連れて、Oracle RACに追加されたノード数ごとに汎用データ・ソースの数をスケールします。これには、Oracle RACトポロジが変更するときに管理者の介入が必要な複雑な構成(n+1個のデータ・ソースが必要です。ここで、nは一般データ・ソース+マルチ・データ・ソースの数)が求められます。

WebLogic Serverマルチ・データ・ソースでのOracle RACの可用性

マルチ・データ・ソースは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。「フェイルオーバー」および「マルチ・データ・ソース管理フェイルオーバーおよびロード・バランシング」を参照してください。

WebLogic Serverマルチ・データ・ソースでのOracle RACのロード・バランシング

マルチ・データ・ソースで、XAや非XA環境のロード・バランシングが可能になります。マルチ・データ・ソースを構成する汎用データ・ソースは、ラウンドロビン・スキームでアクセスされます。接続を切り替えると、WebLogic Serverは、注文リストの次の汎用データ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソースの使用方法の詳細は、「Oracle RACでのマルチ・データ・ソースの使用方法」を参照してください。

ソフトウェア要件

WebLogic ServerをOracle RACで使用するには、各Oracle RACノードに次のソフトウェアをインストールする必要があります。

- Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleが提供するリリース・ノートを参照してください。

- Oracle 11gデータベース管理システム

- 使用しているオペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアおよびクラスタ構成については、Oracleのドキュメントを参照してください。

- Veritas Cluster File Systemなどの共有ストレージ・ソフトウェア。一部のクラスタリングソフトウェアには、ファイル・ストレージ・ソリューションが含まれています。その場合は、共有ストレージ・ソフトウェアは必要ありません。

注意:

最新のWebLogic Serverハードウェア・プラットフォームおよびオペレーティング・システムのサポート、およびWebLogic Serverのバージョンおよびサービス・パックでサポートされるOracle RACバージョンについては、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。Oracle RACソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracleのドキュメントを参照してください。

JDBCドライバ要件

WebLogic ServerをOracle RACとともに使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thin Driver 11gを使用して、データベース接続を作成する必要があります。

ハードウェア要件

WebLogic ServerおよびOracle RACの標準的なシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが含まれます。

WebLogic Serverクラスタ

WebLogic Serverクラスタは、さまざまハードウェア・オプションを使用して多くの方法で構成できます。WebLogic Serverクラスタの構成については、『Oracle WebLogic Serverクラスタの使用』を参照してください。

Oracle RACクラスタ

Oracle RACに関する最新のハードウェア要件については、Oracle RACのドキュメントを参照してください。ただし、WebLogic ServerでOracle RACを使用するには、堅牢な製品レベル品質のハードウェア上でOracle RACインスタンスを実行する必要があります。Oracle RACの構成では、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースのレスポンスが著しく遅れると、データベースのフェイルオーバー処理の間に予期しない動作が生じるおそれがあります。

共有ストレージ

Oracle RACの構成では、データ・ファイル、制御ファイル、およびパラメータ・ファイルはすべて、各Oracle RACインスタンスで共有されて使用されます。次のいずれかのアーキテクチャを使用するHAストレージ・ソリューションをお薦めします。

- デュアル・ポート・ディスク配列などのダイレクト・アタッチド・ストレージ(DAS)またはストレージ・エリア・ネットワーク(SAN)

- ネットワーク・アタッチド・ストレージ(NAS)

サポートされているストレージ・ソリューションの全リストについては、Oracleのドキュメントを参照してください。

Oracle RACでのマルチ・データ・ソースの構成

Oracle RACでマルチ・データ・ソースを使用する場合、Oracle RACインスタンスと対話でき、期待どおりに動作するようにWebLogicドメインを構成する必要があります。次の項では、構成のオプションと要件について説明します。

- Oracle RACで使用するマルチ・データ・ソースの構成の選択

- Oracle RACで使用するマルチ・データ・ソースの構成

- フェイルオーバーの構成に関する考慮事項

- 各Oracle RACインスタンスのリスナー・プロセスの構成

- リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成

- 構成の追加考慮

Oracle RACで使用するマルチ・データ・ソースの構成の選択

WebLogic Serverマルチ・データ・ソースは、Oracle RACの使用に当たり、いくつかの構成オプションをサポートします。

- グローバル・トランザクション(XA)を使用している場合に、複数のOracle RAC 11gインスタンスに接続するには、「グローバル・トランザクションでのマルチ・データ・ソースの使用」を参照してください。

- XAを使用していない場合に、複数のOracle RAC 11gインスタンスに接続するには、「グローバル・トランザクション以外でのマルチ・データ・ソースの使用」を参照してください。

- Oracle RACノードの実行中の特定のサービスに接続するマルチ・データ・ソースも構成できます。XAと非XAドライバの両方がサポートされています。Oracle RACノード上のサービスへの接続の構成に関する項を参照してください。

Oracle RACで使用するマルチ・データ・ソースの構成

マルチ・データ・ソースを使用してWebLogic Serverと複数のOracle RACノードを接続するには、まずOracle RACクラスタ内の各Oracle RACインスタンスに、Oracle Thin DriverとともにJDBCデータ・ソースを構成します。次に、ロード・バランシングのアルゴリズムとフェイルオーバーのアルゴリズムのどちらかを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。

図B-2に、一般的なマルチ・データ・ソースの構成を示します。

図B-2 マルチ・データ・ソースの構成

「図B-2 マルチ・データ・ソースの構成」の説明

ドメインを構成するには、管理コンソールか、または、WebLogic Scripting Tool (WLST)やJMXプログラムなどのお好きな方法を使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。マルチ・データ・ソース内のデータ・ソースを、Oracle RACノードで実行中のサービスに接続できるように構成する方法については、「Oracle RACノードのサービスに対する接続の構成」を参照してください。

この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つルックアップしてから、接続をリクエストします。マルチ・データ・ソースは、構成で指定されたアルゴリズムの種類に基づいて、接続リクエストに応じるためにどちらのデータ・ソース(つまり、フェイルオーバーまたはロード・バランシング)を使用するかを決定します。

マルチ・データ・ソースの属性

マルチ・データ・ソースは、システム内のOracle RACの役割(ロード・バランシングまたはフェイルオーバー)によっては、次の属性を持ちます。

- AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"
Load-Balancingを指定すると、接続リクエストは利用可能なデータ・ソース群に渡って分散されます。High-Availabilityを指定した場合、接続リクエストはリストの最初にある利用可能なプールで処理されます。データ・ソースが切断された場合、接続リクエストはリスト内の次のデータ・ソースで処理されます。

- FailoverRequestIfBusy="true"
フェイルオーバー・アルゴリズムとともにこの属性を指定すると、データ・ソース内の接続がすべて使用中の場合にフェイルオーバーできるようになります。

- TestFrequencySeconds="120"
この属性は、WebLogic Serverが以前に「異常」としてマークしたデータ・ソースのヘルス状態をチェックして、接続を再作成できるかどうか、およびデータ・ソースを再有効化できるかどうかを確認する頻度を制御します。詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

Oracle RACノードの高速フェイルオーバーのためには、この値に短い間隔 - たとえば、10(秒) - を設定します。

フェイルオーバーの構成に関する考慮事項

フェイルオーバーを構成する際には、次の情報について考慮する必要があります。

マルチ・データ・ソースが管理するフェイルオーバーとロード・バランシング

マルチ・データ・ソースでは、グローバル・トランザクションのフェイルオーバーおよびロード・バランシングが可能になります。マルチ・データ・ソースのフェイルオーバー機能の説明は、「マルチ・データ・ソースのフェイルオーバー・エンハンスメント」を参照してください。

図B-2に示すこの構成を使用すると、次の利点があります。

- マルチ・データ・ソース制御による、高速なフェイルオーバー

- WebLogic Serverヘルス・モニターによる、自動フェイルバック

マルチ・データ・ソースは、Oracle RACノードが利用不可能な場合にデータベース接続用フェイルオーバーを処理します。WebLogic Serverで接続テストに失敗した場合、接続の再作成を試みます。それに失敗した場合、サーバーでは、マルチ・データ・ソースの他のデータ・ソース(他のOracle RACノードに対応)に対するルート接続リクエストとデータ・ソースが無効に設定されます。WebLogic Serverは、無効化されたデータ・ソースのデータベース接続の再作成を定期的に試みます。接続が正常に再作成された場合、次にデータ・ソースを再有効化し、データ・ソースへの接続リクエストのルーティングを開始します。接続リクエストのルーティングおよび正常性チェックの機能により、最小時間で失敗後の接続リクエストを満たします。

フェイルオーバー中の遅延

あるOracle RACノードが別のOracle RACノードにフェイルオーバーした場合、現在障害の発生しているノードの処理中のトランザクション・ブランチに関連するデータがクラスタ全体で利用可能になるまでに、遅延が発生することがあります。これにより、未完了のトランザクションが適切に完了できなくなり、さらにはデータベース内でデータのロックが発生することがあります。このような遅延発生の可能性を防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsとXARetryIntervalSecondsが用意されています。

XARetryDurationSecondsは、保留中のトランザクションのXA操作(回復、コミット、ロールバックなど)の再試行を繰り返す間隔を指定します。XARetryIntervalSecondsでは、設定した期間内に再試行する頻度を指定します。

XA呼出しの再試行を有効化するには、Oracle RACインスタンスに接続するWebLogicドメイン内のすべてのJDBCデータ・ソースに対して、XARetryDurationSecondsの値を追加で指定します。例:

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACXAPool</name>
...
<jdbc-xa-params>
...
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>

XARetryDurationSecondsの値は、次の式で決定します。

XARetryDurationSeconds = (データ・ソースからの接続を使用するトランザクションの最長トランザクション・タイムアウト) + (XIDがすべてのOracle RACノードで利用可能になるまでの遅延、通常は5分未満)

たとえば、アプリケーションで設定されている最長のトランザクション・タイムアウトが180秒の場合には、XARetryDurationSecondsを180秒+ 300秒の合計、つまり480秒に設定します。

注意:

一般にXARetryDurationSecondsは、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。

必要に応じて、XARetryIntervalSecondsにも値を設定できます。この値は、XA呼出しの再試行の間隔を決定します。デフォルトでは、この値は60秒です。値を小さくすると、XAの再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。

管理コンソールからXARetryDurationSecondsおよびXARetryIntervalSecondsを有効化するには、次の手順を使用します。

1. まだそうしていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで「サービス」>「JDBC」を展開し、「データ・ソース」を選択します。

3. 「データ・ソースのサマリー」ページでデータ・ソース名をクリックします。

4. 構成: 接続プールタブを選択します。

5. 画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。

6. 「XA再試行期間」]および「XA再試行間隔」を更新します。

7. 「保存」をクリックします。

オプションで、WebLogic Scripting Tool (WLST)またはJMXプログラムを使用できます。

グローバル・トランザクションにおける障害処理の段階的な説明

ノードに障害が発生した場合、データベースに対する処理中のトランザクションには何が起こるのでしょう。プライマリOracle RACノードに障害が発生した場合はどうでしょうか。WebLogic Serverでは、透過的なフェイルオーバーはサポートされていますか。こうした疑問やWebLogic Serverでの障害処理に関するその他の質問への回答として、トランザクション処理の段階を順を追って説明し、その中で各段階での障害の処理方法について解説します。

障害が発生する最初の段階は、アプリケーションがコミットするトランザクションを呼び出す前である可能性があります。この段階でデータベースまたはOracle RACノードに障害が発生した場合、アプリケーションは例外を受け取り、新しい接続を取得してトランザクションの処理を新たに試行する必要が生じます。WebLogic Serverは、透過的フェイルオーバーをサポートしていません。

アプリケーションがトランザクションをコミットする呼出しを行った後で障害が発生した場合、処理中のトランザクションの扱いはPREPARE操作が完了しているかどうかによって変わります。PREPARE操作が完了していない場合、トランザクション・マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外がスローされます。PREPARE操作が完了している場合、トランザクション・マネージャは別のノードを使用して処理中のトランザクションを完了しようとします。

COMMIT操作の間に障害が発生した場合、トランザクション・マネージャではCOMMIT操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。その後トランザクション・マネージャは、成功するまで定期的にCOMMIT操作を再試行し続けます。トランザクションが破棄時間までの間に正常に完了できなかった場合、トランザクションはヒューリスティックな完了を余儀なくされます。

各Oracle RACインスタンスのリスナー・プロセスの構成

リスナー・プロセスは、Oracle RACに、ユーザー・プロセスとOracleインスタンス間で通信経路を確立します。WebLogic ServerでOracle RACを使用する場合、ユーザー・プロセスは通常、JDBCデータ・ソースです。

マルチ・データ・ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ・ソース容量が増えるように構成されている場合、データ・ソースは、構成ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。

図B-3にOracleリスナー・プロセスの機能を示します。

図B-3 Oracleリスナー・プロセスの機能

「図B-3 Oracleリスナー・プロセスの機能」の説明

この機能を有効にするには、2つのオプションがあります。

- ローカル・リスナーを使用します。Oracleクラスタ内の各Oracle RACインスタンスごとにリスナー・プロセスを構成します。各Oracle RACインスタンスについてローカル・リスナーの構成が必要です。各データベース・インスタンスは、そのローカル・リスナーのみ登録するように構成する必要があります。
Oracleインスタンスのリスナー登録は、listener.oraファイルで静的に構成したり、インスタンスの初期化パラメータlocal_listenerを使用して動的に登録できます(両方で登録可能)。動的に登録することをお薦めします。

リスナーは、共有ディスパッチ・プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Serverを使用する場合、専用プロセスの使用をお薦めします。

- リモート・リスナーを使用します。WLSでは、マルチ・データ・ソース内のデータ・ソースのJDBC URLでSERVICE_NAMEとINSTANCE_NAMEの両方を指定する必要があります。「リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成」を参照してください。

リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成

Oracle RACバックエンドに対して、サーバー側のロード・バランシング機能が(remote_listenersを使用して)有効化されている場合は、マルチ・データ・ソース構成のデータ・ソースに使用されたJDBC URLには、INSTANCE_NAMEを含める必要があります。たとえば、次の形式でURLを指定できます。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))

URLにINSTANCE_NAMEを指定できない場合、リモート・リスナーを無効に設定する必要があります。リモート・リスナーを無効に設定するには、各Oracle RACノード上のspfile.ora内にリストされている任意のリモート・リスナーを削除します。例:

*.remote_listener="

この場合、マルチ・データ・ソース構成のデータ・ソースで使用するには次のURLをお薦めします。

jdbc:oracle:thin:@host-vip:port/dbservice

または

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(
CONNECT_DATA=(SERVICE_NAME=dbservice)))

構成の追加考慮

Oracle RACの一部のデプロイメントでは、Oracle RAC構成のデータ・ソースの初期構成以外にパラメータを追加する必要があります。追加するパラメータを次に示します。

- データ・ソース毎にoracle.jdbc.ReadTimeout=300000 (300000ミリ秒)を設定します。
実際に使用するReadTimeoutパラメータの値は、アプリケーションの環境によって異なる場合があります。

- 信頼性がないネットワークでは、サーバーが突然切断されることで発生する頻度の高い切断を検出するのがクライアントにとって困難になります。デフォルトでは、Linux稼働中のクライアントは、突然の切断を検出できるのに7200秒(2時間)かかります。これは、tcp_keepalive_timeプロパティと同等の値です。早期に切断を検出できるようにアプリケーションを構成するには、tcp_keepalive_time、tcp_keepalive_interval、およびtcp_keepalive_probesプロパティの値を、オペレーティング・システム・レベルで低い値に設定してください。

注意:

tcp_keepalive_intervalプロパティに低い値を設定すると、パケットのプローブが高い頻度で発生するようになり、その結果、システムの速度が遅くなります。このプロパティの値は、ご使用のアプリケーション環境のシステム要件に応じて設定してください。

たとえば、WebLogic Server管理対象サーバーが実行中のシステムでは、tcp_keepalive_time=600と設定します。

- 接続記述子のDESCRIPTION句で、ENABLE=BROKENパラメータを指定します。例:
jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.mycompany.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))

次に示すコードの抜粋は、データ・ソース構成の例です。

<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>oracle.jdbc.ReadTimeout</name>
<value>300000</value>
</property>
<property>
<name>user</name>
<value>jmsuser</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>

グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用

この構成では、マルチ・データ・ソースによってトランザクションが必ず1つのOracle RACインスタンスに固定されます。個々のトランザクションはトランザクションに対する最初の接続リクエスト時にロード・バランシングされます。Oracle RACインスタンスが使用できなくなった場合は、マルチ・データ・ソース・レベルでフェイルオーバーが処理されます。PREPARE操作の前にOracle RACインスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバーされます。

- グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースのルール

- グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースで必要な属性

- サンプル構成コード

グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースのルール

マルチ・データ・ソース内のXAデータ・ソースには、以下のルールが適用されます。

- すべてのデータ・ソースが均一である必要があります。つまり、すべてのデータ・ソースがXAドライバを使用することが必要であるか、またはXAドライバを使用できるデータ・ソースはありません。

- すべてのXA関連の属性について、指定する場合には、各データ・ソースに同じ値を設定する必要があります。こうした属性には以下のものがあります。

- XARetryDurationSeconds

- SupportsLocalTransaction

- KeepXAConnTillTxComplete

- NeedTxCtxOnClose

- XAEndOnlyOnce

- NewXAConnForCommit

- RollbackLocalTxUponConnClose

- RecoverOnlyOnce

- KeepLogicalConnOpenOnRelease

注意:

GridLinkデータ・ソースを使用していない場合、XAまたは非XAの環境にかかわらず、Oracle RACインスタンス全体でフェイルオーバーやロード・バランシングに対してマルチ・データ・ソースの使用をお薦めします。非XA環境でのマルチ・データ・ソースの使用方法の詳細は、「グローバル・トランザクション以外でのマルチ・データ・ソースの使用方法」を参照してください。

グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースで必要な属性

マルチ・データ・ソース内の各データ・ソースには、以下の属性が必要です。

- Oracle Thin JDBC Driver 11g。例:

<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>

- KeepXAConnTillTxComplete="true"

- 分散トランザクションが完了するまでのトランザクション処理の間中、必ずデータ・ソースで物理データベース接続を予約し、アプリケーションに同じ接続を提供するようにします。

- これは、Oracle RACでの適切なトランザクション処理のためには必須です。

- XARetryDurationSeconds="300"

- WebLogic Serverのトランザクション・マネージャによる、指定された時間内でのXAの回復、コミット、ロールバック呼出しの再試行を有効にします。

- TestConnectionsOnReserve="true"

- アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。

- 別のOracle RACノードのフェイルオーバーを有効にする必要があります。

- TestTableName="name_of_small_table"。物理データベース接続のテストに使用される表の名前です。この属性の詳細については、「データ・ソースの接続テスト・オプション」を参照してください。

サンプル構成コード

マルチ・データ・ソース、および関連する2つのデータ・ソースのサンプル構成コードを以下に示します。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACXAPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>0</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACXAJndiName</jndi-name>
<global-transactions-protocol>TwoPhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-xa-params>
<keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete>
<xa-end-only-once>true</xa-end-only-once>
<xa-set-transaction-timeout>true</xa-set-transaction-timeout>
<xa-transaction-timeout>120</xa-transaction-timeout>
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACXAPool2</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>0</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACXAJndiName2</jndi-name>
<global-transactions-protocol>TwoPhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-xa-params>
<keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete>
<xa-end-only-once>true</xa-end-only-once>
<xa-set-transaction-timeout>true</xa-set-transaction-timeout>
<xa-transaction-timeout>120</xa-transaction-timeout>
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACXAMDS</name>
<jdbc-data-source-params>
<jndi-name>oracleRACMDSJndiName</jndi-name>
<algorithm-type>Load-Balancing</algorithm-type>
<data-source-list>oracleRACXAPool,oracleRACXAPool2</data-source-list>
</jdbc-data-source-params>
</jdbc-data-source>

グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用

以下の節では、グローバル・トランザクションを必要としないアプリケーション内のマルチ・データ・ソースと共にOracle RACを使用する構成について説明します。

- グローバル・トランザクションを利用しないマルチ・データ・ソース内のデータ・ソースの属性

グローバル・トランザクションを利用しないマルチ・データ・ソース内のデータ・ソースの属性

データ・ソースには以下の属性を指定する必要があります。

- Oracle Thin JDBC Driver 11g。例:

<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-oracle.jdbc.OracleDriver/driver-name>

- TestConnectionsOnReserve="true"

- アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。

- マルチ・データ・ソース内にフェイルオーバーおよび接続リクエスト・ルーティング(事実上、別のOracle RACノードへのフェイルオーバー)を有効化するために、必須です。

- TestTableName="name_of_small_table"

- 物理的なデータベース接続をテストするために使用する表の名前。この属性の詳細については、「データ・ソースの接続テスト・オプション」を参照してください。

サンプル構成コード

WebLogic JDBCマルチ・データ・ソース、および関連するデータ・ソースのサンプル構成コードを以下に示します。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>jdbcPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol24:1521:snrac1</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource</jndi-name>
</jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>jdbcPool2</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource2</jndi-name>
<global-transactions-protocol>OnePhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>jdbcNonXAMultiPool</name>
<jdbc-data-source-params>
<jndi-name>jdbcDataSource</jndi-name>
<algorithm-type>Failover</algorithm-type>
<data-source-list>jdbcPool,jdbcPool2</data-source-list>
<failover-request-if-busy>true</failover-request-if-busy>
</jdbc-data-source-params>
</jdbc-data-source>

注意:

読みやすくするために改行が追加されています。

Oracle RACノード上のサービスに対する接続の構成

Oracle RACクラスタ内のOracleサービスに依存してワークロード管理をする場合は、サービスID (SID)を使用するかわりにマルチ・データ・ソースを使用して、それらのサービスに接続する必要があります。WebLogic Serverのデータ・ソースは特定のOracle RACノード上の特定のサービスにのみ接続するように構成でき、ワークロード管理とロード・バランシングの両方を提供します。

一般に、Oracle RACサービスに接続するには、次を行う必要があります。

- 接続する各サービスごとにマルチ・データ・ソースを作成します。

- 各ノードでサービスがアクティブに実行されているかどうかに関係なく、各マルチ・データ・ソース内で、サービスを構成するクラスタにある各Oracle RACノードに対して1つのデータ・ソースを作成します。

「サービスに接続するためのデータ・ソースの構成」では、これらのデータ・ソースを構成する際の特別な考慮事項について説明します。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理に関するサンプル構成を示します。

サービスに接続するためのデータ・ソースの構成

Oracle RACノード上で実行されるサービスに接続するためのデータ・ソースの構成は、他のデータ・ソースの構成と同じ方法で(WLST、管理コンソール、または構成ウィザードを使用して)行いますが、以下の例外があります。

- initial-capacity="0"
この設定は、WLSの起動時に非アクティブなプールに関するプール作成失敗を防ぎ、ノード上のサービスに接続できない場合でもWLSがデータ・ソースを作成できるようにします。このオプションを0に設定しない場合、データ・ソースの作成が失敗して、サービスの正常な起動が失敗する可能性があります。

管理コンソールでは、データ・ソースを作成した後で編集し、「初期容量」を0に設定します。

- 11gのOracle JDBC Thin (またはThin XA)ドライバ。例:
非XAの場合:

driver-name="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service_1)(INSTANCE_NAME=DB_02)))"

管理コンソールで構成する場合は、「データベース・ドライバ」ドロップダウンから「Oracles's Driver (Thin) for RAC Service-Instance connections」を選択し、「サービス名」フィールドでサービスを指定します。

XAの場合:

driver-name="oracle.jdbc.xa.client.OracleXADataSource"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service1)(INSTANCE_NAME=DBase1)))"

管理コンソールで構成する場合は、「データベース・ドライバ」ドロップダウンから「Oracle's Driver (Thin XA) for RAC Service-Instance connections」を選択し、「サービス名」フィールドでサービスを指定します。

注意:

SERVICE_NAMEは特定のマルチ・データ・ソース内のすべてのデータ・ソースで同じにする必要があります。

特定のマルチ・データ・ソース内では各データ・ソースごとに異なるホスト名とポートを指定します。

- 接続プールに対してmax-capacity (管理コンソールの「最大容量」)を指定する場合は、構成内の各Oracle RACノードの接続容量およびすべてのデータ・ソースからの接続の総数を考慮する必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。

適切なマルチ・データ・ソース・アルゴリズムの選択

サービス接続のシナリオでは、マルチ・データ・ソースをロード・バランシング・アルゴリズムで構成することをお薦めします。マルチ・データ・ソースがロード・バランシング・アルゴリズムで構成されている場合、接続プールはラウンド・ロビン方式で使用されます。この場合、関連付けられたサービスが現在アクティブになっているすべてのOracle RACノード間で、ワークロードがロード・バランシングされます。

マルチ・データ・ソースがフェイルオーバー・アルゴリズムで構成された場合、最初のデータ・ソースは、なんらかの理由によって接続に失敗するまで、関連付けられたOracle RACノード上のサービスに接続するために使用されます(たとえば、Oracle RACノードが使用できないようになるか、またはデータ・ソースでそれ以上接続できなくなります)。その時点では、第2のデータ・ソースが関連付けられたOracle RACノード上のサービスなどに接続するために使用されます。この場合、最初のデータ・ソースに接続しているOracle RACノードは、サービス実行中の残りのノードより多く使用されます。

サービス接続の構成

次の機能を提供するように構成を設計できます。

- ワークロード管理

- ロード・バランシング

ワークロード管理

ワークロード管理の構成では、各マルチ・データ・ソースには、指定したOracle RACノード上の接続対象のサービスがアクティブかまたは非アクティブであるかどうかに関係なく、各Oracle RACノードの指定したサービスに対して1つのデータ・ソースが構成されています。これにより、未計画の停止時間またはスケジュール済メンテナンスによって別のノードが使用されなくなる場合、ノードで非アクティブなサービスを迅速に開始し、そのサービスの接続を作成できます。また、ワークロードの要請に基づいて、使用可能な容量を迅速に増減できます。

ノード上のサービスが起動されると、関連付けられているデータ・ソースはサービスが現在アクティブであることを検出します。データ・ソースは必要に応じて、そのサービスへの接続を確立し始めます。特定のノード上のサービスを停止した場合、関連付けられているデータ・ソースはそのノードへの接続を確立できなくなり、そのノード上でサービスが再起動されるまで、データ・ソースは非アクティブになります。

WLSデータ・ソースでは、接続のテストを行います。これにより、データベースがOracle RAC構成のトポロジの変更によって調整できます。データ・ソースは、ポーリングを行って、関連付けられたサービスがアクティブか非アクティブであるかを判断します。Oracle RACノード上でサービスが使用できない場合、接続テストに失敗します。

図B-4 マルチ・データ・ソースでのワークロード管理

「図B-4 マルチ・データ・ソースでのワークロード管理」の説明

この例では、サービス1はOracle RACノードの1、2および3でアクティブで、サービス2は同じノード上で非アクティブです。サービス2は、Oracle RACノードの4および5でアクティブで、サービス1は、同じノード上で非アクティブです。

Oracle RACノード1は、なんらかの理由で使用不可になる場合、サービス1をOracle RACノード4上で開始できます。WebLogic Serverはサービスがノード4上で実行されていることを検出し、必要に応じて関連付けられたバックアップ・データ・ソースからの接続をノード4に作成し始めます。

ロード・バランシング

ロード・バランシング構成では、各Oracle RACノード上で同時に複数のサービスが実行しています。各WLSマルチ・データ・ソースには、各ノードの指定したサービスに接続するために構成する1つのアクティブな接続プールがあります。このシナリオでは、ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成する必要があります。

図B-5 マルチ・データ・ソースでのロード・バランシング

「図B-5 マルチ・データ・ソースでのロード・バランシング」の説明

この例では、サービス1およびサービス2はそれぞれ使用可能なすべてのOracle RACノード上でアクティブに実行されています。その結果、各マルチ・データ・ソースのすべての接続プールは、5つのノード間のワークロードのバランスを取って、アクティブにラウンド・ロビン方式で接続を作成します。

接続プールのキャパシティ・プランニング

特に注意すべき点は、データ・ソースに対して指定した最大容量の値によっては、特定のOracle RACノードの接続容量を超える可能性があることです。各データ・ソースに対してこの値を設定する方法を決定するときに、次の要素を考慮する必要があります。

- Oracle RACノードでサポートできる最大同時接続数。これは、特定のOracle RACノードでの使用可能なメモリーおよび各サービス接続が消費するメモリー量(サービスごとに異なります)に基づきます。各接続によるメモリー消費は、WLSサーバーから生成される作業の量を制限する主要素です。WLSデータ・ソースから特定のOracle RACノードへの接続をあまりに多く作成して使用可能なメモリー量を超えると、Oracle RACノード上のパフォーマンスが低下するかまたは接続が失敗する可能性があります。
1つのノードで使用可能なメモリー量は(セッション・メモリーごとの) PGAターゲット属性に基づく必要があります。

- 特定のOracle RACノードへの接続を作成できるデータ・ソースの最大数、および単一データ・ソースまたはマルチ・データ・ソースがターゲットとするWebLogicサーバーのインスタンス数。たとえば、1つのデータ・ソースが3つのWLSサーバーをターゲットとする場合、各サーバーはそれぞれデータ・ソースの固有のインスタンスを使用するため、データ・ソースの個数が3になります。これは、サーバーがクラスタの一部である場合または独立したサーバー・インスタンスである場合も同じです。

- 特定のOracle RACノードでアクティブに実行しているサービスの最大数および各サービスへの各接続によってノード上で使用されるメモリー。

- 特定のノード上の各サービスごとに予想される相対的なワークロード。たとえば、サービス1で予想されるワークロードがサービス2で予想されるワークロードの2倍になる場合もあります。
サービスがノード上で常にアクティブになるかどうかにかかわらず、そのノードでサービスを起動する必要がある場合に備えて、そのサービス用のリソースを割り当てる必要があります。

- データ・ソースの最大容量の値を設定するときは、常に最悪のケースのシナリオを使用します。たとえば、すべての使用可能なサービスが各データ・ソースに関連付けられたOracle RACノード上でアクティブに実行していると想定します。

次の例では、各データ・ソースの最大容量の値を決定する方法について説明します。これは、問題を概念的に説明するための簡単な例であり、現実の状況ははるかに複雑であることに注意してください。一般的に、一番良い方法は、データ・ソースの最大容量の値を低めに設定し、Oracle RACノードのメモリー使用量およびパフォーマンスを監視して、関連付けられたOracle RACノードの最大容量に達成するまで最大容量の値を増やすことです。

例

以下のような基本の構成があると仮定します。

- Oracle RACノードが5つで、各ノードはメモリーが16GBです。

- 2つのサービスは、各Oracle RACノード上でアクティブに実行しています。サービス1は、接続当たり10MBのメモリーを使用し、サービス2は接続当たり20MBのメモリーを使用します。

- 各サービスのワークロードは同じです。つまり、各サービスは、指定したOracle RACノード上に同じ接続数を生成します。

- 2つのWebLogic Serverクラスタ。クラスタ1には5つのサーバーがあります。クラスタ2には4つのサーバーがあります。

- 指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ1をターゲットとし、サービス1に接続するように構成されています。

- 指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ2をターゲットとし、サービス2に接続するように構成されています。

サービス2は1接続あたりでサービス1の2倍のメモリーを使用するため、サービス2にはノードのメモリーを約10GB、サービス1には約5GBを割り当てる必要があります。

クラスタ1では、5つのWLSサーバーがあるので、このOracle RACノードに接続リクエストを作成するデータ・ソースが5つあります。これにより、指定したデータ・ソースからの接続に対して1GBのメモリーが使用可能になります(5GB/5)。各接続に対して10MBのメモリーが必要であるため、クラスタ1をターゲットとする各データ・ソースの最大容量値が100以下である必要があります。

クラスタ2では4つのWLSサーバーがあるため、このOracle RACノードに接続リクエストを作成するデータ・ソースが4つあります。これにより、指定したデータ・ソースからの接続に対して2.5GBのメモリーが使用可能になります(10GB/4)。各接続に対して20MBのメモリーが必要であるため、クラスタ2をターゲットとする各データ・ソースの最大容量値が125以下である必要があります。

サービス2がサービス1より多くのワークロードを生む場合は、これらの値を適切に調整する必要があります(サービス2に接続しているデータ・ソースの最大容量の値を増やして、サービス1に接続しているデータ・ソースの値を減らします)。次である間は:

(サービス1への最大接続数x 1つの接続で使用されるメモリー) + (サービス2への最大接続数x 1つの接続で使用されるメモリー) <使用可能なメモリー

パフォーマンス低下や接続障害の可能性を回避することができます。

または、図B-6で示すような単純な構成では、各データ・ソースに指定する「最大容量」値を以下の公式で大まかに決定することができます。

Maximum connection pool capacity = Maximum number of connections to Oracle RAC nodes/(Number of WebLogic Server instances x Nmber of data sources targeted to each instance x Number of active Oracle RAC services configured x Number of Oracle RAC Nodes)

説明:

Oracle RACノードへの最大接続数は、すべてのノード上の使用可能なメモリーの合計を、各接続が消費するメモリーで除算することによって決まります。

WebLogic Serverインスタンス数は、データ・ソースがターゲットとするサーバー・インスタンスの数です。データ・ソースがWLSクラスタをターゲットとする場合は、クラスタ内のサーバーの数になります。

図B-6の例では:

- Oracle RACノード当たりの使用可能なメモリーが8GB、1接続当たりの消費メモリーが10MBであることに基づき、Oracle RACノードのグループに作成できる接続の合計数を最大4000個と想定します。

- データ・ソースがターゲットとするサーバー・インスタンスは合計で5つです。

- 各サーバー・インスタンスをターゲットとするデータ・ソースは5つです。

- 各Oracle RACノードで2つのサービスが実行されます。

- Oracle RACノードは5つです。

この構成では、各データ・ソースに対して入力する最大容量の値は次のようになります。

Maximum connection pool capacity = 4000/(5 server instances x 5 data sources x 2 services x 5 Oracle RAC nodes)

したがって、各データ・ソースの「最大容量」値は16になります。

図B-6 マルチ・データ・ソースの接続構成の例

この式はデータ・ソースの構成に関する一般的なガイドラインにすぎないことに留意してください。多くの構成は非常に複雑なため、このような単純な計算は使えません。

使用する必要がある最大容量の値を計算する際は、常に構成全体での最悪のケースのシナリオを考慮する必要があります。最悪の状況が発生したときのために大きすぎる値を設定するよりも、通常のオペレーションのために低めの値を設定するのが良い方法です。常にOracle RACノードを監視して、データ・ソースの最大容量値を増やしても安全かどうかを決定することができます。

Oracle RACでマルチ・データ・ソースを使用する場合のXAの考慮事項と制限事項

Oracle RACのマルチ・データ・ソースでXA (グローバル・トランザクション)を使用する際は、次の要件および制限を考慮する必要があります。

- マルチ・データ・ソースを使用する場合のOracle RAC XA要件

- マルチ・データ・ソースでOracle RACを使用する場合の既知制限

- データベース・サーバーのクラッシュ後に発生する既知の問題

マルチ・データ・ソースを使用する場合のOracle RAC XA要件

グローバル・トランザクションでマルチ・データ・ソースを使用する場合のOracle RACの要件を次に示します。

- マルチ・データ・ソースの使用

- グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了

- Oracle RACクラスタ内で一意のトランザクションIDの使用

マルチ・データ・ソースの使用

Oracle RACで、マルチ・データ・ソースのXAトランザクションを使用する場合、常にマルチ・データ・ソースを使用します。

グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります

グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります。WebLogicサーバーでは、JDBCデータ・ソースの構成でKeepXAConnTillTxComplete="true"と設定した場合、そのようにできます。

Oracle RACクラスタ内では一意のトランザクションIDを使用する必要があります

グローバル・トランザクションを利用する場合は、トランザクションID (XID)がOracle RACクラスタ内で一意である必要があります。しかし、Oracle ThinドライバやOracle RACインスタンスでは、Oracle RACクラスタ内でXIDが一意であるかどうかを識別できません。同じXIDのトランザクションが複数存在すると、SQLコードがOracle RACクラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外はスローされません。

マルチ・データ・ソースでOracle RACを使用する場合の既知制限

次の項では、Oracle RACとともにXAおよびマルチ・データ・ソースを使用する場合の既知の問題や制限について説明します。

- 障害発生時にデータ・デッドロックが発生する可能性

- トランザクションが順序どおりに完了しない可能性

注意:

これらの制限事項の一部は、Oracleバグ番号3428146および395790でも説明されています。これらの問題の詳細については、Oracleにお問い合わせください。

障害発生時にデータ・デッドロックが発生する可能性

Oracle RACクラスタ全体でトランザクションIDが利用できなくなる時間帯があります。これは既知の制限が原因で、障害発生時に一部の未完了トランザクションが正常に完了できない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。このような障害が発生することを防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsとXARetryIntervalSecondsが用意されています。これらの構成オプションの詳細は、「フェイルオーバー中の遅延」を参照してください。

トランザクションが順序どおりに完了しない可能性

Oracle DataBase Controlを使用した場合、トランザクション処理の順番は保証されません。たとえば、DataBase Controlを使って、次のトランザクション・シーケンスを実行するWebサービスを実装する場合を考えます。

1. 表を作成

2. レコード1を挿入

3. レコード2を挿入

4. レコード3を挿入

5. レコードを選択

表を作成した後でプライマリ・ノードが一時的に停止すると、データベースに送信されたトランザクションが、順序どおりに実行されない可能性があります。

データベース・サーバーのクラッシュ後に発生する既知の問題

トランザクションの処理中に、PREPARE操作は完了したがその結果がトランザクション・ログに書き込まれていない時点で、データベース・サーバー・インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからのCOMMIT呼出しが数分間に渡ってハングすることがあります(TCPタイムアウト期間が経過するまでハングが続く場合もあります)。この事態が発生する時間帯は短く、問題が起こることはまれです。現時点でこの問題の回避策はありません。

Oracle RACでのJDBCストアのリカバリ

JDBCストアとOracle RACを併用している場合、Oracle RACノードのフェイルオーバーに関して考慮する必要のある機能と制限があります。以下の節を参照してください。

- Oracle RACと併用するためのJDBCストアの構成

- 自動での再試行

JDBCストアを使用する主なサービスのリストについては、『Oracle WebLogic Serverサーバー環境の構成』のストア接続の監視に関する項を参照してください。

Oracle RACと併用するためのJDBCストアの構成

JDBCストアのしくみでは、Oracle RACと併用するための構成のオプションが限られています。JDBCストアは、グローバル・トランザクションをサポートするように構成されたJDBCデータ・ソースを使用するように構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。この構成オプションの詳細については、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。

JDBCストアは、1つの接続が失敗するまでその接続を保持し、失敗した時点で次の接続に移って、プロセスを繰り返します。したがって、JDBCストアでは、ロード・バランシング・マルチ・データ・ソースを使用することを含めて、ロード・バランシングを実装することができません。フェイル・オーバー・アルゴリズムを使用するには、JDBCストアに対してマルチ・データ・ソースを構成する必要があります。

つまり、JDBCストアについては次のようにします。

- 非XAドライバを使用します

- マルチ・データ・ソースをフェイルオーバー・モードで構成します。

自動再試行

JMSには、制限された接続再試行メカニズムがあり、これらのメカニズムを使用すると、そのデータベース接続を持つOracle RACノードで発生する障害に対して、サイレントに対応できます。データベースに対してネットワークが一時中断するかまたはOracle RACデータベースが別のノードにフェイルオーバーした場合、第2の接続の試行(再試行)が次のOracle RACノードを継承します。

接続再試行時間の拡張による負の効果を最小化するために、再試行時間および再試回数は制限されています。データベース接続が長時間にわたり使用不可能な場合、遅延によって、JMSが処理を適切に続行する(たとえば、メッセージの正しい順序を保持する)機能が妨害されるおそれがあります。また、この時間内に、処理が十分に進行しない場合、トランザクション・マネージャによってトランザクションのJMSリソースが失効を宣言されるか、メモリー不足が発生する可能性があります。自動再試行が成功するために重要なOracle RACフェイルオーバー時間を最小化する方法については、システム・レベルのチューニングのガイドラインが役立ちます。

自動再試行を緊密なループで行うことは、トランザクションでJMSの処理が発生する場合に特に重要です。JDBCストアでI/O障害が発生すると、ストア・レコードが不明な状態になり、それによってメッセージ自体も不明な状態に置かれます。メッセージがこの不明な状態のままコミットされないように、JMSではそのメッセージに関連するトランザクションを「failedTransaction」とマークします。トランザクション・マネージャで、これ以降にこのメッセージのコミットを完了するどのような試みがなされた場合にも、JMSではjavax.transaction.xa.XAExceptionがスローされ、errorCodeがXAException.XAER_RMERRに設定されます。この例外は、トランザクション・マネージャに対して、リソース・マネージャ(JMS)に一時的なエラーが発生していること、およびトランザクション・マネージャでコミット処理を再試行する必要があることを示すものです。この再試行ロジックにより、JMSが上部レイヤーに(RMERRに変化する)どのような障害をも通信する以前に、接続を確立するための2番目の試行が実施されます。RMERRが生成された場合、その後でメッセージを回復してトランザクションを完了するには、WebLogic Serverを再起動するのが唯一の方法です。

自動での再試行ロジックは、現在のWebLogic Serverでは次のようなオプションで管理されています。

-Dweblogic.store.jdbc.IORetryDelaySeconds=X

ここで、Xは、データベースへの接続が再試行されるまでに経過する必要のある秒数です。デフォルトでは1秒です。この値は、0から15に制限されていて、再試行は1回だけ行われます。2番目の試行で障害が発生すると、例外がコール・スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。

注意:

自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。

C Oracle RACでの接続時フェイルオーバーの使用(非推奨)

この章では、WebLogic Serverで、接続時フェイルオーバーおよびロード・バランシングを使用するように構成されたデータ・ソースを使用するレガシー・アプリケーションに対して接続時フェイルオーバー(非推奨)が行われる仕組みについて説明します。

注意:

新しいアプリケーションには、同じ機能を提供するGridLinkデータ・ソースを使用する必要があります。『Oracle Database JDBC開発者ガイド』のGridLinkデータ・ソースの概要および暗黙的接続キャッシュに関する項を参照してください。

- グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの使用

- グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの構成属性

- サンプル構成コード

グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの使用

接続時フェイルオーバーとロード・バランシングを行うように構成されたデータ・ソースを使用してWebLogic Serverと複数のOracle RACノードを接続するには、後述するように、Oracle RACクラスタ内の各Oracle RACインスタンスにOracle Thin DriverでJDBCデータ・ソースを構成します。図C-1は、システムの概要を示します。

図C-1 Oracle Thin Driverの接続時フェイルオーバーを使用したデータ・ソースの構成

「図C-1 Oracle Thin Driverの接続時フェイルオーバーを使用したデータ・ソースの構成」の説明

ドメインを構成するには、管理コンソールか、または、WebLogic Scripting Tool (WLST)やJMXプログラムなどのお好きな方法を使用できます。

データ・ソースに接続が作成されると、Oracle Thin Driverによって使用するOracle RACインスタンスが決定されます。アプリケーションは接続を取得すると、JNDIツリーでデータ・ソースをルックアップして、データ・ソースからの接続をリクエストします。データ・ソースは、データ・ソース内の接続のプールから使用可能な接続を1つ選んで提供します。

以下の節では、Oracle RACの接続時フェイルオーバー機能を使用して接続の障害に対処する構成について説明します。この構成では、障害のケースによって、フェイルオーバーにかかる時間がTCPタイムアウトと同じ長さになる場合もあります。これは環境により数分間に及ぶ場合があります。

グローバル・トランザクションを利用しない場合の接続時フェイルオーバーの構成属性

この構成を使用するには、以下の属性でWebLogicドメインにJDBCデータ・ソースを作成します。

- 接続時フェイルオーバーを行うように構成されたOracle Thin JDBC Driver 11g。例:

<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=TCP)(HOST=lcqsol24)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)
(HOST=lcqsol25)(PORT=1521))(FAILOVER=on)(LOAD_BALANCE=off))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=snrac)))</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>

- ConnectionReserveTimeoutSeconds="120"

- 接続に対するアプリケーション・リクエストが、接続が利用できるまで120秒間待機できるようにします。

- TestConnectionsOnReserve="true"

- アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。

- 別のOracle RACノードのフェイルオーバーを有効にする必要があります。

- TestTableName="name_of_small_table"。物理データベース接続のテストに使用される表の名前です。この属性の詳細については、「データ・ソースの接続テスト・オプション」を参照してください。

サンプル構成コード

以下にサンプル構成コードを示します。

注意:

読みやすくするために改行が追加されています。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>oracleRACNonXAPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
HOST=lcqsol24)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)
(HOST=lcqsol25)(PORT=152))(FAILOVER=on)
(LOAD_BALANCE=off))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=snrac)))</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>wlsqa</value>
</property>
</properties>
<password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<test-connections-on-reserve>true</test-connections-on-reserve>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<profile-type>4</profile-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>oracleRACJndiName</jndi-name>
<global-transactions-protocol>OnePhaseCommit
</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>

D Oracle RACでの高速接続フェイルオーバーの使用

この章では、WebLogic ServerでOracle Fast Connection Failoverを使用する方法について説明します。

WebLogic Serverでは、アプリケーションに依存せずにOracle RACイベント通知を実装するOracle機能である、高速接続フェイルオーバーがサポートされており、無効な接続の検知とクリーン・アップ、使用可能な接続のロード・バランシング、アクティブなOracle RACインスタンスへの作業の再配布などが可能です。

詳細は、Oracle® Database JDBC Developer's Guide and Referenceの「Fast Connection Failover」(http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/fstconfo.htm#CIHJBFFC)を参照してください。

Oracleの高速接続フェイルオーバーを使用するJDBCドライバ構成

データ・ソースでの高速接続フェイルオーバーを有効にするには、以下の接続プール・プロパティを設定します。

- ドライバ・クラス名 - クラス名をoracle.jdbc.pool.OracleDataSourceに設定します。

- プロパティ - ONS構成文字列を設定し、リモートでOracle RACノードをOracle FAN/ONSイベントにサブスクライブするようにします。例: ONSConfiguration=nodes=hostname1:port1,hostname2:port2

注意:

OracleのOracleDataSourceクラスはXA対応ではないため、設定後のデータ・ソースにXA接続プールは実装されません。

OracleドライバはONSを使用して高速接続フェイルオーバーを実装するため、WebLogicのクラスパスにons.jarを追加する必要があります。それには、ドメインのbinディレクトリにあるsetDomainEnvスクリプトを編集して、POST_CLASSPATH変数にons.jarを追加します。

Copyright © 2007, 2012, Oracle and/or its affiliates. All rights reserved.