Oracle® Fusion Middleware

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

11gリリース1 (10.3.6)

B60997-14(原本部品番号:E13737-16)

2017年11月

このドキュメントでは、WebLogic Server 10.3.6のJDBCデータ・ソース構成および管理情報について説明します。

Oracle Fusion Middleware Oracle WebLogic Server 10.3.6 JDBCデータ・ソースの構成と管理, 11gリリース1 (10.3.6)

B60997-14

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

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(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 Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

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

- 表記規則

1 概要とロードマップ

- ドキュメントの範囲および対象読者

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

- 関連ドキュメント

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

- Avitek医療記録アプリケーション(MedRec)とチュートリアル

- WebLogic Serverディストリビューションに含まれるJDBCのサンプル

- このリリースにおけるJDBCデータ・ソースの新機能と変更された機能

- CapacityIncrement属性

- MinCapacity属性

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

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

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

- Oracle BI Serverのサポート

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

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

- RMIドライバ通信の保護

- プロキシ認証

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

- 接続収集

- 接続ラベリング

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

- ONSのデバッグ

2 WebLogic JDBCリソースの構成

- WebLogic ServerにおけるJDBCリソースの理解

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

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

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

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

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

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

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

- JDBCスキーマ

- JMXおよびWLSTのJDBCリソースへのアクセス

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

- 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イベントの有効化

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

- ウォレット・ファイルの使用

- 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 MBeansのセキュリティ・ロール

- JDBCドメイン構成MBeans

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

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

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

- 無応答データベースが原因で発生するサーバー起動ハングアップの最小化

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

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

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

- LRU(最近最も使用されていない)

- 固定

- 文キャッシュ・サイズ

- 文キャッシュに対する使用制限

- 格納済の文をデータベース変更後にコールした場合のエラー

- プリコンパイルされた文でのsetNullの使用

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

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

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

- データベース接続の作成時における接続テスト

- 定期的な接続テスト

- 予約済の接続のテスト

- データベース接続切断後の接続テスト遅延の最小化

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

- DBMS接続の切断後の接続リクエスト遅延の最小化

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

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

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

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

- 接続リクエストにおける接続待機の有効化

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

- 接続リクエスト待機数の制限

- リークした接続の自動リカバリ

- 適切な接続数によるサーバーのロック回避

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

- スレッドに固定のプロパティの使用によるパフォーマンス向上

- 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構成の選択

- WebLogic ServerでOracle RACを使用する場合の接続の検証

- WebLogic ServerでOracle RACを使用する場合の追加考慮事項

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

- JDBCドライバのサポート

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

- サードパーティJDBCドライバの使用

- JDBCドライバの追加または更新

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

- デバッグ・モードでのOracle Thinドライバの使用方法

- SSL経由のOracle Thinドライバの使用

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)

- 接続アンラップ(WEBLOGIC.JDBC.CONN.UNWRAP)

- プロファイル情報レコード・ログの例

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

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

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

- デバッグの有効化

- コマンド行を使用したデバッグの有効化

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

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

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

- JDBCのデバッグ範囲

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

- UCPのデバッグ

- ONSのデバッグ

- リクエストのDye処理

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 12cデータベースのWebLogic Server 10.3.6サポート

- WebLogic Server 10.3.6でのOracle 12cデータベースの使用

- Oracle 12cデータベースでの11gドライバの使用

- Oracle 12cデータベースでの12cドライバの使用

- 必要なOracle 12cドライバ・ファイル

- Oracle 12cデータベース・ファイルのダウンロード

- WebLogic Server CLASSPATHの更新

- その他の考慮事項

- JDK 7に対するJDBC 4.1サポート

- アプリケーション・コンティニュイティの使用

- アプリケーション・コンティニュイティの機能

- 要件および考慮事項

- アプリケーション・コンティニュイティの構成

- アプリケーション・コンティニュイティ対応ドライバの選択

- 接続コールバックの使用方法

- 特定の接続に対するアプリケーション・コンティニュイティの無効化

- アプリケーション・コンティニュイティのロギングの構成

- Global Database Services

- 要件および考慮事項

- GDS接続対応のGridLinkデータソースの作成

- プラガブル・データベースを使用するコンテナ・データベース

- PDBアクセス対応サービスの作成

- JDBCを使用したPDBの設定

- 自動ONSリスナー・サポート

- データベース常駐接続プーリングのサポート

C 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クラスタの同一インスタンスで開始、準備、完結させる必要性

- トランザクションIDがOracle RACクラスタ内で一意であることの必要性

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

- 一部の失敗シナリオにおけるデータのデッドロックの可能性

- トランザクションが順序外で終了する可能性

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

- Oracle RACによるJDBCストアのリカバリ

- Oracle RACで使用するJDBCストアの構成

- 自動再試行

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

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

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

- 構成コードのサンプル

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

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

はじめに

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

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

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

Oracle Supportへのアクセス

サポートをご購入の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 10.3.6 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の使用」では、WebLogic ServerをOracle Real Application Clusterとともに使用するための構成方法について説明します。

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

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

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

- 付録A「JDBCアプリケーション・モジュールのデプロイメントの構成」では、Oracle Real Application Clustersで使用する汎用データ・ソースの構成方法について説明します。

- 付録C「Oracle RACでのマルチ・データ・ソースの使用」では、WebLogic ServerでOracle Real Application Clusters (RAC)を使用する際のマルチ・データ・ソースの構成および使用方法について説明します。

- 付録D「Oracle RACでの接続時フェイルオーバーの使用(非推奨)」では、接続時フェイルオーバーとロード・バランシングを使用するように構成されたデータ・ソースを使用する従来のアプリケーションに対して、WebLogic Serverで接続時フェイルオーバー(非推奨)を提供する方法について説明します。

- 付録E「Oracle RACでの高速接続フェイルオーバーの使用」では、Oracle高速接続フェイルオーバーでWebLogicサーバーを使用する方法について説明します。

関連ドキュメント

このドキュメントでは、JDBCデータ・ソース構成と管理情報について説明しています。

WebLogic Serverアプリケーションの開発、デプロイおよびモニタリングに関する全体的なガイドラインは、次のドキュメントを参照してください。

- 『Oracle WebLogic Server JDBCのプログラミング』は、WebLogic ServerでJDBC APIプログラミングを行うためのガイドです。

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

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、WebLogic Serverアプリケーションを開発環境および本番環境にデプロイする手順に関する重要な情報源になります。

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

このドキュメントに加え、オラクル社は構成とAPIの使用方法を示し、主要なJDBC開発タスクの実行方法に関する実践的な手順を説明する、JDBCコード・サンプルとチュートリアルを提供しています。

Avitek医療記録アプリケーション(MedRec)とチュートリアル

MedRecは、WebLogic Serverに付属するエンドツーエンドのサンプルJava EEアプリケーションです。このアプリケーションは、独立した集中医療記録管理システムをシミュレートするものです。MedRecアプリケーションは、患者、医師および管理者が各種クライアントを使用して、患者のデータを管理するためのフレームワークを提供します。

MedRecでは、WebLogic ServerとJava EEの機能の実例を挙げ、推奨されるベスト・プラクティスについて重点的に説明します。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 Serverのサポート

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

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

- RMIドライバ通信の保護

- プロキシ認証

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

- 接続収集

- 接続ラベリング

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

- ONSのデバッグ

このリリースに導入されたWebLogic Serverの新機能がすべて含まれる一覧は、『Oracle WebLogic Serverの新機能』を参照してください。

CapacityIncrement属性

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

MinCapacity属性

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

2つの属性に分割されたプールの初期容量および最小容量を事前に処理したInitialCapacity値。

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

- MinCapacityは、縮小計算にのみ使用されます。サーバーの起動時に最小接続が作成されないので遅延します。InitialCapacityはこの機能のために使用されます。

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

- データ・ソースが中断/再開された後は、MinCapacityまたはInitialCapacityの大きい方の値が使用されます。

- 例: InitialCapacityを0に設定してデータベースを起動し、InitialCapacityを50に設定して常時プールに少なくとも50個の接続を維持します。前述のルールでは、MinCapacityが最初に0として処理され、次にプールに常時少なくとも50個の接続があるように50として処理されます。

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

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

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

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

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

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

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

Oracle BI Serverのサポート

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

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

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

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

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

RMIドライバ通信の保護

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

プロキシ認証

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

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

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

接続収集

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

接続ラベリング

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

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

このリリースは、次の新しいデバッグ・スコープを提供します:

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

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

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

- weblogic.jdbc.rac.DebugJDBCREPLAY - リプレイ・デバッグ

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

「JDBCのデバッグ範囲」を参照してください。

ONSのデバッグ

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

2 WebLogic JDBCリソースの構成

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

この章には次の項が含まれます:

- WebLogic ServerにおけるJDBCリソースの理解

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

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

- JMXおよびWLSTのJDBCリソースへのアクセス

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

WebLogic ServerにおけるJDBCリソースの理解

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

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

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

JDBCリソース(データ・ソースまたはマルチ・データ・ソース)を、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して作成すると、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からデータ・ソース・システム・モジュールへの参照

この図では、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からマルチ・データ・ソースおよびデータ・ソース・システム・モジュールへの参照

この図では、config.xmlファイル内に、3つのJDBCモジュールがリストされています。1つのマルチ・データ・ソースと、そのマルチ・データ・ソースによって使用される2つのデータ・ソースです。この2つのデータ・ソースも、マルチ・データ・ソース・モジュール内にリストされています。アプリケーションは、これらのモジュールのうち任意のものをJNDIツリー上でルックアップして、データベース接続をリクエストできます。マルチ・データ・ソースをルックアップした場合、そのマルチ・データ・ソースは、data-source-listパラメータ内のデータ・ソース、データ・ソースのリスト順、およびalgorithm-typeパラメータで指定されているアルゴリズムに応じて、データベース接続の供給に使用する他のデータ・ソースをどれにするかを決定します。マルチ・データ・ソースの詳細は、「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アプリケーション・モジュールの構成の詳細は、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ファイルをデプロイできます。ただし、システムのclasspath内に古いバージョンのドライバがある場合は、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として表示されます。将来のリリースでは、このエラーは致命的なエラーとして扱われる可能性があります。

JMXおよびWLSTのJDBCリソースへのアクセス

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

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

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

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

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

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

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

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

図2-3 JDBC Beanツリー

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

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オブジェクト(プール、データ・ソース、ドライバなど)をトラップします。

- WLSTをオフラインで使用する場合、管理オブジェクト名で次の文字は無効です: ピリオド(.)、スラッシュ(/)またはバックスラッシュ(\)。『Oracle WebLogic Scripting Tool』のWLSTコマンドの構文に関する項を参照してください。

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

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

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

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

この章では、WebLogic Server 10.3.6の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ドメインにJDBCデータ・ソースを作成するには、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用します。

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

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

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

JDBCドライバの選択

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

- Oracle Thinドライバ

- Oracle ThinドライバXA

- Oracle Thinドライバ非XA

- Oracle BI Serverのドライバ(タイプ4): Any

- サード・パーティ製のJDBCドライバ(「WebLogic ServerでのJDBCドライバの使用方法」を参照):

- MySQL (非XA)

- 次に示すデータベース管理システム用の、WebLogicブランドのDataDirectドライバ(「WebLogicブランドのDataDirectドライバの使用」を参照):

- DB2

- Informix

- Microsoft SQL Server

- Sybase

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

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

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

注意:
データ・ソースの作成時に、管理コンソールに一覧表示されるJDBCドライバには、WebLogic Serverでの使用が保証されていないものもあります。JDBCドライバの一覧は、多数の使用可能なデータベース管理システムへの接続を円滑に作成するための利便性を目的として示されます。
JDBCドライバを使用してデータ・ソースにデータベース接続を作成するには、データ・ソースをデプロイするサーバーごとにJDBCドライバをインストールする必要があります。管理コンソールに一覧されるドライバは、データ・ソースの構成に役立つ既知の必須構成オプションとともに示されます。この一覧には、インストールされていないJDBCドライバも表示されます。ドライバのインストールには、システムのPathやClasspathなどの環境変数の設定が含まれることがあります。「サードパーティ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がList of Node VIPsに設定されている場合、データ・ソース接続URLにはVIPアドレスのリストのみが使用できます。

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

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

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

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

接続のテスト

「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。

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

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

接続プール機能の構成

各JDBCデータ・ソースは、そのデータ・ソースのデプロイ時またはサーバーの起動時に作成されるJDBC接続のプールを1つ保持します。アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。

注意:
特定のOracle JDBC拡張機能や、その他のドライバで使用できる他の非標準メソッドでは、プールされた接続の将来のユーザーが接続の動作を継承するという方法で、接続の動作を永続的に変更することが可能です。WebLogic Serverは、このようなタイプの呼出しに対して、可能な場合は接続の保護を試行します。

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

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

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

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

- 詳細な接続プロパティ

次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。

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

- JDBCConnectionPoolParamsBean。これは、JDBCDataSourceBeanの子MBeanです。

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

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

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

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

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

WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性で、SQLと入力し、その後に実行するSQLコードを空白を挟んで入力します。または、SQLを使用せずに単純な表名を指定できます。SELECT COUNT(*) FROM tablenameという文を使用します。この属性を空欄(デフォルト)のままにしておくと、WebLogic Serverは、データベース接続を初期化するコードを実行しなくなります。

WebLogic Serverは、データベース接続をデータ・ソースに作成するたびに、このコードを実行します。また、サーバー起動時、接続プールの拡張時および接続のリフレッシュ時にも、このコードを実行します。

この機能を使用して、DBMS固有の操作設定値(接続固有)を設定することも、必要な操作を実行するためのメモリーや権限を接続に用意することもできます。

コードの先頭には、SQLと、それに続けて空白を入力します。たとえば、Oracle DBMSでは次のようになります。

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

Informix DBMSでは次のようになります。

SQL SET LOCK MODE TO WAIT

SQL文はJDBC Statement.execute()を使用して実行します。InitSQLを使用して設定できるオプションは、DBMSに応じて異なります。サポートされている文については、データベース・ベンダーのドキュメントを参照してください。複数の文を実行する場合は、ストアド・プロシージャを作成して実行することもできます。この構文はベンダー固有です。たとえば、Oracleストアド・プロシージャを実行するには、次のように指定します。

SQL CALL MYPROCEDURE()

詳細な接続プロパティ

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

次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。

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

- JDBCConnectionPoolParamsBean。これは、JDBCDataSourceBeanの子MBeanです。

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

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

SQLExceptionの範囲内の例外コード(sqlException.getErrorCode()によって取得される)として指定されているコードは、致命的エラーが発生して接続が機能しなくなったために、その接続が接続プールから削除されることを意味します。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ドライバに渡される「プロパティ」で定義されているパスワード値は、「パスワード」フィールドの値によりオーバーライドされます。プロパティ文字列のパスワード・プロパティのかわりにパスワード属性を使用することをお薦めします。パスワード値は構成ファイルで暗号化され(モジュール・ファイル内のjdbc-driver-paramsタグでパスワードで暗号化された属性として格納されます)、管理コンソールで表示されないためです。

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

データ・ソースで「接続時にクライアントIDを設定」属性が有効化されている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたときに、WebLogic Serverインスタンスが現在のWebLogicユーザーIDを判別し、そのユーザー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ベースの接続プールにより、アプリケーションは、各種DBMS資格証明を持つ物理接続をプールすることで、特定のDBMS資格証明でJDBC接続を使用できます。

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

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

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

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

異種接続の作成方法

次の項で、異種接続の作成方法について説明します。

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

2. アプリケーションがデータ・ソースから接続を取得しようとします。

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

- 一致なしの場合、デフォルトのDBMS資格証明が使用されます。

注意:
デフォルトのDBMS資格証明には、XAトランザクションを実行して接続テスト操作を実行する機能など、少なくともDBMS権限が必要です。

- 一致が見つからない場合、DBMS資格証明と一致する物理接続を検出するために使用されます。

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

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

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

- プールが最大容量に到達している場合、最低使用頻度(LRU)アルゴリズムに基づき、プールから物理接続が選択され、破棄されます。DBMS資格証明を使用して新しい接続が作成され、予約され、アプリケーションに返されます。

物理接続の作成方法に関係なく、プール内の各物理接続には、プールにより保持されている専用のDBMS資格証明情報があります。プールにより物理接続が予約された後では、現在のスレッドによりそのWebLogicユーザー資格証明が変更され、同じ接続を継続して使用する場合でも、そのDBMS資格証明は変更されません。

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

グローバル・トランザクション内で実行する場合、アプリケーションが現在のスレッドの資格証明を変更し、異なる資格証明で複数のJDBC接続を取得する可能性があります。ただし、IDベースのプール機能は、グローバル・トランザクション内のWebLogic JDBCデータ・ソースの複数の論理JDBC接続を単一の物理JDBC接続にマップします。つまり、WebLogicサーバー・インスタンスごとの各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データ・ソースの使用

この章では、WebLogic Server 10.3.6でのGridLinkデータ・ソースの構成方法とチューニング方法について説明します。

この章には次の項が含まれます:

- GridLinkデータ・ソースとは

- GridLinkデータソースの作成

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

- 接続プール機能の構成

- Oracleパラメータの構成

- ONSクライアントの構成

- Oracleパラメータの構成

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

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

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

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

GridLinkデータ・ソースとは

単一のGridLinkデータ・ソースは、WebLogic Serverと複数のOracle RACクラスタを含む可能性があるOracleデータベース・サービス間の接続性を提供します。脚注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接続を作成しようとすると、java.sql.SQLException: Can not use getXAConnection() when connection caching is enabledという例外が発生します。これは、このプロパティに対するドライバの高速接続フェイルオーバーの実装がXA接続をサポートしていないためです。

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

GridLinkデータ・ソースは、XA環境と非XA環境に対するロード・バランシングとして機能します。GridLinkデータ・ソースは、データベースが発行するOracle FANイベントに基づいて、ランタイム接続ロード・バランシング(RCLB)を使用し、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ロード・バランシング・アドバイザ(LBA)をモニターして、RACクラスタのRACアフィニティが有効化されているかどうかを判断します。最初の接続リクエストはランタイム接続ロード・バランシング(RCLB)を使用してロード・バランシングされ、アフィニティ・コンテキストが割り当てられます。それ以降のすべての接続リクエストは、セッションが終了するかトランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して、同一のOracle RACインスタンスにルーティングされます。次の項を参照してください。

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

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

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

ユーザー・セッションに連続のオンライン・トランザクション処理(OLTP)があるWebアプリケーションでは、同じセットのレコードに対する繰返し操作が同じRACインスタンスで処理される場合にパフォーマンスが向上します。オンライン・ショッピングやオンライン・バンキングなどのビジネス・アプリケーションは、このパターンの典型的な例としてあげられます。

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

注意:
コンテキストは、HTTPセッションに格納されます。これは、アプリケーションがHTTPセッションを各ウィンドウ(1つのブラウザ内または複数のブラウザ全体でのウィンドウ)にマップする方法に応じて異なります。

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

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

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

- Oracle RACが有効化されていてアクティブであり、サービスでRCLBが有効化されている。RCLBは、サービスのGOAL (CLB_GOALではありません)が、SERVICE_TIMEまたはTHROUGHPUTに設定されている場合に、サービスごとに有効化されます。

- クラスタ待機時間において十分なパフォーマンスの向上があるとデータベースで判断され、ペイロードに含まれるアフィニティ・フラグがTRUEに設定されている。

セッション・アフィニティを実装することに有効性がないとデータベースで判断された場合(高データベース可用性条件など)、データベースはロード・バランシング・アルゴリズムをデフォルトの作業割当てポリシーに戻して、ペイロード内のアフィニティ・フラグをFALSEに設定します。

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

グローバル・トランザクションのXAアフィニティにより、Oracle RACクラスタで実行されるグローバル・トランザクションに対するすべてのデータベース操作は、同一のOracle RACインスタンスに向けられるようになります。

図4-5 XAアフィニティ

SCANアドレス

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

注意:
Oracle RAC 11.2以降を使用する場合は、次の点について考慮してください。

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

- Oracle RACのリスナーがList of Node VIPsに設定されていると、GridLinkデータ・ソース構成では、VIPアドレスのリストのみが使用できるようになります。

- Oracle RACのリスナーがMix of SCAN and List of Node VIPsに設定されていると、GridLinkデータ・ソース構成では、SCANとVIPの両方のアドレスが使用できるようになります。

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

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

この機能を使用すると、Oracleウォレットを使用した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ツリーにバインドされるように、データ・ソースを構成します。単一の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フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。参照

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

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

接続プロパティの構成

接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。一般的な属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。

注意:
サービス名の使用方法:

- データベース・ドメインを使用するときには、サービス名にドメイン名の接尾辞を付加する必要があります。たとえば、データベース名がdb.us.myco.comで、サービス名がmyserviceのときには、myservice.us.myco.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に設定します。

サポートされているAGLデータ・ソースURLフォーマット

AGLデータ・ソースは長いフォーマットのJDBC URLのみをサポートします。サポートされている長いフォーマットのパターンは次のようになります。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=[SCAN_VIP])(PORT=[SCAN_PORT])))(CONNECT_DATA=(SERVICE_NAME=[SERVICE_NAME])))

簡易接続(短い)フォーマットURLは、AGLデータ・ソースではサポートされていません。AGLデータ・ソースでの使用がサポートされていない簡易接続URLパターンの例を次に示します。

jdbc:oracle:thin:[SCAN_VIP]:[SCAN_PORT]/[SERVICE_NAME]

AGLデータソースURLに関する推奨事項

次の項では、AGLデータ・ソースURLを作成する際の一般的な推奨事項を示します。

- 単一のDESCRIPTIONを使用します。接続遅延を防ぐためにDESCRIPTION_LISTを避けます。

- 各RACクラスタまたはDataGuardデータベースに1つのADDRESS_LISTを使用します。

- すべてのADDRESS_LISTエントリが同じ値を使用するように、DESCRIPTIONレベルでRETRY_COUNT、RETRY_DELAY、CONNECT_TIMEOUTを入力します。

- RETRY_DELAYは、接続の再試行間の遅延時間(秒)を指定します。この属性はOracle 12.1.0.2リリースの新しい属性です。

- RETRY_COUNTは、接続試行を終了するまでに、ADDRESSリストが横断する回数の指定に使用します。デフォルト値は0です。FAILOVER=onでSCANリスナーを使用中に、RETRY_COUNTを2に設定すると、3つのSCAN IPアドレスがある場合、それぞれが3回横断されるため、接続試行が9回(3 * 3)行われることになります。

- 各アドレス・リストにLOAD_BALANCE=onを指定し、SCANアドレスのバランスを取ります。

- サービス名は、PDBまたは管理サービスではなく、構成されたアプリケーション名にしてください。

- CONNECT_TIMEOUTは、Oracle Net接続の完了に使用する時間全体の指定に使用されます。ログオンの混乱を避けるために、CONNECT_TIMEOUT=90またはそれ以上に設定します。JDBCドライバ12.1.0.2以前では、CONNECT_TIMEOUTは、URLの各アドレスのTCP/IP接続タイムアウトにも使用されていました。TCP/IP接続を考慮する場合、タイムアウト全体の従属的要件ではありますが、短いCONNECT_TIMEOUTの方が適しています。

- URLプロパティによって上書きされるため、データ・ソースにoracle.net.CONNECT_TIMEOUTドライバ・プロパティを設定しないでください。

接続のテスト

「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。

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

「ONSクライアント構成」を使用すると、データ・ソースをOracle FANイベントにサブスクライブして、処理できるようになります。ONSクライアントを構成するには:

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

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

- 必要に応じて、SSLを使用したセキュアなONSクライアント通信を構成します。「セキュアなONSクライアント通信」を参照してください。

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

WebLogic ServerでOracleウォレット・ファイルを使用するには、次の手順を実行する必要があります。

- 次のファイルをWebLogic Server classpathに追加します。

- $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ウォレット・パスワードが格納されているOracleウォレット・ファイルのディレクトリを含めます。Oracle WebLogic Server管理コンソール・ヘルプのOracleウォレットを使用したセキュアなONSリスナーに関する項を参照してください。

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

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

「ONSクライアント構成のテスト」を使用すると、データ・ソース構成をファイナライズする前に、データベース接続をテストできます。

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

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

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

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

ランタイム・ロード・バランシングの構成

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

注意:
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.myco.com)(PORT=1522))
(ADDRESS = (PROTOCOL = SDP)(HOST =
sclcgdb02-bvip.us.myco.com)(PORT=1522))
)
)

その後で、次のURLを使用して、LISTERNER_IBネットワーク上で接続を分散します。

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

接続プール機能の構成

各JDBCデータ・ソースは、そのデータ・ソースのデプロイ時またはサーバーの起動時に作成されるJDBC接続のプールを1つ保持します。アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。

注意:
特定のOracle JDBC拡張機能または、他のドライバで使用可能な標準以外の方法により、接続の動作が永続的に変更され、プールされた接続の将来のユーザーがそれを継承することがあります。WebLogic Serverは、このようなタイプの呼出しに対して、可能な場合は接続の保護を試行します。

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

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

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

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

次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。

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

- JDBCConnectionPoolParamsBean。これは、JDBCDataSourceBeanの子MBeanです。

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

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

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

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

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

注意:
WebLogic Serverの起動時に、Javaシステム・プロパティとしてoracle.jdbc.FastConnectionFailoverを指定してはいけません。

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

WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性に、SQLと入力し、その後に実行するSQLコードを空白を挟んで入力します。この属性を空欄(デフォルト)のままにしておくと、WebLogic Serverは、データベース接続を初期化するコードを実行しなくなります。

WebLogic Serverは、データベース接続をデータ・ソースに作成するたびに、このコードを実行します。また、サーバー起動時、接続プールの拡張時および接続のリフレッシュ時にも、このコードを実行します。

この機能を使用して、DBMS固有の操作設定値(接続固有)を設定することも、必要な操作を実行するためのメモリーや権限を接続に用意することもできます。

コードの先頭には、SQLと、それに続けて空白を入力します。次に例を示します。

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

または

SQL SET LOCK MODE TO WAIT

InitSQLを使用して設定できるオプションは、DBMSに応じて異なります。

注意:
Init SQLは動的属性ではありません。Init SQLの値を変更する場合、データソースをアンデプロイおよび再デプロイするか、サーバーを再起動する必要があります。

Oracleパラメータの構成

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

ONSクライアントの構成

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

- FANイベントの有効化

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

- ウォレット・ファイルの使用

FANイベントの有効化

データ・ソースで、Oracle高速アプリケーション通知(FAN)イベントへのサブスクライブと、このイベントの処理を有効化します。

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

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

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

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

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

ウォレット・ファイルの使用

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

Oracleパラメータの構成

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

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

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

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

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

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

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

注意:
GridLinkデータ・ソースは、IDベースの接続プールをサポートしていません。

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

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

注意:
「プロパティ」フィールドに、名前と値のペアとしてパスワードを入力すること(本番環境では許可されません)、または「パスワード」フィールドにこれを入力することができます。物理データベース接続作成時にJDBCドライバに渡される「プロパティ」で定義されているパスワード値は、「パスワード」フィールドの値によりオーバーライドされます。プロパティ文字列のパスワード・プロパティのかわりにパスワード属性を使用することをお薦めします。パスワード値は構成ファイルで暗号化され(モジュール・ファイル内のjdbc-driver-paramsタグでパスワードで暗号化された属性として格納されます)、管理コンソールで表示されないためです。

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

データ・ソースで「接続時にクライアントIDを設定」属性が有効化されている場合は、アプリケーションによってデータ・ソースのデータベース接続がリクエストされたときに、WebLogic Serverインスタンスが現在のWebLogicユーザーIDを判別し、そのユーザー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ベースの接続プールを有効化」を指定してください。

GridLink JDBCリソースのモニタリング

次の各項では、GridLink JDBCオブジェクトのモニタリングについて説明します。

- 実行時統計の表示

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

JDBCのモニタリングの詳細は、「WebLogic JDBCリソースのモニタリング」を参照してください。

実行時統計の表示

GridLinkデータ・ソースの実行時の統計は、管理コンソールを使用するか、関連するランタイムMBeanを通じて表示できます。

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) - ONSクライアント情報(LBAイベント本体を含む)をトレースします。

UCP JDKロギング

UPC JDKロギングを有効化にする場合は、http://download.oracle.com/docs/cd/B28359_01/java.111/e10788/get_started.htm#sthref67の手順を実行してください。

コマンド行を使用したデバッグの有効化

GridLinkデータ・ソースのデバッグ・プロパティを、コマンド行から適切に設定します。次に例を示します。

-Dweblogic.debug.DebugJDBCRAC=true
-Dweblogic.debug.DebugJDBCONS=true
-Dweblogic.debug.DebugJDBCUCP=true

この方法は静的なものであり、サーバーの起動時にのみ使用できます。

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

次の各項では、GridLinkデータ・ソースを使用する際のベスト・プラクティスについて説明します。

- 例外のキャッシュと処理

例外のキャッシュと処理

アプリケーションは、すべての例外をキャッシュして処理する必要があります。GridLinkデータ・ソースを使用するアプリケーションは、流用された接続でJDBC操作を実行するときに、IO socket read errorなどの例外を予期しておく必要があります。接続の有効性を検査して、必要なときには再接続することがベスト・プラクティスになります。接続の例外は、FANイベントの到着前にドライバが停止を検出した場合や、接続プールのクリーンアップの結果として発生することがあります。計画外停止イベントの場合は、その停止の影響を受けるすべての接続が、接続プールによって中断されます。

脚注の凡例

脚注1: たとえば、Oracle Data Guardなどです。

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

この章では、WebLogic Server 10.3.6でマルチ・データ・ソースを構成および使用して、接続リクエスト時に、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する方法について説明します。

マルチ・データ・ソースとは、データ・ソースが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マルチ・データ・ソース: 構成: 一般」に関する項を参照してください。

WebLogic Serverは、手動で無効化したデータ・ソースに対して、テストも自動的な再有効化も行いません。テストは自動的に無効化されたデータ・ソースに対してのみ行われます。

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、データ・ソースの再有効化が行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。

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

デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在のデータ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。

現在のデータ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、管理コンソールの「JDBCマルチ・データ・ソース: 構成: 一般」ページで「ビジー時はリクエストをフェイルオーバー」オプションを有効にします。(JDBCDataSourceParamsBeanのFailoverRequestIfBusy属性でも設定できます)。有効(trueに設定)の場合、現在のデータ・ソース内のすべての接続が使用中のとき、アプリケーションの接続リクエストはマルチ・データ・ソース内の次に使用可能なデータ・ソースにルーティングされます。無効(デフォルトのfalseに設定)の場合、接続リクエストのフェイルオーバーは行われません。

マルチ・データ・ソースの構成にConnectionPoolFailoverCallbackHandlerが含まれている場合は、コールバック・ハンドラが呼び出されてから、フェイルオーバーが行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

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

フェイルオーバー・アルゴリズムを使用したマルチ・データ・ソースがマルチ・データ・ソースのJDBCデータ・ソースからリストの次のデータ・ソースに接続リクエストをフェイルオーバーする時間を制御するコールバック・ハンドラをWebLogic Serverに登録できます。

フェイルオーバーを行うかどうか、またはいつ行うかをコールバック・ハンドラで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、フェイルオーバーの前に実行できるようになります。

コールバック・ハンドラは、マルチ・データ・ソースのフェイルオーバーのコールバック・ハンドラ属性を介して、マルチ・データ・ソースごとに登録されます。コールバック・ハンドラを適用する各マルチ・データ・ソースに、コールバック・ハンドラを登録する必要があります。また、ドメイン内のマルチ・データ・ソースごとに、別々のコールバック・ハンドラを登録できます。

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

マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースの実装が含まれている必要があります。マルチ・データ・ソースでリスト内の次のデータ・ソースにフェイルオーバーする必要がある場合や、以前に無効化されたデータ・ソースが利用可能になった場合、ConnectionPoolFailoverCallbackインタフェースのallowPoolFailover()メソッドが呼び出され、次に定義されている3つのパラメータ(currPool、nextPoolおよびopcode)の値が渡されます。WebLogic Serverはコールバック・ハンドラからの戻り値を待機し、その後タスクが完了されます。

アプリケーションは、次に定義されている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 - 処理を続行します。この場合、示されたデータ・ソースを再有効化することを意味します。マルチ・データ・ソース・アルゴリズムと、含まれるデータ・ソース・リスト内のデータ・ソースの位置によって、WebLogic Serverはデータ・ソースにルーティングする接続リクエストを再開します。

- 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マルチ・データ・ソースのデプロイ

接続リクエストに応じるために、マルチ・データ・ソースで使用されているデータ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースでは、接続リクエストを満たすために同じサーバーにデプロイされるデータ・ソースを常に使用します。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイ・ターゲットとして選択します。マルチ・データ・ソースをサーバーにデプロイすると、そのサーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。マルチ・データ・ソースをクラスタにデプロイすると、クラスタ内の各サーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。

手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイに関する項を参照してください。

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

この章では、WebLogic Server 10.3.6のOracleドライバとデータベースを使用する場合にデータ・ソースとドライバのパフォーマンスを向上させる詳細構成オプションを提供します。オプションには、プロキシ認証、接続での資格証明の設定、接続収集、接続のラベル付けなどがあります。

この章には次の項が含まれます:

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

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

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

- 接続収集の構成

- 接続のラベル付け

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

WebLogic Serverには、次のようなOracleドライバの使用時に向上したデータ・ソース・パフォーマンスを提供するいくつかの属性が用意されています。

- OracleでJavaNet Fastpathの有効化: Oracle JDBC JavaNet Fastpathを有効化して、データ・コピーと断片化を削減します。

- OracleでUTF8変換の最適化: Oracle JDBC UTF-8変換の最適化オプションを有効化します。

環境でこれらの属性をサポートする場合、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テスト文が再作成されます。

これらの動作は、インスタンス間で接続を共有するアプリケーションに影響を与える場合があり、接続に関連する一部の状態が予期されます。

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

WebLogicデータ・ソースを構成して、Oracleデータベースの接続時にデータベース資格証明を設定する接続が可能です。構成された場合、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()リクエストのプロキシ・ユーザーの接続を返す可能性があります。グローバル・トランザクションでこの機能を使用する場合、単一データベースusernameを指定することをお薦めします。

接続収集の構成

データ・ソースが指定された数の使用可能な接続に達した場合に解放する予約された接続数を指定できます。収集は、指定された数の接続をプール内で常に使用可能にするのに役立ち、接続初期化を最小限に抑えることでパフォーマンスを向上させます。

接続収集は、特にアプリケーションで接続ハンドルをキャッシュする場合に便利です。通常、キャッシングはパフォーマンス上の理由から実行されます。これは、キャッシングにより、接続がトランザクションに参加するために必要となる状態の初期化が最小限になるためです。たとえば、接続はデータ・ソースから予約され、必要なセッション状態で初期化された後、コンテキスト・オブジェクト内に保持されます。この方法で接続を保持することが、接続プールに使用可能な接続がなくなる原因になる可能性があります。接続収集により、予約された接続が適切に回収され、接続を再使用できるようになります。

アプリケーションで接続収集を使用するには、次の手順を実行します。

1. 接続収集の有効化

2. 接続を収集可能にする

3. 収集した接続のリカバリ

接続収集の有効化

データ・ソース構成の「接続収集トリガー数」属性を使用して、接続収集をトリガーするためのしきい値を有効にし、このしきい値を指定します。たとえば、「接続収集トリガー数」が10に設定されている場合、接続収集が有効化され、使用可能な接続数が10まで減少すると、データ・ソースにより予約されている接続の収集が開始されます。値の-1では、接続収集は無効化されます。

接続収集がトリガーされると、「接続収集最大数」により、プールに返却できる予約された接続の数が指定されます。実際に収集される接続の数は、1から「接続収集最大数」の範囲となります。

Oracle WebLogic Server管理コンソール・ヘルプの接続プールに対する接続収集の構成に関する項を参照してください。

接続を収集可能にする

接続収集が有効化されると、すべての接続が収集可能になります。接続を収集可能にしない場合、引数値としてfalseを指定してoracle.ucp.jdbc.HarvestableConnectionインタフェースのsetConnectionHarvestable(boolean)メソッドをコールすることで、その接続を収集不可として明示的にマークする必要があります。

たとえば、トランザクション内でトランザクションが使用される場合に収集されないようにするには、次の文を使用します。

.  . .
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のみコールできます。

- アプリケーションにより接続がクローズされない場合、LEAKプロファイリングが有効の場合には、接続が強制的にクローズされたことを示す警告がログに記録されます。

- コールバックにより例外がスローされた場合、メッセージがログに記録され、その例外は無視されます。すべてのスタック・トレースを取得するには、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メソッドの結果は、接続を必要な状態に再構成するために必要なコストの見積りを表す整数値です。値が大きいほど、接続の再構成にはコストがかかります。接続プールは、常に最も低いコスト値の接続を戻します。アルゴリズムは次のとおりです。

- costメソッドがある接続について0を戻した場合、その接続が適合となります(これは、requestedLabelsとcurrentLabelsが同等ということを示しません)。接続プールは、検出された接続に対してconfigureをコールせず、単に接続を戻します。

- costメソッドが0以外の値(負または正の整数)を戻した場合、コスト値が0の接続を検出するか、使用可能な接続がなくなるまで繰り返します。

- すべての使用可能な接続に対して繰り返して、接続の最低コストがInteger.MAX_VALUE(デフォルトでは2147483647)となった場合、プール内に接続リクエストを満たす接続はありません。新しい接続を作成し、それに対しconfigureメソッドをコールし、この新しい接続を戻します。プールが最大プール・サイズに達している(新しい接続を作成できない)場合は、SQL例外をスローするか、接続待機タイムアウト属性が指定されていれば待機するかのいずれかです。

- すべての使用可能な接続に対して繰り返して、接続の最低コストがInteger.MAX_VALUEよりも低い場合、その接続に対してconfigureメソッドをコールし、その接続を戻します。複数の接続がInteger.MAX_VALUEを下回る場合は、最低コストの接続を戻します。

追加のgetRequestedLabels()メソッドを含む拡張コールバック・インタフェース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つの接続プールに登録できるコールバックは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メソッドを使用して、予約された接続に適用されます。任意の数の接続ラベルを予約された接続に累積的に適用できます。ラベルが接続に適用されるたびに、指定されたキー/値のペアが、ラベルの既存コレクションに追加されます。最後に適用された値のみがどのキーに対しても保持されます。

注意:
予約された接続にラベルを適用するには、ラベリング・コールバックを接続プールに登録する必要があります。登録しないと、ラベリングは無視されます。「ラベリング・コールバックの作成」を参照してください。

次の例では、トランザクション分離レベルで接続を初期化した後、ラベルを接続に適用しています。

. . .
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;

これらのメソッドには、getConnectionメソッドにPropertiesオブジェクトとして渡すラベルが必要です。次の例では、property1 valueというラベルが付いた接続の取得を示します。

. . .
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 Server 10.3.6のWebLogicデータ・ソースのXA、非XAおよびグローバル・トランザクション・オプションについて説明します。

管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic Server 10.3.6は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のプログラミング』のJTAへのOracle WebLogic拡張に関する項を参照)。これが発生した場合、データベース管理者はより大規模な列を持つ表を手動で作成できます。

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フェーズ・コミットをエミュレートするようになります。このオプションは、データ・ソース構成の「構成」→「一般」タブの詳細オプションです。

「非XAドライバの2フェーズ・コミットのエミュレート」オプションが選択されている場合(EnableTwoPhaseCommitがtrueに設定されている場合)、非XA JDBCリソースはXAResource.prepare()メソッドのコール中に常にXA_OKを返します。リソースは、後続のXAResource.commit()またはXAResource.rollback()コールに応答して、ローカル・トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティックな障害の結果、アプリケーション・データは矛盾した状態のままになる場合があります。

コンソールで「非XAドライバ用の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ドライバを介して)、トランザクション・マネージャによって制御されるトランザクションにリソースが参加できるように、譲歩する必要があります。

「非XAドライバ用の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登録

グローバル・トランザクションで複数の非XAリソースを使用する場合、非アトミック出力ではJTASystemExceptionsが確認される可能性があります。非アトミック出力およびSystemExceptionsの確率は、2フェーズ・エミュレートのデータ・ソース登録数によって上昇する傾向があります。

注意:
異なるバージョンのドメインにわたってJTAトランザクションで2フェーズ・エミュレートのデータ・ソースを使用することは、サポートされていません。

8 セキュアなJDBCデータ・ソースへのロールおよびポリシーの使用

この章では、WebLogic Server 10.3.6でセキュアなJDBCデータ・ソースにロールおよびポリシーを使用する方法について説明します。

この章の内容は次のとおりです。

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

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

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

オプションで、JDBCデータ・ソースへのアクセスを制限できます。WebLogic Serverでは、WebLogicリソースへのアクセス権を誰が持っていますか、という質問に対して、セキュリティ・ポリシーが解答を出します。セキュリティ・ポリシーは、WebLogicリソースとユーザー、グループ、またはロールの間の関連付けを定義するときに作成します。WebLogicリソースは、セキュリティ・ポリシーが割り当てられるまでは保護されません。すべてのWebLogic Serverリソースに対してセキュリティを設定する方法については、Oracle WebLogic Server管理コンソール・ヘルプのロールおよびポリシーを使用したリソースの保護に関する項を参照してください。サーバー・リソースの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

管理者がJDBCデータ・ソースに対して実行できるアクションを制限できる管理者用メソッドを割り当てることで、JDBCリソース操作を保護できます。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のJava DataBase Connectivity (JDBC)リソースに関する項を参照してください。

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

JDBC MBeansでは、管理者およびデプロイヤ・ロールのみ使用できます。次の各項では、JDBC MBeansに定義されたセキュリティ・ロールについて説明します。

- JDBCドメイン構成MBeans

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

WebLogic Serverのデフォルトのセキュリティ設定の詳細は、Oracle WebLogic Server MBeanリファレンスのMBeansのデフォルトのセキュリティ・ポリシーに関する項を参照してください。

JDBCドメイン構成MBeans

デフォルトのセキュリティ設定をオーバーライドする設定を持つ次のドメイン構成JDBC MBeans。

- JDBCConnectionPoolMBean (非推奨)

- JDBCDataSourceFactoryMBean (非推奨)

- JDBCDataSourceMBean (非推奨)

- JDBCMultiPoolMBean (非推奨)

- JDBCSystemResourceMBean

- JDBCTxDataSourceMBean (非推奨)

Oracle WebLogic Server MBeanリファレンスのドメイン構成MBeansに関する項を参照してください。

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

デフォルトのセキュリティ設定をオーバーライドする設定を持つ次のシステム・モジュールJDBC MBeans。

- JDBCConnectionPoolParamsBean

- JDBCDataSourceBean

- JDBCDataSourceParamsBean

- JDBCDriverParamsBean

- JDBCPropertiesBean

- JDBCPropertyBean

- JDBCXAParamsBean

Oracle WebLogic Server MBeanリファレンスのシステム・モジュールMBeansに関する項を参照してください。

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

この章では、WebLogic Server 10.3.6でサーバーおよびクラスタにデータ・ソースをデプロイする方法について説明します。

この章には次の項が含まれます:

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

- 無応答データベースが原因で発生するサーバー起動ハングアップの最小化

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

サーバーまたはクラスタにデータ・ソースをデプロイするには、デプロイメント・ターゲットとしてサーバーまたはクラスタを選択します。サーバーにデータ・ソースがデプロイされると、WebLogic Serverにより、サーバーにデータ・ソースのインスタンス(データ・ソースのデータベース接続のプールを含む)が作成されます。クラスタにデータ・ソースをデプロイすると、WebLogic Serverにより、クラスタ内の各サーバーにデータ・ソースのインスタンスが作成されます。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプのターゲットJDBCデータ・ソースに関する項を参照してください。

無応答データベースが原因で発生するサーバー起動ハングアップの最小化

サーバー起動時に、WebLogic Serverにより、サーバーにデプロイされているデータ・ソースでデータベース接続の作成が試行されます。データベースに到達できない場合、サーバーの起動は長期間のSTANDBY状態でハングアップすることがあります。この原因は、データベース・サーバーからの応答を待機するJDBCドライバ・コード内でハングアップするWebLogic Serverスレッドです。ハングアップの継続時間は、JDBCドライバおよびWebLogic ServerマシンのTCP/IPタイムアウト設定により決まります。

この問題に対処するために、WebLogic Serverには、ServerMBeanのJDBCLoginTimeoutSeconds属性が含まれます。この属性に値を設定すると、その値はjava.sql.DriverManager.setLoginTimeout()に渡されます。データベース接続の作成に使用されるJDBCドライバにsetLoginTimeoutメソッドが実装されている場合、データベース接続の作成試行の待機時間は、指定されているタイムアウト時間のみです。

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

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

この章には次の項が含まれます:

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

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

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

- 接続リクエストにおける接続待機の有効化

- リークした接続の自動リカバリ

- 適切な接続数によるサーバーのロック回避

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

- スレッドに固定のプロパティの使用によるパフォーマンス向上

- アンラップされたデータ型オブジェクトの使用

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

アプリケーションまたはEJBでプリコンパイルされた文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバー間の通信処理、およびデータベース・サーバー上での通信処理に相当なオーバーヘッドが発生します。処理コストを最小限に抑えるには、アプリケーションで使用されるプリコンパイルされた文およびコール可能文をWebLogic Serverでキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。

データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。

- 文キャッシュのタイプ: 文キャッシュにどの文を格納するかを決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください。

- 文キャッシュ・サイズ: 接続ごとにキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください。

管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの文キャッシュの構成に関する項を参照してください。

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

文キャッシュのタイプ(またはアルゴリズム)は、データ・ソース内の接続ごとにキャッシュに格納するプリコンパイルされた文またはコール可能文を決定します。次のオプションから選択できます:

- LRU(最近最も使用されていない)

- 固定

LRU(最近最も使用されていない)

LRU(最近最も使用されていない、デフォルト)を文キャッシュのタイプとして選択した場合、WebLogic Serverでは、文キャッシュ・サイズに達するまで、プリコンパイルされた文およびコール可能文がキャッシュされます。アプリケーションがConnection.prepareStatement()をコールすると、WebLogic Serverでは、文が文キャッシュに格納されているかどうかが確認されます。格納されている場合は、キャッシュされた文が返されます(その文がまだ使用されていない場合)。文がキャッシュ内に存在せず、キャッシュがいっぱいの場合は(キャッシュ内の文の数=文キャッシュ・サイズ)、WebLogic Serverはキャッシュ内のどの文が最近最も使用されていないかを判別して、キャッシュ内のその文を新しい文に置換します。

WebLogic ServerにおけるLRU文キャッシュのアルゴリズムでは、近似LRUスキームが使用されます。

固定

FIXEDを文キャッシュのタイプとして選択した場合、WebLogic Serverでは、文キャッシュ・サイズに達するまで、接続時に使用されたプリコンパイルされた文およびコール可能文がキャッシュされます。追加の文を使用した場合、それらの文はキャッシュされません。

この文キャッシュのアルゴリズムを使用すると、ほとんど使用されない文が誤ってキャッシュされることがあります。通常は、LRUアルゴリズムが優先されます。その理由は、めったに使用しない文は最終的にキャッシュ内でよく使用される文に置換されるためです。

文キャッシュ・サイズ

「文キャッシュ・サイズ」属性によって、データ・ソースのインスタンス別に、接続ごとにキャッシュするプリコンパイルされた文とコール可能文の合計数が決まります。文をキャッシュすることによって、システム・パフォーマンスの向上を図ることができます。ただし、開いているプリコンパイルされた文とコール可能文をDBMSでどのように処理するかを検討する必要があります。多くの場合、DBMSには、開いている文ごとにカーソルが保持されています。これは、文キャッシュ内にあるプリコンパイルされた文およびコール可能文に当てはまります。キャッシュする文が多すぎると、データベース・サーバーでのオープン・カーソルの限度を超過する場合があります。

たとえば、サーバー2台に10個の接続をデプロイしているデータ・ソースがあり、文キャッシュ・サイズが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つの基本的なテストが用意されています。

- 自動テスト: データ・ソースに対するオプションを使用して構成し、データベース接続が常に正常であるようにします。

- 手動テスト: データ・ソースのトラブルシューティングを実行できます。

次の各項では、自動接続テスト・オプションについて説明します。手動の接続テストの詳細は、「データ・ソースおよびデータベース接続のテスト」を参照してください。

データ・ソースに対する自動テスト・オプションを構成するには、管理コンソールから、またはJDBCConnectionPoolParamsBeanを使用するWLSTによって次のオプションを設定します。

- テスト頻度 - (JDBCConnectionPoolParamsBean内のTestFrequencySeconds): この属性は、未使用接続のテスト間の秒数の指定に使用します。WebLogic Serverでは未使用の接続がテストされ、障害のある接続はすべて閉じられて置換されます。テスト対象の表名を設定する必要もあります。

- 予約時に接続をテスト - (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve): クライアントに接続する前に、各接続をテストする場合にこのオプションを有効にします。これを有効にすると、リクエストへの応答が若干遅れますが、接続が正常であることが保証されます。テスト対象の表名を設定する必要もあります。

- テスト対象の表名 - (JDBCConnectionPoolParamsBean内のTestTableName): この属性は、接続テストで使用する表名の指定に使用します。また、SQLと入力してスペースを1つ続け、テストとして実行するSQLコードを入力することによって、標準テストのかわりに実行するSQLコードを指定することもできます。テスト対象の表名は、データベース接続テストの有効化には必須です。

- アイドル・プール接続を信頼する秒数 - (JDBCConnectionPoolParamsBean内のSecondsToTrustAnIdlePoolConnection): このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であると信頼されて接続テストがスキップされることが問題なしと実証された後の秒数の指定に使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください。

これらのオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 接続: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。

接続テスト・オプションの設定手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。

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

データ・ソース内でデータベース接続をテストする際、WebLogic Serverでは、データ・ソースから接続を予約し、その接続に対して小規模な問合せを実行して、接続をデータ・ソース内のプールに戻します。サーバー・インスタンスによってプール状況に関する統計が追跡されます。追跡される内容は、接続テストの完了に要する時間数、接続を待機している接続数、テスト中の接続数などです。最近のテスト接続動作の履歴を使用して、接続テストが失敗したと判断されるまでサーバー・インスタンスが待機する時間が計算されます。

あるスレッドの接続が通常よりも長くかかっているように思われる場合、サーバー・インスタンスは、異常に長時間のテストが完了するまで、その他のスレッドのテストを遅らせることがあります。そのスレッドの接続テストに時間がかかりすぎている場合(デフォルトでは10秒)、プールはDBMS接続の失敗を宣言して無効になり、予約されていなくても、またはアプリケーションが使用中であっても、すべての接続が強制的に切断されます。

これは非常にまれなケースであり、ネットワーク・ケーブルの切断や、ソケットでコールを実行中のJVMスレッドをロックする可能性のあるその他の問題により発生する果てしなく続く中断により、JVMがOS TCPの限度(通常は10分)に到達するまでブレークできないと判断される可能性を軽減することを意図しています。この方法でプールが無効になると、DBMSへの再接続が定期的に試行されます(デフォルトは5秒ごと)。新しい接続が実行されると、プールが再有効化され、後続の接続リクエストが通常として機能します(ロードの必要に応じてプールが再移入されます)。

テストで使用される問合せは、テスト対象の表名の値によって決定されます。値が表名である場合、問合せはselect 1 from table_nameとなります。テスト対象の表名に、SQLで始まり、その後にスペースと問合せが続く完全問合せが含まれている場合は、データベース接続のテスト時にその問合せが使用されます。

接続がテストに失敗すると、その接続が閉じられて再作成され、その後で新しい接続がテストされます。

接続テストのセマンティクスの詳細は、次の各項で説明します。

- データベース接続の作成時における接続テスト

- 定期的な接続テスト

- 予約済の接続のテスト

- データベース接続切断後の接続テスト遅延の最小化

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

- DBMS接続の切断後の接続リクエスト遅延の最小化

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

データベース接続の作成時における接続テスト

データ・ソース内に接続が作成されると、WebLogic Serverでは、テスト対象の表名の値によって定義された問合せを使用して各接続がテストされます。接続は、データ・ソースがデプロイされるときに作成されます。作成のタイミングは、サーバーの起動時、データ・ソースの作成時、接続に対する需要を満たすために容量を増やすとき、あるいは、接続テストに失敗した接続を再作成するときです。

このテストの目的は、新しい接続が実行可能であり、アプリケーションから接続が要求されたときに使用可能であることを確認することです。

定期的な接続テスト

テスト頻度が0よりも大きい場合は、アプリケーションによって現在予約されていないプールされた接続が定期的にテストされます。このテストは、テスト対象の表名で定義された問合せに基づいています。接続がテストに失敗すると、その接続が閉じられて再作成され、さらに、新しい接続をテストした後でプールに戻されます。

予約済の接続のテスト

「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータ・ソースからの接続をリクエストしたときに、「テスト対象の表名」で指定された問合せを使用して接続がテストされ、その後でアプリケーションに接続が渡されます。デフォルト値は有効になっていません。

予約済の接続をテストすると、接続リクエストに対する応答に遅れが生じますが、アプリケーションが接続を取得した時点で接続が実行可能であることが保証されます。「アイドル・プール接続を信頼する秒数」を調整することによって、予約済の接続のテストによる影響を最小限に抑えられます。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください。

データベース接続切断後の接続テスト遅延の最小化

DBMSとの接続が、たとえ瞬間的であっても切断すると、データ・ソース内の一部、またはすべてのJDBC接続が通常は使用できなくなります。データ・ソースが要求時に接続をテストするように構成されている場合、アプリケーションがデータベース接続をリクエストしたときに、接続がテストされ、接続が使用不能であることが検出されて、リクエストを満たすために新しい接続への置換が試みられます。通常は、DBMSがオンライン復旧した時点でリフレッシュ・プロセスが成功します。ただし、場合によっては、また一部の失敗モードでは、使用不能の接続をテストすると遅延が長期化することがあります。

この遅延を最小化するため、WebLogicデータ・ソースには、多数の接続テスト失敗の後にデータ・ソース内のすべての接続を使用不能と見なし、データ・ソース内のすべての接続を閉じるロジックが組み込まれています。すべての接続が閉じられた後でアプリケーションが接続をリクエストした場合、データ・ソースは、はじめに使用不能の接続をテストする必要もなく、接続を作成します。この動作によって、データ・ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小限に抑えられます。

WebLogic Serverでは、データ・ソースに対する「テスト頻度」の設定に基づいて、すべての接続を閉じる前の失敗数が決定されます。

- 「テスト頻度」が0より大きい場合、すべての接続を閉じる前のテスト失敗数は2に設定されます。

- 「テスト頻度」が0に設定されている場合(定期テストは無効になります)、すべての接続を閉じる前のテスト失敗数は、データ・ソースの最大容量の25%に設定されます。

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

DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、テストを続けて使用不能の接続の置換を試行します。データベースが使用可能になったときにこの動作によってデータ・ソースが即時に反応できるため、この動作は効果的です。ただし、使用不能のデータベース接続のテストにはネットワークのタイムアウトと同じ時間がかかるため、クライアントに対して長時間の遅延が生じることがあります。

この遅延を最小化するため、WebLogicデータ・ソースには、使用不能の接続を置き換えるために2回連続して失敗した後にデータ・ソースを無効化するロジックが含まれています。アプリケーションが無効化されたデータ・ソースからの接続をリクエストした場合は、接続が使用できないことをクライアントに通知するためにPoolDisabledSQLExceptionがすぐにスローされます。

このように無効になったデータ・ソースに対して、リフレッシュ・プロセスが定期的に実行されます。リフレッシュ・プロセスは次の処理を行います。

- サーバー・インスタンスは、データベース・サーバーに対して5秒ごとにヘルス・チェックを実行します。この設定は構成可能ではありません。

- サーバー・インスタンスは、データベースのリカバリを認識すると、新しいデータベース接続を作成してデータ・ソースを有効にします。

また、管理コンソールを使用してデータ・ソースを手動で有効にすることもできます。

DBMS接続の切断後の接続リクエスト遅延の最小化

DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、テストを続けて使用不能の接続の置換を試行します。データベースが使用可能になったときにこの動作によってデータ・ソースが即時に反応できるため、この動作は効果的です。ただし、使用不能のデータベース接続をテストして置換を無駄に試行すると、OSネットワークのタイムアウト(分)と同じ時間がかかる場合があるため、クライアントにとって予想される失敗メッセージが得られるまで長時間の遅延が生じることがあります。

注意:
データ・ソースがマルチ・データ・ソースに追加されている場合、そのマルチ・データ・ソースはデータ・ソースの無効化および再有効化の責任を引き受けます。デフォルトでは、マルチ・データ・ソースは2分ごとに(構成可能)チェックを行い、接続を再確立できるデータ・ソースをすべて再有効化します。

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

大量の非常に短いサイクル(reserve-do_one_query-closeなど)でDBMS接続を使用するアプリケーションの場合、データ・ソースが接続をテストすると、使用サイクルごとに相当量のオーバーヘッドが生じることがあります。接続テストの影響を最小限に抑えるには、JDBCデータ・ソース構成で「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用した、または最近テストしたデータベース接続を信頼して接続テストをスキップします。

データ・ソースに対して「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータベース接続をリクエストすると、データベース接続がテストされた後でアプリケーションに接続が渡されます。「アイドル・プール接続を信頼する秒数」に対して指定された時間内にリクエストが行われた場合、接続はテスト済であるか、アプリケーションにより正常に使用されているため、アプリケーションに接続を渡す前の接続テストはスキップされます。

データ・ソースに対する「テスト頻度」が0より大きい値である場合にも、接続が正常に使用されていて、「アイドル・プール接続を信頼する秒数」に指定された時間内にデータ・ソースに接続が戻されていれば、接続テストはスキップされます。

「アイドル・プール接続を信頼する秒数」の設定手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。

「アイドル・プール接続を信頼する秒数」は、特に通信量が大容量の間にデータベース接続テストによって生じた遅延を最小化することによって、アプリケーションのパフォーマンスを向上できるチューニング機能です。ただし、特に設定値が高すぎる場合は、接続テストの効果が低下する可能性があります。適切な値は、使用環境と、接続が使用できなくなる可能性によって異なります。

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

接続テスト属性が使用環境に最もよく適合するように設定することをお薦めします。たとえば、アプリケーションでデータベース接続失敗が許容されない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して「予約時に接続をテスト」を有効にし、接続がアプリケーションに渡される前にすべての接続がテストされるようにすることをお薦めします。アプリケーションがデータ・ソースから接続を受け取る際の遅延に影響を受けやすく、使用不能の接続を使用したことによるアプリケーション・エラーを許容できる場合には、「アイドル・プール接続を信頼する秒数」の設定値を高くし、「テスト頻度」の設定値を低くして、「予約時に接続をテスト」を有効にすることをお薦めします。

これらの設定を使用すると、アプリケーションが接続をリクエストするときではなく、接続が使用されていないときに、プール内の接続をテストするデータ・ソースへのアプリケーションの依存度が高くなります。

注意:
最終的に、WebLogicが最善を尽くしたとしても、WebLogicでの接続テストが正常に行われた直後、かつアプリケーションが接続を使用する直前に接続が失敗する可能性があります。したがって、すべてのアプリケーションは、使用不能の接続により予想外の例外が発生した場合でも適切に応答できるように作成する必要があります。

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

管理コンソールを使用してデータ・ソースを作成すると、管理コンソールでは、選択したDBMSに基づき、データ・ソースの「テスト対象の表名」属性が自動的に設定されます。「テスト対象の表名」属性は、テスト・オプションの構成方法に応じて、オプションとして定期的に実行される接続テストで、または、接続を作成または予約するときに使用されます。データベースのテストが正常に行われるためには、データ・ソース内にデータベース接続を作成するデータベース・ユーザーがデータベース表へのアクセス権を持っている必要があります。アクセス権がない場合は、ユーザーにアクセス権を付与するか(この変更はDBMSで行います)、または、「テスト対象の表名」属性をユーザーがアクセス権を持つ表の名前に変更します(この変更はWebLogic Server管理コンソールで行います)。

「テスト対象の表名」は、オーバーロードのパラメータです。この最も単純なフォームでは、WLSが接続をテストするために問い合せる表の名前を指定します。これをOracleに関して任意の表("DUAL"など)に設定すると、データ・ソースは問合せselect count(*) from DUALを実行します。この方法で使用する場合は、小規模でめったに更新されない表(できれば、DUALなどのpseudo-table)を選択することをお薦めします。

このパラメータを定義する2番目の方法では、接続をテストするために任意のSQL文字列を実行できるようにします。このオプションを使用するには、パラメータを"SQL"に設定し、さらに目的のSQL文字列を指定します。たとえば、SQL select 1はSQLServerに対して機能します。これは定数を選択する問合せに表を必要としません。このオプションは、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

進行状況

SQL SELECT COUNT(*) FROM SYSTABLES

Sybase

SQL SELECT 1

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

WebLogic JDBCデータ・ソースには「接続作成の再試行間隔」オプション(JDBCConnectionPoolParamsBean内のConnectionCreationRetryFrequencySeconds)が組み込まれていて、データベースへの接続設定を試行する間隔を秒数で指定できます。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続作成が再試行され、成功するまで続行されます。このオプションは、サーバー起動時にデータ・ソースが作成されたとき、データ・ソースがデプロイされたとき、または初期容量が増加されたときに作成された接続に適用されます。プール拡張用に作成されたり、プール内の使用不能の接続を置換するために作成された接続には適用されません。

デフォルトでは、「接続作成の再試行間隔」は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データ・ソース: 構成: 接続プール」ページで、「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」の値を設定すると、指定した秒数の間に予約された接続に対してアクティビティが発生しなかった場合、接続がデータ・ソースに強制的に戻されます。0(デフォルト値)に設定した場合、この機能は無効になります。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。

実際のタイムアウトは、「非アクティブ接続タイムアウト」の設定値を超過することがあります。内部のデータ・ソース・メンテナンス・スレッドは5秒ごとに実行されます。非アクティブ接続タイムアウト(例: 30秒)に達すると、非アクティブな接続がないかチェックされます。現在のチェックの直前、または前のチェックの直後に予約された接続のタイムアウトを回避するために、サーバーは非アクティブの接続に対して「第2のチャンス」を与えます。次回のチェック時でも接続がまだ非アクティブの場合、その接続はタイムアウトして、データ・ソースに強制的に戻されます。概して、設定値よりも50%多い遅延が生じる可能性があります。

適切な接続数によるサーバーのロック回避

アプリケーションが使用可能な接続の存在しないデータ・ソースから接続を取得しようとすると、データ・ソースに使用可能な接続がないという例外がデータ・ソースからスローされます。このエラーを回避するには、接続リクエストのピーク・ロードの受容に必要なサイズまでデータ・ソースが拡大できることを確認します。データ・ソース内で使用可能な最大接続数を増やすには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページで、データ・ソースの「最大容量」の値を高くします。

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

JDBCデータ・ソースに対して「文タイムアウト」オプションを指定すると、データ・ソースから予約されたデータベース接続での文の処理時間を制限できます。「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間がJDBCドライバに渡されます。コールが実行され、ドライバから例外がスローされた場合は値が無視されます。ドライバは、警告なくコールをサポートしなかったり、限定的サポートをドキュメント化している場合があります。ドライバのドキュメントをチェックして、予想される動作を確認することをお薦めします。

「文タイムアウト」が-1(デフォルト)に設定されると、文はタイムアウトしません。

このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。

スレッドに固定のプロパティの使用によるパフォーマンス向上

アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。

Pinned-To-Threadを有効にすると、アプリケーションが実行スレッドを使用して初めて接続を予約するときにデータ・ソースからのデータベース接続がその実行スレッドに固定されます。アプリケーションが接続の使用を終了してconnection.close()をコールすると、接続が実行スレッドに固定されたままになり、データ・ソースに戻されません(コールしない場合は、接続がデータ・ソースに戻されます)。その後、アプリケーションが同じ実行スレッドを使用して接続をリクエストすると、WebLogic Serverによってスレッドで予約済みの接続が提供されます。複数のスレッドが同時に接続を予約しようとする場合に発生する、データ・ソースでのロックの競合がなく、限られた数のデータベース接続から同じ接続を予約しようとするスレッドの競合もありません。

注意:
このリリースでは、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. 「データ型のラップ」で、チェック・ボックスを選択解除してラップを無効にします。

7. 「保存」をクリックします。

8. これらの変更をアクティブにするには、管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックします。
この変更は即時に有効にはなりません。データ・ソースを再デプロイするか、サーバーを再起動する必要があります。

WLSTを使用したラップの無効化

データ型のラップを無効にするWLSTコード・スニペットは、次のとおりです。

. . .
jdbcSR = create(dsname,"JDBCSystemResource");
theJDBCResource = jdbcSR.getJDBCResource();
poolParams = theJDBCResource.getJDBCConnectionPoolParams();
poolParams.setWrapTypes(false);
. . .

この変更は即時に有効にはなりません。データ・ソースを再デプロイするか、サーバーを再起動する必要があります。

11 WebLogic ServerでのOracle RACの使用

この章では、WebLogic Server 10.3.6でOracle Real Application Clusters (Oracle RAC)を使用するための要件および構成タスクについて説明します。

Oracle WebLogic Server 10.3.6は、Oracle Database 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は、2台以上のクラスタ化マシンで実行しており、クラスタ・テクノロジを使用して共有ストレージ・デバイスにアクセスする2つ以上のOracleデータベース・インスタンスで構成されています。このアーキテクチャをサポートするために、これらのデータベース・インスタンスをホストするマシンが高速のインターコネクトによってリンクされてクラスタを構成します。インターコネクトは、クラスタのノード間の通信手段として使用される物理ネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサードパーティのクラスタリング・ソフトウェアが提供しています。

Oracle RACインストールは単一の標準Oracleデータベースのような外観であり、同じツールと手法でメンテナンスが行われます。クラスタ内のすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACは共有データへの各ノードのアクセスを調整して一貫性を維持し、整合性を確保します。クラスタへのノードの追加は簡単であり、ノードを追加する際にデータをパーティション化する必要がありません。つまり、Oracle RACのノード、ストレージ、またはその両方を追加することによって、使用率と需要の増加に伴うデータベース層のスケーラビリティを水平に設定できます。

ソフトウェア要件

Oracle RACによってWebLogic Serverを使用するには、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ドライバ11gを使用してデータベース接続を作成する必要があります。

ハードウェア要件

標準的なWebLogic Server/Oracle RACシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが組み込まれています。

WebLogic Serverクラスタ

WebLogic Serverクラスタの構成方法は多数あり、様々なハードウェア・オプションも使用できます。WebLogic Serverクラスタの構成の詳細は、Oracle WebLogic Serverのクラスタの使用に関する項を参照してください。

Oracle RACクラスタ

Oracle RACの最新のハードウェア要件については、Oracle RACドキュメントを参照してください。ただし、Oracle RACをWebLogic Serverで使用するには、Oracle RACインスタンスを強力な、本番品質のハードウェア上で実行する必要があります。Oracle RAC構成によって、合理的に予想されるアプリケーション・ロード要件に適したデータベース処理パフォーマンスが生成される必要があります。データベース応答に異常な遅延が生じると、データベース・フェイルオーバー・シナリオの際に予想外の動作が発生する可能性があります。

共有ストレージ

Oracle RAC構成では、すべてのデータ・ファイル、制御ファイル、パラメータ・ファイルは、すべてのOracle RACインスタンスで使用するために共有されます。次のいずれかのアーキテクチャを使用しているHAストレージ・ソリューションをお薦めします。

- 直接アタッチ・ストレージ(DAS): デュアル・ポート・ディスク・アレイまたはストレージ・エリア・ネットワーク(SAN)など

- ネットワーク接続ストレージ

サポートされるストレージ・ソリューションの詳細リストは、Oracleドキュメントを参照してください。

WebLogic ServerでOracle RACを使用するための構成オプション

WebLogic ServerでOracle RACを使用する場合、WebLogicドメインがOracle RACインスタンスと対話でき、適切に実行されるようにするために、WebLogicドメインを構成する必要があります。次の各項では、構成オプションと要件について説明します。

- Oracle RACを使用するためのWebLogic Server構成の選択

- WebLogic ServerでOracle RACを使用する場合の接続の検証

- WebLogic ServerでOracle RACを使用する場合の追加考慮事項

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ノード上のサービスへの接続の構成

はい

はい

いいえ

いいえ

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

WebLogicでは、Oracle Data Guardとマルチ・データ・ソースおよびAGLとの併用をサポートしています。マルチ・データ・ソースと併用する場合は、次の制限事項があります。

- フェイルオーバー・ポリシーのみがサポートされています。

- プライマリ・データ・センターでは1つのRACインスタンスのみが許可されています。マルチ・データ・ソースのメンバーである単一の汎用データ・ソースが、プライマリ・データ・センター用に構成されます。SCANを使用する場合は、INSTANCE_NAMEも指定する必要があります。

- 各スタンバイ・インスタンスに対して、マルチ・データ・ソースのメンバーである汎用データ・ソースを構成する必要があります。SCANを使用する場合は、各インスタンスに対してINSTANCE_NAMEも指定する必要があります。マルチ・データ・ソースのメンバーは、RACクラスタにおいて複数のインスタンスを表すことはできません。

WebLogic ServerでOracle RACを使用する場合の接続の検証

アプリケーションでJDBC 4.0 Connection.isValid APIを使用して接続の実行可能性を検証できます。

注意:
WebLogic Serverは、oracle.ucp.jdbc.ValidConnection.isValidまたはoracle.ucp.jdbc.ValidConnection.setInvalidはサポートしていません。

WebLogic ServerでOracle RACを使用する場合の追加考慮事項

AGLデータ・ソースまたはマルチ・データ・ソースでOracle RACを使用する場合、トランザクションを調整するために、データベース・サービス上の分散トランザクション処理(DTP)属性を使用しないでください。このオプションによって、サービスが常に1つのRACインスタンス上のみで実行されることが保証されます。単一のインスタンスへのトランザクション・アフィニティは、WebLogic ServerによってAGLまたはマルチ・データ・ソースに対して自動的に管理されます。DTPではサービス用のすべてのトランザクションが単一のRACインスタンスに制限されるのとは対照的に、これによってRACクラスタ全体が分散トランザクションで使用可能になります。

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

この章では、WebLogic Server 10.3.6でのJDBCドライバの設定方法および使用方法を説明します。

この章には次の項が含まれます:

- JDBCドライバのサポート

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

- サードパーティJDBCドライバの使用

- JDBCドライバの追加または更新

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

- デバッグ・モードでのOracle Thinドライバの使用方法

- SSL経由のOracle Thinドライバの使用

JDBCドライバのサポート

WebLogic Serverでは、アプリケーション・データ・アクセスおよびデータベース依存機能がサポートされています。詳細は、『Oracle WebLogic Serverの新機能』のデータベースの相互運用性に関する項を参照してください。

WebLogic ServerとともにインストールされるJDBCドライバ

Oracle WebLogic Serverとともに、Oracle Thinドライバの11gバージョン(JDK 6用のojdbc6_g.jar)がインストールされます。

注意:
WebLogic Serverとともに、WebLogicブランドのDataDirectのドライバもインストールされます。詳細は、「WebLogicブランドのDataDirectドライバの使用」を参照してください。

WebLogic Serverとともに、Oracle Thinドライバに加えて、mySQL 5.0.x (mysql-connector-java-commercial-5.0.x-bin.jar) JDBCドライバもインストールされます。

このドライバは、weblogic.jarとともにWL_HOME\server\libフォルダ(WL_HOMEはWebLogic Serverがインストールされるフォルダ)にインストールされます。weblogic.jarのマニフェストには、このファイルがリストされており、そのためこのファイルはweblogic.jarのロード時(サーバーの起動時)にロードされます。したがって、このJDBCドライバをCLASSPATHに追加する必要はありません。WebLogic Serverとともにインストールされるドライバの異なるバージョンを使用する予定の場合は、「JDBCドライバの追加または更新」を参照してください。

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を参照してください。

サードパーティJDBCドライバの使用

WebLogic ServerとともにインストールされないサードパーティJDBCドライバを使用する予定がある場合、ドライバ・ファイルへのパスでCLASSPATHを更新することにより、それらのドライバ・ファイルをインストールする必要があります。「JDBCドライバの追加または更新」を参照してください。

サポート対象のJDBCドライバの詳細は、『Oracle WebLogic Serverの新機能』のサポート対象の構成に関する項およびデータベースの相互運用性に関する項を参照してください。

JDBCドライバの追加または更新

新しいJDBCドライバを追加または既存のJDBCドライバを更新するには、次のようにします。

1. 既存のJDBCドライバを更新する場合、対応するJARファイルのバックアップ・コピーを作成します。WebLogic Serverとともにインストールされるドライバは、WL_HOME\server\libディレクトリにあります。

2. 適切な位置で新しいドライバJARを追加します。ドライバが異なる名前を持つ場合は、新しいドライバJARを追加し、古いJARをサブディレクトリから削除します。ドライバJARが同じ名前を持つ場合は、更新されたJARで元のJARを置き換えます。

3. CLASSPATHを変更する必要があるかどうかを判断します。

- JDBCドライバJARがWebLogic Serverとともにインストールされ、置き換えるJARの名前が同じ場合、CLASSPATHを変更する必要はありません。これらのファイルはweblogic.jarファイルのマニフェストに直接または間接的に含まれるので、サーバーの開始時に自動的にロードされます。

- 新しいJDBCドライバを追加する場合、または置き換えるJARの名前が元のJARと異なるJDBCドライバを更新する場合、次の手順を実行します。

- すべてのドメインで、WL_HOME/common/binのcommEnv.cmd/shスクリプトを編集し、使用するJARファイルをWEBLOGIC_CLASSPATH環境変数の先頭に追加します。使用するJARはクライアントJARファイルの前にある必要があります。必要に応じて、元のJARに対する参照を削除します。

- 特定のWebLogic Serverドメインに対し、そのドメインのbinディレクトリにあるsetDomainEnv.cmd/shスクリプトを編集し、そのJARファイルをPRE_CLASSPATH環境変数の先頭に追加します。使用するJARはクライアントJARファイルの前にある必要があります。必要に応じて、元のJARに対する参照を削除します。

注意:
setDomainEnvは、startWebLogicスクリプトなどの他のスクリプトがソースとなるように指定されます。setDomainEnvは、インタラクティブ・シェル内から直接呼び出さないでください。そうすることにより、使用するドメインで予期できない問題が発生する可能性があります。

Oracle 11g Thinドライバのグローバリゼーション・サポート

Oracle Thinドライバの11gバージョンでのグローバリゼーション・サポートのために、Oracleではnls_charset.zipにかわるorai18n.jarファイルを提供しています。Oracleのオブジェクト型およびコレクションにおいて、CHARおよびNCHAR型のデータに、US7ASCII、WE8DEC、WE8ISO8859P1およびUTF8以外の文字セットを使用する場合、CLASSPATHにorai18n.jarおよびorai18n-mapping.jarを含める必要があります。

orai18n.jarおよびorai18n-mapping.jarは、WL_HOME\server\ext\jdbc\oracle\11gフォルダのWebLogic Serverインストールに含まれています。これらのファイルは、weblogic.jar manifestマニフェスト・ファイルからは参照されないため、使用前にCLASSPATHに追加する必要があります。

デバッグ・モードでのOracle Thinドライバの使用方法

WL_HOME\server\ext\jdbc\oracle\11gフォルダには、ojdbc6_g.jarファイル(JDK 6の場合)とojdbc5_g.jarファイル(JDK 5の場合)があります。これらは、デバッグおよび追跡をサポートするクラスを備えたOracle Thinドライバのバージョンです。Oracle Thinドライバをデバッグ・モードで使用するには、CLASSPATHの先頭に、これらのファイルへのパスを追加します。

SSL経由のOracle Thinドライバの使用

この項では、SSL経由でOracle Thinドライバを使用する場合に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 Server 10.3.6で稼働中のサーバー、およびコンテナ内にデプロイされたアプリケーションで生成される診断データを作成、収集、分析、アーカイブする方法、およびそのデータにアクセスする方法について説明します。

このデータにより、サーバーおよびアプリケーションの実行時のパフォーマンスに関する指標が提供され、障害発生時に失敗を隔離して診断することができます。WebLogic JDBCは、このサービスを利用して、実行時の統計、ある一定の期間に渡ってのプロファイル情報、ロギングおよびデバッグの機能を拡張し、WebLogicドメインが円滑に実行され続けるよう支援します。

実行時の統計を使用すると、WebLogicドメインのデータ・ソースをモニターして、問題があるかどうか確認できます。問題がある場合、プロファイリングを使用して、問題の原因となっているアプリケーションを特定できます。アプリケーションを絞り込んだ後、JDBCデバッグ機能を使用して、そのアプリケーション内の問題点を突き止めることができます。

この章には次の項が含まれます:

- 実行時統計の表示

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

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

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

実行時統計の表示

実行時の統計を表示すると、WebLogicドメイン内のデータ・ソースをモニターできます。

データ・ソースの統計

データ・ソースの実行時の統計は、管理コンソールまたはJBCDataSourceRuntimeMBeanを使用して表示できます。JDBCDataSourceRuntimeMBeanは、データ・ソースの現在の状態を取得するためのメソッド、およびアクティブな接続の平均数、アクティブな接続の現在の数、アクティブな接続の最大数など、データ・ソースに関する統計を取得するためのメソッドを提供しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プリコンパイルされた文のキャッシュの統計

プリコンパイルされた文のキャッシュの実行時統計は、管理コンソールまたはJBCDataSourceRuntimeMBeanを使用して表示できます。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プロファイル・ロギング

WebLogic Server 10.3.6以前は、データ・ソース・プロファイル・レコードがWLDFイベントとして記録されました。操作性とパフォーマンスを向上させるため、WebLogic Serverではデータ・ソース・プロファイル・ログを使用してイベントが格納されます。プロファイル・ログには次の利点があります。

- ログ・ローテーション: 標準WebLogicロギング実装を使用して、古いデータを構成、ローテーションおよびリタイアできます。Oracle WebLogic Server MBeanリファレンスのDataSourceLogFileMBeanを参照してください。

- データ・アクセシビリティ: 一般的なテキスト・エディタ、WLDF Data Accessorまたは管理コンソールを使用できます。「診断データへのアクセス」を参照してください。

データ・ソース・プロファイリングのログの基本特性を次に示します。

- すべてのデータ・ソース・プロファイル・タイプに対して単一のログ・ファイルが使用されます。各プロファイル・レコードに、フィルタ処理のためのプロファイル・タイプ名があります。「プロファイル・タイプ」を参照してください。

- サーバー上のすべてのデータ・ソースに対して単一のログ・ファイルが使用されます。各プロファイル・レコードには、フィルタ処理のための修飾されたデータ・ソース名があります(該当する場合、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)

- 接続アンラップ(WEBLOGIC.JDBC.CONN.UNWRAP)

- プロファイル情報レコード・ログの例

接続の使用率(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)

マルチスレッド接続使用状況のプロファイリングを有効にすると、異なるスレッドにより以前に取得された接続を不正に使用しているスレッドについて情報が収集されます。アプリケーションが問題を報告し、その問題の原因が、複数のスレッドが1つの接続を同時に使用していることと考えられる場合、この情報が役立ちます。レコードには、次の情報が格納されます。

- 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.JDBC.CONN.UNWRAP)

文使用状況のプロファイリングを有効にすると、getVendorObject WebLogic拡張APIまたはJDBC 4.0のunwrapメソッドを使用して基になるJDBC接続にアクセスするアプリケーション・コンポーネントについてプロファイル情報が収集されます。レコードには、次の情報が格納されます。

- PoolName: この接続が属するデータ・ソースの名前

- ID: オブジェクトがアンラップされた場所のスタック・トレース

- User: オブジェクトをアンラップしているスレッドのスタック・トレース

- Timestamp: オブジェクトがいつアンラップされたか示すタイム・スタンプ

プロファイル情報レコード・ログの例

標準的な出力ログからの文使用状況(PROFILE_TYPE_STMT_USAGE_STR)のプロファイル情報レコードの例を、次に示します。

####<JDBC Data Source-0> <WEBLOGIC.JDBC.STMT.USAGE> <0> <java.lang.Exception
at
.
.
.
weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run( ContainerSupportProviderImpl.java:254)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
> <select 1 from dual>

プロファイル・ログの各コンポーネントは、カッコ(<および>)で囲まれています。

- プール名: JDBC Data Source-0

- プロファイル・タイプ: WEBLOGIC.JDBC.STMT.USAGE

- タイムスタンプ: 0 (ミリ秒)

- ユーザー: java.lang.Exception at . . . at weblogic.work.ExecuteThread.run(ExecuteThread.java:254

- ID: select 1 from dual

診断データへのアクセス

次の方法のいずれかを使用して、診断データにアクセスできます。

- WebLogic管理コンソール。次の項を参照してください。

- Oracle WebLogic Server管理コンソール・ヘルプのログの表示および構成に関する項

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

- WebLogic診断フレームワーク(WLDF)のData Accessorコンポーネント。『Oracle WebLogic Server診断フレームワークの構成と使用』のData Accessorによる診断データへのアクセスに関する項。

- テキスト・エディタを使用して情報を手動で表示。

- データ・ソースのプロファイリングを実行する場合、デフォルトの収集時間は300秒であるため、データをただちに表示できない場合があります。結果をより適切に視覚化するために、収集時間を小さい値(たとえば、5秒)に設定する必要がある場合があります。

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

注意:
この機能は、WebLogic Server 10.3.6.0では非推奨であり、今後のリリースでは削除される可能性があります。

WebLogic Serverは、JDBCドライバでコールされるメソッドのコールバックを提供しています。これらのコールバックを使用して、実行中のメソッド、スローされた例外、ドライバ・メソッドの実行に使用された時間など、JDBCドライバの使用状況をモニターおよびプロファイリングできます。

コールバック機能を有効にするには、JDBCデータ・ソース記述子(モジュール)内のdriver-interceptor要素のためのコールバック・ハンドラの完全修飾パスを指定します。コールバック・ハンドラには、weblogic.jdbc.extensions.DriverInterceptorインタフェースが実装されている必要があります。JDBCドライバのコールバックを有効にすると、JDBCドライバ内のメソッドが呼び出される前、および呼び出された後に、WebLogic Serverにより、登録されているコールバック・ハンドラの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プログラムには、次のコードが含まれています。

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): リプレイ・デバッグを追跡します。

- 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);

リクエストのDye処理

デバッグのもう1つのオプションは、JDBCサブシステムを通じて個々の(通常、dye処理された)アプリケーション・リクエストのフローを追跡することです。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のDyeInjectionモニターによるDye Vectorの構成に関する項を参照してください。

14 WebLogic JDBCリソースの管理

この章では、管理コンソール、コマンドライン、JMXプログラムまたはWebLogic Scripting Tool (WLST)スクリプトを使用して、WebLogic Server 10.3.6ドメイン内の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ネットワーク障害などの障害が管理されます。割り当てられた期間がすぎると、サーバー・インスタンスはプールをパージおよび無効化(すべての接続をクローズして追加の予約をブロック)し、再接続するとすぐにプールを再有効化します。

DBMSがクライアントへの応答を一時的に停止し、既存の接続でサービスを再開する可能性がある場合、10秒という値により、ピーク時の負荷を許容する適切な時間が提供されます。ただし、待機時間が長すぎる場合、または短すぎる場合、サーバーを起動するために使用されるstartWebLogicスクリプトに、環境に合わせた値を含むフラグを追加します。時間の値をゼロ(0)秒に設定すると、サーバーは無限に待機します。

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

この付録では、WebLogic Server 10.3.6でのエンタープライズ・アプリケーションのパッケージ化およびスコープ設定の方法について説明します。

エンタープライズ・アプリケーションをパッケージ化する際、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モジュールの作成

XMLディスクリプタ・ファイルの作成をサポートする任意の開発ツールを使用して、JDBCアプリケーション・モジュールを作成できます。次に、weblogic.DeployerユーティリティなどのJSR 88ベース・ツール、または管理コンソールを使用して、JDBCモジュールをデプロイし、管理します。

注意:
管理コンソールを使用してJDBCデータ・ソースを作成し、その後で、アプリケーションで使用するためにモジュールをテンプレートとしてコピーできます。ネームスペースでのネーミング競合を避けるために、モジュールのname要素およびjndi-name要素を変更してからアプリケーションでデプロイする必要があります。

各JDBCモジュールは、データ・ソースまたはマルチ・データ・ソースを表します。データ・ソースを表すモジュールには、データ・ソースのすべての構成パラメータが含まれます。マルチ・データ・ソースを表すモジュールには、マルチ・データ・ソースで使用するデータ・ソース・モジュールのリストも含め、マルチ・データ・ソース用の構成パラメータが含まれています。

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

アプリケーション・モジュールとして再使用できるデータ・ソース・モジュールを管理コンソールで作成する手順は次のとおりです。

1. 「JDBCデータ・ソースの作成」で説明するように、データ・ソースを作成します。データ・ソース・モジュールは、ドメイン・ディレクトリのconfig/jdbcサブディレクトリに作成されます。

2. data-source-name.xmlファイルをアプリケーション内のサブディレクトリにコピーし、接尾辞として-jdbcが含まれるようにコピーの名前を変更します(例: new-data-source-name-jdbc.xml)。

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およびトランザクション・プロトコルの設定が同じである必要があります。

その他のすべての構成パラメータはオプションであるか、値が指定されない場合に使用されるデフォルト値が設定されています。ただし、実用的な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 - 接続プールの構成のエントリが含まれています。接続テスト・オプション、文キャッシュ・オプションなどがあります。この要素は、weblogic-javaee.xsdスキーマからconnection-pool-paramsを継承します。これには、initial-capacity、max-capacity、およびプールされたリソースに共通のその他のオプションも含まれます。詳細は、次を参照してください。

- 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 - XAデータベース接続処理オプションに関するエントリ(keep-xa-conn-till-tx-complete、xa-transaction-timeoutなど)が含まれます。各要素の説明は、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のencryptユーティリティを使用してパスワードを処理します。このユーティリティによって暗号化されたパスワードが返され、それをpassword-encrypted要素としてJDBCモジュールに含めます。WebLogic Serverのencryptユーティリティの使用法の詳細は、『WebLogic Scripting Toolコマンド・リファレンス』のencryptに関する項を参照してください。

JDBCモジュールの新規ドメインへのデプロイ

JDBCモジュールをドメイン間で移動することは、アプリケーションを開発環境から本番環境に移動する場合などのように、一般的に使われる方法です。ただし、WebLogic Serverのencryptユーティリティにより生成された暗号化キーは、新しいドメインに転送できません。暗号化されたデータベース・パスワードを持つ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モジュールとディスクリプタの関係

weblogic-application.xml内のパッケージ化されたJDBCモジュール参照

エンタープライズ・アプリケーションにJDBCモジュールを含める際、各JDBCモジュールを、アプリケーションでパッケージ化されたweblogic-application.xmlディスクリプタ・ファイル内のタイプ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など)で、各resource-ref-name参照をデータ・ソースのjndi-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 12cデータベースのWebLogic Server 10.3.6サポート

この付録では、WebLogic Server 10.3.6を構成してOracle 12cデータベースで実行する方法について説明します。

この付録の構成は、次のとおりです。

- WebLogic Server 10.3.6でのOracle 12cデータベースの使用

- JDK 7に対するJDBC 4.1サポート

- アプリケーション・コンティニュイティの使用

- Global Database Services

- プラガブル・データベースを使用するコンテナ・データベース

- 自動ONSリスナー・サポート

- データベース常駐接続プーリングのサポート

WebLogic Server 10.3.6でのOracle 12cデータベースの使用

次の各項では、WebLogic Server 10.3.6でOracle 12cデータベースを準備および使用する方法について説明します。

- Oracle 12cデータベースでの11gドライバの使用

- Oracle 12cデータベースでの12cドライバの使用

Oracle 12cデータベースでの11gドライバの使用

12cデータベースでのWebLogic Server 10.3.6の最も簡単な統合は、WebLogic Server10.3.6配布キットに含まれている11g (特に11.2.0.3)ドライバjarファイルを使用することです。12cデータベースで11gドライバを使用する場合、既知の問題またはアップグレードの問題はありません。以下の点に注意する必要があります。

- 新しいクライアントjarファイルまたはWebLogic Serverの変更なしでプラガブル・データベース(PDB)機能を使用できます。ただし、クライアントからコンテナを動的に変更するALTER SESSION SET CONTAINER機能は使用できません。

- アプリケーション・コンティニュイティはサポートされません。

- データベース常駐接続プール(DRCP)およびONS自動構成はサポートされていません。

- Active GridLinkデータ・ソースを使用して、グローバル・データベース・サービス(GDS)を使用できます。

- JDBC 4.1メソッドはサポートされていません。

Oracle 12cデータベースでの12cドライバの使用

次の各項では、WebLogic Server 10.3.6およびOracle 12cデータベースで実行するために12cドライバを準備および使用する方法について説明します。

- 必要なOracle 12cドライバ・ファイル

- Oracle 12cデータベース・ファイルのダウンロード

- WebLogic Server CLASSPATHの更新

- その他の考慮事項

必要なOracle 12cドライバ・ファイル

この項では、WebLogic Server 10.3.6でOracle 12cドライバを使用するのに必要なファイルをリストします。これらのファイルは、12cデータベース$ORACLE_HOMEディレクトリの下にインストールされます。クライアント・パッケージまたはデータベース・パッケージをインストールする必要があります。

注意:
CLASSPATHの先頭でWebLogic Serverを実行するために使用されるCLASSPATHにこれらのjarファイルを追加する必要があります。すべての11gクライアントjarファイルの前に来る必要があります。

次のojdbcファイルの1つを選択します。

- jdbc/lib/ojdbc7.jar

- jdbc/lib/ojdbc7_g.jar

- jdbc/lib/ojdbc7dms.jar

- jdbc/lib/ojdbc6.jar

- jdbc/lib/ojdbc6_g.jar

- jdbc/lib/ojdbc6dms.jar

次の表に、追加の必須ドライバ・ファイルをリストします。

表B-1 追加の12cドライバ・ファイル

ファイル

説明

ucp/lib/ucp.jar

ユニバーサル接続プール

opmn/lib/ons.jar

Oracle Network Serverクライアント

jlib/orai18n.jar

I18Nサポート

jlib/orai18n-mapping.jar

I18Nサポート

jlib/oraclepki.jar

Oracleウォレット・サポート

jlib/osdt_cert.jar

Oracleウォレット・サポート

jlib/osdt_core.jar

Oracleウォレット・サポート

次の表に、SQL XMLサポートの追加ファイルをリストします。

表B-2 SQL XMLサポートの追加ファイル

ファイル

説明

rdbms/jlib/xdb.jarucp/lib/ucp.jar

SQLXMLサポート

lib/xmlparserv2_sans_jaxp_services.jar

SQLXMLサポート

jlib/orai18n-collation.jar

SQLXMLサポート

Oracle 12cデータベース・ファイルのダウンロード

12c Oracleデータベースのjarファイルは、本バージョンのWebLogic Serverには同梱されていません。最小インストール用のクライアント・キットのカスタム・インストールを実行することをお薦めします。http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.htmlを参照してください。

Oracle Database 12cリリース1で、使用しているOSプラットフォームのすべて表示リンクを選択します。最小インストールの場合、Oracle Database 12cリリース1クライアントの見出しで、適切なzipファイルを選択してダウンロードします。ファイルを解凍し、インストーラを実行します。「カスタム」を選択し、Oracle JDBC/Thinインタフェース、Oracle Netリスナー、Oracle Advancedセキュリティ・チェック・ボックスの順に選択します。

WebLogic Server CLASSPATHの更新

Oracle 12cデータベースとOracle 12c JDBCドライバを使用するには、WebLogic Server環境のCLASSPATHを更新する必要があります。「必要なOracle 12cドライバ・ファイル」で指定した必須ファイルをCLASSPATH (11.2.0.3ドライバのjarファイルの前)に追加します。

次のコード・サンプルに、WebLogic環境のCLASSPATHを更新する単純なシェル・スクリプトの概要を示します。ORACLE_HOMEが適切に設定されていることを確認します。この例では、SEP変数がプラットフォームに適切なCLASSPATHセパレータ(";"または":")に設定されていることを前提としています。

#!/bin/sh

# source this file in to add the new 12c jar files at the beginning of the
# CLASSPATH

case "`uname`" in
*CYGWIN*)
SEP=";"
;;
Windows_NT)
SEP=";"
;;
*)
SEP=":"
;;
esac
# For external, just use ORACLE_HOME;
dir=${ORACLE_HOME:?}

# We need one of the following
#jdbc/lib/ojdbc7.jar
#jdbc/lib/ojdbc7_g.jar
#jdbc/lib/ojdbc7dms.jar
#jdbc/lib/ojdbc6.jar
#jdbc/lib/ojdbc6_g.jar
#jdbc/lib/ojdbc6dms.jar
if [ "$1" = "" ]
then
ojdbc=ojdbc7.jar
else
ojdbc="$1"
fi
case "$ojdbc" in
ojdbc7.jar|ojdbc7_g.jar|ojdbc7dms.jar|ojdbc6.jar|ojdbc6_g.jar|ojdbc6dms.jar)
ojdbc=jdbc/lib/$ojdbc
;;
*)
echo "Invalid argument - must be ojdbc7.jar|ojdbc7_g.jar|ojdbc7dms.jar|ojdbc6.jar|ojdbc6_g.jar|ojdbc6dms.jar"
exit 1
;;
esac
CLASSPATH="${dir}/${ojdbc}${SEP}$CLASSPATH"
CLASSPATH="${dir}/ucp/lib/ucp.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/opmn/lib/ons.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/orai18n.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/orai18n-mapping.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/oraclepki.jar ${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/osdt_cert.jar ${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/osdt_core.jar${SEP}$CLASSPATH"
# SQL XML support
CLASSPATH="${dir}/lib/xmlparserv2_sans_jaxp_services.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/jlib/orai18n-collation.jar${SEP}$CLASSPATH"
CLASSPATH="${dir}/rdbms/jlib/xdb.jar${SEP}$CLASSPATH"

たとえば、setdb12c_jars.shという名前を使用して環境内でこのスクリプトを保存します。次に、ojdbc6dms.jarを使用してスクリプトを実行します。

.  ./setdb12c_jars.sh ojdbc6dms.jar

留意事項

この項では、Oracle 12cデータベースでWebLogic Server 10.3.6を使用する方法の追加情報について説明します。

- WebLogic Server 10.3.6は、12cデータベース配布キットのaqapi.jarファイルの使用をサポートしておらず、12cデータベースでのAQ JMSの使用をサポートしていません。

- Active GridLinkデータ・ソースによる12cクライアントjarファイルおよび12cデータベースの両方を使用する場合、WebLogic Server 10.3.6はアプリケーション・コンティニュイティをサポートします。「アプリケーション・コンティニュイティの使用」を参照してください。

- 11gデータベースでの12cクライアントjarファイルの実行がサポートされています。

- Active GridLinkで実行している場合、12cクライアントjarファイルで実行するときに-Doracle.ucp.PreWLS1212Compatible=trueシステム・プロパティをサーバー・コマンドラインに追加する必要があります。

- 12cクライアントjarには、JDBC仕様に準拠するためのローカル・トランザクション処理のいくつかの変更が含まれています。setAutoCommit(true)がコールされ、ローカル・トランザクションが存在する場合、トランザクションが自動的にコミットされます(以前のリリースでは、アクションが実行されません)。setAutoCommit(true)が設定され、コミットがコールされる場合、例外がスローされます(以前のリリースでは、アクションが実行されません)。既存のアプリケーションでこれらの状況が発生し、ソフトウェアをすぐに変更できない可能性があります。レガシー動作の既存のアプリケーションを保持するため、-Doracle.jdbc.autoCommitSpecCompliant=falseシステム・プロパティをサーバー・コマンドラインに追加します。

- ojdbc7*.jarファイルで実行する場合、JDBC 4.1メソッドがサポートされます

JDK 7に対するJDBC 4.1サポート

このリリースのWebLogic Serverでは、環境でJDK 7が使用されており、JDBCドライバがJDBC 4.1準拠である場合に、JDBC 4.1仕様がサポートされます。新しいJDBC 4.1のメソッドをOracleシン・クライアントで使用する場合は、ojdbc7.jarを使用する必要があります。JDBC 4.1をサポートしていないドライバの場合は、このメソッドが呼び出されると、java.lang.AbstractMethodErrorがスローされます。http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-spec/index.htmlで「JDBC(tm) 4.1仕様」を参照してください。

注意:
Java SE 7のgetParrentLoggerメソッドの使用に必要なjava.sql.driverインタフェースは、現時点ではサポートされていません。http://docs.oracle.com/javase/7/docs/api/index.html?java/sql/Driver.htmlを参照してください。

JDK 7では、http://jcp.org/aboutJava/communityprocess/maintenance/jsr114/114MR2approved.pdfで定義されたRowset 1.1の軽度の変更もサポートしています。新規RowSetFactoryのWebLogic Serverへの実装をweblogic.jdbc.rowset.JdbcRowSetFactoryといいます。

アプリケーション・コンティニュイティの使用

現在の環境では、基盤になるソフトウェア・レイヤー、ハードウェア・レイヤー、通信レイヤーおよび記憶域レイヤーの停止について、アプリケーション開発者が明確に対処する必要があります。そのため、アプリケーション開発は複雑化し、機能停止はユーザーに対して表面化します。たとえば、ユーザーに対して送信ボタンを2回クリックしないように警告するアプリケーションがあります。その警告を無視したユーザーは、意図しないうちに商品を2回購入したり、同じ請求書に対して複数回の支払を実行してしまうことがあります。

アプリケーション・コンティニュイティ(リプレイとも呼ばれる)は、Active GridLinkデータ・ソースに対応するアプリケーションに依存しない汎用のインフラストラクチャであり、アプリケーション側からの作業の回復を可能にし、多くのシステム障害、通信障害およびハードウェア障害をマスクします。つまり、エンド・ユーザーのトランザクションは、時差なしに1回で実行されるようになります。エンド・ユーザーがサービスの中断を認識するとしても、継続しても意味のない機能停止の場合に限られます。

次に示す各項では、アプリケーション・コンティニュイティの構成方法と使用方法について説明します。

- アプリケーション・コンティニュイティの機能

- 要件および考慮事項

- アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティの機能

計画済停止か計画外停止かにかかわらず、次に示すデータベース・サービスの損失による停止については、アプリケーション・コンティニュイティによりデータベース・セッションが再構築されます。高速アプリケーション通知またはリカバリ可能なORACLEエラーで停止が識別されると、Oracleドライバは次のように動作します。

- 新しいデータベース・セッションを確立して、未処理の状態を解消します。

- コールバックが登録されている場合は、コールバックを発行して、そのセッションの初期状態をアプリケーションが再確立できるようにします。

- リクエスト中に累積した保存済の履歴を実行します。

Oracleドライバは、リプレイ・コールのタイミングを判断します。コールは、アプリケーションがデータベースの状態を変更する方法に応じて経時的に処理されるか、遅延処理の実装を使用して処理されます。リプレイは、Oracle 12c Database Serverで制御されます。リプレイが承認されるようにするには、リプレイされるコールごとに、元のコールの実行中にアプリケーションで表示されていて潜在的に使用されていたクライアントの表示状態とまったく同じ状態を返す必要があります。

要件および考慮事項

次の項では、WebLogicアプリケーションでアプリケーション・コンティニュイティを使用する際の要件と考慮事項について説明します。

- Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースでの12cドライバの使用」を参照してください。

- このリリースのアプリケーション・コンティニュイティは、読取りおよび書込みトランザクションのみサポートします。XAトランザクションは、サポートされていません。「アプリケーション・コンティニュイティ対応ドライバの選択」を参照してください。

注意:
autocommit=FALSEを設定していることを確認して、トランザクション・セマンティクスが分断化と、環境でのアプリケーション・コンティニュイティの無効化を防止してください。

- 非推奨のoracle.sql.*具体クラスはサポートされていません。該当部分は、それに対応するoracle.jdbc.*インタフェースまたはjava.sql.*インタフェースのどちらかを使用するように変更する必要があります。標準のjava.sql.*インタフェースの使用をお薦めします。

- アプリケーション・コンティニュイティは、中間結果をメモリーに格納することで動作します。アプリケーションは、この機能なしで実行するよりも実行速度が遅くなり、より大量のメモリーが必要になります。

- WebLogicの文キャッシュの使用はサポートされていません。WebLogicの文キャッシュが構成されている場合は、そのキャッシュは接続がクローズされるたびにクリアされます。

- アプリケーション・コンティニュイティ機能には、追加の制限事項と例外事項があります。これらは、アプリケーションがリプレイを使用できるかどうかに影響することがあります。詳細は、Oracle® Database JDBC開発者ガイドのJavaのアプリケーション・コンティニュイティに関する項を参照してください。

- データソースのURLで指定されるデータベース・サービスは、フェイルオーバー・タイプにTRANSACTIONを設定し、-commit_outcomeパラメータにTRUEを設定して構成する必要があります。次に例を示します。
srvctl modify service -d mydb -s myservice -e TRANSACTION -commit_outcome TRUE -rlbgoal SERVICE_TIME -clbgoal SHORT

アプリケーション・コンティニュイティの構成

次の各項では、環境内にアプリケーション・コンティニュイティを実装する方法について説明します。

- アプリケーション・コンティニュイティ対応ドライバの選択

- 接続コールバックの使用方法

- 特定の接続に対するアプリケーション・コンティニュイティの無効化

- アプリケーション・コンティニュイティのロギングの構成

アプリケーション・コンティニュイティ対応ドライバの選択

管理コンソールは、リプレイ・ドライバのエントリがありません。JDBCリプレイ・データ・ソースを構成するには、既存のOracleデータ・ソース・クラスをリプレイ・データ・ソース・クラスoracle.jdbc.replay.OracleDataSourceImplに手動で置き換える必要があります。

WebLogic Server管理コンソールを使用する場合:

1. WebLogic Server管理ホーム・ページから、「GridLink for RACデータ・ソースの構成」を選択します。

2. 「新規」をクリックして、「GridLinkデータ・ソース」を選択します。

3. 「データベース・ドライバ」で、OracleのGridLink Connections用ドライバ(Thin)バージョン: 11以上を選択します。

4. サーバーをターゲット指定せずにデータ・ソースの作成を終了します。

5. 新しいデータ・ソースを選択および編集します。

6. 「構成」→「接続プール」タブから、「ドライバ・クラス名」属性の値をoracle.jdbc.replay.OracleDataSourceImplに置き換えます。

7. 「保存」をクリックします。

8. 「ターゲット」タブを選択します。

9. ターゲット・サーバーを選択します。

10. 「保存」をクリックします。

「データベースのタイプ」が「Oracle」であることを確認します。「要件および考慮事項」を参照してください。

接続コールバックの使用方法

次の各項では、接続コールバックの使用方法について説明します。

- 初期化コールバックの作成

- 初期化コールバックの登録

- 初期化コールバックの登録解除

初期化コールバックの作成

接続初期化コールバックを作成する場合は、アプリケーションにoracle.ucp.jdbc.ConnectionInitializationCallbackインタフェースのinitialize(java.sql.Connection connection)メソッドを実装する必要があります。コールバックは、接続プールごとに1つのみ作成できます。

ラベリング・コールバックが接続プールに登録されていると、コールバックは無視されます。それ以外の場合、コールバックはプールから接続がチェックアウトされるたびに実行されます。また、リカバリ可能なエラーに続くリプレイ時に再接続が成功するたびに実行されます。実行時とリプレイ時に同じコールバックを使用することで、リプレイ時には、元のセッションが確立されたときに使用されたものと完全に同じ初期化が使用されるようになります。コールバックの呼出しが失敗すると、その接続についてのリプレイは無効になります。

注意:
接続初期化コールバックは、クライアント(JDBC over RMI)ではサポートされません。

次の例では、単純な初期化コールバックの実装を示します。

. . .
import oracle.ucp.jdbc.ConnectionInitializationCallback ;
. . .
class MyConnectionInitializationCallback implements ConnectionInitializationCallback {
public MyConnectionInitializationCallback()  {
}
public void initialize(java.sql.Connection connection)  throws SQLException {
// Re-set the state for the connection, if necessary
}
}

初期化コールバックの登録

WLDataSourceインタフェースには、初期化コールバックを登録するためのregisterConnectionInitializationCallback(ConnectionInitializationCallback callback)メソッドが用意されています。1つの接続プールに登録できるコールバックは1つのみです。次の例は、MyConnectionInitializationCallbackクラスに実装されている初期化コールバックの登録方法を示しています。

. . .
import weblogic.jdbc.extensions.WLDataSource;
. . .
MyConnectionInitializationCallback callback = new MyConnectionInitializationCallback();
((WLDataSource)ds).registerConnectionInitializationCallback(callback);
. . .

また、コールバックは、管理コンソールからデータ・ソースの「Oracle」タブで、「接続初期化コールバック」属性にコールバック・クラスを入力することでも登録できます。

初期化コールバックの登録解除

WLDataSourceインタフェースには、ConnectionInitializationCallbackの登録を解除するためのunregisterConnectionInitializationCallback()メソッドが用意されています。次の例は、初期化コールバックの削除方法を示しています。

. . .
import weblogic.jdbc.extensions.WLDataSource;
((WLDataSource)ds).unregisterConnectionInitializationCallback();
. . .

特定の接続に対するアプリケーション・コンティニュイティの無効化

アプリケーション・コンティニュイティは、次のコードを使用することで、接続単位で無効化できます。

. . .
if (connection instanceof oracle.jdbc.replay.ReplayableConnection) {
((oracle.jdbc.replay.ReplayableConnection)connection).disableReplay();
}
. . .

アプリケーション・コンティニュイティのロギングの構成

アプリケーション・コンティニュイティ処理のロギングを有効化するには、次のWebLogicプロパティを使用します。

-Dweblogic.debug.DebugJDBCReplay=true

-Djava.util.logging.config.file=configfileを使用して、ログ出力のフォーマットとロギング・レベルを制御します(configfileは、標準JDKのロギングで使用される構成ファイル・プロパティのパスとファイル名です)。次に、SimplFormatterを使用する構成ファイルの例を示します。この例では、ロギング・レベルをFINESTに設定しています。

handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
#OR - use other formatters like the ones below
#java.util.logging.ConsoleHandler.formatter = java.util.logging.XMLFormatter
#java.util.logging.ConsoleHandler.formatter = oracle.ucp.util.logging.UCPFormatter

#OR - use FileHandler instead of ConsoleHandler
#handlers = java.util.logging.FileHandler
#java.util.logging.FileHandler.pattern = replay.log
#java.util.logging.FileHandler.limit = 3000000000
#java.util.logging.FileHandler.count = 1
#java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
oracle.jdbc.internal.replay.level attribute=FINEST

「Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用」を参照してください。

Global Database Services

Global Data Services (GDS)により、分散データベース環境でシームレスな集中管理を提供するグローバル・サービスが使用できるようになります。グローバル・サーバーは、複数のRACおよび単一インスタンスのOracleデータベースをData GuardやGoldenGateなどのレプリケーション技術で相互接続して、それら全体でのロード・バランシング、フォルト・トレランスおよびリソース使用率を自動化します。

次の各項では、WebLogic ServerのGDSに対する要件と構成について説明します。

- 要件および考慮事項

- GDS接続対応のGridLinkデータソースの作成

要件および考慮事項

次の項では、WebLogic ServerでGlobal Database Servicesを使用する際の要件と考慮事項について説明します。

- Oracle 12c JDBCドライバとデータベースは必須です。「WebLogic Server 10.3.6でのOracle 12cデータベースの使用」を参照してください。

- 単一のSCANアドレスを使用して、複数のGlobal Service Manger (GSM)アドレスを置換することはできません。

- 更新操作が適切に処理されるようにするには、プライマリ・データベースでのみ有効になる更新用のサービスを定義する必要があります。

- プライマリ・データベースとセカンダリ・データベースに配置される読取り専用操作のサービスは個別に定義してください。

- 1つのURLに定義できるサービスは1つに限られ、1つのデータソース構成に定義できるURLは1つになるため、一方のデータソースを更新サービス用に定義し、もう一方のデータソースを読取り専用サービス用に定義する必要があります。

- 更新操作が更新データソースで処理され、読取り専用操作が読取り専用データソースで処理されるように、アプリケーションを作成する必要があります。

GDS接続対応のGridLinkデータソースの作成

管理コンソールを使用して、GridLinkデータソースを作成します。このデータソースでは、GDS接続を提供するように変更したURLを使用します。Oracle WebLogic Server管理コンソール・ヘルプのJDBC GridLinkデータ・ソースの作成に関する項を参照してください。

GDS URLの接続情報は、RACクラスタの接続情報と類似しています。これには、次の基本情報が含まれています。

- サービス名(グローバル・サービス名)

- Global Service Managerのアドレス/ポートのペア

- CONNECT_DATAパラメータのGDSリージョン

次に、サンプルURLを示します。

jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=(LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS=(HOST=myHost1.com)(PORT=1111)(PROTOCOL=tcp))
(ADDRESS=(HOST=myHost2.com)(PORT=2222)(PROTOCOL=tcp)))
(CONNECT_DATA=(SERVICE_NAME=my.gds.cloud)(REGION=west)))

プラガブル・データベースを使用するコンテナ・データベース

コンテナ・データベース(CDB)はOracleデータベース機能の1つであり、多数のデータベースを、単一CDBに含まれる複数のプラガブル・データベース(PDB)を使用して単一データベースに統合することにより、多数のデータベースを持つ場合のオーバーヘッドを最小限に抑えます。『Oracle Database管理者ガイド』のOracleプラガブル・データベースの管理に関する項を参照してください。

- PDBアクセス対応サービスの作成

- JDBCを使用したPDBの設定

PDBアクセス対応サービスの作成

PDBへのアクセスは、WebLogic Serverデータ・ソースに対して完全に透過的になります。その他のデータベースと同様に、サービスを含むURLを使用してアクセスします。サービスは、PDBに関連付けられている必要があります。これは、SQLPlusで、セッションをPDBに関連付けて、サービスを作成し、そのサービスを開始することで作成できます。

alter session set container = cdb1_pdb1; -- configure service for each PDB
execute dbms_service.create_service('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com','replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com');
execute DBMS_SERVICE.START_SERVICE('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com');

アプリケーション・コンティニュイティと併用するようにサービスを設定するには、サービスを適切に構成する必要があります。次に、SQLPlusの例を示します。

declare
params dbms_service.svc_parameter_array ;
begin
params('goal') := 'service_time' ;
params('commit_outcome') := 'true' ;
params('aq_ha_notifications') := 'true' ;
params('failover_method') := 'BASIC' ;
params('failover_type') := 'TRANSACTION' ;
params('failover_retries') := 60 ;
params('failover_delay') := 2 ;
dbms_service.modify_service('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com', params);
end;
/

JDBCを使用したPDBの設定

初めてプールの接続を作成するときには、CDB内の特定のPDBに関連付けられたサービスを含むURLを使用して接続を作成します。

ALTER SESSION SET CONTAINERの実行は、WebLogic Server 10.3.6のJDBCからサポートされていません。

自動ONSリスナー・サポート

WebLogic Server 10.3.6では、自動ONSリスナーがサポートされていません。ONS構成情報をデータソース用にOracleパラメータで指定する必要があります。

データベース常駐接続プーリングのサポート

WebLogic Server 10.3.6では、データベース常駐接続プーリング(DRCP)はサポートされていません。

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

この付録では、WebLogic Server 10.3.6で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データ・ソースの使用をお薦めします。「Oracle RACでのWebLogic Serverの使用」を参照してください。

Oracle Real Application Clustersの概要

Oracle Real Application Clusters (Oracle RAC)は高可用性ソリューションに追加できるソフトウェア・コンポーネントであり、複数のマシンを使用しているユーザーは単一のデータベースにアクセス可能になり、さらにパフォーマンスの向上も実現できます。Oracle RACは、2台以上のクラスタ化マシンで実行しており、クラスタ・テクノロジを使用して共有ストレージ・デバイスにアクセスする2つ以上のOracleデータベース・インスタンスで構成されています。このアーキテクチャをサポートするために、これらのデータベース・インスタンスをホストするマシンが高速のインターコネクトによってリンクされてクラスタを構成します。インターコネクトは、クラスタのノード間の通信手段として使用される物理ネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサードパーティのクラスタリング・ソフトウェアが提供しています。図C-1は、Oracle RAC構成を示しています。

図C-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に追加されたノード数に応じて拡大します。これには複雑な構成が必要であり(n+1データ・ソースが必要です。この場合のnは汎用データ・ソース数にマルチ・データ・ソース1つを加えた値です)、Oracle RACトポロジが変更された場合は管理者操作が必要になります。

WebLogic Serverマルチ・データ・ソースによるOracle RACの可用性

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。「フェイルオーバー」および「マルチ・データ・ソースで管理されるフェイルオーバーおよびロード・バランシング」を参照してください。

WebLogic Serverマルチ・データ・ソースによるOracle RACロード・バランシング

マルチ・データ・ソースは、XA環境と非XA環境に対するロード・バランシングとして機能します。マルチ・データ・ソースを構成する汎用データ・ソースへのアクセスには、ラウンドロビン・スキームが使用されます。接続を切り替える際に、WebLogic Serverは、一覧表示されている順に次の汎用データ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソースの使用の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

ソフトウェア要件

Oracle RACによってWebLogic Serverを使用するには、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ドライバ11gを使用してデータベース接続を作成する必要があります。

ハードウェア要件

標準的なWebLogic Server/Oracle RACシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが組み込まれています。

WebLogic Serverクラスタ

WebLogic Serverクラスタの構成方法は多数あり、様々なハードウェア・オプションも使用できます。WebLogic Serverクラスタの構成の詳細は、Oracle WebLogic Serverのクラスタの使用に関する項を参照してください。

Oracle RACクラスタ

Oracle RACの最新のハードウェア要件については、Oracle RACドキュメントを参照してください。ただし、Oracle RACをWebLogic Serverで使用するには、Oracle RACインスタンスを強力な、本番品質のハードウェア上で実行する必要があります。Oracle RAC構成によって、合理的に予想されるアプリケーション・ロード要件に適したデータベース処理パフォーマンスが生成される必要があります。データベース応答に異常な遅延が生じると、データベース・フェイルオーバー・シナリオの際に予想外の動作が発生する可能性があります。

共有ストレージ

Oracle RAC構成では、すべてのデータ・ファイル、制御ファイル、パラメータ・ファイルは、すべてのOracle RACインスタンスで使用するために共有されます。次のいずれかのアーキテクチャを使用しているHAストレージ・ソリューションをお薦めします。

- 直接アタッチ・ストレージ(DAS): デュアル・ポート・ディスク・アレイまたはストレージ・エリア・ネットワーク(SAN)など

- ネットワーク接続ストレージ

サポートされるストレージ・ソリューションの詳細リストは、Oracleドキュメントを参照してください。

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

Oracle RACでマルチ・データ・ソースを使用する際、WebLogic DomainがOracle RACインスタンスと相互作用して、予想どおりに実行できるようにWebLogic Domainを構成する必要があります。次の各項では、構成オプションと要件について説明します。

- 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 Thinドライバを使用したOracle RACクラスタの各Oracle RACインスタンスのJDBCデータ・ソースを最初に構成します。次に、ロード・バランシング用アルゴリズムまたはフェイルオーバー用アルゴリズムを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。

図C-2に、標準的なマルチ・データ・ソース構成を示します。

図C-2 マルチ・データ・ソース構成

管理コンソール、またはドメインの構成に優先的に使用したいその他の手段、たとえばWebLogic Scripting Tool (WLST)またはJMXプログラムが使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、「JDBCマルチ・データ・ソースの構成」を参照してください。Oracle RACノード上で実行するサービスに接続するためにマルチ・データ・ソースにデータ・ソースを構成する方法については、「Oracle RACノード上のサービスへの接続の構成」を参照してください。

この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つ検索してから、接続をリクエストします。マルチ・データ・ソースによって、接続リクエストへの対応に使用するデータ・ソースが、構成で指定されたアルゴリズムのタイプ(フェイルオーバーまたはロード・バランシング)に基づいて決定されます。

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

マルチ・データ・ソースには、システム・ロード・バランシングまたはフェイルオーバーでのOracle RACのロールに応じて、次の属性を割り当てることができます。

- AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"
Load-Balancingオプションを指定した場合、接続リクエストは使用可能なデータ・ソースの間で配信されます。高可用性オプションを指定した場合、接続リクエストはリスト内で最初に使用可能なプールにより対応されます。データ・ソースが使用不能になると、接続リクエストはリストの次のデータ・ソースで処理されます。

- FailoverRequestIfBusy="true"
フェイルオーバー・アルゴリズムを使用している場合、この属性により、データ・ソース内のすべての接続が使用中のときにフェイルオーバーが有効になります。

- TestFrequencySeconds="120"
この属性は、接続が再作成可能かどうか、およびデータ・ソースが再有効化できるかどうかを判別するために、以前に異常とマークされたデータ・ソースのヘルスをWebLogic Serverがチェックする頻度を制御します。詳細は、「JDBCマルチ・データ・ソースの構成」を参照してください。

Oracle RACノードの高速フェイルオーバーを実現するには、この値をより小さい間隔、たとえば10 (秒)に設定します。

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

フェイルオーバーを構成する際は、次の情報を考慮してください。

マルチ・データ・ソースで管理されるフェイルオーバーおよびロード・バランシング

マルチ・データ・ソースは、グローバル・トランザクションに対してフェイルオーバー機能およびロード・バランシング機能を提供します。マルチ・データ・ソースのフェイルオーバー機能の説明は、「マルチ・データ・ソース・フェイルオーバー機能の拡張」を参照してください。

図C-2に示す構成により、次の機能を取得できます。

- マルチ・データ・ソースにより制御される高速フェイルオーバー

- WebLogic Serverヘルス・モニターによる自動フェイルバック

マルチ・データ・ソースは、Oracle RACノードが使用できなくなった場合にデータベース接続に対するフェイルオーバーを処理します。WebLogic Serverが接続をテストして接続が失敗した場合は、接続を再作成しようと試みます。この試みが失敗すると、サーバーはデータ・ソースを無効にして、接続リクエストをマルチ・データ・ソース内の他のデータ・ソース(他のOracle RACノードに対応するもの)にルーティングします。WebLogic Serverは、無効になったデータ・ソース内でデータベース接続の再作成を定期的に試行します。接続の再作成に成功すると、WebLogic Serverは次にデータ・ソースを再有効化して、そのデータ・ソースへの接続リクエストのルーティングを開始します。接続リクエストのルーティングと自動ヘルス・チェック機能により、失敗後の接続リクエストへの対応の遅延が最小限に抑えられます。

フェイルオーバー時の遅延

Oracle RACノードが別のOracle RACノードに対してフェイルオーバーを起こした際、失敗したノード上で進行中のトランザクション・ブランチに関連しているデータがクラスタ全体で使用可能になるまでに、遅延が生じる場合があります。このため、不完全なトランザクションが適切に完了することができず、データベースでさらにデータのロックが生じる可能性があります。このような遅延による潜在的影響を防ぐために、WebLogic Serverには、Oracle RACに対するXAコールの再試行を有効にする2つの構成属性、XARetryDurationSecondsおよびXARetryIntervalSecondsが用意されています。

コーディネータとして動作しているサーバーがサービスに戻る場合、リカバリ中に次のアクションが実行されます。

- トランザクション・マネージャはトランザクション・チェックポイントとリソース・チェックポイントをTLogから読み取ります。

- TLOG (トランザクション・チェックポイント)から読み取られたトランザクションはアクティブになり、その状態はコミットに設定されます。TMはこれらのトランザクションを他の実行時トランザクションと同じようにコミットしようとします。コミットが失敗すると、猶予期間が過ぎた後、AbandonTimeoutSecondsまで、コミットの再試行プロセスが実行されます。

- リソース上のTMコールxa.recoverはTLOG (リソース・チェックポイント)から読み取って、保留中のトランザクションのリストを取得します。xa.recoverコールが失敗すると、TMはXARetryDurationSecondsの期間、XARetryIntervalSecondsごとに、リソースでxa.recoverコールを再試行します。

次の式を使用して、XARetryDurationSecondsの値を決定します。

XARetryDurationSeconds = (汎用データ・ソースからの接続を使用するトランザクションの最長トランザクション・タイムアウト) + (すべてのOracle RACノード上でXIDが使用可能になるまでの遅延、通常は5分以下)

たとえば、アプリケーションで最長トランザクション・タイムアウトを180秒に設定している場合は、XARetryDurationSecondsを180秒+300秒、合計480秒に設定します。

注意:
通常は、すべてのトランザクションが適切に完了できるのに必要な最低値よりも少し高めにXARetryDurationSecondsを設定することをお薦めします。この値を必要最低値よりも高く設定しても、通常操作中のアプリケーションのパフォーマンスに特に影響しません。準備が済んでいても完了できなかったトランザクションでは、追加の処理が行われた場合のみ影響が生じます。

オプションとして、XARetryIntervalSecondsの値を設定することもできます。この値によって、XA再試行コールの間隔が決定します。デフォルトでは、この値は60秒です。値を低くすると、XA再試行の間隔も短くなります。ほとんどの場合、デフォルト値で十分です。

XAコールの再試行を有効にする方法

WebLogic Server管理コンソールからXARetryDurationSecondsおよびXARetryIntervalSecondsを有効にするには、次の手順を実行します。

1. WebLogic Server管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックしていない場合は、クリックします。

2. 「ドメイン構造」ツリーで「サービス」→「JDBC」を展開し、「データ・ソース」を選択します。

3. 「データ・ソースのサマリー」ページで、データ・ソース名をクリックします。

4. 「構成: 接続プール」タブを選択します。

5. 画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。

6. 「XA再試行期間」および「XA再試行間隔」を更新します。

7. 「保存」をクリックします。

オプションとして、WebLogic Scripting Tool (WLST)またはJMXプログラムを使用できます。

グローバル・トランザクションに対する失敗処理の手順

そのノードが失敗すると、そのデータベース・ノードに対する処理中のトランザクションはどうなるか?プライマリOracle RACノードはいつ失敗するのか?WebLogic Serverは、透過的フェイルオーバーをサポートしているか?WebLogic Serverの失敗処理に関するこれらの質問や、その他の質問に答えるために、トランザクションの処理手順を1つずつ実行し、それぞれのステージで失敗がどのように処理されるかを説明します。

失敗が起こる可能性のある最初のステージは、アプリケーションがコミット対象のトランザクションをコールする前です。このステージでデータベースまたはOracle RACノードが失敗した場合、アプリケーションは例外を受け取るため、新規接続を取得し、トランザクション処理時に新しく試行する必要があります。WebLogic Serverでは、透過的フェイルオーバーをサポートしていません。

アプリケーションがコミット対象のトランザクションをコールした後で失敗が発生した場合、処理中のトランザクションの処理方法は、PREPARE操作が完了したかどうかによって異なります。PREPARE操作が完了していない場合は、トランザクション・マネージャがそのトランザクションをロールバックして、失敗したトランザクションに関する例外がアプリケーションに送信されます。PREPARE操作が完了している場合、トランザクション・マネージャは別のノードを使用して処理中のトランザクションを完了させようとします。

COMMIT操作中に失敗が発生した場合、トランザクション・マネージャはCOMMIT操作の再試行を数回試みます。この試行中、接続はブロックされることに注意してください。最初の再試行セットの間にCOMMIT操作が成功しなかった場合、アプリケーションは例外を受け取ります。その後、トランザクション・マネージャは成功するまでCOMMIT操作の再試行を定期的に続行します。トランザクションが中止期間内に正常に終了できなかった場合、トランザクションはヒューリスティックに完了させられます。

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

Oracle RACでは、リスナー・プロセスによってユーザー・プロセスとOracleインスタンスとの間に通信経路が設定されます。Oracle RACをWebLogic Serverで使用する場合、ユーザー・プロセスは通常はJDBCデータ・ソースです。

マルチ・データ・ソースが作成されると、アプリケーションで流用できるようにデータベース接続プールの作成が試みられます。プールされたデータベース接続が操作不能になったり、データ・ソースが容量が増加するように構成されている場合、データ・ソースは、構成ファイルで指定された最大値まで追加のデータベース接続を作成しようと試みます。これらのすべてのインスタンスで、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。

図C-3は、Oracleリスナー・プロセスの機能を示しています。

図C-3 Oracleリスナー・プロセスの機能

この機能を有効にするには、次の2つのオプションが使用できます。

- ローカル・リスナーの使用。Oracleクラスタ内のOracle RACインスタンスごとにリスナー・プロセスを構成します。WLSでは、Oracle RACインスタンスごとにローカル・リスナーを構成する必要があります。各データベース・インスタンスは、そのローカル・リスナーのみに登録されるように構成します。
Oracleインスタンスは、listener.oraファイル内で静的にリスナーに登録されるか、インスタンス初期化パラメータlocal_listenerを使用して動的に登録されるか、またはその両方で登録されるように構成できます。動的登録の使用をお薦めします。

リスナーは、共有ディスパッチャ・プロセスまたは専用プロセスのいずれかを開始できます。WebLogic Serverで使用する場合は、専用プロセスの使用をお薦めします。

- リモート・リスナーの使用。WLSでは、マルチ・データ・ソース内のデータ・ソースのJDBC URLに、SERVICE_NAMEおよびINSTANCE_NAMEの両方を指定する必要があります。「リモート・リスナー有効時または無効時のマルチ・データ・ソースの構成」を参照してください。

リモート・リスナー有効時または無効時のマルチ・データ・ソースの構成

サーバー側のロード・バランシング機能が(remote_listenersを使用して)Oracle RACバックエンドで有効になっている場合、マルチ・データ・ソース構成のデータ・ソースで使用される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.myco.com)(INSTANCE_NAME=orcl1)))

次のコード・スニペットは、データ・ソース構成の一例です。

<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.us.myco.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.myco.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 JDBC Thinドライバ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 JDBC Thinドライバ11g。次に例を示します。

<url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url>
<driver-name>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つずつ作成します。

「サービスに接続するようにデータ・ソースを構成」では、これらのデータ・ソースの構成で特に考慮すべき点を説明しています。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理のいずれかの構成例を示しています。

サービスに接続するようにデータ・ソースを構成

任意のデータ・ソースを構成する場合と同じ方法で(WLST、管理コンソール、または構成ウィザードを使用)、Oracle RACノード上で稼働中のサービスに接続するようにデータ・ソースを構成します。ただし、次の例外があります。

- 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)))"

管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストからRACサービス・インスタンス接続用のOracleのドライバ(Thin)を選択し、「サービス名」フィールドでサービスを指定します。

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)))"

管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストからRACサービス・インスタンス接続用のOracleのドライバ(Thin XA)を選択し、「サービス名」フィールドでサービスを指定します。

注意:
SERVICE_NAMEは、指定されたマルチ・データ・ソースのすべてのデータ・ソースに対して同じである必要があります。
指定されたマルチ・データ・ソース内のデータ・ソースごとに異なるHOST NAMEおよびポート(またはその一方)を指定します。

- 接続プールに対してmax-capacity (管理コンソールでは「最大容量」)を指定する際、構成内の各Oracle RACノードの接続容量と、すべてのデータ・ソースからの接続総数を考慮に入れる必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。

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

サービス接続のシナリオでは、マルチ・データ・ソースの構成にロード・バランシング・アルゴリズムを使用することをお薦めします。ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成した場合、その接続プールはラウンドロビン方式で使用されます。この場合、関連するサービスが現在アクティブになっているすべてのOracle RACノードにわたって、ワークロードがロード・バランシング処理されます。

マルチ・データ・ソースの構成にフェイルオーバー・アルゴリズムを使用した場合は、接続の試行が失敗するまで(たとえば、Oracle RACノードが使用できなくなったり、使用可能な接続がデータ・ソースになくなるなどの理由で)、関連するOracle RACノード上のサービスへの接続に最初のデータ・ソースが使用されます。失敗した時点で、関連するOracle RACノード上のサービスへの接続に2番目のデータ・ソースが使用され、これが順次続行されます。この場合、最初のデータ・ソースの接続先であるOracle RACノードは、サービスが稼働中であるその他のノードよりも多く使用されることになります。

サービス接続の構成

次の機能を提供できるように構成を設計できます。

- ワークロード管理

- ロード・バランシング

ワークロード管理

ワークロード管理構成では、接続しているサービスが特定のOracle RACノードでアクティブか、または非アクティブかどうかに関係なく、各マルチ・データ・ソースでは、それぞれ1つのデータ・ソースが各Oracle RACノードの特定のサービス用に構成されています。このため、計画外ダウンタイムやスケジュールされたメンテナンスなどにより別のノードが使用できなくなった場合に、ノード上で非アクティブなサービスをすばやく開始して、そのサービスへの接続を作成できます。また、ワークロード需要に基づいて、指定されたサービスの使用可能容量をすばやく増加または削減することもできます。

ノード上でサービスが開始すると、関連付けられたデータ・ソースはサービスがアクティブになっていることを検出し、必要に応じてそのノードへの接続を開始します。指定されたノード上のサービスが停止すると、関連付けられたデータ・ソースはそのノードへの接続ができなくなり、サービスが再開始されるまで非アクティブになります。

WLSデータ・ソースは、接続テストを実行します。このため、データ・ソースは、Oracle RAC構成のトポロジの変更に応じて調整できます。データ・ソースはポーリングを実行して、関連付けられたサービスがアクティブか、または非アクティブかを確認します。サービスがOracle RACノード上で使用不可になると、接続テストは失敗します。

図C-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つ割り当てられています。このシナリオでは、ロード・バランシング・アルゴリズムを使用するように各マルチ・データ・ソースを構成します。

図C-5 マルチ・データ・ソースを使用したロード・バランシング

この例では、サービス1およびサービス2は使用可能なすべてのOracle RACノード上でそれぞれアクティブに稼働しています。その結果、各マルチ・データ・ソース内のすべての接続プールは、5つのノードの間でワークロードのバランスを取りながら、ラウンドロビン方式でアクティブに接続を行います。

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

データ・ソースに指定した最大容量の値によって、特定のOracle RACノードの接続容量を超過することがあります。データ・ソース別にこの値を設定する際、次の要因を考慮する必要があります。

- 1つのOracle RACノードでサポートできる同時接続の最大数。これは、1つのOracle RACノードで使用可能なメモリーと、各サービス接続の消費メモリー量(これはサービスごとに異なる場合があります)に基づきます。各接続のメモリー消費量は、WLSサーバーから生成できる作業量に対する主な制約要因です。WLSデータ・ソースからOracle RACノードへの接続が多すぎるために使用可能メモリー量を超えた場合、Oracle RACノードのパフォーマンスが低下し、接続失敗につながることがあります。
ノードの使用可能メモリーは、PGAターゲット属性(セッション・メモリーごと)に基づいていることが望ましいです。

- 特定のOracle RACノードに対して潜在的に接続を作成できるデータ・ソースの最大数、および各汎用データ・ソース/マルチ・データ・ソースをターゲットに指定するWebLogicサーバー・インスタンス数。たとえば、3つのWLSサーバーのターゲットとして指定されたデータ・ソースが1つある場合、各サーバーはデータ・ソースの中でそれぞれ専用のインスタンスを使用するため、そのデータ・ソースは3つのデータ・ソースとしてカウントされます。これは、サーバーがクラスタの一部であるか、または独立したサーバー・インスタンスであるかどうかのケースです。

- 特定のOracle RACノードでアクティブに稼働中であると思われるサービスの最大数、および各サービスへの接続ごとにノードで消費されるメモリー。

- 特定のノード上のサービスごとに予想される相対的なワークロード。たとえば、サービス1の予想ワークロードは、サービス2の予想ワークロードの2倍になる場合があります。
サービスが常にノードでアクティブであるかどうかに関係なく、ノード上でそのサービスを開始する必要がある場合は、そのサービスに対してリソースを割り当てることをお薦めします。

- データ・ソースに最大容量値を設定する場合は、常に最悪ケースのシナリオを使用してください。たとえば、各データ・ソースに関連付けられたOracle RACノードで、使用可能なすべてのサービスがアクティブに稼働するものと想定します。

次の例で、各データ・ソースの最大容量値を決定する方法について説明します。これは問題の概念をわかりやすく示すための非常に簡単な例であり、実際の状況ははるかに複雑であることを念頭においてください。一般に、低い最大容量値を使用してデータ・ソースを過少構成し、メモリー使用率とパフォーマンスに関してOracle RACノードをモニターし、その後で、関連付けられたOracle RACノードの最大容量に近づくまで最大容量値を上方に調整するのが最もよい方法です。

例

次の基本構成を使用しているとします。

- それぞれが16GBのメモリーを持つ5つのOracle RACノード。

- 各Oracle RACノードでアクティブに稼働している2つのサービス。サービス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つ存在することになります。したがって、1つのデータ・ソースからの接続に使用可能なメモリーは1GB (5GB/5)になります。各接続では10MBのメモリーが必要なため、クラスタ1のターゲットとなるデータ・ソースごとの最大容量値は100以下になります。

クラスタ2には4つのWLSサーバーがあるため、このOracle RACノードに対して接続リクエストを作成するデータ・ソースが4つ存在することになります。したがって、1つのデータ・ソースからの接続に使用可能なメモリーは2.5GB (10GB/4)になります。各接続では20MBのメモリーが必要なため、クラスタ2のターゲットとなるデータ・ソースごとの最大容量値は125以下になります。

サービス2がサービス1よりも多くのワークロードを生成する場合は、これらの値を適切に調整する必要があります(サービス2に接続しているデータ・ソースの最大容量値を増やし、サービス1に接続しているデータ・ソースの値を減らします)。次の状況であるかぎり:

(サービス1の最大接続数 x 接続ごとに使用するメモリー) + (サービス2の最大接続数 x 接続ごとに使用するメモリー) < 利用可能なメモリー

パフォーマンス低下または接続失敗の可能性を回避できます。

あるいは、図C-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クラスタである場合、これはクラスタ内のサーバー数になります。

図C-6の例では、次のようになっています。

- Oracle RACノード1つごとに使用可能なメモリーが8GB、接続ごとの使用メモリーが10MBであるとして、Oracle RACノードのグループに接続できる接続総数が最大4000であると仮定します。

- データ・ソースをターゲットとするサーバー・インスタンスが合計5つあります。

- 各サーバー・インスタンスのターゲットとなるデータ・ソースが5つあります。

- 各Oracle RACノードで稼働している2つのサービスがあります。

- 5つのOracle RACノードがあります。

この構成では、データ・ソースごとに入力する最大容量値は次のようになります。

Maximum connection pool capacity = 4000/(5 server instances x 5 data sources x 2 services x 5 Oracle RAC nodes)

この場合、データ・ソースごとの最大容量値は16になります。

図C-6 マルチ・データ・ソースの接続構成例

この式は、データ・ソースの構成に関する一般的なガイドラインにすぎないことを念頭に置いてください。多数の構成になると複雑すぎて、このように簡単な計算を使用できないためです。

使用する最大容量値を計算する際、構成全体を対象とした最悪ケースのシナリオを常に考慮してください。最悪ケースのシナリオを展開する際に、この値を通常操作に対して過大構成するのではなく、過少構成するのが最善です。Oracle RACノードを常にモニターしていると、データ・ソースの最大容量値を高くしても安全かどうかが判別できます。

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

Oracle RACのマルチ・データ・ソースでXA(グローバル・トランザクション)を使用する際に、次の要件と制限事項を考慮してください。

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

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

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

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

グローバル・トランザクションを指定してマルチ・データ・ソースを使用する際、Oracle RACには次の要件があります。

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

- グローバル・トランザクションをOracle RACクラスタの同一インスタンスで開始、準備、完結させる必要性

- トランザクションIDがOracle RACクラスタ内で一意であることの必要性

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

Oracle RACのマルチ・データ・ソースとともにXAトランザクションを使用する際は、常にマルチ・データ・ソースを使用します。

グローバル・トランザクションをOracle RACクラスタの同一インスタンスで開始、準備、完結させる必要性

グローバル・トランザクションは、Oracle RACクラスタの同一インスタンスで開始、準備、および完結させる必要があります。JDBCデータ・ソース構成でKeepXAConnTillTxComplete="true"を設定すると、WebLogic Serverのデータ・ソースがこのタスクに対応します。

トランザクションIDがOracle RACクラスタ内で一意であることの必要性

グローバル・トランザクションを使用する際、トランザクションID (XID)はOracle RACクラスタ内で一意である必要があります。ただし、Oracle ThinドライバもOracle RACインスタンスも、XIDがOracle RACクラスタ内で一意であるかどうかを判別することはできません。同じXIDを持つトランザクションは、例外がスローされることなく、Oracle RACクラスタの異なるインスタンス上でSQLコードを実行できます。

マルチ・データ・ソースでOracle RACを使用する際の既知の制限事項

次の各項では、Oracle RACでXAおよびマルチ・データ・ソースを使用する際の既知の問題と制限事項について説明します。

- 一部の失敗シナリオにおけるデータのデッドロックの可能性

- トランザクションが順序外で終了する可能性

注意:
これらの制限事項の中には、Oracleのバグ番号3428146および395790で説明しているものもあります。これらの問題の詳細は、オラクル社にお問い合せください。

一部の失敗シナリオにおけるデータのデッドロックの可能性

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ストアのリカバリ

Oracle RACとともにJDBCストアを使用している場合は、Oracle RACノードのフェイルオーバーに関連して検討すべき機能と制限事項があります。次の各項を参照してください。

- Oracle RACで使用するJDBCストアの構成

- 自動再試行

JDBCストアを使用する主要なサービスのリストは、『Oracle WebLogic Serverサーバー環境の構成』のストア接続のモニタリングに関する項を参照してください。

Oracle RACで使用するJDBCストアの構成

JDBCストアの動作方法により、Oracle RACで使用するJDBCストアの構成に使用できるオプションが制限されます。グローバル・トランザクションのサポートが構成されたJDBCデータ・ソースを使用するようにJDBCストアを構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。この構成オプションの詳細は、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。

JDBCストアは接続が失敗するまでその接続を保持しており、失敗した時点で次の接続に移動して、プロセスを繰り返します。したがって、ロード・バランシングのマルチ・データ・ソースも含め、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.IORetryDelayMillis=x

この場合、xはデータベースへの接続が再試行されるまでの経過時間(ミリ秒)です。デフォルト値は、1000ミリ秒です。この値は0から15000ミリ秒の範囲に制限されており、再試行は1回のみ試みられます。2回目の試みで失敗すると、コール・スタックまで例外が伝播され、失敗したトランザクションに関連するメッセージをリカバリするには手動での再起動が必要になります。

注意:
自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。

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

この付録では、接続時フェイルオーバーとロード・バランシングを使用するように構成されたデータ・ソースを使用している従来のアプリケーションに対してWebLogic Server 10.3.6で接続時フェイルオーバー(非推奨)が機能する方法について説明します。

注意:
新規アプリケーションでは、同じ機能を持つGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースについておよび『データベースJDBC開発者ガイド』の暗黙的な接続キャッシングに関する項を参照してください。

この付録の内容は次のとおりです。

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

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

- 構成コードのサンプル

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

接続時フェイルオーバーおよびロード・バランシング用に構成されたデータ・ソースを使用してWebLogic Serverを複数のOracle RACノードに接続するには、次の各項で説明するように、Oracle RACクラスタでOracle Thinドライバを使用して、Oracle RACインスタンス別にJDBCデータ・ソースを構成します。図D-1は、システムの概要を示しています。

図D-1 Oracle Thinドライバの接続時フェイルオーバーを使用するデータ・ソース構成

管理コンソール、またはドメインの構成に優先的に使用したいその他の手段、たとえばWebLogic Scripting Tool (WLST)またはJMXプログラムが使用できます。

データ・ソースに接続が作成されると、使用するOracle RACインスタンスがOracle Thinドライバによって決定されます。アプリケーションは、接続を取得すると、JNDIツリー上でデータ・ソースを検索して、そのデータ・ソースからの接続をリクエストします。データ・ソースは、データ・ソース内の接続プールから使用可能な接続の1つを配信します。

次の各項では、Oracle RACの接続時フェイルオーバー機能を使用して接続の失敗を処理する構成について説明します。この構成では、失敗した場合のフェイルオーバー時間はTCPタイムアウトの時間になりますが、これは使用環境に応じて数分かかる場合もあります。

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

この構成を使用するには、次の属性が指定されているWebLogicドメインにJDBCデータ・ソースを作成します。

- 接続時フェイルオーバー用に構成されたOracle JDBC Thinドライバ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>

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

この付録では、Oracle高速接続フェイルオーバーでWebLogic Server 10.3.6を使用する方法について説明します。

WebLogic Serverは、高速接続フェイルオーバーをサポートしています。これは、無効な接続の検出とクリーンアップ、使用可能な接続のロード・バランシング、およびアクティブなOracle RACインスタンス上での作業の再配信などのOracle RACイベント通知を実装するために、アプリケーション非依存の方法を提供するOracle機能の1つです。

詳細は、『Oracle®データベースJDBC開発者ガイドおよびリファレンス』の高速接続フェイルオーバーに関する項(http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/fstconfo.htm#CIHJBFFC)を参照してください。

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

データ・ソースで高速接続フェイルオーバーを有効化するには、次の接続プールのプロパティを設定します。

- ドライバ・クラス名内: クラス名をoracle.jdbc.pool.OracleDataSourceに設定します。

- プロパティ内: Oracle RACノードをリモートにサブスクライブするONS構成文字列をOracle FAN/ONSイベントに設定します。例: ONSConfiguration=nodes=hostname1:port1,hostname2:port2

注意:
OracleのOracleDataSourceクラスはXA対応ではないため、結果として生じるデータ・ソースではXA接続プールは実装されません。

OracleドライバがONSを使用して高速接続フェイルオーバーを実装するため、ons.jarをWebLogic classpathに追加する必要があります。これを実行するには、ドメインのbinディレクトリのsetDomainEnvスクリプトを編集し、ons.jarをPOST_CLASSPATH変数に追加します。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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)を参照してください。