Oracle® Fusion Middleware

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

12c (12.2.1)

E70015-01(原本部品番号:E55151-02)

2015年11月

このマニュアルでは、JDBCデータ・ソース構成と管理情報について説明しています。

Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理12c (12.2.1)

E70015-01

Copyright © 2007, 2015, 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データ・ソースの新機能と変更された機能

- デフォルト・データ・ソース

- 簡略化されたドライバ・インストール/更新

- プロキシ・データ・ソースのサポート

- UCPデータ・ソースのサポート

- マルチテナント用のJDBCデータ・ソースのサポート

- 接続リークのプロファイリングの拡張

- 接続ベースのシステム・プロパティの拡張

- アプリケーション・コンティニュイティの実行時統計

- ONSノード・リスト構成の拡張

- DRCPネットワーク・タイムアウト・プロパティ

- エディションベースの再定義(EBR)のドキュメントの拡張

- 計画メンテナンスとデータベース停止のガイドライン

- ONSおよびJDBCデバッグの変更の有効化

- 接続時フェイルオーバーのサポートの削除

2 WebLogic JDBCリソースの構成

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

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

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

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

- 汎用データ・ソース・モジュール

- Active GridLinkデータ・ソースのシステム・モジュール

- マルチ・データ・ソース・システム・モジュール

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

- 標準のJava EEアプリケーション・モジュール

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

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

- バージョニングされたアプリケーションの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コードを使用したデータベース接続の初期化

- 詳細な接続プロパティ

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

- エディションベースの再定義の使用

- JDBC接続でのEBRの使用

- エディションを使用するためのWebLogicデータ・ソースの構成

- Oracleパラメータの構成

- ONSクライアントの構成

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

- Oracle RACの停止に対する汎用データ・ソースの処理

- ドライバ・レベル・フェイルオーバーの汎用データ・ソースの処理

4 デフォルト・データ・ソースの使用

- デフォルト・データ・ソースとは

- デフォルト・データ・ソースの特性

- WebLogic Serverのデフォルト・データ・ソースの定義

- カスタム・デフォルト・データ・ソースの定義

- カスタム・デフォルト・データ・ソース・ディスクリプタの作成

- デフォルト・データ・ソースのオーバーライド

- デフォルト・データ・ソースを使用する場合の互換性の制限

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

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

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

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

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

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

- フェイルオーバー

- ロード・バランシング

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

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

- 使用中の接続に対するフェイルオーバーの実施不可能

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

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

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

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

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

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

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

- フェイルオーバーの仕組み

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

- フェイルバックの仕組み

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

- マルチ・データ・ソースでの計画データベース・メンテナンス

- プロセスの概要

- データ・ソースの停止

- WLSTの例

- 重要な考慮事項

6 Active GridLinkデータ・ソースの使用方法

- Active GridLinkデータ・ソースとは

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

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

- GridLinkアフィニティ

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

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

- SCANアドレス

- Oracleウォレットを使用したONSリスナーとのセキュアな通信

- Active Data Guardのサポート

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

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

- データ・ソース名

- データ・ソース・スコープ

- JNDI名

- ドライバの選択

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

- 接続プロパティの構成

- 接続プロパティの入力

- 完全なURLの入力

- 接続のテスト

- ONSクライアント構成

- FANイベントの有効化

- ONSホストおよびポートの構成

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

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

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

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

- SDPを使用したランタイム・ロード・バランシングの構成

- AGL接続プール機能の構成

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

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

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

- Oracleパラメータの構成

- WLSTを使用したONSクライアントの構成

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

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

- 実行時統計の表示

- JDBCOracleDataSourceRuntimeMBean

- JDBCOracleDataSourceInstanceRuntimeMBean

- ONSDaemonRuntimeMBean

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

- JDBCのデバッグ範囲

- UCP JDKロギング

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

- FAN通知を使用しないActive GridLinkデータ・ソースの使用方法

- ActiveGridlink属性の理解

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

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

- Active Gridlinkデータ・ソースによる接続の作成

- AGLとマルチ・データ・ソースの比較

- マルチ・データ・ソースからActive GridLinkへの移行

- マルチ・データ・ソースからの移行に伴うアプリケーションの変更

- マルチ・データ・ソースからの移行に伴う構成の変更

- マルチ・データ・ソースからActive GridLinkデータ・ソースへの移行の基本手順

- AGLデータ・ソースでのデータベース停止時間の管理

- データベースの停止に対応するActive GridLink構成

- 計画停止の手順

- 計画外停止

7 Proxyデータ・ソースの使用

- プロキシ・データ・ソースとは

- プロキシ・データ・ソースの作成

- WebLogic Server管理コンソールでのプロキシ・データ・ソースの構成

- プロキシ・データ・ソース・プロパティの設定

- ターゲットの選択

- WLSTを使用したプロキシ・データ・ソースの構成

- プロキシ・データ・ソースJDBCリソースのモニタリング

8 ユニバーサル接続プール・データ・ソースの使用

- ユニバーサル接続プール・データ・ソースとは

- ユニバーサル接続プール・データ・ソースの作成

- WebLogic Server管理コンソールでのUCPデータ・ソースの構成

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

- 接続プロパティの設定

- データベース接続のテスト

- ターゲットの選択

- WLSTを使用したUCPデータ・ソースの構成

- ユニバーサル接続プールJDBCリソースのモニタリング

9 接続収集

- 接続収集とは

- 接続収集の有効化

- 接続を収集可能としてマーキング

- 収集した接続のリカバリ

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

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

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

- 要件および考慮事項

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

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

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

- リプレイのタイムアウトの設定

- アプリケーション・コンティニュイティの無効化

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

- JDBCドライバ・デバッグの有効化

- アプリケーション・コンティニュイティの実行時統計の表示

- WLSTのサンプル

- Javaのサンプル

- Oracle 12cデータベースにおけるアプリケーション・コンティニュイティに関する制限

- データベース常駐接続プーリング

- 要件および考慮事項

- DRCPの構成

- DRCP対応データ・ソースの構成

- DRCP対応データベースの構成

- Global Database Services

- 要件および考慮事項

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

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

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

- DRCPおよびCDB/PDB

- JDBCを使用したPDBの設定

- テナントの切替えに関する制限

11 接続のラベル付け

- 接続ラベリングとは

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

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

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

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

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

- 接続ラベルの適用

- ラベル付けされた接続の予約

- 不一致ラベルのチェック

- 接続ラベルの削除

- 初期化および再初期化コストを使用した接続の選択

- 初期化および再初期化コストを使用する場合の考慮事項

- パッケージ・アプリケーションによる接続ラべリングの使用

- パッケージ・アプリケーションでラベル付けされた接続を使用する場合の考慮事項

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

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

- 「ロギング・ラスト・リソース」トランザクション・オプションの理解

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

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

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

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

- 2フェーズ・コミットのエミュレート・トランザクション・オプションの理解

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

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

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

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

- 複数の非XA登録

- 接続クローズ時のローカル・トランザクションの完了

13 データ・ソースのセキュリティの理解

- WebLogicデータ・ソース・セキュリティのオプションの概要

- WebLogicデータ・ソース・セキュリティのオプション

- 資格証明マッピングとデータベース資格証明

- 接続へのクライアント識別子の設定

- Oracleプロキシ・セッション

- IDベースの接続プール

- トランザクション内の接続

- WebLogicデータ・ソース・リソースのパーミッション

- データ・ソース・セキュリティの例

- 暗号化された接続プロパティの使用

- 管理コンソールの使用時に接続プロパティを暗号化するためのベスト・プラクティス

- 接続プロパティを暗号化するためのWLSTの例

- WLSTを使用して、暗号化されたプロパティで既存のデータ・ソースを更新する方法

- WLSTを使用して、暗号化されたプロパティを作成する方法

- データ・ソースおよびOracleドライバでのSSLと暗号化の使用

- データ・ソースおよびOracleドライバでのSSLの使用

- OracleウォレットでのSSLの使用

- Active GridLink ONS over SSL

- データ・ソースおよびOracleドライバでのデータ暗号化の使用

14 Oracleウォレットの作成および管理

- Oracleウォレットとは

- ウォレットを保持する場所

- 外部パスワード・ストアの作成方法

- ウォレットを使用するWebLogic Serverデータ・ソースの定義

- ウォレット・ファイルのコピー

- データ・ソース構成の更新

- DB接続文字列のかわりにTNS別名を使用

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

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

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

16 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を使用する場合の追加考慮事項

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

- JDBCドライバのサポート

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

- WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加

- DOMAIN_HOME/libのサード・パーティJARファイルの使用

- データ・ソースのサポート

- /libのサード・パーティJARファイルの使用の例

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

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

18 WebLogic JDBCリソースのモニタリング

- 実行時統計の表示

- データ・ソースの統計

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

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

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

- プロファイル・タイプ

- 接続使用状況(WEBLOGIC.JDBC.CONN.USAGE)

- 待機中の接続予約(WEBLOGIC.JDBC.CONN.RESV.WAIT)

- 失敗した接続予約(WEBLOGIC.JDBC.CONN.RESV.FAIL)

- 接続リーク(WEBLOGIC.JDBC.CONN.LEAK)

- 接続の最終使用状況(WEBLOGIC.JDBC.CONN.LAST_USAGE)

- マルチスレッド接続使用状況(WEBLOGIC.JDBC.CONN.MT_USAGE)

- 文キャッシュ・エントリ(WEBLOGIC.JDBC.STMT_CACHE.ENTRY)

- 文使用状況(WEBLOGIC.JDBC.STMT.USAGE)

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

- クローズ済JDBCオブジェクトの使用状況(WEBLOGIC.JDBC.CLOSED_USAGE)

- ローカル・トランザクション接続リーク(WEBLOGIC.JDBC.CONN.LOCALTX_LEAK)

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

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

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

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

- デバッグの有効化

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

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

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

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

- JDBCのデバッグ範囲

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

- UCPのデバッグ

- ONSのデバッグ

- リクエストのDye処理

19 WebLogic JDBCリソースの管理

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

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

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

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

- 接続プールの縮小

- 接続プールのリセット

- 接続プールの中断

- 接続プールの再開

- データ・ソースの停止

- データ・ソースの起動

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

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

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

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

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

- 固定

- 文キャッシュ・サイズ

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

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

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

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

- 文キャッシュを使用する際のその他の考慮事項

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

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

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

- 定期的な接続テスト

- 予約済の接続のテスト

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

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

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

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

- デフォルトのテスト対象の表名を使用したデータベース接続テスト

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

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

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

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

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

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

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

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

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

- PinnedToThreadが有効になっている場合の接続プール管理操作の変更

- PinnedToThreadが有効になっている場合のデータベース・リソースの追加コスト

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

- ラップを無効にする方法

- 管理コンソールを使用したラップの無効化

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

- メンテナンス・タイマーのチューニング

A Oracle 12cデータベースの使用

- Oracle 12cデータベースに対するWebLogic JDBC機能

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

- アプリケーション・コンティニュイティのサポート

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

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

- Global Database Servicesのサポート

- 自動ONSリスナー

- WebLogic Serverでの12Cデータベース機能サポートのサマリー

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

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

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

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

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

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

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

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

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

- JDBCモジュールでのデータベース・パスワードの暗号化

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

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

- Java EEディスクリプタ・ファイルでのJDBCモジュールの参照

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

- その他のディスクリプタにおいてパッケージ化されたJDBCモジュール参照

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

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

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

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

- サービスに接続するようにデータ・ソースを構成

- サービス接続の構成

- ワークロード管理

- ロード・バランシング

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

- マルチ・データ・ソースを使用したSCANアドレスの使用

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

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

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

- グローバル・トランザクションをOracle RACクラスタの同一インスタンスで開始、準備、完結させる必要性

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

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

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

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

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

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

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

- JMS接続に対する自動再試行

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

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

E JDBCのスマート・アップグレードのサポート

はじめに

ここでは、ドキュメントのアクセシビリティ機能とこのマニュアル(『Oracle WebLogic Server 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 WebLogic Server JDBCデータ・ソースの管理』)の内容と構成について説明します。

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

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

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

- 関連ドキュメント

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

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

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

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

このドキュメントでは、具体的なJDBCプログラミングのトピックについては説明していません。WebLogic Serverのドキュメントと、このトピックに関するリソースは、「関連ドキュメント」を参照してください。

対象読者には、Java EEとJDBCの概念についての知識があることを前提としています。このドキュメントでは、WebLogic Serverが提供する付加価値の高い機能について重点的に説明しています。

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

- この章、第1章「概要とロードマップ」では、このガイドの編成内容を紹介し、現行リリースの新機能について説明します。

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

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

- 第4章「デフォルト・データ・ソースの使用」では、デフォルト・データ・ソースについて説明します。

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

- 第6章「Active GridLinkデータ・ソースの使用方法」では、WebLogic Active GridLinkデータ・ソース構成について説明します。

- 第7章「Proxyデータ・ソースの使用」では、WebLogicプロキシ・データ・ソース構成について説明します。

- 第8章「ユニバーサル接続プール・データ・ソースの使用」では、ユニバーサル接続プール(UCP)・データ・ソースについて説明します。

- 第9章「接続収集」では、アプリケーションで接続収集を構成および使用する方法について説明します。

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

- 第11章「接続のラベル付け」では、接続にラベルを付けてパフォーマンスを向上する方法について説明します。

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

- 第13章「データ・ソースのセキュリティの理解」では、JDBCデータ・ソースを保護するためにWebLogic Serverで構成オプションが使用される方法について説明します。

- 第14章「Oracleウォレットの作成および管理」では、WebLogic Serverデータ・ソース定義のデータベース資格証明書を格納するOracleウォレットの作成方法と管理方法を説明します。

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

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

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

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

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

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

- 付録A「Oracle 12cデータベースの使用」では、Oracle 12cと相互運用するためのWebLogic Serverリリース12.1.2以降の構成方法について説明します。

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

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

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

関連ドキュメント

このドキュメントでは、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のインストール時に、オプションでインストールされます。MedRecは、ORACLE_HOME\user_projects\domains\medrecディレクトリから開始できます。ORACLE_HOMEは、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリです。

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

WebLogic ServerのEXAMPLES_HOME\wl_server\examples\src\examplesにはAPIコードのサンプルがインストールされます(オプション)。EXAMPLES_HOMEは、WebLogic Serverのコード・サンプルが構成されるディレクトリを表しています。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード・サンプルに関する項を参照してください。

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

このリリースには、次の新機能と変更された機能が含まれています。

- デフォルト・データ・ソース

- 簡略化されたドライバ・インストール/更新

- プロキシ・データ・ソースのサポート

- UCPデータ・ソースのサポート

- マルチテナント用のJDBCデータ・ソースのサポート

- 接続リークのプロファイリングの拡張

- 接続ベースのシステム・プロパティの拡張

- アプリケーション・コンティニュイティの実行時統計

- ONSノード・リスト構成の拡張

- DRCPネットワーク・タイムアウト・プロパティ

- エディションベースの再定義(EBR)のドキュメントの拡張

- 計画メンテナンスとデータベース停止のガイドライン

- ONSおよびJDBCデバッグの変更の有効化

- 接続時フェイルオーバーのサポートの削除

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

デフォルト・データ・ソース

Oracleでは、Java EE 7準拠ランタイムで必要なデフォルト・データ・ソースのサポートを提供しています。これには、WebLogic ServerとともにインストールされたDerbyデータベースにアクセスするためにアプリケーションで使用できる構成済のデータ・ソースが含まれます。第4章「デフォルト・データ・ソースの使用」を参照してください。

簡略化されたドライバ・インストール/更新

以前のリリースでは、新しいJDBCドライバを追加する場合、または置き換えるJARの名前が元のJARと異なるJDBCドライバを更新する場合、WebLogic Serverのクラスパスを更新してJDBCドライバ・クラスの場所を含める必要がありました。このリリースでは、ドライバを$DOMAIN_HOME/libディレクトリに配置するだけで済み、クラスパスを変更する必要はありません。「WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加」を参照してください。

プロキシ・データ・ソースのサポート

Oracleでは、WebLogic Server Java EEマルチテナント環境のデータベース間で切替えを実行できる新しいデータ・ソース・タイプを提供しています。第7章「Proxyデータ・ソースの使用」を参照してください。

UCPデータ・ソースのサポート

UCPデータ・ソースは、Oracle Universal Connection Pooling (UCP)を使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。詳細は、第8章「ユニバーサル接続プール・データ・ソースの使用」を参照してください。

マルチテナント用のJDBCデータ・ソースのサポート

WebLogic Serverマルチテナント用のデータ・ソース構成およびモニタリングのサポート。『WebLogic Server MTの使用』のJDBCの構成に関する項を参照してください。

接続リークのプロファイリングの拡張

接続リークのプロファイリングの拡張には、次の機能が含まれます。

- 新しい属性(Set Connection Leak Timeout Seconds): 予約済の接続がリークしているとみなすまでの時間の長さを指定するために、Inactive Connection Timeout Secondsのかわりに使用できます。

- 2つの新しいプロファイル・レコード:

- クローズ済JDBCオブジェクトの使用状況 - 接続、文または結果セットを閉じるアプリケーション・コンポーネントに関するプロファイル情報を収集します。

- ローカル・トランザクション接続リーク - ローカル・トランザクションのリークが発生するアプリケーション・コンポーネント(起動するがトランザクションをコミットまたはロールバックしない)に関するプロファイル情報を収集します。

詳細は、「プロファイル情報の収集」を参照してください。

接続ベースのシステム・プロパティの拡張

環境に基づいた変数を使用して接続ベースのシステム・プロパティを設定できます。詳細は、「接続ベースのシステム・プロパティの有効化」を参照してください。

アプリケーション・コンティニュイティの実行時統計

アプリケーション・コンティニュイティ(またはリプレイ)の統計は、汎用データ・ソースおよびActive GridLinkデータ・ソースのJDBCReplayStatisticsRuntimeMBeanを通じて使用できます。詳細は、「アプリケーション・コンティニュイティの実行時統計の表示」を参照してください。

ONSノード・リスト構成の拡張

プロパティ・ノード・リストを使用してONSノード・リストを構成できるようになりました。プロパティ・ノード・リストは、単一のノード・リストのかわりに使用できる、各レコードがキー=値のペアで構成された複数のレコードを含む文字列です。詳細は、「ONSクライアント構成」を参照してください。

DRCPネットワーク・タイムアウト・プロパティ

このリリースでは、システム・プロパティweblogic.jdbc.attachNetworkTimeoutが提供されており、サーバーへのアタッチ後に(Oracle pingデータベース操作を使用して)データベースへのラウンドトリップを強制するネットワーク・タイムアウトを指定できます。その後、タイムアウトは設定解除されます。詳細は、「データベース常駐接続プーリング」を参照してください。

エディションベースの再定義(EBR)のドキュメントの拡張

この機能を説明するドキュメントは、JDBC接続でEBRを使用する方法の詳細を含むように拡張され、エディションを使用するようにWebLogicデータ・ソースを構成する方法も記載されています。詳細は、「エディションベースの再定義の使用」を参照してください。

計画メンテナンスとデータベース停止のガイドライン

マルチ・データ・ソースおよびActive Gridlinkデータ・ソースでデータベース・メンテナンスと停止時間を計画して管理するための手順とガイドラインが含まれます。詳細は、以下のトピックを参照してください。

- マルチ・データ・ソースでの計画データベース・メンテナンス

- AGLデータ・ソースでのデータベース停止時間の管理

ONSおよびJDBCデバッグの変更の有効化

ONSおよびJDBCリプレイ・デバッグを有効化するには、Java Util Loggingを構成する必要があります。詳細は、以下のトピックを参照してください。

- JDBCドライバ・デバッグの有効化

- ONSのデバッグ

接続時フェイルオーバーのサポートの削除

Oracle接続時フェイルオーバーは、以前のリリースで非推奨になりました。この機能とそれに関連する付録は、このリリースでは削除されています。

2 WebLogic JDBCリソースの構成

この章では、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におけるデータ・ソースの詳細は、第3章「JDBCデータ・ソースの構成」を参照してください。

Active GridLink (AGL)データ・ソースは、1つ以上のOracle RACクラスタ内の1つ以上のノードに及ぶ接続プールを提供します。これは、ノード全体にわたる接続の動的ロード・バランシングをサポートし、クラスタに対するノードの追加や削除を示すイベントを処理します。第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

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

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

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

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

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

表2-1は、JDBCのモジュール・タイプと、それらの構成および変更方法を示しています。

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

モジュール・タイプ

作成に使用するツール

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

JMXでの変更(リモート)

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

管理コンソールでの変更

システム

WebLogic Server管理コンソールまたはWLST

はい

はい

いいえ

可(JMXを使用)

アプリケーション

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

いいえ

いいえ

可(デプロイメント・プランを使用)

可(デプロイメント・プランを使用)

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

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

JDBCリソースは、システム・モジュールとして、またはアプリケーション・モジュールとして、作成および管理されます。WebLogicは、標準または独自のJDBCアプリケーション・モジュールをサポートします。標準のJDBCアプリケーション・モジュールは、JEE 6の注釈またはdatasourcedefinitionに基づくスキーマの定義を使用して作成されます。独自のJDBCアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションに含めて構成するか、スタンドアロンのモジュールとして構成できます。

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

JDBCシステム・モジュール

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

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

汎用データ・ソース・モジュール

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

注意:
「汎用」は単純なデータ・ソースを、マルチ・データ・ソースやAGLデータ・ソースと区別するために使用する用語です。

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

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

Active GridLinkデータ・ソースのシステム・モジュール

AGLデータ・ソース・システム・モジュールは汎用データ・ソース・システム・モジュールと同様に、JDBCSystemResource要素として、ドメインのconfig.xmlファイルに含まれています。AGLデータ・ソースには、ONSおよびFANを含むjdbc-oracle-paramsセクションが含まれます。

AGLデータ・ソースの詳細は、第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

マルチ・データ・ソース・システム・モジュール

同様に、マルチ・データ・ソース・システム・モジュールは、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パラメータで指定されているアルゴリズムに応じて、データベース接続の供給に使用する汎用データ・ソースをどれにするかを決定します。

注意:
マルチ・データ・ソースのメンバーは、汎用データ・ソースである必要があります。マルチ・データ・ソースやAGLデータ・ソースはメンバーにできません。

マルチ・データ・ソースの詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

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

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

標準のJava EEアプリケーション・モジュール

Java EE ではデータソース・リソースを、データベース接続の柔軟で移植性に優れたメソッドのためのアプリケーション・モジュールとしてプログラムで定義できます。『Oracle WebLogic Server JDBCアプリケーションの開発』のデータソース・リソース定義の使用に関する項を参照してください。

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

JDBCリソースは、標準のJava EEモジュールと同様に、アプリケーション・モジュールとしても管理できます。独自のJDBCアプリケーション・モジュールとは、単なるjdbc-data-source.xsdスキーマ(http://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手可能)に準拠するXMLファイルであり、データ・ソースを表します。

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

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

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

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

注意:
独自のJDBCモジュールをスタンドアロン・モジュールとしてデプロイする場合、マルチ・データ・ソースのデプロイ順序は、そのメンバーの汎用データ・ソースのデプロイ順序より大きい数値である必要があります。

JDBCアプリケーション・モジュールの詳細は、付録B「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内に古いバージョンのドライバがある場合は、weblogic.xmlファイル内でPREFER-WEB-INF-CLASSES=trueを設定して、アプリケーションとともにパッケージ化されたドライバ・クラスを使用できるようにします。

EARまたはWARに埋め込まれているOracleドライバをojdbc6.jarまたはojdbc7.jarで使用する場合、関連するクラス・ローダーのクリーンアップに関して既知の問題が存在します。この問題を解決するには、ServletContextListenerのcontextDestroyed()メソッドからoracle.jdbc.OracleDriver.deregisterHack()をコールします。

WEB-INF/libディレクトリを使用して、ドライバJARファイルを保持することもできます。次の例は、WARおよびEARファイルの様々なディレクトリの場所を示しています。

Application (ear)
Web module (war)
WEB-INF/lib
EJB module
META-INF
APP-INF/lib

ただし、prefer-web-inf-classesまたはprefer-application-packagesセットで、DOMAIN_HOME/lib (「DOMAIN_HOME/libのサード・パーティJARファイルの使用」を参照)またはシステム・クラスパスとWEB-INF/libまたはAPP-INF/libの両方に同じJARの2つのバージョンを保持することはできません。つまり、次のいずれかのみを行う必要があります。

- DOMAIN_HOME/libまたはシステム・クラスパスを使用して、ドメイン内のすべてのアプリケーションにドライバを取得します。

- アプリケーションに埋め込まれたドライバを使用します。

注意:
この制限に従わない場合、(JAR、バージョン変更、およびJARの参照順序に応じて)アプリケーションでClassCastExceptionが発生する可能性があります。

JARファイルが複数の場所に存在する場合、次のルールが適用されます。

- weblogic.xmlのprefer-web-inf-classesがfalseの場合、優先順位は、システム・クラスパス > DOMAIN_HOME/lib > APP-INF/lib > WEB-INF/libになります。

- weblogic.xmlのprefer-web-inf-classesがtrueの場合、WEB-INF/libのクラスが他のすべての場所に優先します。

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://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手できます。

注意:
パッケージ化されたデータ・ソースの場合、スキーマのjdbc-data-source-params要素内のスコープはApplicationにのみ設定する必要があります。値Applicationは、次のものに対して無効になります。

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

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

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

JDBCデータ・ソース・タイプ

データ・ソースは、記述子にdatasource-typeセットが含まれる必要があります。この機能は、WebLogic Server 12.2.1で追加されたもので、下位互換性を確保するためのオプションです。有効な値は、次のとおりです。

- GENERIC - 汎用データ・ソース

- MDS - マルチ・データ・ソース

- AGL - Active GridLinkデータ・ソース

- UCP - ユニバーサル接続プール・データ・ソース

- PROXY - 複数テナント・データ・ソース用プロキシ

datasource-typeがUCPまたはPROXYに設定されていない場合、次の検証が実行されます。

- datasource-typeがAGLに設定されている場合、FANの有効化がfalseで、ONSリストが構成されておらず、Active GridLinkフラグがfalseであっても、それはActive GridLinkデータ・ソースとして扱われます。

- datasource-typeがAGLに設定されていない場合、FANの有効化がtrueであるか、ONSリストが構成されているか、またはActive GridLinkフラグがtrueであっても、それはエラーになります。

- データ・ソース・リストが存在せず(マルチ・データ・ソースのメンバーが含まれない状態)、datasource-typeがGENERICまたはAGL以外に設定されている場合、それはエラーになります。

- データ・ソース・リストが存在し(マルチ・データ・ソースのメンバーが含まれる状態)、datasource-typeがMDS以外に設定されている場合、それはエラーになります。

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

JDBCリソースは、『Oracle WebLogic Serverの理解』のシステム管理ツールとAPIの概要に関する項にリストされている管理ツールを使用して作成できます。JDBCリソースを作成すると、WebLogic Serverで各リソースのMBean (マネージドBean)が作成されます。その後、JMXまたはWebLogic Scripting Tool (WLST)を使用してMBeanにアクセスできます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』および『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、JDBCMultiDataSourceRuntimeMBeanおよびJDBCDataSourceRuntimeMBeansのリストにアクセスするためのメソッドを提供します。

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

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

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

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

WebLogic ServerでのJava EE管理モデルの使用については、『Oracle WebLogic Server Java EE管理アプリケーションの開発』を参照してください。

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メソッドを使用します。

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

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

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

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

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

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

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

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

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

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

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

- JDBCデータ・ソースの理解

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

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

- 汎用の接続プール機能の構成

- 詳細な接続プロパティ

- Oracleパラメータの構成

- ONSクライアントの構成

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

- Oracle RACの停止に対する汎用データ・ソースの処理

- ドライバ・レベル・フェイルオーバーの汎用データ・ソースの処理

JDBCデータ・ソースの理解

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

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

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

- 汎用データ・ソース - 汎用データ・ソースとその接続プールによって、効率的なシステム運用の維持を円滑にする接続管理プロセスが提供されます。アプリケーションや環境に適合するオプションをデータ・ソースで設定できます。

- Active GridLink (AGL)データ・ソース - 1つ以上のOracle RACクラスタ内の1つ以上のノードに及ぶ接続プールを提供するデータ・ソース。これは、ノード全体にわたる接続の動的ロード・バランシングをサポートし、クラスタに対するノードの追加や削除を示すイベントを処理します。第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

- マルチ・データ・ソース(MDS) - マルチ・データ・ソースとは、汎用データ・ソースのグループに関する抽象化のことです。この抽象化により、ロード・バランシングやフェイルオーバー処理を実現します。第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

- プロキシ・データ・ソース - WebLogic Serverマルチテナント環境のデータベース間で切替えを実行できるデータ・ソース。第7章「Proxyデータ・ソースの使用」を参照してください。

- ユニバーサル接続プール(UCP)・データ・ソース - UCPデータ・ソースは、Oracle Universal Connection Pooling (UCP)を使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。詳細は、第8章「ユニバーサル接続プール・データ・ソースの使用」を参照してください。

JDBCデータ・ソースの作成

WebLogicドメインにJDBCデータ・ソースを作成するには、WebLogic Server管理コンソール、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用します。

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

- 『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server JDBCデータ・ソースに関する項

- サンプルのWLSTスクリプトEXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py。EXAMPLES_HOMEは、WebLogic Serverのコード・サンプルが構成されるディレクトリを表しています。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

次の各項では、WebLogic Server管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。

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

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

- 接続プロパティの構成

- 接続のテスト

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

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

「JDBCデータ・ソースのプロパティ」には、データ・ソースのアイデンティティを決定するオプションと、データベース接続でデータを処理する方法を決定するオプションがあります。

データ・ソース名

JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース間で一意の名前を付ける必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。特定のアプリケーションにパッケージ化されたJDBCアプリケーション・モジュールの場合、データ・ソースの名前は、同様にスコープ設定されたJDBCデータ・ソース間で一意にする必要があります。

データ・ソース・スコープ

使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。

JNDI名

単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。

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

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

JDBCドライバの選択

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

- Oracle Thinドライバ

- Oracle ThinドライバXA

- Oracle Thinドライバ非XA

- MySQL (非XA)

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

- 次に示すデータベース管理システム用の、WebLogicブランドのDataDirectドライバ(『Oracle WebLogic Server JDBCアプリケーションの開発』のWebLogicブランドのDataDirectドライバの使用に関する項を参照):

- DB2

- Informix

- Microsoft SQL Server

- Sybase

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

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

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

注意:
データ・ソースの作成時に、WebLogic Server管理コンソールに一覧表示されるJDBCドライバには、WebLogic Serverでの使用が保証されていないものもあります。JDBCドライバの一覧は、多数の使用可能なデータベース管理システムへの接続を円滑に作成するための利便性を目的として示されます。
JDBCドライバを使用してデータ・ソースにデータベース接続を作成するには、データ・ソースをデプロイするサーバーごとにJDBCドライバをインストールする必要があります。WebLogic Server管理コンソールに一覧されるドライバは、データ・ソースの構成に役立つ既知の必須構成オプションとともに示されます。この一覧には、インストールされていないJDBCドライバも表示されます。ドライバのインストールには、システムのPathやClasspathなどの環境変数の設定が含まれることがあります。「WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加」を参照してください。JDBCドライバの更新に伴って、構成要件が変更されることがあります。WebLogic Server管理コンソールは、WebLogic Serverソフトウェアがリリースされた時点での既知の構成要件を使用します。JDBCドライバの構成オプションが変更されているときには、その構成オプションの手動でのオーバーライドが必要になる場合があります。その場合、データ・ソースの作成時またはデータ・ソースの作成後にプロパティのページでオプションをオーバーライドします。

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

WebLogic Server管理コンソールを使用して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管理およびデプロイメント・ガイド』の動的データベース・サービスでの自動ワークロード管理の概要に関する項を参照してください。

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

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

接続のテスト

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

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

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

汎用の接続プール機能の構成

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

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

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

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

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

- 接続ベースの暗号化されたプロパティの有効化

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

- 詳細な接続プロパティ

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

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

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

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

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

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

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

システム・プロパティ値が設定されている場合、それは暗号化されたプロパティ値をオーバーライドし、次にその値が通常のプロパティ値をオーバーライドします(プロパティ名ごとに1つのプロパティ値のみを持つことができます)。

システム・プロパティ値には、表3-1にリストされた変数の1つを含めることができます。これらの1つ以上の変数がシステム・プロパティに含まれる場合、対応する値で置換されます。値が検出されない場合、置換は実行されません。これらのどの変数もシステム・プロパティで検出されない場合、値は、システム・プロパティ名として扱われます。

表3-1 JDBCデータ・ソースのシステム・プロパティ値でサポートされる変数

変数

値の説明

${pid}

ManagementFactory.getRuntimeMXBean().getName()の前半部分(@まで)

${machine}

ManagementFactory.getRuntimeMXBean().getName()の後半部分

${user.name}

Javaシステム・プロパティuser.name

${os.name}

システム・プロパティos.name

${datasourcename}

JDBCディスクリプタによるデータ・ソース名。パーティション名は含みません。

${partition}

パーティション名またはDOMAIN

${serverport}

WebLogic Serverサーバー・リスニング・ポート

${serversslport}

WebLogic ServerサーバーSSLリスニング・ポート

${servername}

WebLogic Serverサーバー名

${domainname}

WebLogic Serverドメイン名

次の例に、プロパティのサンプル・セットを示します。

<properties>
<property>
<name>user</name>
<sys-prop-value>user</sys-prop-value>
</property>
<property>
<name>v$session.osuser</name>
<sys-prop-value>${user.name}</sys-prop-value>
</property>
<property>
<name>v$session.process</name>
<sys-prop-value>${pid}</sys-prop-value>
</property>
<property>
<name>v$session.machine</name>
<sys-prop-value>${machine}</sys-prop-value>
</property>
<property>
<name>v$session.terminal</name>
<sys-prop-value>${datasourcename}</sys-prop-value>
</property>
<property>
<name>v$session.program</name>
<sys-prop-value>WebLogic ${servername} Partition ${partition}</sys-prop-value>
</property>
</properties>

この例の説明:

- userは、-Duser=valueの値に設定されます

- v$sessionの値は、表3-1の説明どおりに設定されます
たとえば、myserverで実行されているv$session.programは、WebLogic myserver Partition DOMAINに設定されます

各値には、次の長さ制限があることに注意してください。

- osuser - 30

- process - 24

- machine - 64

- terminal - 30

- program - 48

接続ベースの暗号化されたプロパティの有効化

WebLogic JDBCデータ・ソースは、暗号化された値を使用したドライバ・プロパティの設定をサポートしています。接続ベースの暗号化されたプロパティを構成するには、WebLogic Server管理コンソールを使用して、データ・ソース構成のEncrypted Properties属性を編集します。詳細は、「暗号化された接続プロパティの使用」を参照してください。

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

WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、WebLogic Server管理コンソールの「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()

詳細な接続プロパティ

次の各項では、詳細な接続プロパティのうち重要なプロパティについて重点的に説明します。

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

- エディションベースの再定義の使用

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

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

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

エラー・コード

説明

3113

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

3114

Oracleに接続されていません

1033

Oracleの初期化またはシャットダウン中です

1034

Oracleは使用できません

1089

即時シャットダウン処理中 - 操作はできません

1090

シャットダウン処理中 - 接続はできません

17002

I/O例外

DB2の場合は、次の致命的エラー・コードは事前定義されています: -4498、-4499、-1776、-30108、-30081、-30080、-6036、-1229、-1224、-1035、-1034、-1015、-924、-923、-906、-518、-514、58004。

Informixの場合、次の致命的エラー・コードは事前定義されています: -79735、-79716、-43207、-27002、-25580、-4499、-908、-710、43012。

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

エディションベースの再定義の使用

エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。これにより、データのアップグレード前とアップグレード後のビューが同時に存在できるため、ホット・アップグレード機能が実現します。その後、特定のセッションに使用するビューを指定できます。

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

- 『Oracle Database開発ガイド』のエディションベースの再定義の使用に関する項を参照してください

- ホワイト・ペーパー『エディションベースの再定義』(http://www.oracle.com/technetwork/database/features/availability/edition-based-redefinition-1-133045.pdf)

JDBC接続でのEBRの使用

JDBC接続でEBRを使用する場合、次の2つのアプローチがあります。

- データベース・サービスを使用してデータベースに接続し、そのサービスで最初のセッション・エディションが指定された場合、そのサービスの最初のセッション・エディションが接続の最初のセッション・エディションになります。このアプローチは、接続のオーバーヘッドが最小限になるため推奨されます。
データベース・サービスの作成または変更時に、その最初のセッション・エディションを指定できます。データベース・サービスを作成または変更にするには、srvctl add serviceまたはsrvctl modify serviceコマンドを使用することをお薦めします。サービスのデフォルトの最初のセッション・エディションを指定するには、-editionオプションを使用します。

別の方法として、DBMS_SERVICE.CREATE_SERVICEまたはDBMS_SERVICE.MODIFY_SERVICEプロシージャを使用してデータベース・サービスを作成または変更し、EDITION属性でサービスのデフォルトの最初のセッション・エディションを指定することもできます。

- SQL文のALTER SESSION SET EDITIONを使用して、データベースに接続した後にセッション・エディションを変更します。セッション・エディションは、USE権限のある任意のエディションに変更することができます。ただし、エディションを変更すると、場合によってはセッションおよびデータベース・サーバーの状態の相当量を再生成する必要があります。セッションでエディションを変更するときに、DBMS_SESSION.RESET_PACKAGEを使用してこの状態の一部をクリーンアップすることをお薦めします。

エディションベースの再定義を使用する場合、新しいWebLogic Serverの機能は何も必要ありません。

EBRを使用するには、現在の環境が、以前のEDITIONを参照するデータ・ソースを持つ以前のバージョンのアプリケーションと、新しいEDITIONを参照するデータ・ソースを持つ新しいバージョンのアプリケーションで構成されている必要があります。WebLogic Serverアプリケーションの複数のバージョンを参照する場合、本番再デプロイメント機能でWebLogic Serverのバージョニングされたアプリケーションを使用する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用のアプリケーションの開発に関する項を参照してください。Oracle Database EBRとWebLogic Serverのバージョニングされたアプリケーションを組み合せることで、各機能を単独で使用するより全体の機能性が向上し、停止時間なしでアプリケーションをアップグレードできます。

バージョンを切り替えることができるように、最初にバージョニングされたデータベースとバージョニングされたアプリケーションを組み合せて実行する必要があります。WebLogic Serverアプリケーションをバージョニングするには、単純にMANIFEST.MFファイルにWeblogic-Application-Versionプロパティを追加します(これはデプロイメント時に指定することもできます)。

エディションを使用するためのWebLogicデータ・ソースの構成

次のリストでは、Oracle Databaseエディションを使用するためにWebLogicデータ・ソースを構成できる様々な方法について説明します。

- 単一エディションを使用するパッケージ化されたデータ・ソース - データ・ソースを構成する場合の推奨方法は、すべてが自己包含型となるようにアプリケーションEARまたはWARファイルに格納されたパッケージ化データ・ソース・ディスクリプタを使用することです。これを行うことで、各データ・ソースで同じ名前を使用でき、エディションに基づいて変数名を使用するためにアプリケーションを変更する必要がなくなります。ディスクリプタのデータ・ソースURLは、適切なエディションに関連付けられたデータベース・サービスを参照する必要があります。なんらかの理由でデータベース・サービスのかわりにSIDを使用する場合(現在は非推奨)、別の方法として、データ・ソース・ディスクリプタの初期化SQLパラメータにSQL ALTER SESSION SET EDITION = nameを指定します。このSQL文は、データ・ソース・プールに新しい物理データベース接続が作成されるたびに実行されます。このアプローチでは、データ・ソースがデータベースの単一エディションと、そのエディションを使用するすべての接続を参照していることが前提です。
パッケージ化されたデータ・ソースを使用する場合、次の制限があることに注意してください。

- ロギング・ラスト・リソース(LLR)でパッケージ化されたデータ・ソースを使用することはできません。システム・リソースを使用する必要があります。

- バージョニングされたアプリケーションのglobal-transactions-protocolに対してEmulateTwoPhaseCommitを使用する場合、アプリケーション・スコープのパッケージ化されたデータ・ソースを使用することはできません。グローバル・スコープのデータ・ソースを使用する必要があります。

したがって、LoggingLastResourceまたはEmulateTwoPhaseCommitを使用する必要がある場合、このアプローチは使用できません。詳細は、「JDBCアプリケーション・モジュールの制限」を参照してください。

- 単一エディションを使用するシステム・リソース・データ・ソース - パッケージ化されたデータ・ソースのかわりにシステム・リソースを使用できます。この場合、各データ・ソースは、一意の名前およびJNDI名を持つ必要があります。アプリケーションは、実行時にその名前を柔軟に使用できる必要があります。たとえば、データ・ソースJNDI名をシステム・プロパティとして渡し、JNDIでデータ・ソースをルックアップするコードでその値を使用できます。
データ・ソースごとに1つのエディションを使用する場合のデメリットは、それがパッケージ化されたものでもシステム・リソースでも、より多くのデータベース接続が必要になることです。単一エディション・アプローチは、古いエディションと新しいエディションの実行期間が比較的短い場合に有効です。多くのデータ・ソースまたは接続(あるいはその両方)を使用するアプリケーションでは、これは実行可能なアプローチではありません。

- 複数エディションを使用するシステム・リソース・データ・ソース - 代替方法として、複数のエディションを参照するデータ・ソースを使用します。推奨構成では、引き続き単一のエディションに関連付けられたデータベース・サービスを使用します。ただし、接続は、接続の存続期間中に様々なエディションに再度関連付けられます。

- 予約ごとのエディションの設定による複数エディション - アプリケーションで、接続を取得するたびにデータベース・エディションを設定できます。毎回このコールを行うことに関連して多少のオーバーヘッド(データベース・サーバーへのラウンドトリップとセッションの設定)が発生し、接続が予約される場所では常にアプリケーション・コードを変更する必要があります。リプレイ・ドライバを使用する場合、この初期化はConnectionInitializationCallbackで実行する必要があります。詳細は、「接続コールバックの使用方法」を参照してください。
新しいエディションへの移行が行われる短い期間を対象に最適化するのではなく、通常の使用例を対象に最適化することが重要です。このアプローチでは、必要なエディション上にすべての接続が存在する通常の状況を対象に最適化されません。

- 接続ラベリングを使用した複数エディション - エディションを接続に関連付け、適切なエディションで接続を予約するよう試みることができます。プロパティで接続にタグ付けする場合の推奨方法は、接続ラベリングを使用することです。次に、アプリケーションは、接続ラベリングに関連付けられた部分を実装する必要があります。

- 接続が予約される場合、コンテキストで必要なエディションを決定する必要があります。

- プロパティ(この場合はエディション)が一致しているかどうかを判別する照合メソッドが必要です。

- SQL ALTER SESSION SET EDITION = nameを使用して接続がまだ照合されていない場合、接続を照合するラベリング初期化メソッドが必要です。

特に既存の接続のリストを排他的にスキャンして一致を検出する場合、接続ラベリングに関連するオーバーヘッドが発生します。これに対して、通常の使用例では、すべての接続が現在のエディションに一致するため、一致を検出する必要はありません。エディション間でスラッシングが発生し、一致を検出するために(または一致がないことを確認するために)検索時間が長くかかる可能性があるのは、移行時のみです。

Oracleパラメータの構成

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

ONSクライアントの構成

ONSクライアントを構成して、汎用データ・ソースをAGLデータ・ソースに変更します。構成情報と追加の環境要件の詳細は、第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

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

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

Oracle RACの停止に対する汎用データ・ソースの処理

複数のHOSTまたはOracle RACでのURLのSCANアドレスであるHOSTを使用して、汎用データ・ソースを使用できます。ただし、これらのURLパターンを使用すると、Oracle RACの停止に対するトランザクション処理、モニタリングおよび正常な処理を複雑化させる制限が発生します。

注意:
Oracle RACデータベースでは、マルチ・データ・ソースまたはActive GridLinkを使用することをお薦めします。第6章「Active GridLinkデータ・ソースの使用方法」または付録C「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

次の制限事項は、WebLogic Serverインスタンスが、プール内の接続に関連付けられたOracle RACインスタンスを認識しないために発生するものです。

- 汎用データ・ソースでは、マルチ・データ・ソースまたはActive GridLinkデータ・ソースが提供するプール内の単一インスタンスを無効化できません。Oracle RACインスタンスのいずれかが(計画的に、または計画外で)停止した場合、データ・ソースは停止したインスタンスに対して、プール内のすべての接続を個別に無効化しながらテストします。オーバーヘッドやアプリケーションの遅延が増大するだけでなく、プールでは複数の失敗が確認され、プール全体が無効化されることになります。プールが無効化されることを回避するには、「フラッシュされるまでのテストの失敗数」の値を0に設定します。詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項のページ

- Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項。

- この構成には、JTAまたはグローバル・トランザクションは使用できません。WebLogic ServerはOracle RACインスタンスを認識しないので、トランザクション・アフィニティを保証できません。トランザクションが複数のサーバーにまたがる場合や、トランザクションを完了させるのに別の接続が使用されるような失敗が発生した場合、これは問題になります。トランザクションを完了させるために必要な追加の接続が同じOracle RACインスタンス内に存在しないために、トランザクション処理が失敗する可能性があります。

- Oracle RACインスタンスに基づいて接続を監視することはできません。

ドライバ・レベル・フェイルオーバーの汎用データ・ソースの処理

ドライバ・レベル・フェイルオーバーを使用する汎用データ・ソースのかわりに、マルチ・データ・ソースまたはActive GridLinkデータ・ソースを使用することをお薦めします。

いくつかのデータベース・ドライバでは、URLで複数のデータベース・インスタンスを定義して、あるデータベースから次のデータベースにフェイルオーバーを行う機能がサポートされます。ドライバ・レベル・フェイルオーバーで汎用データ・ソースを使用することもできますが、いくつかの制限があります。これらの制限によって、データベース・インスタンスの停止に対するトランザクション処理、モニタリングおよび正常な処理が複雑化します。

次の制限事項は、WebLogic Serverインスタンスが、プール内の接続に関連付けられたデータベース・インスタンスを認識しないために発生するものです。

- 汎用データ・ソースでは、マルチ・データ・ソースが提供するプール内の単一インスタンスを無効化できません。データベース・インスタンスのいずれかが(計画的に、または計画外で)停止した場合、データ・ソースは停止したインスタンスに対して、プール内のすべての接続を個別に無効化しながらテストします。オーバーヘッドやアプリケーションの遅延が増大するだけでなく、プールでは複数の失敗が確認され、プール全体が無効化されることになります。プールが無効化されることを回避するには、「フラッシュされるまでのテストの失敗数」の値を0に設定します。詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項のページ

- Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項

- この構成には、JTAまたはグローバル・トランザクションは使用できません。WebLogic Serverはデータベース・インスタンスを認識しないので、トランザクション・アフィニティを保証できません。トランザクションが複数のサーバーにまたがる場合や、トランザクションを完了させるのに別の接続が使用されるような失敗が発生した場合、これは問題になります。トランザクションを完了させるために必要な追加の接続が同じデータベース・インスタンス内に存在しないために、トランザクション処理が失敗する可能性があります。

- データベース・インスタンスに基づいて接続を監視することはできません。

4 デフォルト・データ・ソースの使用

この章では、デフォルト・データ・ソースの使用方法について説明します。

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

- デフォルト・データ・ソースとは

- カスタム・デフォルト・データ・ソースの定義

- デフォルト・データ・ソースを使用する場合の互換性の制限

デフォルト・データ・ソースとは

Oracleでは、Java EE 7準拠ランタイムで必要なデフォルト・データ・ソースを提供しています。この事前構成されたデータ・ソースは、WebLogic ServerとともにインストールされたDerbyデータベースにアクセスするためにアプリケーションで使用できます。これには次のJNDI名でアクセスできます。

java:comp/DefaultDataSource

上記のメッセージは下のメッセージと同じです。

@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;

DataSourceリソース参照は、Resource注釈のlookup要素またはresource-refデプロイメント・ディスクリプタ要素のlookup-name要素を使用してデフォルト・データ・ソースに明示的にバインドできます。

注意:
Derbyデータベースは、デフォルトではstartWebLogicコマンドによって起動されます。WebLogic Serverインスタンスの起動および停止の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。

デフォルト・データ・ソースの特性

デフォルト・データ・ソースには、次の特性があります。

- デプロイされているコンポーネントごとに使用できる必要があります。

- デプロイ済コンポーネントでのみアクセス可能で、システム・リソースまたはスタンドアロン・デプロイメントであるデータ・ソースではアクセスできません。

- 参照が行われた後にのみコンソールに表示されます。

- 他のJava EEデプロイメントのように、コンポーネントごとにデプロイメントとして表示されます。

- 構成できません。

- 関連付けられたアプリケーションのライフサイクルを持ちます

WebLogic Serverのデフォルト・データ・ソースの定義

次の表では、WebLogic Serverのデフォルト・データ・ソースの定義を規定する構成設定を提供します。

表4-1 デフォルト・データ・ソースの構成

属性

値

名前

java:comp/DefaultDataSource

初期容量

0

最小容量

0

最大容量

15

クラス名

org.apache.derby.jdbc.ClientDataSource

ポート

1527

ホスト

localhost

データベース名

DefaultDataSource

ユーザー

なし

パスワード

なし

トランザクション

false

MaxStatements

0

MaxIdleTimeout

未設定

カスタム・デフォルト・データ・ソースの定義

事前構成されたデフォルト・データ・ソースを使用することも、カスタム・デフォルト・データ・ソースを実装することもできます。カスタム・デフォルト・データ・ソースを実装するには、次のいずれかの方法を使用します。

- java:comp/DefaultDataSourceにバインドされたカスタム・デフォルト・データ・ソース・ディスクリプタを定義します(「カスタム・デフォルト・データ・ソース・ディスクリプタの作成」を参照)。

- 別のJNDI名を指し示すようにデフォルト・データ・ソースをオーバーライドします(「デフォルト・データ・ソースのオーバーライド」を参照)。

コンポーネントのデプロイ後、コンポーネントでjava:comp/DefaultDataSourceを使用できない場合、WebLogic Serverの事前構成済デフォルト・データ・ソースをコンポーネントで使用できます。ただし、startWebLogic.shスクリプトを実行する前に、DERBY_FLAG=falseを設定してDerbyデータベースを無効化した場合、WebLogic Serverの事前構成済デフォルト・データ・ソースは使用できません。

カスタム・デフォルト・データ・ソース・ディスクリプタの作成

事前構成済デフォルト・データ・ソースのかわりとなるjava:comp/DefaultDataSourceにバインドされたデータ・ソース・ディスクリプタを構成できます。例として、次にEARアプリケーションのJava EE 6の注釈を示します。

@Stateless(mappedName="DSBean")
@DataSourceDefinition(name="java:comp/DefaultDataSource",
className="oracle.jdbc.OracleDriver",
portNumber=1521,
serverName="myServer",
databaseName="myDB",
user="a username",
password="a password",
transactional=false
)
public class DSBean implements DSInterface
. . .

デフォルト・データ・ソースのオーバーライド

別の既存のデータ・ソースを指し示すようにサーバーまたはサーバー・テンプレートの構成でデフォルト・データ・ソース属性のJNDI名を更新して、WebLogic Serverで提供される事前構成済デフォルト・データ・ソースをオーバーライドできます。『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の次のトピックを参照してください。

- サーバーの一般構成の定義に関する項

- サーバー・テンプレートの一般設定の構成に関する項

パーティション化された環境では、DataSourcePartitionMBeanを使用してこの属性をオーバーライドできます。『WebLogic Server MTの使用』のJDBCの構成に関する項を参照してください。

デフォルト・データ・ソースを使用する場合の互換性の制限

Weblogic Server 12.2.1より前のリリースでは、WebLogic Serverは、res-refの名前を使用してJNDIのデータ・ソースをルックアップすることで、未解決のデータ・ソースres-ref参照を自動的に解決しようと試みます。この動作は、Java EE 7より前では定義されていません。このWebLogic Serverリリースでは、Java EE 7の定義に従ってデフォルト・データ・ソースを使用します。

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

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

マルチ・データ・ソースとは、汎用データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされる汎用データ・ソースのグループ周辺を抽象化したものです。アプリケーションは、汎用データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用する汎用データ・ソースが決定されます。

注意:
Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください。

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

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

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

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

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

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

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

- マルチ・データ・ソースでの計画データベース・メンテナンス

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

マルチ・データ・ソースは、汎用データ・ソースのプールと考えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用するのが最適です。

マルチ・データ・ソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。これによって、Oracle RACなどを使用する環境で、再デプロイすることなく、データベース・ノードと対応する汎用データ・ソースを追加および削除でき、次のことができます。

- スループットに応じてOracle RACクラスタを拡大および縮小します。「データベース・ノードの追加」を参照してください。

- メンテナンスのためにOracle RACノードを停止します。「データベース・ノードの削除」を参照してください。

付録C「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 Server管理コンソールまたはWebLogic Scripting Toolでマルチ・データ・ソースを作成して、その後汎用データ・ソースをマルチ・データ・ソースに割り当てます。

マルチ・データ・ソースの作成方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソースの構成に関する項を参照してください。

マルチ・データ・ソースの構成時に作成される構成ファイルについては、「WebLogic Serverにおける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は、手動で無効化した汎用データ・ソースに対して、テストも自動的な再有効化も行いません。テストは自動的に無効化された汎用データ・ソースに対してのみ行われます。

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

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

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

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

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

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

WebLogic Serverには、フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースが、どのタイミングでマルチ・データ・ソース内の、あるJDBC汎用データ・ソースからの接続リクエストを、リスト内の次の汎用データ・ソースにフェイルオーバーするかを制御する、コールバック・ハンドラを登録できます。

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

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

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

マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、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などの絶対名を指定する必要があります。WebLogic Server管理コンソールを使用してフェイルオーバーのコールバック・ハンドラを設定できます(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データ・ソースのターゲット指定とデプロイに関する項を参照してください。

マルチ・データ・ソースでの計画データベース・メンテナンス

次の項では、WebLogicマルチ・データ・ソースによるアクセス時に、データベース・サーバーでサービスを中断せずに計画メンテナンスを処理する方法について説明します。

サービスの中断を回避するには、ローリング方式でデータベースを更新できるように、複数のデータベース・インスタンスが使用できる必要があります。Oracle RACクラスタおよびOracle GoldenGate (またはそれらの製品の組合せ)を使用すると、この目的を達成できます。(Oracle DataGuardは、サービスを中断しない計画メンテナンスに使用することはできません。)各データベース・インスタンスは、マルチ・データ・ソースの汎用データ・ソース・メンバーとして構成されます。このアプローチでは、アプリケーションが定期的にプールに接続を返すことが前提です。

プロセスの概要

次の手順では、計画メンテナンス・プロセスの概要を示します。

1. 中間層システムで、メンテナンスで停止されるOracle RACインスタンスに関連付けられたすべてのメンバー・データ・ソースを停止します。他のメンバーのために接続を予約できるように、各マルチ・データ・ソース・リストのデータ・ソースをすべて停止しないことが重要です。データ・ソースの停止が完了するのを待機します。詳細は、次を参照してください。

- データ・ソースの停止

- Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanの停止操作に関する項。

2. 必要に応じて、WebLogicデータ・ソースに関連付けられていないデータベース側の残りの接続を削減できます。この場合、Oracle Databaseサーバーでは、メンテナンスで停止されるインスタンスのアプリケーション・サービスの停止(または再配置)、リスナーの停止、データベース・インスタンスのサービスに対するトランザクション切断の発行などを行います。

3. 適切なツールを使用してデータベース・インスタンスを停止します。

4. 計画メンテナンスを実行します。

5. 適切なツールを使用してデータベース・インスタンスを再起動します。

6. データベース・インスタンスでアプリケーションを使用する準備ができたら、サービスを起動します。

7. 中間層システムで、メンバー・データ・ソースを起動します。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanの起動操作に関する項を参照してください。

データ・ソースの停止

データ・ソースを停止する場合、まずデータ・ソースを中断してから、接続を含む関連リソースを解放します。マルチ・データ・ソースのメンバー・データ・ソースが中断としてマークされると、マルチ・データ・ソースは、中断したプールから接続を取得しなくなります。かわりに、接続を予約するため、次のメンバー・データ・ソースに移動します。同時にマルチ・データ・ソース・リストのメンバー・データ・ソースをすべて停止しないことが重要です。すべてのメンバーが停止または失敗した場合、マルチ・データ・ソースへのアクセスは失敗し、アプリケーションは障害を認識します。

停止プロセスの最初の手順としてデータ・ソースを正常に中断すると、次の処理が発生します。

- データ・ソースは、操作の開始時に即座に中断としてマークされ、そのデータ・ソースでそれ以上接続は作成されなくなります。

- アイドル(非予約)接続は、無効としてマークされます。(それらは閉じられません。)

- 中断操作のタイムアウト期間の経過後、プールに残っているすべての接続は中断としてマークされ、接続に対する任意の操作でデータ・ソースが中断していることを示す次の例外がスローされます。
java.sql.SQLRecoverableException: Connection has been administratively disabled. Try later.

- これらの接続は、プールに残され、閉じられません。それらが正常かどうかは、データ・ソースが再開されるまでわかりません。この場合、データベースが停止され、データ・ソースが再開された場合、プールの接続が正常ではないことがわかります。かわりに、無効な接続をすべて閉じるデータ・ソースの停止を実行します。
デフォルトでは、タイムアウト期間は60秒です。このタイムアウト期間の値は、Inactive Connection Timeout Secondsを0 (ゼロ)以外の値に構成(または動的に設定)することで変更できます。非アクティブ・タイムアウト期間に上限はありません。ただし、実際の処理では、使用中(予約済)のリソースが10分の1秒ごとにチェックされるため、タイムアウト値が2時間に設定され、すべての予約済リソースが1秒後に解放されると、停止は1秒後に完了します。

この停止操作は、同期的に実行されるため、使用できる非同期バージョンのMBean操作はありません。

これは、ロード・バランシングまたはフェイルオーバーによって構成されたマルチ・データ・ソースでも使用できます。

WLSTの例

次のWLSTのスクリプト例は、中断タイムアウト期間を延長してから、ランタイムMBeanを使用してデータ・ソースを停止するように構成を編集する方法を示しています。このスクリプトは、すべてのWebLogic Serverサーバーおよびデータ・ソースの既存のフレームワークに統合する必要があります。

java weblogic.WLST myscript2.py
import sys, socket, os
hostname = socket.gethostname()
datasource='myds'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
# Edit the configuration to set the suspend timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource + '/JDBCConnectionPoolParams/' + datasource )
cmo.setInactiveConnectionTimeoutSeconds(21600) # set the suspend timeout
save()
activate()
# Shutdown the data source
serverRuntime()
cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' + datasource )
#cmo.start()
cmo.shutdown()
exit()

重要な考慮事項

次のリストで、計画メンテナンスの実行時に考慮する必要のある問題について説明します。

- マルチ・データ・ソースでデータベース・サービスを使用している場合、マルチ・データ・ソースを中断または停止する前にデータベース・サービスを停止または再配置することはできません。それを行うと、マルチ・データ・ソースは、現在存在しないサービスへの接続を作成する可能性があり、データベースが停止している場合と同様の応答をしてすべての接続を強制終了し、正常な停止が行われません。マルチ・データ・ソースを中断することで、関連するインスタンスで新しい接続が作成されないことが保証されるため、サービスを停止する必要はありません。(マルチ・データ・ソースは、このインスタンスでのみ接続を作成することに注意してください。再配置されても、別のインスタンスでは接続を作成しません。)また、マルチ・データ・ソースを中断することで、すべての接続に対する操作が停止されるため、マルチ・データ・ソース・プールに残っているどのセッションでも後続の処理は発生しません(トランザクションは完了しません)。

- マルチ・データ・ソース・アルゴリズムによって強制適用されるXAアフィニティに関する問題が発生することがあります。Oracle RACインスタンスでXAブランチが作成されると、同じインスタンスですべての追加ブランチが作成されます。Oracle RACではインスタンス間のXAがサポートされますが、準備フェーズの前にアプリケーションが直面する重要な制限があり、マルチ・データ・ソースによって、すべての操作が同じインスタンス上で発生するように強制されます。正常な中断操作が開始すると同時に、メンバー・データ・ソースは中断としてマークされ、そこでそれ以上接続は割り当てられなくなります。グローバル・トランザクションを使用するアプリケーションが、中断しているデータ・ソースで別のブランチを開始しようとすると、接続を取得できずにトランザクションは失敗します。複数のWebLogic ServerにまたがるXAトランザクションの場合、中断は正常に行われません。この問題は、2フェーズ・コミットのエミュレートまたは1フェーズ・コミット(すべての作業に単一の接続を使用)およびロギング・ラスト・リソース(LLR)には適用されません。

- なんらかの理由で、その時点ですべての接続が無効化されるデータ・ソースの中断とリソースの解放を分離する必要がある場合、中断の後にforceShutdownを実行できます。強制停止を使用して、2回目の待機期間を回避する必要があります。このプロセスの使用はお薦めできません。

- データベースの停止時にデータ・ソースの正常な停止を行うには、データ・ソースを含める必要があります。データ・ソースを停止してからデータベースを停止するこのプロセスでは、中間層とデータベース・サーバー処理の間で調整が必要です。マルチ・データ・ソースのかわりにActive GridLinkを使用すると処理が簡略化されます。詳細は、第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

- Oracle Databaseを使用する場合、高可用性向けに構成できるように、データベースごとにアプリケーション・サービスを構成することをお薦めします。アプリケーション・サービスを使用することで、それを使用するためのデータ・ソースを起動せずに、単独でデータベースを起動できます。アプリケーション・サービスが明示的に起動されたら、管理者は、データ・ソースでデータベースを使用できるように設定できます。

6 Active GridLinkデータ・ソースの使用方法

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

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

- Active GridLinkデータ・ソースとは

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

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

- AGL接続プール機能の構成

- Oracleパラメータの構成

- WLSTを使用したONSクライアントの構成

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

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

- FAN通知を使用しないActive GridLinkデータ・ソースの使用方法

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

- AGLとマルチ・データ・ソースの比較

- マルチ・データ・ソースからActive GridLinkへの移行

- AGLデータ・ソースでのデータベース停止時間の管理

Active GridLinkデータ・ソースとは

単一のAGLデータ・ソースにより、WebLogic Serverと、1つ以上のOracle RACクラスタが含まれるOracle Databaseサービスとの間の接続を提供します。Oracle Databaseサービスとは、共通属性を持つワークロードのことです。このサービスにより、管理者は単一のエンティティとしてワークロードを管理できます。AGLデータ・ソースの数は、Oracle RACクラスタのノード数に合わせるのではなく、データベース内でのサービス数の増加に合わせてスケールします。複数クラスタの高可用性サポートには、Data Guard、GoldenGate、Global Database Serviceなどがあります。

注意:
Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください。

図6-1 Active GridLinkデータ・ソースの接続

AGLデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。

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

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

- GridLinkアフィニティ

- SCANアドレス

- Oracleウォレットを使用したONSリスナーとのセキュアな通信

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

AGLデータ・ソースは、高速接続フェイルオーバーを使用します。また、Oracle Notification Service (ONS)を使用したOracle RACイベントに応答します。これにより、AGLデータ・ソースの接続プールには確実に有効な接続(予約済の接続を含む)が格納されるようになり、接続のポーリングやテストの必要がなくなります。さらに、接続は使用可能になるときに、確実に新しいノード上に作成されるようになります。

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

AGLデータ・ソースでは、次の目的に高速接続フェイルオーバーを使用します。

- 高速な障害検出を提供する。

- 無効な接続を中断して、接続プールから削除する。

- Oracle RACノードの計画済停止と計画外停止に対して正常なシャットダウンを実行する。「計画停止の手順」および「計画外停止」を参照してください。

- ノードの追加や削除などのトポロジの変化に適応する。

- 実行時の作業リクエストをアクティブなすべてのOracle RACインスタンスに分散する(クラスタへの再参加を含む)。

注意:
AGLデータ・ソースは、非推奨のFastConnectionFailoverEnabled接続プロパティをサポートしていません。このプロパティを有効化したXA接続を作成しようとすると、java.sql.SQLException: Can not use getXAConnection() when connection caching is enabledという例外が発生します。これは、このプロパティに対するドライバの高速接続フェイルオーバーの実装がXA接続をサポートしていないためです。

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

AGLデータ・ソースでは、ロード・バランシングを使用できます。AGLデータ・ソースは、データベースが発行するOracle FANイベントに基づいて、ランタイム接続ロード・バランシング(RCLB)を使用し、Oracle RACの各インスタンスに接続を分散します。つまり、データベースのトポロジに関係なく、データベースがAGLデータ・ソースを通じて接続のロード・バランシングを駆動するため、データ・ソースの構成が簡略化され、パフォーマンスが向上します。

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

- バック・エンド・ノードの能力(CPU、可用性、応答時間など)に応じた作業分散の調整。

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

- 高いパフォーマンスおよびスケーラビリティに対応するプール済接続の管理。

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

FANが有効化されていない場合、AGLデータ・ソースはラウンドロビン・ロード・バランシング・アルゴリズムを使用して、各Oracle RACノードに接続を割り当てます。

注意:
各接続は、AGLデータ・ソースで一定期間ごとにシャットダウンされます。様々なOracle RACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシング率と一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。
この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティweblogic.jdbc.gravitationShrinkFrequencySecondsを使用します。値を0にすると、再バランシング処理が無効になります。

GridLinkアフィニティ

WebLogic Server GridLinkのアフィニティ・ポリシーは、Oracle RACクラスタの使用率を最大化して、アプリケーション・パフォーマンスを向上するためのものです。次の項を参照してください。

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

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

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

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

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

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

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

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

AGLデータ・ソースは、AffEnabled属性を使用することでOracle RACロード・バランシング・アドバイザ(LBA)をモニターして、Oracle RACクラスタのOracle RACアフィニティが有効化されているかどうかを判断します。最初の接続リクエストはランタイム接続ロード・バランシング(RCLB)を使用してロード・バランシングされ、アフィニティ・コンテキストが割り当てられます。それ以降のすべての接続リクエストは、セッションが終了するかトランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して、同一のOracle RACインスタンスにルーティングされます。アフィニティは、データベース名、サービス名およびインスタンス名に基づいています。デフォルトでは、AGLデータ・ソースのセッション・アフィニティ・ポリシーは常に有効化されていますが、Webセッションのセッション・アフィニティは次の場合にアクティブになります。

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

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

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

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

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

- XAトランザクションは、複数のインスタンスを対象にできません。

- XAトランザクション内の接続には、厳密なアフィニティが強制適用されます。適切なインスタンスに接続が作成できない場合は、例外がスローされます。

図6-5 XAアフィニティ

SCANアドレス

複数のノード間で接続をロード・バランシングするために、次の2つのオプションがあります。

- LOAD_BALANCE=onにして、複数の非SCANアドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))

- 1つのOracle単一クライアント・アクセス名(SCAN)アドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scanname)(PORT=scanport))(CONNECT_DATA=(SERVICE_NAME=myservice)))

SCANアドレスは、WebLogicコンソールで、TNSリスナーとONSリスナーの両方のホストを指定するために使用できます。SCANアドレスを含むAGLデータ・ソースは、Oracle RACのノードが追加または削除された場合でも変更する必要がないため、複数の非SCANアドレスを使用するよりもお薦めできます。ただし、SCANアドレスは、このアドレスを使用するようにデータベースを構成している場合にのみ使用できます。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。

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

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

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

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

SCANアドレスの使用方法の詳細は、次を参照してください。

- 『Real Application Clusters管理およびデプロイメント・ガイド』の動的データベース・サービスでの自動ワークロード管理の概要に関する項。

- ホワイト・ペーパー『Oracle Single Client Access Name (SCAN)』(http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdf)

Oracleウォレットを使用したONSリスナーとのセキュアな通信

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

Active Data Guardのサポート

Active GridLinkは、Oracle Active Data Guardとも連携します。単一インスタンス(Oracle Restartを使用)とOracle RACデータベースの両方に対して、Oracle Clusterwareがインストールされ、プライマリ・サイトおよびスタンバイ・サイトでアクティブになっている必要があります。Oracle Data GuardブローカはOracle Clusterwareと連動して、Data Guardフェイルオーバーの発生後、ロールベースのサービスを新規プライマリ・データベースへ適切にフェイルオーバーします。Cluster Ready Services (CRS)は、ロール変更が発生するとFANイベントを送信します。

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

WebLogicドメイン内にAGLデータ・ソースを作成する場合は、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用します。

内容は次のとおりです。

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

- サンプルのWLSTスクリプトEXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py。EXAMPLES_HOMEは、WebLogic Serverのコード・サンプルが構成されるディレクトリを表しています。このサンプルでは、汎用データ・ソースが作成されます。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

次の各項では、WebLogic Server管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。

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

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

- 接続プロパティの構成

- 接続のテスト

- ONSクライアント構成

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

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

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

「JDBCデータ・ソースのプロパティ」には、データ・ソースのアイデンティティを決定するオプションと、データベース接続でデータを処理する方法を決定するオプションがあります。

データ・ソース名

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

データ・ソース・スコープ

使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。

JNDI名

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

ドライバの選択

アプリケーション・コンティニュイティのリプレイ・ドライバ(XAまたは非XA Thinドライバ)を選択します。アプリケーション・コンティニュイティの詳細は、「アプリケーション・コンティニュイティ」を参照してください。

注意:
現時点では、リプレイ・ドライバはXAトランザクションをサポートしていません。

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

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

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

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

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

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

- 2フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。「2フェーズ・コミットのエミュレート・トランザクション・オプションの理解」を参照してください。

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

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

接続プロパティの構成

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

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

- データベース・ドメインを使用するときには、サービス名にドメイン名の接尾辞を付加する必要があります。たとえば、データベース名がdb.country.myCorp.comで、サービス名がmyserviceのときには、myservice.db.country.myCorp.comと入力する必要があります。

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

- 接続プロパティの入力

- 完全なURLの入力

接続プロパティの入力

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

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

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

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

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

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

コンソールにより、完全なJDBC URLが自動的に生成されます。次に例を示します。

jdbc:oracle:thin:@( DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myService)))

完全なURLの入力

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

- 「完全なJDBC URL」に、JDBC URLを入力します。次に例を示します。
jdbc:oracle:thin:@( DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1521))) (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を避けます。

- Oracle 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ノード・リストを構成する場合、値を指定せず、自動ONSによるONS構成の実行を許可することをお薦めします。ただし、Oracleウォレットおよびパスワードを指定する必要がある場合や、ONSトポロジを明示的に指定する場合など、一定の場合には明示的にONS構成を設定する必要があります。

- FANイベントの有効化

- ONSホストおよびポートの構成

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

WLSTを使用してONSクライアントを構成することもできます。例については、「WLSTを使用したONSクライアントの構成」を参照してください。

管理コンソールのデータ・ソースのサマリー・ページでONSクライアントを構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのONSクライアント・パラメータの構成に関する項を参照してください。

注意:
WebLogic Serverリリース12.1.2以降でOracle 12cデータベースを使用している場合は、AGLデータ・ソース構成の一部としてONSリスナーのリストを指定する必要はありません。ONSリストは、データベースからドライバに自動的に提供されます。この情報は、関連するランタイムMBeanで確認できます。ただし、関連するONSのOracleウォレットをSSLで使用する場合は、ONSリスナーのリストを指定する必要があります。

FANイベントの有効化

Oracle Fast Application Notification (FAN)イベントにサブスクライブして処理できるようにデータ・ソースを構成するには、「FANの有効化」を選択します。

ONSホストおよびポートの構成

OnsNodeList値を構成する場合、単一ノード・リストまたはプロパティ・ノード・リストという2つの方法を使用できます。どちらも使用できますが、両方は使用できません。WebLogic ServerのOnsNodeListに等号(=)が含まれる場合、プロパティ・ノード・リストであると仮定されます。

どちらのタイプのノード・リストでも、FAN通知にアクセスするため、ホスト名のかわりに単一クライアント・アクセス名(SCAN)アドレスを使用できます。SCANアドレスの詳細は、「SCANアドレス」を参照してください。

次のものを使用してOnsNodeList値を構成するには:

- 単一ノード・リスト - ONSベースのFANイベントを受信するためのONSデーモン・リスニング・アドレスおよびポートのカンマ区切りのリストを指定します。たとえば、rac1:6200,rac2:6200となります。AGLデータ・ソースを作成するときに管理コンソールの「ONSホストとポート」フィールドに単一ノード・リストを入力できます。

- プロパティ・ノード・リスト - 各レコードがキー=値のペアで構成された複数のレコードを含む文字列を指定し、改行('\n')文字で終了します。たとえば、nodes.1=rac1:6200,rac2:6200となります。データ・ソースを作成するときに「ONSホストとポート」フィールドにプロパティ・ノード・リストを入力することはできません。かわりに、このフィールドは空白のままにする必要があります。データ・ソースの作成が終了した後に、そのデータ・ソースの設定ページにある「構成: ONS」タブでプロパティ・ノード・リストを入力できます。
プロパティ・ノード・リストには次のキーを指定できます。

- nodes.id - リモートONSサーバーの一意のトポロジを表すノードのリスト。idは、ノード・リストの一意の識別子を指定します。重複するエントリは無視されます。いずれかのリストで構成されているノードのリストに、同じクライアントの他のリストで構成されているノードを含めることはできません(これを行うと、重複する通知が送信および配信されます)。リストの書式は、コロンで区切られたONSデーモン・リスニング・アドレスとポートのペアのカンマ区切りのリストです。

- maxconnections.id - ONSサーバーで管理されている同時接続の最大数を指定します。idは、このパラメータが適用されるノード・リストを指定します。デフォルトは3です。

- active.id trueの場合、リストはアクティブになり、構成された数のONSサーバーに対して接続が自動的に確立されます。falseの場合、リストは非アクティブになり、アクティブなリストの接続を1つも確立できない場合にのみ、フェイルオーバー・リストとして使用されます。非アクティブなリストは、一度に1つのアクティブなリストのフェイルオーバーとしてのみ機能でき、アクティブなリストで単一の接続が再確立されると、フェイルオーバー・リストは非アクティブに戻ります。リストのフェイルオーバー後にクライアントがパブリッシュした通知のみがフェイルオーバー・リストに送信されることに注意してください。idは、このパラメータが適用されるノード・リストを指定します。デフォルトはtrueです。

- remotetimeout - 各リモート・サーバーに対する接続のタイムアウト期間(ミリ秒)。リモート・サーバーがこのタイムアウト期間内に応答しない場合、接続は閉じられます。デフォルト値は30秒です。

注意:
文字列ではwalletfileとwalletpasswordがサポートされますが、WebLogic Serverでは、これらの値について、個別の構成要素があります(OnsWalletFileとOnsWalletPasswordEncrypted)。

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

SSLを使用してONSデーモンと通信するには、Oracleウォレット・ファイルを使用する必要があります。

ウォレット・ファイルを使用するには、「ONSウォレット・ファイル・ディレクトリ」フィールドに、SSL証明書を格納するOracleウォレット・ファイルのディレクトリを入力します。必要に応じて、「ONSウォレット・パスワード」フィールドにウォレット・パスワードを入力します。

既存のActive GridLinkデータ・ソースを更新する場合、ウォレット・ディレクトリおよびパスワードを含めるようにAGL構成を更新する必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracleウォレットを使用したセキュアなONSリスナーに関する項を参照してください。

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

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

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

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

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

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

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

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.country.myCorp.com)(PORT=1522))
(ADDRESS = (PROTOCOL = SDP)(HOST =
sclcgdb02-bvip.country.myCorp.com)(PORT=1522))
)
)

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

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

AGL接続プール機能の構成

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

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

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

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

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

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

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

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

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

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

WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、WebLogic Server管理コンソールの「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()

Oracleパラメータの構成

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

WLSTを使用したONSクライアントの構成

WLSTを使用してONSクライアントを構成することもできます。次のコード部分は、Active GridLinkデータ・ソースのOracleパラメータを設定する場合の例です。

cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCOracleParams/' + dsName)
cmo.setFanEnabled(true)
cmo.setOnsNodeList('nodes.1=rac1:6200,rac2:6200\nmaxconnections.1=3\n')

ONSクライアントの構成の詳細は、「ONSクライアント構成」を参照してください。

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

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

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

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

- 実行時統計の表示

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

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

実行時統計の表示

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

JDBCOracleDataSourceRuntimeMBean

JDBCOracleDataSourceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。JDBCOracleDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、AGLデータ・ソース内でアクティブな各ノードに対する子のJDBCOracleDataSourceInstanceRuntimeMBeanも保持しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceRuntimeMBeanに関する項を参照してください。

JDBCOracleDataSourceInstanceRuntimeMBean

JDBCOracleDataSourceInstanceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。アクティブなONSリスナーごとに1つのインスタンスが存在します。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを検出する唯一の方法になります。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceInstanceRuntimeMBeanに関する項を参照してください。

ONSDaemonRuntimeMBean

ONSDaemonRuntimeMBeanには、AGLデータ・ソースに関連付けられたONSクライアント構成をモニタリングするメソッドがあります。

次に示すのは、ONS接続をテストするためのWLSTスクリプトです。この例では、Active GridLinkデータ・ソースの名前はgldsで、ターゲットはmyserverになっています。

connect(<wluser>, <wlpassword>, 't3://localhost:7001')
serverRuntime()
cd('JDBCServiceRuntime')
cd('myserver')
cd('JDBCDataSourceRuntimeMBeans')
cd('glds')
cd('ONSClientRuntime')
cd('glds')
cd('ONSDaemonRuntimes')
cd('glds_0')
cmo.ping()

詳細は、Oracle WebLogic Server MBeanリファレンスのONSDaemonRuntimeMBeanに関する項を参照してください。

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

WebLogic Serverのデバッグ機能を有効化すると、アプリケーションで発生した特定の問題を追跡できるようになります。

JDBCのデバッグ範囲

JDBCの登録済デバッグ範囲は、次のとおりです。

- DebugJDBCRAC - AGLデータ・ソースのライフサイクル、UCPコールバックおよび接続情報に関する情報を出力します。

- DebugJDBCONS - ONSクライアント情報(LBAイベント本体を含む)をトレースします。アクティブなONSリスナーごとに、1つのトレースを使用できます。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを確認する唯一の方法になります。

- DebugJDBCReplay - アプリケーション・コンティニュイティのリプレイ情報をトレースします。

- DebugJDBCUCP - UCPドライバからの下位レベルOracle RAC情報をトレースします。

UCP JDKロギング

UCP JDKロギングを有効化するには、『Oracle Universal Connection Pool for JDBC開発者ガイド』のUCPでのロギングの設定に関する項の手順に従ってください。

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

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

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

これらの値の設定は、静的であり、サーバー起動時にのみ使用されます。

ONSデバッグを有効化するには、Java Util Loggingを構成する必要があります。これを行うには、コマンド行で次のプロパティを設定します。

-Djava.util.logging.config.file=configfile
-Doracle.ons.debug=true

このコマンドで、configfileは、ログ出力のフォーマットとロギング・レベルを制御するために標準のJDKロギングで使用される構成プロパティ・ファイル・プロパティのパスとファイル名です。configfileに次の行を含める必要があります。

oracle.ons.level=FINEST

詳細は、Java Platform Standard Edition 7 API仕様のjava.util.loggingに関する項を参照してください。

FAN通知を使用しないActive GridLinkデータ・ソースの使用方法

AGLデータ・ソースは、高速アプリケーション通知(FAN)を有効化することなく構成して使用することもできます(ただし、これは推奨されていません)。この構成では、2回連続して接続テストに失敗すると、Oracle RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。TestConnectionsOnReserveを有効化することをお薦めします。構成済のファイアウォールが、このプロトコルを遮断する場合は、FANをオフにすることが必要になる場合があります。

次の表は、「FANの有効化」がfalseに設定されているときに使用できる、AGLデータ・ソースの機能を示しています。

表6-1 GridLinkの機能(「FANの有効化」がFalseの場合)

Active GridLinkの機能

「FANの有効化」がFalseの場合に使用可能

Oracle RACクラスタへのアクセスのための単一データ・ソース構成

はい

個別のOracle RACクラスタ・インスタンスに対するランタイムMBean

はい

ランタイム・ロード・バランシング(RLB)を使用した接続ロード・バランシング

いいえ

高速アプリケーション通知

いいえ

高速接続フェイルオーバー(FCF)

いいえ

正常なシャットダウン

いいえ

グラビテイション (接続の再バランシング)

いいえ

ONSクライアント・サポート(パスワードおよび暗号化されたウォレットの構成を含む)

はい

トランザクション・アフィニティ

はい

セッション・アフィニティ

いいえ

ActiveGridlink属性の理解

WebLogic Server 12.1.2以降では、ActiveGridlink属性を使用して、データ・ソース構成がAGLデータ・ソースであることを明示的に宣言します。これは、WebLogic Server管理コンソールでGridLinkデータ・ソースを作成するときに、自動的に有効化されます。WLSTを使用してデータ・ソース構成を作成する場合は、ActiveGridlink=trueを設定する必要があります。

注意:
WebLogic Server 12.1.2より以前のリリースとの後方互換性を維持するために、FanEnabled=trueまたはOnsNodeListがNULL以外のときには、データ・ソース構成は常にAGLデータ・ソース構成になります。この場合、ActiveGridlink値は無視されます。

従来のデータ・ソース構成は、アップグレード処理時に更新されません。高速アプリケーション通知(FAN)を有効化することなくOracle RACクラスタにアクセスするために、従来のAGLデータ・ソースを更新する必要がある場合は、編集またはWLSTを使用して構成内でActiveGridlink=trueを設定します。

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

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

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

- Active Gridlinkデータ・ソースによる接続の作成

例外のキャッシュと処理

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

Active Gridlinkデータ・ソースによる接続の作成

この項では、AGLの接続の変更点について要約します。FANとONSは有効化されていることを前提にしています。

- 構成済の初期容量に基づいて、最初にプールに接続が追加されます。これには、リスナーに基づいた接続時間のロード・バランシングが使用されます。これが正しく機能するには、複数の非SCANアドレスにLOAD_BALANCE=ONを指定するか、SCANを使用する必要があります。

- ランタイム・ロード・バランシングに基づいて必要に応じて、接続がプールに追加されます。ただし、これは、トランザクションまたはWebセッションの最後のリクエストにアフィニティを提供するインスタンスに接続が追加された場合、XAアフィニティまたはWebセッション・アフィニティによりオーバーライドされます。

- 計画済停止イベントが発生すると、そのインスタンスの未使用の接続はすぐに解放され、使用中の接続はプールに返された時点で解放されます。

- 計画外停止イベントが発生すると、そのインスタンスのすべての接続がすぐに破棄されます。

- 起動イベントが発生すると、新しいインスタンスに接続が事前に作成されます。

- グラビテイションの縮小が発生すると、負荷の高いインスタンス(期間単位)で未使用の接続が1つ破棄されます。

- 通常の縮小が発生すると、最小容量になるまで未使用接続の半数が破棄されます。このとき、負荷(期間単位)は考慮されません。

AGLとマルチ・データ・ソースの比較

AGLは、Oracle RACクラスタのサポートに対応したマルチ・データ・ソース(MDS)の上位実装です。次の項では、AGLデータ・ソースの利点に関する追加情報について説明します。AGLの利点は、次のとおりです。

- 単一URLによるデータ・ソースが1つ必要です。マルチ・データ・ソースでは、n個の汎用データ・ソースと1つのマルチ・データ・ソースを使用した構成が必要になります。

- 汎用データ・ソースのうちの1つの実行速度低下が障害に結び付く、ポーリング・メカニズムが不要になります。

- クラスタに対するノードの手動追加や手動削除が不要になります。

- ノードが使用可能になったときに、高速内部通知(帯域外)を提供します。これにより、Oracle Notification Service (ONS)を使用した新しいノードへの接続のロード・バランシングが可能になります。

- ノードが停止したときに高速内部通知を提供します。これにより、接続はONSを使用してノードを回避できるようになります。

- ロード・バランシング・アドバイザ(LBA)を提供します。これにより、負荷が最小のノードに新しい接続が作成されるようになります。また、LBA情報はグラビテイションにも使用され、負荷に基づいてアイドル接続を移動します。

- XAトランザクションまたはWebセッションに基づいたアフィニティを提供します。これにより、大幅にパフォーマンスが向上することがあります。

- DataGuardのようなHA構成の利点をフル活用します。詳細は、Oracleホワイト・ペーパーのOracle WebLogic Serverと可用性の高いOracle Database: Oracle統合最大可用性ソリューションを参照してください。

マルチ・データ・ソースからActive GridLinkへの移行

Oracle RAC接続対応のマルチ・データ・ソース(MDS)は、2005年からWebLogic Serverでサポートされています。Oracle RACが普及するに従い、MDSも広く使用されるようになりました。2011年初頭にActive GridLink (AGL)が導入されたことで、多くのMDSユーザーがAGLに移行しています。自動化されたアップグレード・パッチは存在しませんが、目的の環境にAGLを手動で実装するプロセスは簡単です。「AGLとマルチ・データ・ソースの比較」を参照してください。

マルチ・データ・ソースからの移行に伴うアプリケーションの変更

アプリケーションに対しては、なにも変更する必要はありません。標準的なアプリケーションは、JNDIのMDSを検索し、そのMDSを使用して接続を取得します。MDSと同じJNDI名をAGLに指定すると、アプリケーションでJNDIのデータ・ソース名を使用するプロセスはまったく同じになります。

マルチ・データ・ソースからの移行に伴う構成の変更

構成にのみ変更が必要になります。AGLデータ・ソースは、MDSからの情報と、単一のAGL記述子で結合されたメンバー汎用データ・ソースで構成されています。唯一必要になる追加情報は、Oracle RACクラスタに関するOracle Notification Service (ONS)の構成です。多くの場合、ONS情報はMDSで使用されていたものと同じホスト名で構成されていて、唯一の追加情報はポート番号です。このポート番号は、SCANアドレスを使用することで簡略化できます。

MDS記述子には、多量の情報は含まれていません。主な構成要素は、次のとおりです。

- JNDI名。アプリケーションに対する透過性を維持するためには、これを新しいAGLデータ・ソース名にする必要があります。MDSをAGLデータ・ソースと同時に実行するときには、AGLデータ・ソースに新しいJNDI名を付ける必要がありますが、その場合はアプリケーションも新しいJNDI名を使用するように更新する必要があります。

- メンバー汎用データ・ソースのリストは、AGLデータ・ソースの構成に必要な残りの情報を提供します。
各メンバー汎用データ・ソースは、それぞれに独自のURLを持ちます。付録C「Oracle RACでのマルチ・データ・ソースの使用」で説明するように、次のパターンになります。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=
(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))

各メンバーは、独自のホスト/ポートのペアを持ちます。各メンバーは、同一のサービスを持つことがあり、多くの場合、別々のホストの同じポートを持ちます。AGLデータ・ソースのURLは、ホスト/ポートのペアで構成されています。次に例を示します。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2-vip)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=dbservice))

これには、複数のホストや仮想IP (VIP)のアドレスではなく、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用するようにしてください。SCANアドレスは、より簡単でノードの変更がクラスタ透過的になります。SCANアドレスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。次に例を示します。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scanaddress)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=dbservice))

- 「アルゴリズムのタイプ」は無視します。

マルチ・データ・ソースからActive GridLinkデータ・ソースへの移行の基本手順

次の項では、マルチ・データ・ソースからActive GridLinkデータ・ソースに移行する際に必要な基本手順について説明します。

- WebLogic Server管理コンソールを使用して、マルチ・データ・ソースと汎用データ・ソースを構成から削除します。

- WebLogic Server管理コンソールを使用して、単一のAGLデータ・ソースを追加します。

- マルチ・データ・ソースと同じJNDI名を付けます。

- どの汎用データ・ソースを使用していたかに応じて、XAドライバまたは非XAドライバを選択します。

- 完全なURLを入力します。詳細は、「マルチ・データ・ソースからの移行に伴う構成の変更」を参照してください。

- ユーザーとパスワードを設定します。これは、マルチ・データ・ソース・メンバーに使用していたものと同じ内容にする必要があります。

- 「GridLinkデータソース接続のテスト」ページで、「すべてのリスナーのテスト」をクリックして、新しいURLを検証します。

- ONS接続の情報を入力します。1つ以上のhost:portペアを指定します。例: host1-vip:6200またはscanaddress:6200。可能な場合は、単一のSCANアドレスとポートを使用します。「FANの有効化」が選択されていることを確認します。

- ONS接続をテストします。

- データ・ソースをデプロイします。

- AGLデータ・ソースを編集して、追加パラメータを構成します。
新しいデータ・ソースの作成中には構成できないデータ・ソースのパラメータが多数あります。多くの場合、マルチ・データ・ソースで使用していたパラメータ設定を使用できます。競合が発生した場合は、その競合を解決してから、環境に応じた適切な設定値を選択する必要があります。

WebLogic Server管理コンソールを使用してAGLデータ・ソースを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成に関する項を参照してください。

AGLデータ・ソースでのデータベース停止時間の管理

次の項では、Oracle RACデータベース環境のActive GridLinkデータ・ソースでデータベース停止時間を処理する方法について説明します。

- データベースの停止に対応するActive GridLink構成

- 計画停止の手順

- 計画外停止

データベースの停止に対応するActive GridLink構成

AGLデータ・ソースが次のように構成されていることを確認します。

- 高速アプリケーション通知(FAN)が有効です。FANは、データベース・サービス、インスタンス、データベース自体、およびクラスタを構成するノードの状態変更に関する迅速な通知を行います。これにより、アプリケーションにエラーを返すことなく、計画メンテナンス中に作業を排出できます。

- 自動ONSまたは明示的に定義されたONS構成を使用しています。詳細は、「ONSクライアント構成」を参照してください。

- 動的データベース・サービスを使用しています。管理サービスまたはPDBサービスを使用して接続しないでください。これらは、管理目的専用であり、FANではサポートされません。

- テスト接続が有効です。停止の状況によっては、停止イベントが処理される前に接続が流用されている場合、アプリケーションは、古い接続を取得する可能性があります。たとえば、この状況は、着信接続リクエストと同時にソケットが閉じられたときに、クリーン・インスタンスの停止で発生することがあります。アプリケーションがエラーを受信することを避けるには、接続プールで接続チェックを有効にする必要があります。この場合、test-connections-on-reserveをtrueに設定し、test-table (Oracleの推奨値はSQL ISVALID)を設定する必要があります。

- SCAN使用が最適化されています。データベース・ドライバ12.1.0.2以上では、最適化としてADDRESSLISTのURL設定LOAD_BALANCE=TRUEを設定し、SCANアドレス用にDNSから返されるSCAN IPアドレスを強制的に並べ替えます。
12.1.0.2より前のデータベース・ドライバでは、接続プロパティoracle.jdbc.thinForceDNSLoadBalancing=trueを使用します。

詳細は、「SCANアドレス」を参照してください。

計画停止の手順

計画停止時間の場合、その主な目標は、データベース・サーバーでメンテナンスが進行中であっても、アプリケーションを中断することなくスケジュール済メンテナンスを管理することです。この目標を達成するには、次のことが必要です。

- 透過的スケジュール済メンテナンス - データベース・サーバーのスケジュール済メンテナンス・プロセスが、アプリケーションに対して透過的であることが保証されます。

- セッション排出 - データベース・サーバーでメンテナンスのためにインスタンスを停止する場合、セッション排出によって、そのノードでインスタンスを使用しているすべての作業が完了し、アイドル・セッションが削除されることが保証されます。セッションは、処理中の作業に影響を与えることなく排出されます。

メンテナンス目的で(システム内またはシステム間でのソフトウェアとハードウェアのアップグレード、修理、変更、移行など)、使用されているサービスは、WebLogic Serverアプリケーションの操作および可用性を中断することなく、一度に1回または複数回正常に停止されます。FAN DOWNイベントが発生すると、AGLは、メンテナンスの対象となる1つ以上のインスタンスからセッションを排出します。ターゲット・データベース・インスタンスで実行されている非シングルトン・サービスを停止するか(それらがまだ残りの実行中のインスタンスで使用可能であると仮定)、シングルトン・サービスをターゲット・インスタンスから別のインスタンスに再配置する必要があります。サービスが排出されると、インスタンスは、アプリケーション・エラーなしで停止されます。

次の手順では、計画メンテナンス・プロセスの概要を示します。

1. メンテナンスの対象となるインスタンスでDBAがトリガーしたDOWNイベントが検出されます。

2. 1つ以上のターゲット・インスタンスからセッションを排出します。

3. データベース・サーバーでスケジュール済メンテナンスを実行します。

4. アップグレードした1つ以上のノードで操作を再開します。

データベース・サーバーと中間層の両方で操作を調整する必要のあるマルチ・データ・ソースとは異なり、Active GridLinkは、それらの操作をすべてデータベース・サーバーから管理できるようにデータベースと連携するため、プロセスが簡略化されます。表6-2は、データベース・サーバーで実行される手順と中間層での対応する応答を示しています。

表6-2 AGL計画メンテナンスのためにデータベース・サーバーで実行される手順

手順番号

データベース・サーバーの手順

コマンド

中間層の応答

1.

-forceなしで非シングルトン・サービスを停止するか、シングルトン・サービスを再配置します。

–serverオプションを省略すると、インスタンスのすべてのサービスに影響します。

$ srvctl stop service –db db_name -service service_name -instance instance_name

または

$ srvctl relocate service –db db_name -service service_name -oldinst oldins -newinst newinst

サービスのFAN計画停止(reason=USER)イベントは、サービスが使用できなくなったため、接続を排出する必要があることを接続プールに通知します。停止されたサービスのアイドル接続は、即座に解放されます。使用中の接続は、アプリケーションから返された(論理的に閉じられた)ときに解放されます。新しい接続は、サービスを提供する他のインスタンスおよびデータベースで予約されます。このFANアクションは、アプリケーションを中断することなく、インスタンスからのセッションの排出を開始します。

2.

停止したサービスを無効化して、自動的に再起動されないようにします。サービスの無効化はオプションです。この手順は、アクションが完了するまでサービスの自動的な再起動が禁止されるメンテナンス・アクションに推奨されます。

$ srvctl disable service –db db_name -service service_name -instance instance_name

新しい接続は、停止または無効化されたサービスに中間層で関連付けられません。

3.

セッションの排出を許可します。

所要時間は、アプリケーションに応じて異なります。長時間実行される問合せになることもあります。バッチ・プログラムは、定期的に接続を返して新しい接続を取得するように記述されていない可能性があります。メンテナンスの前にバッチを排出することをお薦めします。

4.

長時間実行されるセッションをチェックします。トランザクション切断を使用してこれらのセッションを終了します。セッションの排出を待機します。問合せを再度実行して、セッションが残っているかどうかをチェックできます。

SQL> select count(*) from (select 1 from v$sessionwhere service_name in upper('service_name') union all select 1 from v$transaction where status = 'ACTIVE' )

SQL> exec dbms_service.disconnect_session( 'service_name', DBMS_SERVICE.POST_TRANSACTION)

中間層の接続はエラーを受け取ります。アプリケーション・コンティニュイティを使用している場合、別のインスタンスで新しい接続に対する操作を自動的にリプレイすることで、アプリケーションからエラーを隠蔽できます。それ以外の場合、アプリケーションはSQLExceptionを受け取ります。

5.

手順1から4を繰り返します。

計画メンテナンスの対象となるすべてのサービスで繰り返します

6.

immediateオプションを使用してデータベース・インスタンスを停止します。

$ srvctl stop instance –db db_name -instance instance_name -stopoption immediate

データベースとサービスが再起動されるまで中間層に影響はありません。

7.

オプションで、メンテナンス中に自動的に再起動しないようにインスタンスを無効化します。

この手順は、メンテナンス中にサービスを再開できないメンテナンス操作向けです。

$ srvctl disable instance –db db_name -instance instance_name

8.

スケジュール済メンテナンス作業(パッチ、修理および変更)を実行します。

9.

インスタンスを有効化して起動します。

$ srvctl enable instance –db db_name -instance instance_name

$ srvctl start instance –db db_name -instance instance_name

10.

サービスを有効化して起動します。サービスが起動されて実行中であることを確認します。

$ srvctl enable service –db db_name -service service_name -instance instance_name

$ srvctl start service –db db_name -service service_name -instance instance_name

サービスのFAN UPイベントは、新しいインスタンスが使用可能になったため、次回のリクエストの送信時にこのインスタンスでセッションを作成できることを接続プールに通知します。セッションの自動リバランスが開始します。

図6-6は、計画停止時間の前後に2つのOracle RACインスタンス間で行われるサービスの接続の配分を示しています。接続ワークロードが、両方のインスタンス間で50対50から100対0に移行していることがわかります。言い換えると、RAC_INST_1は、ビジネス操作に影響を与えることなくメンテナンスのために停止できます。

図6-6 2つのOracle RACインスタンス間での接続の配分

計画外停止

計画外停止が発生する場合、いくつかの相違点があります。

- データベース・サーバーのコンポーネントに障害が発生すると、そのノードで実行されているインスタンス上ですべてのサービスが使用できなくなる可能性があります。障害が発生しているため、サービスの停止または無効化は行われません。

- FAN計画外停止イベント(reason=FAILURE)が中間層に配信されます。

- すべてのセッションが即座に閉じられるため、アプリケーションは、TCP/IPタイムアウトを待機することはありません。他のインスタンスの既存の接続は使用可能なままで、必要に応じてそれらのインスタンスに新しい接続が開かれます。

- 接続の正常な排出は行われません。アプリケーション・コンティニュイティを使用するように構成されているサービスを使用するアプリケーションの場合、アクティブ・セッションが残存インスタンスでリストアされ、操作をリプレイすることでリカバリされるため、停止はアプリケーションから隠蔽されます。アプリケーション・コンティニュイティで保護されていない場合、インスタンスとアクティブに通信するセッションは、SQLExceptionを受信します。

7 Proxyデータ・ソースの使用

この章では、プロキシ・データ・ソースの構成方法とモニター方法について説明します。プロキシ・データ・ソースは、WebLogic Serverマルチテナント環境のデータベース間で切替えを実行できます。

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

- プロキシ・データ・ソースとは

- プロキシ・データ・ソースの作成

- プロキシ・データ・ソースJDBCリソースのモニタリング

プロキシ・データ・ソースとは

WebLogic Serverマルチテナント環境で、データ・ソースを含むリソースは、パーティションごとにレプリケートされます。プロキシ・データ・ソースによって、パーティションまたはテナントに関連付けられたデータ・ソースにアクセスするための軽量メカニズムが提供され、複数のデータ・ソースの管理が簡略化されます。多くの場合、アプリケーションは、ネーミング規則やコンテキスト名(パーティションまたはテナント)などを認識しないまま、名前でデータ・ソースに迅速にアクセスする必要があります。プロキシ・データ・ソースは、基礎となるデータ・ソースに対するアクセスを提供します。すべての重要な処理が、それが指し示すデータ・ソースで発生します。つまり、実際には、基礎となるデータ・ソースがデプロイメント、管理、セキュリティなどを処理します。

注意:
必要に応じて、非マルチテナント環境でもプロキシ・データ・ソースを使用できます。

プロキシ・データ・ソースが提供するWebLogic Serverデータ・ソースへのアクセスには、次の特徴があります。

- 最小限の構成。

- 二重接続プーリングを含まない最小限のパフォーマンス・オーバーヘッド(たとえば、プロキシと基礎となる接続プールの両方で接続プーリングは発生しません)。

- WebLogic Serverマルチテナント環境のレプリケートされたデータ・ソース間での切替え機能。

- データ・ソース・オブジェクトへのJNDIアクセス。

- javax.sql.DataSourceを実装するデータ・ソース・オブジェクト。

- 環境のコンテキスト(パーティションやテナントなど)に基づいてデータ・ソースの切替えを実行するために実装できるコールバック・インタフェース。

- 切替えに使用するコンテキスト・レベル(テナント、パーティション、スレッド内の他の情報など)と切替えの実行先データ・ソースの両方におけるアプリケーションによる切替え構成。

- 切替え可能なすべてのデータ・ソースに対する直接アクセス。

プロキシ・データ・ソースの作成

WebLogicドメインにプロキシ・データ・ソースを作成する場合、WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)およびFusion Middleware Controlを使用できます。管理コンソールとWLSTによる方法については、次の項を参照してください。

- WebLogic Server管理コンソールでのプロキシ・データ・ソースの構成

- WLSTを使用したプロキシ・データ・ソースの構成

Fusion Middleware Controlを使用してプロキシ・データ・ソースを作成する手順については、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJDBCプロキシ・データ・ソースの作成に関する項を参照してください。

プロキシ・データ・ソースを作成する場合、次の点に注意してください。

- プロキシ・データ・ソースは、切替えプロパティの値を検証して、それらがコンテキスト名やデータ・ソースに一致していることを確認しません。無効なデータ・ソースが指定されると、接続の取得に失敗します。ただし、プロキシが指し示すデータ・ソースは、構成時またはデプロイ時に使用可能である必要はありません。

- プロキシが指し示すデータ・ソースに関するルールはありません。ただし、一般的に各メンバーは、基本的に同じ機能を提供する必要があります。それらは、異なるベンダー・ドライバに基づくものでかまいませんが、同じスキーマ、トランザクション・プロパティおよび一般機能を持つ必要があります。Oracleでは、Oracle Container Database/Pluggable Databaseテクノロジを使用するように基礎となるデータ・ソースを構成することや、データ・ソースでOracleドライバを使用することは想定されていません。

- プロキシ・データ・ソースは、javax.sql.DataSourceインタフェースを提供します。XADataSourceと同等のものは、提供されていないか、不要です。XADataSourceの追加メソッドは、トランザクションのリスト化を処理する場合にのみ必要です。トランザクションの処理は、プロキシ・レベルではなくメンバー・レベル(実際のデータ・ソース・レベル)で処理されるため、2つのレベルでそれを行うと、問題が発生します。

- プロキシ・データ・ソースは、アプリケーション・スコープの環境でサポートされず、それらがアプリケーション・スコープのデータ・ソースを参照することもありません。それらは、システム・リソースとして定義され、サーバーまたはクラスタ(あるいはその両方)をターゲットとする必要があります(WebLogic Serverは、ドメインをターゲットにできません)。

WebLogic Server管理コンソールでのプロキシ・データ・ソースの構成

WebLogic Server管理コンソールでプロキシ・データ・ソースを作成する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのプロキシ・データ・ソースの作成に関する項を参照してください。この手順には、データ・ソースの構成ウィザードにアクセスする方法も含まれます。プロキシ・データ・ソースを作成するには、ウィザードの「新規」メニューから「プロキシ・データ・ソース」を選択します。

次の各項では、WebLogic Server管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。

- プロキシ・データ・ソース・プロパティの設定

- ターゲットの選択

プロキシ・データ・ソース・プロパティの設定

「PROXYデータ・ソース・プロパティ」セクションには、データ・ソースのアイデンティティとデータベース接続でのデータの処理方法を決定するオプションが含まれます。これらのプロパティを構成するためのガイドラインは、次のとおりです。

- データ・ソース名 - 「名前」フィールドにプロキシ・データ・ソースの名前を入力します。JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。

- スコープ - 使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。

- JNDI名 - 「JNDI名」フィールドにプロキシ・データ・ソースのJNDI名を入力します。単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数JNDI名のデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。

- 切替えプロパティ - プロキシ・データ・ソースの切替えコールバック・メソッドに渡す切替えプロパティを入力します。この値は、切替えコールバックの要件に応じて異なります。デフォルトの切替えコールバックでは、プロキシの切替えプロパティの書式は、partition1=datasource1;partition2=datasource2;...;default=datasourcenです。これは、切替えコールバックのgetDataSource()の第2引数に渡されます。
デフォルトのWebLogic Server実装では、現在のパーティションを使用して切替えプロパティのデータ・ソースをルックアップします。パーティション内に存在しない場合、パーティション値はDOMAINです。一致が検出されないか、パーティション内に存在しない場合、defaultに関連付けられたデータ・ソースが使用されます。デフォルト値が適切ではない場合、default値を指定しないでください(NULLが返されます)。WebLogic Server内では、デフォルト・コールバックのみを使用できます。

- 切替えコールバック - プロキシの切替えコールバック・クラスの名前を入力します。デフォルト・コールバックを使用するには、この値を空のままにします。コールバック・クラスを指定する場合、それにweblogic.jdbc.extensions.DataSourceSwitchingCallbackインタフェースを実装する必要があります。このインタフェースには、2つのパラメータを使用する1つのメソッドがあります。2つのパラメータの書式は、実装に応じて異なります。第1パラメータ(プロキシ・データ・ソースのJNDI名のカンマ区切りのリスト)は、デフォルト・コールバックでは使用されません。第2パラメータは、前述の切替えプロパティで説明したとおりです。

ターゲットの選択

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

WLSTを使用したプロキシ・データ・ソースの構成

他のデータ・ソース・タイプを作成するのと同じ方法で、WLSTを使用してプロキシ・データ・ソースを作成できます。ただし、必要な属性の数は、プロキシ・データ・ソースの方が少なくなります。

プロキシ・データ・ソースの構成要素は、次のとおりです。

- name

- datasource-type=PROXY

- jdbc-data-source-params proxy-switching-properties - 切替えの実行方法を定義する文字列。この値は、オプションであり、指定しない場合はNULLです。この値は、構成可能で動的です。

- jdbc-data-source-params proxy-switching-callback - weblogic.jdbc.extensions.DataSourceSwitchingCallbackを実装するクラスの名前を定義する文字列。この値は、オプションであり、WebLogic Serverではデフォルト・コールバック・クラスが使用されます。この値は、構成可能で動的です。

- jdbc-data-source-params jndi-name - データ・ソースがWebLogic Server (Java EE) JNDIにマップされる文字列の名前の配列。JNDI名に関する他のネーミング規則に加え、プロキシ・データ・ソースのJNDI名には、カンマ(,)を含めることができません。

WebLogic Serverデータ・ソース・ディスクリプタからの他の要素は、認識されません。他の要素を指定しても、無視されます。

例7-1に、プロキシ・データ・ソースを作成するためのサンプルWLSTスクリプトを示します。

例7-1 プロキシ・データ・ソースを作成するためのサンプルWLSTスクリプト

import sys, socket
import os
hostname = socket.gethostname()
connect("weblogic","welcome1","t3://"+hostname+":7001")
edit()
startEdit()
serverName="AdminServer"
serverBean = getMBean('/Servers/'+serverName)
host='%s.us.company.com' %hostname
print 'Creating Proxy datasource'
domain = getMBean("/")
startEdit()
resourceName='proxyDS'
print "Creating data source in domain"
systemResource=domain.createJDBCSystemResource(resourceName)
systemResource.setName(resourceName)
jdbcResource=systemResource.getJDBCResource()
jdbcResource.setName(resourceName)
jdbcResource.setDatasourceType('PROXY')
jdbcDataSourceParams=jdbcResource.getJDBCDataSourceParams()
jdbcDataSourceParams.addJNDIName(resourceName)
jdbcDataSourceParams.setProxySwitchingProperties('partition1=partition1:ds;default=domain:ds')
cd('/SystemResources/' + resourceName )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + serverName + ',Type=Server')], ObjectName))
save()
activate()

注意:
プロキシ・データ・ソースの基礎としてWebLogic Serverに付属する汎用データ・ソースを作成するためのサンプルWLSTスクリプトも使用できます。

EXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py

ここでEXAMPLES_HOMEは、WebLogic Serverのコード・サンプルを構成するディレクトリです。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

プロキシ・データ・ソースJDBCリソースのモニタリング

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

JDBCProxyDataSourceRuntimeMBeanは、JDBCDataSourceRuntimeMBeanを拡張して、WebLogic Server管理コンソールなどのツールのJDBCサービスから他のJDBC MBeanのリストとともにそれを返すことができるようにします。PROXYデータ・ソースの場合、状態が設定されます。アクティブな接続などの実行時の統計は、すべて設定されません(それらは-1に設定されます)。

実行時の統計に加え、テストに成功すると、testPool()操作はNULLを返します。それ以外の場合、エラー文字列を返します(他のデータ・ソース・タイプと同様)。操作の残りは、アクションを実行しません。

詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCProxyDataSourceRuntimeMBeanに関する項を参照してください。

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

8 ユニバーサル接続プール・データ・ソースの使用

この章では、ユニバーサル接続プール(UCP)・データ・ソースの構成方法とモニター方法について説明します。

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

- ユニバーサル接続プール・データ・ソースとは

- ユニバーサル接続プール・データ・ソースの作成

- ユニバーサル接続プールJDBCリソースのモニタリング

ユニバーサル接続プール・データ・ソースとは

UCPデータ・ソースは、Oracle Universal Connection Pooling (UCP)を使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。

注意:
一般的には、Active GridLinkデータ・ソース、マルチ・データ・ソースまたは汎用データ・ソースと、これらのデータ・ソース実装に含まれるOracle WebLogic Server接続プーリングを使用してOracle Databaseとの接続を確立することをお薦めします。

UCPデータ・ソースの実装は、疎結合されており、アプリケーションによる新しいUCP機能の使用をサポートするためにucp.jarを切り替えることができます。UCPデータ・ソースは、アプリケーション・スコープ環境や、パッケージ化またはスタンドアロン・モジュール環境ではサポートされません。

Oracle WebLogic Serverでは、UCPデータ・ソースの次のサポートが提供されます。

- 汎用データ・ソース、マルチ・データ・ソースまたはActive GridLinkデータ・ソースの代替データ・ソースとしての構成。

- データ・ソースのデプロイおよびアンデプロイ。

- 基本的なモニタリングおよび統計:

- ConnectionsTotalCount

- CurrCapacity

- FailedReserveRequestCount

- ActiveConnectionsHighCount

- ActiveConnectionsCurrentCount

- Oracle簡易ドライバ、XAドライバおよびアプリケーション・コンティニュイティ・ドライバでの動作保証。

UCPデータ・ソースでは、次の機能はサポートされません。

- WebLogic Serverトランザクション・マネージャ(1フェーズ、LLR、JTS、JDBC TLog、決定子リソースなど)。

- 追加のライフサイクル操作(中断、再開、停止、強制停止、開始など)。

- 任意の接続プールの汎用サポート。

- Oracle WebLogic Serverセキュリティ・オプション。

- 前にリストされているもの以外のJDBCドライバ。

- JMS、リース、EJBなどのOracle WebLogic Serverデータ操作。

- UCPデータ・ソースに対するRMIアクセス。

Oracle Universal Connection Poolの詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。

ユニバーサル接続プール・データ・ソースの作成

WebLogicドメインにUCPデータ・ソースを作成する場合、WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)およびFusion Middleware Controlを使用できます。管理コンソールとWLSTによる方法については、次の項を参照してください。

- WebLogic Server管理コンソールでのUCPデータ・ソースの構成

- WLSTを使用したUCPデータ・ソースの構成

Fusion Middleware Controlを使用してUCPデータ・ソースを作成する手順については、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJDBC UCPデータ・ソースの作成に関する項を参照してください。

WebLogic Server管理コンソールでのUCPデータ・ソースの構成

WebLogic Server管理コンソールでUCPデータ・ソースを作成する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのUCPデータ・ソースの作成に関する項を参照してください。この手順には、データ・ソースの構成ウィザードにアクセスする方法も含まれます。

次の各項では、WebLogic Server管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。

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

- 接続プロパティの設定

- データベース接続のテスト

- ターゲットの選択

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

「JDBCデータ・ソースのプロパティ」セクションには、データ・ソースのアイデンティティとデータベース接続でのデータの処理方法を決定するオプションが含まれます。これらのプロパティを構成するためのガイドラインは、次のとおりです。

- データ・ソース名 - 「名前」フィールドにUCPデータ・ソースの名前を入力します。JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。

- スコープ - 使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。

- JNDI名 - 「JNDI名」フィールドにUCPデータ・ソースのJNDI名を入力します。単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数JNDI名のデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。

- 「データベースのタイプ」および「ドライバ」 - UCPデータ・ソースは、Thin XA、非XAおよびアプリケーション・コンティニュイティ(リプレイ)・ドライバという3つのOracleドライバで動作保証されています。メニューから必要なドライバを選択します。
表8-1に、ドライバとJDBC接続ファクトリのサポートされる組合せを示します。

表8-1 UCPデータ・ソースでサポートされるドライバと接続ファクトリの組合せ

ドライバ

ファクトリ(ConnectionFactoryClassName)

oracle.ucp.jdbc.PoolDataSourceImpl (デフォルト)

oracle.jdbc.pool.OracleDataSource

oracle.ucp.jdbc.PoolXADataSourceImpl

oracle.jdbc.xa.client.OracleXADataSource

oracle.ucp.jdbc.PoolDataSourceImpl

oracle.jdbc.replay.OracleDataSourceImpl

注意:
現時点では、リプレイ・ドライバはXAトランザクションをサポートしていません。
表8-1のリストにある非XAドライバを、表にあるXAファクトリで指定すると、エラーが生成されます。表に含まれない値を指定しても、それらは検証されません。

jdbc-driver-paramsにdriver-nameが指定されていない場合、デフォルトでoracle.ucp.jdbc.PoolDataSourceImplに設定されます。

サポートされるドライバ名を指定したが、ConnectionFactoryClassName接続プロパティを指定しない場合、表8-1の対応するエントリが使用されます。サポートされるドライバ名を指定しない場合、エラーが生成されます。

接続プロパティの設定

接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。管理コンソールでUCPデータ・ソースの接続プロパティを入力する場合、2つの方法があります。

ウィザードの「接続プロパティ」ページには、UCPドライバに使用できるすべての接続プロパティが表示されるため、適切な値を入力できます。別の方法として、「データベース接続のテスト」ページの「プロパティ」テキスト・ボックスに、propertyName=valueという書式を使用して直接プロパティを入力することで、プロパティを構成できます。「接続プロパティ」ページで入力した値は、「プロパティ」テキスト・ボックスにすでにリストされています。

表8-2では、UCPデータ・ソースで構成できる接続プロパティについて説明します。UCPの接続プロパティの詳細は、Oracle Universal Connection Pool for JDBC Java APIリファレンスのクラスPoolDataSourceImplに関する項を参照してください。属性は、PoolDataSourceImplクラスのセッターによって決定されます。set接頭辞なしの属性名を使用してください。名前の大文字と小文字は区別されません。

表8-2 UCP接続プールのプロパティ

プロパティ

タイプ

説明

AbandonedConnectionTimeout

int

中止接続タイムアウトを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは0です。

ConnectionFactoryClassName

String

接続ファクトリのクラス名を設定します。

ConnectionFactoryProperties

name=value

接続ファクトリの複数の接続ファクトリ・プロパティを設定します。

ConnectionFactoryProperty

name=value

接続ファクトリの1つの接続ファクトリ・プロパティを設定します。

ConnectionHarvestMaxCount

int

接続収集の発生時に収集できる接続の最大数を設定します。

ConnectionHarvestTriggerCount

int

接続プールの接続収集が発生するときに使用可能な接続の数を設定します。

ConnectionLabelingHighCost

int

接続ラベリングで接続を高コストとして識別するコスト値を設定します。

ConnectionPoolName

String

接続プール名を設定します。

ConnectionProperties

name=value

接続ファクトリの複数の接続プロパティを設定します。

ConnectionProperty

name=value

接続ファクトリの1つの接続プロパティを設定します。

ConnectionWaitTimeout

int

使用中の接続をクライアントが解放するまでの待機時間(秒)を設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは3です。

DatabaseName

String

データベース名を設定します。

DataSourceName

String

データ・ソース名を設定します。

Description

String

データ・ソースの説明を設定します。

FastConnectionFailoverEnabled

Boolean

このプール対応のデータ・ソースを使用してアクセスされる接続プールの高速接続フェイルオーバー(FCF)を有効化します。有効な値は、trueおよびfalseです。

HighCostConnectionReuseThreshold

int

接続ラベリングの高コストの接続再使用しきい値を設定します。

InactiveConnectionTimeout

int

非アクティブ接続タイムアウトを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは0です。

InitialPoolSize

int

初期プール・サイズを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。これを最大プール・サイズより大きい値に設定すると無効になります。デフォルトは0です。

LoginTimeout

int

ログイン・タイムアウトを設定します。

MaxConnectionReuseCount

int

接続再使用数プロパティを設定します。

MaxConnectionReuseTime

long

接続再使用時間プロパティを設定します。

MaxIdleTime

int

プールで使用可能な接続のアイドル・タイムアウトを設定します。

MaxPoolSize

int

接続の最大数を設定します。

有効値の範囲は、1からInteger.MAX_VALUEまでです。デフォルトはInteger.MAX_VALUEです。

MaxStatements

int

接続でプールするかキャッシュできる文の最大数を設定します。

MinPoolSize

int

接続の最小数を設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。これを最大プール・サイズより大きい値に設定すると無効になります。デフォルトは0です。

NetworkProtocol

String

データ・ソース・ネットワーク・プロトコルを設定します。

ONSConfiguration

String

リモートONSサブスクリプションに使用される構成文字列を設定します。

Password

String

接続を取得するためのパスワードを設定します。

PortNumber

int

データベース・ポート番号を設定します。

PropertyCycle

int

プロパティ・サイクル(秒)を設定します。

RoleName

String

データ・ソース・ロール名を設定します。

ServerName

String

データベース・サーバー名を設定します。

SQLForValidateConnection

String

SQLForValidateConnectionプロパティの値(SQL)を設定します。

TimeoutCheckInterval

int

timeoutCheckInterval (秒)を設定します。

TimeToLiveConnectionTimeout

int

接続を使用中のままにできる最大時間(秒)を設定します。

URL

String

データベースへの接続を取得するためにデータ・ソースで使用するURLを設定します。

User

String

接続を取得するためのユーザー名を設定します。

ValidateConnectionOnBorrow

Boolean

流用した接続を最初に検証するかどうかを設定します。有効な値は、trueおよびfalseです。

注意:
通常の文字列リテラルに加え、システム・プロパティと暗号化プロパティがサポートされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- システム・プロパティの設定に関する項

- 接続プロパティの暗号化に関する項

jdbc-driver-params URLが設定されている場合、URLプロパティは無視されます。encrypted-passwordが設定されている場合、パスワード・プロパティは無視されます。

属性ConnectionFactoryProperty、ConnectionFactoryProperties、ConnectionPropertyおよびConnectionFactoryPropertiesは、"name1=value1,name2=value2..."という形式の値を受け入れます。

データベース接続のテスト

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

ターゲットの選択

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

WLSTを使用したUCPデータ・ソースの構成

他のデータ・ソース・タイプを作成するのと同じ方法で、WLSTを使用してUCPデータ・ソースを作成できます。ただし、必要な属性の数は、UCPデータ・ソースの方が少なくなります。

UCPデータ・ソースの構成要素は、次のとおりです。

- name

- datasource-type=UCP

- jdbc-driver-params url

- jdbc-driver-params property - user

- jdbc-driver-params password-encrypted

- jdbc-data-source-params jndi-name

- jdbc-driver-params other properties

WebLogic Serverデータ・ソース・ディスクリプタからの他の要素は、認識されません。他の要素を指定しても、無視されます。

例8-1に、UCPデータ・ソースを作成するためのサンプルWLSTスクリプトを示します。

例8-1 UCPデータ・ソースを作成するためのサンプルWLSTスクリプト

import sys, socket
import os
hostname = socket.gethostname()
connect("weblogic","welcome1","t3://"+hostname+":7001")
edit()
startEdit()
serverName="AdminServer"
serverBean = getMBean('/Servers/'+serverName)
host='%s.us.company.com' %hostname
print 'Creating UCP datasource'
domain = getMBean("/")
startEdit()
resourceName='ucpDS'
print "Creating datasource ds in domain"
systemResource=domain.createJDBCSystemResource(resourceName)
systemResource.setName(resourceName)
jdbcResource=systemResource.getJDBCResource()
jdbcResource.setName(resourceName)
jdbcResource.setDatasourceType('UCP')
driverParams=jdbcResource.getJDBCDriverParams()
driverParams.setDriverName('oracle.ucp.jdbc.PoolDataSourceImpl')
driverParams.setUrl('jdbc:oracle:thin:@dbhost:1521/otrade')
properties = driverParams.getProperties()
properties.createProperty('user', 'dbuser')
properties.createProperty('ConnectionFactoryClassName', 'oracle.jdbc.pool.OracleDataSource')
driverParams.setPassword('MYPASSWD')
jdbcDataSourceParams=jdbcResource.getJDBCDataSourceParams()
jdbcDataSourceParams.addJNDIName(resourceName)
jdbcDataSourceParams.setGlobalTransactionsProtocol('None')
cd('/SystemResources/' + resourceName )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + serverName + ',Type=Server')], ObjectName))
save()
activate()

注意:
UCPデータ・ソースの基礎としてWebLogic Serverに付属する汎用データ・ソースを作成するためのサンプルWLSTスクリプトも使用できます。

EXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py

ここでEXAMPLES_HOMEは、WebLogic Serverのコード・サンプルを構成するディレクトリです。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

ユニバーサル接続プールJDBCリソースのモニタリング

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

JDBCUCPDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、JDBCDataSourceRuntimeMBeanを拡張して、JDBCサービスから他のJDBC MBeanのリストとともにそれを返すことができるようにします。

実行時の統計に加え、テストに成功すると、testPool()操作はNULLを返しますが、それ以外の場合はエラー文字列を返します(他のデータ・ソース・タイプと同様)。プールのテストが実行されるのは、検証用に実行するSQL文字列(SELECT 1 from DUALなど)がSQLForValidateConnectionに設定されている場合のみです。操作の残りは、アクションを実行しません。

詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCUCPDataSourceRuntimeMBeanに関する項を参照してください。

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

9 接続収集

この章では、アプリケーションで接続収集を構成および使用する方法について説明します。

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

- 接続収集とは

- 接続収集の有効化

- 接続を収集可能としてマーキング

- 収集した接続のリカバリ

接続収集とは

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

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

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

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デバッグを使用します。

- クリーンアップ・メソッドの戻り値は無視されます。

- データ・ソースで使用可能な接続が指定した数まで減少すると、アプリケーションにより収集可能とマークされた予約済接続が接続収集により解放されます。デフォルトでは、このチェックは30秒間隔で実行されます。weblogic.jdbc.harvestingFrequencySecondsシステム・プロパティを使用して、この動作を調整できます。このプロパティは、マークされた接続を収集する前にシステムが待機する時間を秒単位で指定します。このシステム・プロパティを1未満に設定すると、収集が無効になります。

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

この章では、データ・ソースで接続予約の管理を可能にする詳細な構成オプションについて説明します。

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

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

- データベース常駐接続プーリング

- Global Database Services

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

- テナントの切替えに関する制限

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

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

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

次に示す各項では、アプリケーション・コンティニュイティの構成方法と使用方法について説明します。

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

- 要件および考慮事項

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

- アプリケーション・コンティニュイティの実行時統計の表示

- Oracle 12cデータベースにおけるアプリケーション・コンティニュイティに関する制限

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

計画済停止か計画外停止かにかかわらず、次に示すデータベース・サービスの損失による停止については、アプリケーション・コンティニュイティによりデータベース・セッションが再構築されます。高速アプリケーション通知またはリカバリ可能なORACLEエラーで停止が識別されると、Oracleドライバは次のように動作します。

- 新しいデータベース・セッションを確立して、未処理の状態を解消します。

- コールバックが登録されている場合は、コールバックを発行して、そのセッションの初期状態をアプリケーションが再確立できるようにします。

- リクエスト中に累積した保存済の履歴を実行します。

Oracleドライバは、リプレイ・コールのタイミングを判断します。コールは、アプリケーションがデータベースの状態を変更する方法に応じて経時的に処理されるか、遅延処理の実装を使用して処理されます。リプレイは、Oracle 12c Database Serverで制御されます。リプレイが承認されるようにするには、リプレイされるコールごとに、元のコールの実行中にアプリケーションで表示されていて潜在的に使用されていたクライアントの表示状態とまったく同じ状態を返す必要があります。

図10-1 アプリケーション・コンティニュイティ

要件および考慮事項

WebLogicアプリケーションでアプリケーション・コンティニュイティを使用する場合、次の要件および考慮事項に注意してください。

- Oracle 12c JDBCドライバとデータベースは必須です。付録A「Oracle 12cデータベースの使用」を参照してください。

- アプリケーション・コンティニュイティは、読取りトランザクションと読取り/書込みトランザクションをサポートします。XAトランザクションは、サポートされていません。アプリケーション・コンティニュイティ対応のOracleドライバなど、非XAドライバを使用するトランザクションをサポートする場合は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の非XA JDBCドライバによるグローバル・トランザクションの有効化に関する項を参照してください。

注意:
autocommit=FALSEを設定していることを確認して、トランザクション・セマンティクスが分断化と、環境でのアプリケーション・コンティニュイティの無効化を防止してください。

- 非推奨のoracle.sql.*具体クラスはサポートされていません。該当部分は、それに対応するoracle.jdbc.*インタフェースまたはjava.sql.*インタフェースのどちらかを使用するように変更する必要があります。標準のjava.sql.*インタフェースの使用をお薦めします。『Oracle WebLogic Server JDBCアプリケーションの開発』のOracle JDBCタイプのAPI拡張機能の使用方法に関する項を参照してください。

- アプリケーション・コンティニュイティは、中間結果をメモリーに格納することで動作します。アプリケーションは、この機能なしで実行するよりも実行速度が遅くなり、より大量のメモリーが必要になります。

- 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ドライバ・デバッグの有効化

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

適切なJDBCドライバを使用するようにデータ・ソースを構成するには、次のいずれかの方法を使用します。

- 新しいデータ・ソースを作成する場合は、構成ウィザードのドロップダウン・メニューからデータベース・ドライバを選択するように求められたときに、対象の環境でアプリケーション・コンティニュイティをサポートする適切なOracleドライバを選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーション・コンティニュイティの有効化に関する項を参照してください。

- 管理コンソールで既存のデータ・ソースを編集する場合は、「接続プール」タブを選択して、「ドライバ・クラス名」をoracle.jdbc.replay.OracleDataSourceImplに変更してから、「保存」をクリックします。

- テキスト・エディタまたはWLSTでデータ・ソースを作成または編集する場合は、JDBCドライバをoracle.jdbc.replay.OracleDataSourceImplに設定します。

「要件および考慮事項」を参照してください。

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

次の各項では、接続コールバックの使用方法について説明します。

- 初期化コールバックの作成

- 初期化コールバックの登録

- 初期化コールバックの登録解除

初期化コールバックの作成

接続初期化コールバックを作成する場合は、アプリケーションに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);
. . .

また、コールバックは、WebLogic Server管理コンソールからデータ・ソースの「Oracle」タブで、「接続初期化コールバック」属性にコールバック・クラスを入力することでも登録できます。実行時にコールバックを設定するのではなく、このコールバック属性を構成するようにしてください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーション・コンティニュイティの有効化に関する項を参照してください。

初期化コールバックの登録解除

WLDataSourceインタフェースには、ConnectionInitializationCallbackの登録を解除するためのunregisterConnectionInitializationCallback()メソッドが用意されています。次の例は、初期化コールバックの削除方法を示しています。

. . .
import weblogic.jdbc.extensions.WLDataSource;
((WLDataSource)ds).unregisterConnectionInitializationCallback();
. . .

リプレイのタイムアウトの設定

WebLogic Server管理コンソールで、データ・ソースの「Oracle」タブにあるReplayInitiationTimeout属性を使用すると、接続のリプレイ・セッション・コンテキストをタイムアウトにして終了するまでに、データ・ソースでアプリケーション・コンティニュイティのリプレイ処理に許容する時間を設定できます。

WebLogic HTTPリクエスト・タイムアウトを使用するアプリケーションの場合は、ReplayInitiationTimeoutが適切に設定されていることを確認してください。

- ReplayInitiationTimeoutの値はHTTPセッション・タイムアウトの値と等しくなるように設定して、HTTPセッション全体がリプレイ・セッションでカバーされるようにする必要があります。デフォルトのReplayInitiationTimeoutとデフォルトのHTTPセッション・タイムアウトは、どちらも3600秒です。

- HTTPタイムアウト値がReplayInitiationTimeout値よりも長い場合、リプレイ・イベントはHTTPセッション全体には使用できなくなります。

- HTTPタイムアウト値がReplayInitiationTimeout値よりも短い場合は、アプリケーション側で接続を閉じてリプレイ・セッションを終了する必要があります。

アプリケーション・コンティニュイティの無効化

アプリケーション・コンティニュイティは、次のコードを使用することで、接続単位で無効化できます。

. . .
if (connection instanceof oracle.jdbc.replay.ReplayableConnection) {
((oracle.jdbc.replay.ReplayableConnection)connection).disableReplay();
}
. . .

アプリケーション・コンティニュイティをデータベース・サービス・レベルで無効化するには、サービスのフェイルオーバー・タイプをNONEに変更します。次に例を示します。

srvctl modify service -d mydb -s myservice -e NONE

アプリケーション・コンティニュイティをデータ・ソース・レベルで無効化するには、ReplayINitializationTimeoutを0に設定します。0 (ゼロ)秒に設定すると、リプレイ処理(フェイルオーバー)は無効化されます(beginおよびendRequestは引き続き呼び出されます)。

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

アプリケーション・コンティニュイティ処理のロギングを有効化するには、次の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にデプロイされたアプリケーションへのWebLogicロギング・サービスの追加』を参照してください。

JDBCドライバ・デバッグの有効化

JDBCドライバ・デバッグを有効化するには、Java Util Loggingを構成する必要があります。これを行うには、コマンド行で次のプロパティを設定します。

-Djava.util.logging.config.file=configfile
-Doracle.jdbc.Trace=true

このコマンドで、configfileは、ログ出力のフォーマットとロギング・レベルを制御するために標準のJDKロギングで使用される構成プロパティ・ファイル・プロパティのパスとファイル名です。

configfileには、次の行のいずれかが含まれる必要があります。

- oracle.jdbc.internal.replay.level=FINEST - リプレイ・デバッグ

- oracle.jdbc.level = FINEST - 標準JDBCデバッグ

詳細は、Java Platform Standard Edition 7 API仕様のjava.util.loggingに関する項を参照してください。

アプリケーション・コンティニュイティの実行時統計の表示

アプリケーション・コンティニュイティ(またはリプレイ)の統計は、汎用データ・ソースおよびActive GridLinkデータ・ソースのJDBCReplayStatisticsRuntimeMBeanを通じて使用できます。

JDBCReplayStatisticsRuntimeMBeanの特徴:

- 汎用データ・ソースおよびActive GridLinkデータ・ソースで使用できます。マルチ・データ・ソース(MDS)、プロキシ・データ・ソースおよびUCPデータ・ソースでは使用できません(NULLが返されます)。

- 12.1.0.2以降のOracle Thinドライバとともに実行する場合のみ使用できます。これより前のドライバ・バージョンでは使用できません(NULLが返されます)。

- データ・ソースがリプレイ・ドライバを使用するように構成されている場合のみ使用できます。非リプレイ・ドライバ(OracleドライバやXAドライバなど)では使用できません(NULLが返されます)。

- 初期設定された統計はありません(それらは-1に初期化されます)。MBeanのrefreshStatistics()操作を呼び出して、取得の前に統計を更新する必要があります。

注意:
統計のリフレッシュは、負荷の高い操作です。プール全体がロックされ、統計を集計するために予約済および未予約の接続がすべて調査されます。この操作を頻繁に実行すると、データ・ソースのパフォーマンスが影響を受けます。パフォーマンスは、統計をクリアする場合にも影響を受ける可能性があります。

表10-1は、JDBCReplayStatisticsRuntimeMBeanを使用してアクセスできる統計を示しています。

表10-1 JDBCReplayStatisticsRuntimeMBeanの実行時統計

名前

説明

TotalRequests

正常に送信されたリクエストの合計数。

TotalCompletedRequests

完了したリクエストの合計数

TotalCalls

実行済JDBCコールの合計数。

TotalProtectedCalls

アプリケーション・コンティニュイティで保護された実行済JDBCコールの合計数。

TotalCallsAffectedByOutages

停止の影響を受けるJDBCコールの合計数。これには、ローカル・コールと、データベース・サーバーへのラウンドトリップを含むコールの両方が含まれます。

TotalCallsTriggeringReplay

リプレイをトリガーしたJDBCコールの合計数。リプレイは一部のリクエストで無効化されることがあるため、すべてのコールが停止トリガー・リプレイの影響を受けるわけではありません。

TotalCallsAffectedByOutagesDuringReplay

リプレイの実行中に停止の影響を受けるJDBCコールの合計数。停止は、カスケードされ、リプレイの進行中にコールが複数回起動する可能性があります。アプリケーション・コンティニュイティは、最大再試行制限に到達していないかぎり、これが発生するとリプレイを自動的に再試行します。

SuccessfulReplayCount

成功したリプレイの合計数。リプレイの成功により、停止はアプリケーションから隠蔽されます。

FailedReplayCount

失敗したリプレイの合計数。

リプレイが失敗すると、元の例外に関連付けられた失敗の理由とともに、アプリケーションに元のSQLRecoverableExceptionが再スローされます。アプリケーションは、理由を取得するためにgetNextExceptionを呼び出すことができます。

ReplayDisablingCount

リプレイが無効化された合計回数。

リクエストの実行中にリプレイが無効化されると、そのリクエストの残りのコールは、アプリケーション・コンティニュイティによって保護されなくなります。停止によって残りのコールのいずれかが起動すると、リプレイは試行されず、アプリケーションはSQLRecoverableExceptionを受け取ります。

TotalReplayAttempts

リプレイ試行の合計数。アプリケーション・コンティニュイティは、リプレイの失敗時に自動的に再試行するため、この数は、リプレイをトリガーしたJDBCコールの数を超える可能性があります。

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

- Oracle WebLogic Server MBeanリファレンスのJDBCReplayStatisticsRuntimeMBeanに関する項

- Oracle JDBC Java APIリファレンスのReplayableConnection.StatisticsReportTypeに関する項

WLSTのサンプル

WLSTを使用してランタイムMBeanの統計にアクセスできます。次のサンプルのWLSTスクリプトは、JDBCReplayStatisticsRuntimeMBeanの情報を出力する方法を示しています。

import sys, socket, os
hostname = socket.gethostname()
datasource='JDBC GridLink Data Source-0'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
serverRuntime()
cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' +
datasource + '/JDBCReplayStatisticsRuntimeMBean/' +
datasource + '.ReplayStatistics')
cmo.refreshStatistics()
ls()
total=cmo.getTotalRequests()
cmo.clearStatistics()

Javaのサンプル

次のJavaの例は、JDBCReplayStatisticsRuntimeMBeanを使用して統計を公開する方法を示しています。

import javax.naming.NamingException;
import javax.management.AttributeNotFoundException;
import javax.management.MBeanServer;
import javax.management.InstanceNotFoundException;
import javax.management.ReflectionException
import javax.management.ObjectName;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanAttributeInfo;
import javax.management.MBeanOperationInfo;
import javax.management.MBeanException;
import javax.management.MBeanParameterInfo;
import weblogic.management.runtime.JDBCReplayStatisticsRuntimeMBean;
public void printReplayStats(String dsName) throws Exception {
MBeanServer server = getMBeanServer();
ObjectName[] dsRTs = getJdbcDataSourceRuntimeMBeans(server);
for (ObjectName dsRT : dsRTs) {
String name = (String) server.getAttribute(dsRT, "Name");
if (name.equals(dsName)) {
ObjectName mb = (ObjectName)server.getAttribute(dsRT,
"JDBCReplayStatisticsRuntimeMBean");
server.invoke(mb, "refreshStatistics", null, null);
MBeanAttributeInfo[] attributes =
server.getMBeanInfo(mb).getAttributes();
for (int i = 0; i < attributes.length; i++) {
if (attributes[i].getType().equals("java.lang.Long")) {
System.out.println(attributes[i].getName()+"="+
(Long) server.getAttribute(mb, attributes[i].getName()));
}
}
}
}
}
MBeanServer getMBeanServer() throws Exception {
InitialContext ctx = new InitialContext();
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
return server;
}
ObjectName[] getJdbcDataSourceRuntimeMBeans(MBeanServer server)
throws Exception {
ObjectName service = new ObjectName(
"com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime .RuntimeServiceMBean");
ObjectName serverRT = (ObjectName) server.getAttribute(service,
"ServerRuntime");
ObjectName jdbcRT = (ObjectName) server.getAttribute(serverRT,
"JDBCServiceRuntime");
ObjectName[] dsRTs = (ObjectName[]) server.getAttribute(jdbcRT,
"JDBCDataSourceRuntimeMBeans");
return dsRTs;
}

Oracle 12cデータベースにおけるアプリケーション・コンティニュイティに関する制限

Oracle Database Release 12cをアプリケーション・コンティニュイティと組み合せて使用する場合、次の制限が適用されます。

- DRCPはサポートされません。つまり、Webリクエストはリプレイされず、停止が発生した場合は元のjava.sql.SQLRecoverableExceptionがスローされます。

- ALTER SESSION SET CONTAINERを使用したPDBテナント切替えと併用できません。

データベース常駐接続プーリング

データベース常駐接続プーリング(DRCP)により、Oracleデータベースに常駐する複数のWeb層および中間層のデータ・ソースで、データベース・サーバーの処理とセッションをプールできるようになります。Database Resident Connection Pooling (DRCP)を参照してください(http://www.oracle.com/technetwork/articles/oracledrcp11g-1-133381.pdf)。

次の各項では、WebLogic ServerでのDRCPの使用と構成について説明します。

- 要件および考慮事項

- DRCP対応データ・ソースの構成

要件および考慮事項

次の項では、WebLogicアプリケーションでDRCPを使用する際の要件と考慮事項について説明します。

- Oracle 12c JDBCドライバとデータベースは必須です。付録A「Oracle 12cデータベースの使用」を参照してください。

- WebLogicの文キャッシュがDRCPと併せて構成されている場合、その文キャッシュは接続がclose()でプールに返されるたびにクリアされます。

- WebLogic Serverのデータ・ソースは、DRCP接続にラベリングする接続をサポートしていないため、SQLExceptionがスローされます。たとえば、WLDataSourceのプロパティにgetConnectionを使用したり、LabelableConnectionのメソッドが呼び出されると、例外が生成されます。ただし、WLDataSourceのregisterConnectionLabelingCallbackおよびremoveConnectionLabelingCallbackは許可されています。

- WebLogic Serverは、システム・プロパティとしてのoracle.jdbc.DRCPConnectionClassの定義をサポートしていません。これは、接続プロパティとしてデータ・ソース記述子で定義する必要があります。

- DRCPを効果的にするために、アプリケーションは処理の完了後にできるだけ早く接続プールに接続を返す必要があります。接続を保持して収集を使用すると、DRCPの使用が無意味になります。

- DRCPを使用する場合、JDBCプログラムは、接続に対して操作を実行する前にサーバーにアタッチする必要があり、プールされたセッションを他の接続で使用できるようにサーバーからデタッチする必要があります。デフォルトでは、JDBCプログラムがサーバーにアタッチしている場合、それは実際にはセッションを予約しませんが、予約を返して次のデータベース・ラウンドトリップまで遅延させます。結果として、後続のデータベース操作は、セッションを予約できないために失敗する可能性があります。これが発生することを避けるため、サーバーへのアタッチ後にデータベースへのラウンドトリップを強制するネットワーク・タイムアウト値があります。これが発生すると、ネットワーク・タイマーは設定解除されます。デフォルトのネットワーク・タイムアウトは、10,000ミリ秒です。これを別の値に設定するには、システム・プロパティweblogic.jdbc.attachNetworkTimeoutを設定します。
このプロパティは、アタッチの実行とデータベース・ラウンドトリップの返却を待機するタイムアウト(ミリ秒)です。0に設定すると、サーバー・アタッチに関する追加処理は実行されません。

DRCPの構成の詳細は、『Oracle® Database管理者ガイド』のデータベース常駐接続プーリングの構成に関する項を参照してください。

DRCPの構成

次の各項では、対象の環境にDRCPを構成する方法について説明します。

- DRCP対応データ・ソースの構成

- DRCP対応データベースの構成

DRCP対応データ・ソースの構成

DRCPをサポートするようにデータ・ソースを構成するには:

- 新しいデータ・ソースを作成する場合は、データ・ソースの構成ウィザードの追加構成プロパティの下にある「接続プロパティ」タブで、「oracle.jdbc.DRCPConnectionClass」フィールドにDRCP接続クラスを入力します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC汎用データ・ソースの作成に関する項およびJDBC GridLinkデータ・ソースの作成に関する項を参照してください。
結果として、データ・ソースは次のようになります。

- 作成された短縮形のURLに、接尾辞:POOLEDが追加されます。例: jdbc:oracle:thin:@//host:port/service_name:POOLED

- サービス形式のURLの場合は、CONNECT_DATA要素の(SERVICE_NAME=name)パラメータの後に(SERVER=POOLED)が追加されます。

- DRCP接続クラスの値/名前ペアは、「接続プール」タブに接続プロパティとして表示されます。例: oracle.jdbc.DRCPConnectionClass=myDRCPclass。

- 管理コンソールで既存のデータ・ソースを編集する場合は、「接続プール」タブを選択して、次の手順を実行します。

- 「URL」を変更して、接尾辞:POOLEDを含めます。サービスURLの場合は、(SERVER=POOLED)を含めます。

- 接続のプロパティを更新して、DRCP接続クラスの値/名前ペアを含めます。例: oracle.jdbc.DRCPConnectionClass=myDRCPclass。

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

- テキスト・エディタまたはWLSTを使用して、データ・ソースを作成または編集する場合は、次の手順を実行します。

- URL要素を変更して、接尾辞:POOLEDを含めます。サービスURLの場合は、(SERVER=POOLED)を含めます。例: <url>jdbc:oracle:thin:@host:port:service:POOLED</url>

- 接続のプロパティを更新して、DRCP接続クラスの値/名前ペアを含めます。次に例を示します。

<properties>
<property>
<name>aname</name>
<value>avalue</value>
</property>
<property>
<name>oracle.jdbc.DRCPConnectionClass</name>
<value>myDRCPclass</value>
</property>
</properties>

- データ・ソース定義に、oracle.jdbc.DRCPConnectionClass接続プロパティまたはPOOLED URLのどちらか一方のみが含まれている場合、WebLogic Serverは構成エラーをスローします。この検証が実行されるのは、コンソールで接続リスナーをテストする場合、システム・ブート中にデータ・ソースをデプロイする場合、またはデータ・ソースをターゲット指定する場合です。

- TestConnectionsOnReserve=trueを設定して、MAX_THINK_TIMEによる問題を最小化します。「DRCP対応データベースの構成」を参照してください。

- TestFrequencySecondsには、INACTIVITY_TIMEOUTよりも小さい値を設定します。「DRCP対応データベースの構成」を参照してください。

DRCP対応データベースの構成

DRCPをサポートするようにOracleデータベースを構成するには:

- DRCPは、データベース側で有効化する必要があります。DRCPの有効化には、次のコマンドを使用します。
SQL> DBMS_CONNECTION_POOL.CONFIGURE_POOL('SYS_DEFAULT_CONNECTION_POOL')

SQL> EXECUTE DBMS_CONNECTION_POOL.START_POOL();

- 次に示すサーバー・プール構成のパラメータは、適切に設定する必要があります。

- MAXSIZE: プール内の最大プール・サーバー数。デフォルト値は40です。接続プールでは、プールされたサーバーの5%が認証用に確保され、プールされたサーバーの少なくとも1つは認証用に常時確保されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。
MAXSIZEには、DRCPを使用する最大のWebLogic接続プールのサイズを設定してください。

- INACTIVITY_TIMEOUT: プール内のプール・サーバーがアイドル状態を維持する最大時間(秒単位)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。サーバー・プールのサイズがMINSIZEの場合には、このパラメータは適用されません。
WebLogicデータ・ソースから確保した接続が使用されていない場合は、非アクティブのタイムアウトが発生して、DRCP接続が解放されます。INACTIVITY_TIMEOUTを適切に設定するか、使用されない接続はWebLogicデータ・ソースに返すようにしてください。TestFrequencySecondsを使用して、未使用の接続がタイムアウトにならないようにすることもできます。

- MAX_THINK_TIME: クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいられる最大時間(秒単位)。クライアント・アプリケーションが、プールからプール・サーバーを取得した後、MAX_THINK_TIMEで指定した時間内にデータベース・コールを発行しない場合、プール・サーバーは解放されてクライアント接続が終了します。デフォルト値は120です。
WebLogicデータ・ソースから確保した接続は、MAX_THINK_TIME以内にアクティビティがないと、その接続は解放されます。Test Connections On Reserveを設定するか(「予約済の接続のテスト」を参照)、MAX_THINK_TIMEを適切に設定します。接続テストのオーバーヘッドを最小限に抑えるには、SecondstoTrustanIdlePoolConnectionに、MAX_THINK_TIMEよりも小さい合理的な値を設定します。第20章「データ・ソース接続プールのチューニング」を参照してください。

サーバー・プールの構成パラメータが環境で正しく設定されていない場合、WebLogicデータ・ソース接続にアクセスしたときに、データ・ソース接続が終了し、アプリケーションでソケット例外などのエラーを受信する可能性があります。

Global Database Services

Global Data Services (GDS)により、分散データベース環境でシームレスな集中管理を提供するグローバル・サービスが使用できるようになります。グローバル・サーバーは、複数のOracle RACおよび単一インスタンスのOracleデータベースをData GuardやGoldenGateなどのレプリケーション技術で相互接続して、それら全体でのロード・バランシング、フォルト・トレランスおよびリソース使用率を自動化します。

次の各項では、WebLogic ServerのGDSに対する要件と構成について説明します。

- 要件および考慮事項

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

要件および考慮事項

次の項では、WebLogic ServerでGlobal Database Servicesを使用する際の要件と考慮事項について説明します。

- Oracle 12c JDBCドライバとデータベースは必須です。付録A「Oracle 12cデータベースの使用」を参照してください。

- 単一のSCANアドレスを使用して、複数のGlobal Service Manger (GSM)アドレスを置換することはできません。

- 更新操作が適切に処理されるようにするには、プライマリ・データベースでのみ有効になる更新用のサービスを定義する必要があります。

- プライマリ・データベースとセカンダリ・データベースに配置される読取り専用操作のサービスは個別に定義してください。

- 1つのURLに定義できるサービスは1つに限られ、1つのデータ・ソース構成に定義できるURLは1つになるため、一方のデータ・ソースを更新サービス用に定義し、もう一方のデータ・ソースを読取り専用サービス用に定義する必要があります。

- 更新操作が更新データ・ソースで処理され、読取り専用操作が読取り専用データ・ソースで処理されるように、アプリケーションを作成する必要があります。

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

WebLogic Server管理コンソールを使用して、GridLinkデータ・ソースを作成します。このデータ・ソースでは、GDS接続を提供するように変更したURLを使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成に関する項を参照してください。

GDS URLの接続情報は、Oracle 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 Databaseの機能で、1つのCDB内に複数のプラガブル・データベース(PDB)を持つ単一のデータベースに多数のデータベースを統合して、多数のデータベースによるオーバーヘッドを最小限に抑えます。『Oracle Database管理者ガイド』のCDBの作成および構成に関する項を参照してください。

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

- DRCPおよびCDB/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;
/

DRCPおよびCDB/PDB

DRCPは、PDBでは使用できません。CDBにのみ関連付ける必要があります。構成する場合は、CDBを指すようにセッションを設定して、DRCPプールを開始します。次に例を示します。

alter session set container = cdb$root;
execute dbms_connection_pool.configure_pool('SYS_DEFAULT_CONNECTION_POOL');
execute dbms_connection_pool.start_pool();

JDBCを使用したPDBの設定

初めてプールの接続を作成するときには、CDB内の特定のPDBに関連付けられたサービスを含むURLを使用して接続を作成します。同じCDB内では、動的なPDBの変更が可能です。PDBを変更するには、次のSQL文を実行します。

ALTER SESSION SET CONTAINER = name;

コンテナの変更後は、次の項目が変更できなくなります。

- Oracle RACインスタンス

- 接続オブジェクト

- WebLogicの接続ライフサイクル(enabled/disabled/destroyed)

- WebLogicの接続属性。

それ以外の接続に関する状態は、PDB間での情報の漏洩を防止するために消去されます。

構成後には、次の項目がリセットされます。

- アプリケーション・コンティニュイティ(リプレイ)

- DRCP

- クライアント識別子

- プロキシ・ユーザー

- 接続収集コールバック。

テナントの切替えに関する制限

ALTER SESSION SET CONTAINERを使用してテナント間で切替えを行う場合、新しいPDBでどのユーザー・サービスに切り替えるかを示すメカニズムが現在ありません。かわりに、そのテナントのPDBサービスが使用されます。PDBサービスは、各PDB用に作成される管理サービスです(したがって、各PDBには少なくとも1つの管理サービスがあります)。これは管理サービスであり、ユーザー・レベルのサービス機能はサポートされていません。将来のデータベース・リリースでは、ユーザー・サービスを許可することによって、こうした制限は削除される予定です。

データベース・リリース12.1でテナントの切替えを使用する場合、WebLogic Serverには他にも次の制限事項があります。

- XAトランザクションおよびグローバル・トランザクションはサポートされません。

- FANはサポートされません。FANはサポートされませんが、ただしActive GridLinkにより、複数のOracle RACインスタンスの単一のデータ・ソース・ビューという利点が得られ、また接続ロード・バランシングを使用して再構成を行うことなく接続が利用可能なため、新しいインスタンスで接続を予約する機能が得られます。メトリックがサポートされないため、この接続ロード・バランシングはセッションの数だけに基づいています。Active GridLinkデータ・ソースによるテナントの切替えを使用する場合は、「FANの有効化」をfalseに設定する必要があります。ランタイム・ロード・バランシングは、既存の接続を最適に予約するためには(ローカルでもグローバル・データ・サービスでも)使用できません。かわりに、接続の割当てにはラウンドロビンを使用します。これは、ランタイム・ロード・バランシングの情報が利用不可であるため接続グラビティションがサポートされていないことも意味します。セッション・アフィニティはサポートされません。(自動ONSを含めて) ONSはサポートされず、このことは、Global Data ServicesやActive Data Guardのような機能にも影響を与えます。WebLogicでは、インスタンスが停止しているかどうかを確認するために、DOWNイベントを受信するかわりに接続テストが使用されます。これがAGLにとって意味することの詳細は、FAN通知を使用しないActive GridLinkデータ・ソースの使用を参照してください。トランザクション・アフィニティはFANに基づいていないため影響を受けません。汎用データ・ソースには(FANを使用しないため)この制限は適用されません。

- DRCPはサポートされません。接続が、データベースに存在するリクエストしたテナントと一致しない接続プールから選択された場合は、エラーが発生します(サービスの切替えはDRCPでサポートされていません)。WebLogic Serverは接続を選択する際にテナントとの一致を行わないため、有効な接続が選択されている保証はありません。

- アプリケーション・コンティニュイティはサポートされません。必要な属性(FAILOVER_TYPE=TRANSACTIONおよびCOMMIT_OUTCOME=true)をPDBサービスで設定できません。

- プロキシ認証はサポートされていません。java.sql.SQLException "ORA-01017: invalid username/password"がスローされます。

- サービスに基づく多くのデータベース機能(サービスに基づく管理操作、サービスベースのメトリック、Enterprise Managerのトップ・コンシューマ、データベース・サービスベースのアラート、ユーザー・サービスへのパラレル問合せの制限など)が使用できません。

11 接続のラベル付け

この章では、接続にラベルを付けてパフォーマンスを向上させる方法について説明します。

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

- 接続ラベリングとは

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

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

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

- ラベル付けされた接続の予約

- 不一致ラベルのチェック

- 接続ラベルの削除

- 初期化および再初期化コストを使用した接続の選択

- パッケージ・アプリケーションによる接続ラべリングの使用

接続ラベリングとは

多くの場合、アプリケーションは、接続プールから取得した接続を使用する前に初期化します。初期化は一様ではなく、アプリケーション・コード内でメソッド・コールを必要とする単純な状態の再初期化や、ネットワーク上でのラウンドトリップを必要とするデータベース操作などがあります。このような初期化のコストは非常に高い場合があります。

接続のラベル付けを使用すると、アプリケーションが接続に任意の名前/値のペアを付けることができます。アプリケーションは、必要なラベルが付いた接続を接続プールにリクエストできます。特定のラベルと特定の接続状態を関連付けることで、すでに初期化されている接続をプールから取得し、再初期化の時間とコストを回避できます。接続ラベリング機能は、ユーザー定義キーまたは値に意味を与えません。ユーザー定義キーおよび値の意味は、アプリケーションでのみ定義されます。

接続ラベリングの例には、ロール、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の両メソッドを実装する単純なラベリング・コールバックの実装を示します。このコールバックは、特定のトランザクション分離レベルで初期化されるラベル付けされた接続の検出に使用されます。

例11-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;
}
}

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

WebLogic Serverデータ・ソースは、ラベリング・コールバックを登録するためのregisterConnectionLabelingCallback(ConnectionLabelingCallback callback)メソッドを備えています。1つの接続プールに登録できるコールバックは1つのみです。次のコード例では、MyConnectionLabelingCallbackクラスに実装されているラベリング・コールバックの登録を示します。

. . .
import weblogic.jdbc.extensions.WLDataSource;
. . .
MyConnectionLabelingCallback callback = new MyConnectionLabelingCallback();
((WLDataSource)ds).registerConnectionLabelingCallback( callback );
. . .

WebLogic Server管理コンソールを使用してコールバックを登録することもできます。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);
. . .

ラベル付けされた接続の予約

WebLogic Serverデータ・ソースは、プールからラベル付けされた接続を予約するために使用する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);
. . .

初期化および再初期化コストを使用した接続の選択

一部のアプリケーションでは、接続プールが高コストの接続を識別し、接続数が一定のしきい値を下回った場合に、これらの接続を使用してリクエストを処理しないようにする機能が求められます。これにより、すでにプールにある他のテナント接続に再初期化のオーバーヘッドを発生させることなく、プールが最新の物理接続を使用して様々なテナントからの接続リクエストを処理できるようになります。

WebLogic Serverでは、高コストの接続を識別するために、次の接続プロパティを用意しています。

- ConnectionLabelingHighCost: 0よりも大きい値の場合、コスト値がこのプロパティ値以上である接続は高コストの接続と見なされます。デフォルト値はInteger.MAX_VALUEです。
たとえば、プロパティの値を5に設定した場合、ラベリング・コールバックから計算されたコスト値が5以上の接続はすべて高コストの接続と見なされます。

- HighCostConnectionReuseThreshold: 0より大きい値の場合、プール内の接続数合計のしきい値を指定し、この値より大きい場合、接続ラべリングはリクエストを処理するためにプール内で高コストの接続を再利用できます。このしきい値を下回れば、接続ラべリングは使用可能な低コストの接続を使用するか、まったく新しい物理接続を作成してリクエストを処理します。デフォルト値は0です。
たとえば、20に設定した場合、使用可能な低コストの接続が存在せず、接続の合計数が20に到達すると、接続ラべリングは高コストの接続を再利用します。

構成プロパティの構成の詳細は、次の各項を参照してください。

- 汎用データ・ソースの詳細は、「汎用の接続プール機能の構成」を参照してください。

- AGLデータ・ソースの詳細は、「AGL接続プール機能の構成」を参照してください。

初期化および再初期化コストを使用する場合の考慮事項

この項では、接続コストに基づいて接続を選択する場合の追加の考慮事項について説明します。

- 有効なコールバック登録によって接続ラべリングがアクティブ化されます。登録後、接続プールは定期的に新しいしきい値をチェックして、次のことを判断します。

- ConnectionLabelingHighCost以上のコストが接続に発生しているかどうか。

- 接続数の合計が、MinCapacityおよびMaxCapacityの制限を含む、アクティブな接続作成リクエストの数を表しているかどうか。

- 新しいしきい値に達しても、コスト値がInteger.MAX_VALUEのラベル付けされた接続は再利用されません。

- ラベル付けされた接続リクエストを処理するために、プール内のラベル付されていない(ステートレスな)接続を再利用してはならないという要件はありません。HighCostConnectionReuseThresholdに達して、接続ラべリングがアクティブ化されると、新しい物理接続を作成するより、プールでは引き続きラベル付されていない(ステートレスな)接続が優先されます。

パッケージ・アプリケーションによる接続ラべリングの使用

WebLogic Serverでは、EARまたはWARファイル内のラべリングや接続初期化などのコールバックをパッケージ・アプリケーションで使用できます。

データ・ソース構成でアプリケーションでパッケージ化されたコールバック・クラスを定義するには:

- アプリケーションの一部としてデータ・ソースを定義します。
たとえば、コールバックの実装クラスがWARにパッケージ化されているか、アプリケーションから参照される共有ライブラリの一部として定義されている場合、EARファイルには、モジュール・ディスクリプタ内でコールバック・クラス名を参照する、アプリケーションでパッケージ化されたデータ・ソース構成が含まれます。

- weblogic-application.xmlファイルのアプリケーション・クラス・ローダー階層の一部として、(コールバックの実装を含む)アプリケーションWARファイルを指定します。
次に例を示します。

. . .
<classloader-structure>
<module-ref>
<module-uri>appcallbacks.war</module-uri>
</module-ref>
</classloader-structure>

パッケージ・アプリケーションでラベル付けされた接続を使用する場合の考慮事項

WebLogic Serverでは、コールバック・クラスをアプリケーションにパッケージ化するときに、グローバル・スコープのデータ・ソース・システム・リソースに対して、モジュール・ディスクリプタ内に接続ラべリング・コールバックまたは接続初期化コールバックを指定することはできません。グローバル・データ・ソースでは、コールバックの実装クラスがWebLogicクラスパス上に存在する必要があります。ただし、WARまたはEARにパッケージ化されるアプリケーション・コールバックに対するこの制限は、Oracle WebLogic Server Java APIリファレンスのWLDataSourceインタフェースに関する項を使用して、アプリケーションが実行時にコールバックを登録するようにすることで回避できます。

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

この章では、WebLogicデータ・ソースのXA、非XAおよびグローバル・トランザクション・オプションについて説明します。

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

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

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

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

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

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

- 2フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。「2フェーズ・コミットのエミュレート・トランザクション・オプションの理解」を参照してください。

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

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

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

- 「ロギング・ラスト・リソース」トランザクション・オプションの理解

- 2フェーズ・コミットのエミュレート・トランザクション・オプションの理解

- 接続クローズ時のローカル・トランザクションの完了

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

アプリケーションでグローバル・トランザクションを使用する場合、JDBCデータ・ソースでデータベース接続を作成するために、XA JDBCドライバを使用する必要があります。XAドライバが使用できないデータベースの場合、またはXAドライバを使用しないことを選択した場合は、データ・ソースでのグローバル・トランザクションのサポートを有効化する必要があります。また、アプリケーションが次の条件に適合する場合も、グローバル・トランザクションのサポートを有効化する必要があります。

- トランザクションの管理にWebLogic ServerのEJBコンテナを使用する。

- 1回のトランザクション中に複数のデータベース更新が含まれる。

- トランザクション中に、データベース、Java Messaging Service (JMS)など複数のリソースにアクセスする。

- 複数のサーバー(クラスタリングされた、またはクラスタリングされていない)上で同一のデータ・ソースを使用する。

EJBアーキテクチャでは、一般的に、データベース処理を行う複数のEJBが単一のトランザクションの一部として呼び出されます。XAがない場合、これを行う唯一の方法は、すべてのトランザクション参加者がまったく同じデータベース接続を使用することです。グローバル・トランザクションを有効化して、「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を選択すると、WebLogic Serverは、JTSドライバを内部で使用して、EJB間で接続を明示的に渡さなくても、すべてのEJBが同じトランザクション・コンテキスト内で同じデータベース接続を確実に使用するようにします。

複数のEJBが1つのトランザクションに参加し、かつデータベース接続にXA JDBCドライバを使用しない場合は、次のオプションを使用してデータ・ソースを構成します。

- 「グローバル・トランザクションのサポート」を選択

- 「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を選択

この構成により、JTSドライバは、同じトランザクション内のすべてのデータベース処理に同じデータベース接続を内部で強制的に使用します。

XA (XAドライバが必須)では、EJBはトランザクションの各部分に対して、別々のデータベース接続を使用できます。WebLogic Serverは、2フェーズ・コミット・プロトコルを使用してトランザクションを調整します。これにより、トランザクションがすべて完了するか、まったく完了しないかのどちらかになります。

「ロギング・ラスト・リソース」トランザクション・オプションの理解

WebLogic Serverは、JDBCデータ・ソースを通じてのロギング・ラスト・リソース(LLR)トランザクションの最適化をサポートしています。LLRは、パフォーマンス向上のためのオプションであり、1つの非XAリソースが、XAと同じACID保証を使用してグローバル・トランザクションに参加できるようにします。LLRは、最後のエージェントによる最適化を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるという点です。LLRリソースは、トランザクション処理にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。

LLRの最適化では、次によりパフォーマンスが向上します。

- XA JDBCドライバがデータベースに接続する必要がなくなります。XA JDBCドライバは、一般的に、非XA JDBCドライバに比べて非効率的です。

- トランザクションを完了させるまでの処理手順の数が少なくなり、それによりネットワーク・トラフィックとディスクI/O数も減少します。

- データベース・レベルでのXA処理の必要性がなくなります。

LLR用に構成されたデータ・ソースからの接続が、2フェーズ・コミット(2PC)グローバル・トランザクションに参加する場合、WebLogic Serverトランザクション・マネージャは次の処理によって、トランザクションを完了させます。

- 他のすべての(XA対応の)トランザクション参加リソースに対するprepareの呼出し。

- (ファイル・ベースのトランザクション・ログではなく)LLR参加リソースの表へのコミット・レコードの挿入。

- LLR参加リソースのローカル・トランザクション(トランザクション・コミット・レコードの挿入とアプリケーションのSQL処理の両方を含む)のコミット。

- その他すべてのトランザクション参加リソースに対するcommitの呼出し。

1フェーズ・コミット(1PC)のグローバル・トランザクションの場合、LLRはローカル・トランザクションを使用してデータベース操作を完了させることによって、XAオーバーヘッドを排除しますが、2PCトランザクション・レコードはデータベースへ書き込まれません。

ロギング・ラスト・リソースの最適化により、LLR参加リソースに対するコミット・レコードが書き込まれ、データの整合性が維持されます。ローカル・トランザクション・コミットの最中にトランザクションが失敗した場合、WebLogic Serverトランザクション・マネージャは、他のすべてのトランザクション参加リソースに対してトランザクションをロールバックします。失敗からリカバリするため、WebLogic Serverトランザクション・マネージャはデフォルトのストアにある他のトランザクション・ログ・ファイルと一緒にLLRリソース上のトランザクション・ログを読み取り、必要なすべてのトランザクション処理を完了させます。XA参加リソースと関連付けられた処理は、コミット・レコードが存在する場合はコミットされます。それ以外の場合、処理はロールバックされます。

LLR対応のJDBCデータ・ソースを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。ロギング・ラスト・リソース・トランザクション処理の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。

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

使用している環境によっては、パフォーマンス上の利点を得るために、トランザクション処理用として、2フェーズ・コミット・プロトコルのかわりにLLRトランザクション・プロトコルを検討する必要があります。LLRトランザクション・プロトコルには、次の利点があります。

- 非XA JDBCドライバ、さらにはXA非対応データベースも、2フェーズ・コミット・トランザクションに安全に参加できます。

- XAプロトコルがデータベースで使用されなくなります。

- JDBC XA接続よりもパフォーマンスが向上します。

- データベースの行ロックが保持される時間が短縮されます。

- 他のXA処理よりも先に、データベース処理が常にコミットされます。XAトランザクションでは、これらの操作は並列にコミットされます。したがって、たとえばJMS送信がトランザクションに参加する場合、JMSメッセージはデータベース処理のコミット前に配信されます。LLRでは、ローカル・トランザクションにおけるデータベース処理は、他のすべてのトランザクション処理よりも前に完了されます。

- JDBCデータ・ソースの「2フェーズ・コミットのエミュレート」オプションと異なり、ヒューリスティック障害のリスクが増大しません。

注意:
LLR最適化により、挿入、更新および削除の操作において、パフォーマンスが大幅に向上します。ただし、LLRでの読取り操作では、XAでの読取り操作と比べて、パフォーマンスが若干低下します。
LLRでのパフォーマンス・チューニングの詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のLLRでのパフォーマンスの最適化に関する項を参照してください。

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

LLRトランザクション最適化を有効化するには、ロギング・ラスト・リソース・トランザクション・プロトコルを使用するJDBCデータ・ソースを作成し、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。

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

アプリケーションで、LLR対応データ・ソースからのJDBC接続を、その他のデータ・ソースからのJDBC接続と同じように使用します。トランザクションの開始後、JNDIツリーでデータ・ソースをルックアップし、その後データ・ソースからの接続をリクエストします。ただし、LLR最適化が行われていると、WebLogic Serverは接続のリクエストを内部で管理し、トランザクション処理をXAトランザクションとは異なった方法で扱います。ロギング・ラスト・リソースの処理方法の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。

次の点に注意してください。

- LLRデータ・ソースでプログラミングを行う場合は、LLRデータ・ソースに対してgetConnectionをコールする前に、グローバル・トランザクションを開始する必要があります。グローバル・トランザクションを開始する前にgetConnectionをコールした場合、接続は独立したものとなり、その後で開始されるグローバル・トランザクションに関連付けられません。接続はautoCommit(true)モードで動作します。このモードでは、すべての更新がそのまま自動的にコミットされます。アプリケーション・コードでautoCommitの状態を明示的にfalseに設定して、独自のローカル・トランザクションを明示的に管理しないかぎり、更新をロールバックする方法はありません。

- 1つのトランザクションには、1つの内部JDBC LLR接続しか予約されません。その接続が、トランザクション処理全体を通して使用されます。

- 予約された接続は、トランザクションのコーディネータ・サーバーに常にホストされます。データ・ソースのターゲットには、必ずコーディネートしているサーバーまたはクラスタを指定してください。『Oracle WebLogic Server JTAアプリケーションの開発』のLLRでのパフォーマンスの最適化に関する項も参照してください。

- 同一名のデータ・ソースからのトランザクション内での追加のJDBC接続リクエストについては、後続の接続リクエストが、データ・ソースの別のインスタンス(つまり、最初のリクエストに対して接続を供給した元のデータ・ソースとは異なるサーバーにデプロイされているデータ・ソース)に対して行われていたとしても、操作は元の接続リクエストから予約された接続にルーティングされます。次の点に注意してください。

- ルーティングされたLLR接続は、ローカルでホストされているXA接続よりも、機能やパフォーマンスの点で劣ります。(「複数サーバー構成における非XAリソースのパフォーマンス低下の可能性」を参照してください。)

- 接続リクエストをルーティングすると、同時トランザクションの数が制限されます。同時LLRトランザクションの最大数は、コーディネータのJDBC LLRデータ・ソースの構成済サイズ(MaxCapacity)と同じです。

- ルーティングされた接続は、ローカル接続より機能が低下しており、その結果、失敗する可能性があります。特に、問合せResultSet内のシリアライズできないカスタム・データ型は失敗する可能性があります。

- 単一LLRデータ・ソースのインスタンスのみが、特定のトランザクションに参加できます。単一LLRデータ・ソースは、複数のWebLogicサーバーに対してインスタンスを持つ場合があり、2つのデータ・ソースは、構成された名前が同じ場合、同一とみなされます。複数のLLRデータ・ソース・インスタンスが検出され、それらが同じデータ・ソースのインスタンスでない場合、トランザクション・マネージャはトランザクションをロールバックします。

- weblogic.transaction.nonxa.NonXAResourceインタフェースを実装するリソース・アダプタ(コネクタ)は、LLRリソースもまた参加しているグローバル・トランザクションには参加できません。どちらも、トランザクションの最後のリソースである必要があるためです。双方のリソース・タイプが同じトランザクションに参加している場合、この競合が検出されると、トランザクションのcommit()メソッドが、javax.transaction.RollbackExceptionをスローします。

- LLR接続では、データベース処理に別個のローカル・トランザクションを使用するため、XA接続を使用して同じデータベースに加えられた変更(および保持されるロック)はすべて、全処理が同じグローバル・トランザクション内で発生するとしても、LLR処理の最中には認識されません。場合によっては、これによりデータベースにデッドロックが発生します。単一のグローバル・トランザクションにおいて、同一データベース内でXA処理とLLR処理を組み合せることはできません。

- LLRデータ・ソースからの接続は、リモート・オブジェクト・リクエスト・ブローカやTuxedoによって開始されたトランザクションなど、外部トランザクション・マネージャが調整するトランザクションには参加できません。

- グローバル・トランザクションは、LLRデータ・ソースと同じ名前のデータ・ソースを含む別の従来ドメインまでは波及できません。

- JDBC LLR 2PCトランザクションでは、トランザクション・データが大きすぎてLLR表内に収まらない場合、トランザクションはコミット中にロールバック例外がスローされて失敗します。アプリケーションがトランザクション処理中に多数のトランザクション・プロパティを追加した場合、これが発生する可能性があります。(『Oracle WebLogic Server JTAアプリケーションの開発』のJTAのOracle WebLogic拡張機能に関する項を参照してください。)これが発生した場合、データベース管理者は、より大規模な列を持つ表を手動で作成できます。

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

LLR対応のJDBCデータ・ソースを構成する場合、次の要件と制限を考慮してください。ロギング・ラスト・リソースの処理方法の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。

- 1つのサーバーにつき、LLR表は1つです。

- 複数のLLRデータ・ソースが1つの表を共有することがあります。

- 表が見つからない場合、WebLogic Serverは自動的に表を作成します。

- デフォルト名はWL_LLR_SERVERNAMEです。表名を構成するには、WebLogic Server管理コンソールの「詳細」オプションの「サーバー」→「構成」→「一般」タブを選択してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: 一般に関する項を参照してください。

- データベースが停止している場合や、起動中にLLR表にアクセスできない場合、サーバーは起動しません。

- 複数のサーバーが同じLLR表を共有することは許可されません。起動の際には、ドメインおよびサーバーの名前が、作成された時点の表に格納されたドメインおよびサーバーの名前と一致するかどうか確認されます。WebLogic Serverは、複数のサーバーが同じLLR表を共有していることを検出すると、1つまたは複数のサーバーを停止します。

- LLRでは、サーバー移行およびトランザクション・リカバリ・サービス移行がサポートされます。トランザクション・リカバリ・サービス移行を使用するには、各LLRリソースが、クラスタまたはクラスタ内の候補サーバーのセットに対してターゲット指定されている必要があります。『Oracle WebLogic Server JTAアプリケーションの開発』の失敗したクラスタ化サーバーのトランザクションのリカバリに関する項を参照してください。

- LLRトランザクション・オプションは、JDBCアプリケーション・モジュールでは使用できません。

- LLRでマルチ・データ・ソースを使用する場合、メンバーは、すべて同じデータベースのレプリケートされたコピーである必要があります。レプリケーションは、単一のOracle RACクラスタ、Data GuardまたはGolden Gateの複数のインスタンスを使用するなど、Oracleテクノロジを使用して実行できます。Oracle RACを使用する場合は、LLRトランザクション・オプションはOracle RACバージョン10gリリース2 (10gR2)以降で、次の設定でのみ使用できます。

- すべてのWebLogicアプリケーション・データベースのJDBCの対話で、READ_COMMITTEDトランザクション分離レベル(デフォルト)を使用する必要があります。

- Oracle RACのMAX_COMMIT_PROPAGATION_DELAYの値は0(ゼロ、デフォルト)に設定する必要があります。

マルチ・データ・ソースでのLLRの使用は、Oracle RACでのみサポートされます。マルチ・データ・ソースのメンバーは、すべてLLRデータ・ソースであるか、すべてそれ以外である必要があります。

- Oracle RACを使用する場合、サーバーの起動時またはサーバーの起動失敗時に、MDSの1つ以上のメンバーがリカバリ処理に使用できる必要があります。

- Oracle RACを使用しない場合、サーバーの起動時またはサーバーの起動失敗時に、MDSのすべてのメンバーがリカバリ処理に使用できる必要があります

- LLRデータ・ソース上で資格証明マッピングまたはIDプールを使用する場合、マップされるユーザーはすべて、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フェーズ・エミュレートのデータ・ソースを使用することは、サポートされていません。

接続クローズ時のローカル・トランザクションの完了

非XA接続では、接続のクローズ時に自動コミットがfalseの状態にあれば、setAutoCommit(true)がコールされます。JDBCの仕様に従えば、これにより未処理のローカル・トランザクションはすべて自動的にコミットされます。一部のドライバ(Oracle 10.xおよび11.xのドライバ)では、ローカル・トランザクションがコミットされません。アプリケーションによって、接続のクローズ前にローカル・トランザクションが完了(コミットまたはロールバック)されていない場合、接続は未処理作業とともにプールに返され、未処理作業は完了することがないか、その接続の次回予約によってコミットまたはロールバックされる可能性があります。これを防ぐために、WebLogicデータ・ソースでは、接続がプールに返される際にコミットがコールされます(Oracle 10.xまたは11.xドライバで実行されている場合)。クローズ時に明示的なコミットが必要な場合、システム・プロパティweblogic.datasource.endLocalTxOnNonXaConWithCommit=trueを設定します。

クローズ時にコミットするのではなく、中止したローカル・トランザクションをロールバックすることもできます。次のプロパティを設定すると、ローカル・トランザクションを中止した場合にコミットではなくそれをロールバックできます。

-Dweblogic.datasource.endLocalTxOnNonXaConWithCommit=false
-Dweblogic.datasource.endLocalTxOnNonXaConWithRollback=true

注意:
中止したトランザクションをそのままにしておくことは、プログラミング上適切ではありません。アプリケーションでローカル・トランザクションを明示的にコミットまたはロールバックすることをお薦めします。

XA接続では、WebLogicデータ・ソースによって、接続のクローズ時にローカル・トランザクションが常にロールバックされます。システム・プロパティweblogic.datasource.endLocalTxOnXaConWithCommit=trueを設定することで、トランザクションをロールバックするかわりにコミットできます。

13 データ・ソースのセキュリティの理解

この章では、アプリケーション環境でデータ・ソースのセキュリティを構成および使用する方法について説明します。考慮事項として、WebLogic Serverおよびデータベースのユーザーの数とその増減、データ・アクセスの粒度、セキュリティ識別の深度(接続または実際のユーザーのプロパティ)、ソフトウェア・スタック内の各種コンポーネントの調整、ドライバ機能などがあります。

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

- WebLogicデータ・ソース・セキュリティのオプションの概要

- WebLogicデータ・ソース・セキュリティのオプション

- トランザクション内の接続

- WebLogicデータ・ソース・リソースのパーミッション

- データ・ソース・セキュリティの例

- 暗号化された接続プロパティの使用

- データ・ソースおよびOracleドライバでのSSLと暗号化の使用

WebLogicデータ・ソース・セキュリティのオプションの概要

デフォルトでは、データ・ソースに対し単一のデータベース・ユーザーおよびパスワードを定義します。これをデータ・ソース・ディスクリプタに格納することや、Oracleウォレットを利用することができます(第14章「Oracleウォレットの作成および管理」を参照)。これは、非常に簡単で効率的なセキュリティへのアプローチです。接続プール内のすべての接続をこのユーザーが所有し、接続が不足しても特別な処理は行われません。つまり、この接続プールは同種接続プールであり、リクエストによりセキュリティの観点から接続を取得できます(アフィニティなど、その他の観点もあります)。アプリケーションのエンド・ユーザーに関係なく、プール内のすべての接続では、DBMSにアクセスするために同じセキュリティ資格証明が使用されます。接続を取得するとき、情報はすべてデータ・ソース・ディスクリプタまたはウォレットから入手できるため追加情報は不要です。次に例を示します。

java.sql.Connection conn =  mydatasource.getConnection();

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

次に示すように、JDBC APIを使用して、プログラムによりデータベース・ユーザー名およびパスワードを指定することもできます。

java.sql.Connection conn = mydatasource.getConnection(”user”, ”password”);

JDBCの仕様により、getConnection(”user”, ”password”)メソッドにはデータベース・ユーザーと関連するパスワードを渡す必要がありますが、ソフトウェア・ベンダーは、この仕様を独自に解釈して実装を開発してきました。Oracle WebLogic Serverでは、デフォルトでは、これはアプリケーション・サーバー・ユーザーおよびパスワードとして扱われます。

- このペアは、有効なユーザーかどうか確認するために認証され、このユーザーがWebLogicセキュリティ・パーミッション・チェックに使用されます。

- 次にこのユーザーは、データ・ソース資格証明マッパーを使用してデータベース・ユーザーおよびパスワードにマップされます。

WebLogic Serverの実装は、一般的にはこの仕様に従っていますが、データベース資格証明はアプリケーション・コードからワンステップで削除されます。

デフォルトのアプローチはシンプルであり、1人のユーザーのみがすべての処理を行うことになります。誰が更新を実際に行ったか特定できず、また、少なくともデータベース・レベルでは、SQL操作を実行するユーザー別にSQL操作を制限できません。任意のタイプのユーザー別ロジックを、データベースに依存するのではなく、アプリケーション・コードに組み込む必要があります。操作に関するユーザー別情報を提供するために構成できる各種WebLogicデータ・ソース機能があります。

WebLogicデータ・ソース・セキュリティのオプション

次の表で、WebLogicデータ・ソースでデータベース・セキュリティ資格証明を構成するために使用できる各種機能について説明します。

表13-1 セキュリティ資格証明のためのWebLogicデータ・ソース構成オプション

機能

説明

次で使用可能

次では使用不可

ユーザー認証

(デフォルト)

デフォルトのgetConnection(user, password)動作: WebLogicにより入力が検証され、ディスクリプタのユーザー/パスワードが使用されます。

プロキシ・セッション、クライアント識別子の設定

IDプール、データベース資格証明の使用

データベース資格証明の使用

資格証明マッピングを使用するかわりに、指定されたユーザーおよびパスワードを直接使用します。

クライアント識別子の設定、プロキシ・セッション、IDプール

ユーザー認証

クライアント識別子の設定

接続に関連するクライアント識別子プロパティの設定(OracleおよびDB2のみ)。

すべて

N/A

プロキシ・セッション

接続に関連する軽量プロキシ・ユーザーの設定(Oracleのみ)。

ユーザー認証、クライアント識別子の設定、データベース資格証明の使用

IDプール

IDプール

指定ユーザーが所有する接続の異種プール

クライアント識別子の設定、データベース資格証明の使用

プロキシ・セッション、ユーザー認証、ラベリング、Active GridLink

注意:
これらの機能はすべて、XAドライバと非XAドライバの両方で使用できます。

これらの機能はすべて、WebLogic Server管理コンソールのデータ・ソース構成タブの「ID」タブで構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: IDオプションに関する項を参照してください。

注意:
WebLogic Serverリリース12.1.2よりも前では、プロキシ・セッションおよび「データベース資格証明の使用」オプションは、「Oracle」タブにのみ存在しました。

次の項でこれらの機能について詳しく説明します。

- 資格証明マッピングとデータベース資格証明

- 接続へのクライアント識別子の設定

- Oracleプロキシ・セッション

- IDベースの接続プール

資格証明マッピングとデータベース資格証明

各WebLogicデータ・ソースには、資格証明マップがあります。これは、WebLogicユーザーの場合は、セキュリティ資格証明(ユーザーおよびパスワード)にキーをマップするために使用されるメカニズムです。デフォルトでは、接続取得時にユーザーおよびパスワードが指定されると、それらはWebLogicユーザーの資格証明として扱われ、検証され、データ・ソースに関連付けられている資格証明マップを使用してデータベース・ユーザーおよびパスワードに変換されます。データ・ソースの資格証明マップで一致するエントリが見つからない場合、データ・ソース定義に関連付けられているユーザーおよびパスワードが使用されます。このデフォルト設定メカニズムのために、どのパーミッションをデフォルト・ユーザーに付与するか注意する必要があります。または、無効なデフォルト・ユーザーを定義して、どのユーザーにも誤って許可が付与されないようにすることもできます(この場合、プールの初期容量をゼロに設定して、プールに有効なユーザーのみが追加されるようにする必要があります)。

資格証明マップにエントリを作成する手順:

1. WebLogicユーザーを作成します。WebLogic Server管理コンソールで、「セキュリティ・レルム」に移動し、レルムを選択し(たとえば、myrealm)、「ユーザー」を選択し、「新規」を選択します。

2. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項の説明に従い、マッピングを作成します。

資格証明マッピングを使用した場合の利点を次に示します。

- データベース・ユーザー/パスワードをプログラムにハードコーディングしません。また、WebLogicユーザー/パスワードに加えて、これを要求する必要はありません。

- WebLogicセキュリティ設定とデータベース設定の間には抽象層があり、多数のWebLogic IDをDB IDの小規模なセットにマップできます。これにより、WebLogicユーザーが追加/削除されると、必要な中間層の構成のみ更新されます。

データ・ソースへのアクセス権を持つユーザーの数を削減することで、ユーザー・メンテナンスのオーバーヘッドを軽減できます。たとえば、サーブレットに、データ・ソース・アクセスのために事前定義されたWebLogicユーザー/パスワードが1つあり、それがgetConnection(user, password)コールを使用してそのコードに組み込まれているとします。すべてのWebLogicユーザーは、サーブレットにコーディングされている特定のDBMSアクセスにリープできますが、どのユーザーもデータ・ソースへの一般アクセス権を所有する必要はありません。たとえば、売上DBMSがあり、このDBMSを非認証アクセスから保護する必要がある一方で、このDBMSにすべてのユーザーが必要とする日ごとのデータが含まれる場合があります。売上データ・ソースには制限アクセスを構成し、サーブレットを作成して、その接続リクエストに特定のデータ・ソース・アクセス資格証明を組み込みます。この接続を使用して、通常必要となる日ごとの情報のみコール元に配信します。サーブレットはその他のデータを公開できず、WebLogicユーザーはデータ・ソースへの他のアクセスを取得できません。これは、多数の大規模アプリケーションが使用するアプローチであり、WebLogic Serverのデフォルト・マッピング動作の背後にあるロジックです。

資格証明マップを使用した場合のデメリットを次に示します。

- 多数のユーザーの管理(作成、更新、削除)は困難です。WLSTスクリプトまたはカスタムJMXクライアント・ユーティリティを使用して、資格証明マップ・エントリを管理できます。

- データ・ソース間で資格証明マップを共有できないため、複製する必要があります。

一部のアプリケーションでは、資格証明マップを使用しない方が適切です。かわりに、getConnection(user, password)に渡す資格証明をデータベース資格証明として扱う必要があり、接続のためにデータベースでの認証に使用する必要があります。これにより、資格証明マップの使用が回避されます。これは、use-database-credentialsをtrueに設定することで有効化されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「Oracleパラメータの構成」を参照してください。

use-database-credentialsを有効化すると、次の属性の資格証明マッピングが無効化されます。

- identity-based-connection-pooling-enabled

- oracle-proxy-session

- set client identifier

注意:
データ・ソース・スキーマでは、クライアント識別子の設定機能はcredential-mapping-enabledという名前です。ドキュメントおよびコンソールでは、これがクライアント識別子の設定として参照されます。

資格証明マッピングの動作とデータベース資格証明の使用の確認

- 資格証明マップを使用する場合、データベースへのアクセス権を持つユーザーのために、データベース・ユーザーへの各WebLogicユーザーのマッピングが必要です。マッピングを行わないと、データ・ソースのデフォルト・ユーザーが使用されます。接続取得時に常にユーザー/パスワードを指定する場合、それらの特定ユーザーの資格証明マップ・エントリのみ必要です。

- ユーザー/パスワードを指定せずにデータベース資格証明を使用する場合、データ・ソース・ディスクリプタのデフォルト・ユーザーおよびパスワードが常に使用されます。接続取得時にユーザー/パスワードを指定する場合、そのユーザーが資格証明に対し使用されます。WebLogicユーザーは、データ・ソース接続プロセスにまったく関係しません。

接続へのクライアント識別子の設定

データ・ソースでこの機能を有効化すると、クライアント・プロパティが接続に関連付けられます。基礎となるSQLユーザーは、接続の存続中、未変更のままですが、クライアント値は変更できます。この情報は、アカウント、監査またはデバッグに使用できます。クライアント・プロパティは、先に説明した「データベース資格証明の使用」の設定に基づき、資格証明マップに基づきデータベース・ユーザーにマップされたWebLogicユーザーに基づくか、getConnection()メソッドのデータベース・ユーザー・パラメータに直接基づきます。

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

クライアント識別子の設定機能は、次のインタフェースに基づき、Oracle ThinドライバおよびIBM DB2ドライバを使用した場合にのみ利用できます。

- Oracle 12cよりも前では、oracle.jdbc.driver.OracleConnection.setClientIdentifier(client)が使用されます。監査およびデバッグにこれを使用する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』の「CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持」を参照してください。ojdbcN.jarファイルまたはojdbcN_g.jarファイルを使用し、ドライバからgetClientIdentifier()を使用して値を取得できます。

注意:
Oracle Fusion MiddleWareおよびOracle Fusion ApplicationsのデフォルトJARファイルであるojdbcNdms.jarを使用している場合、Oracleドライバを使用したクライアント識別子の設定は無効になります。この場合、クライアント識別子の設定機能はサポートされません。

SQL問合せの一部としてデータベースから値を取得するには、次のような文を使用します。

select sys_context('USERENV','CLIENT_IDENTIFIER') from DUAL

- Oracle 12c以降では、java.sql.Connection.setClientInfo(”OCSID.CLIENTID", client)が使用されます。プロパティ値は独自ですが、これはJDBC標準APIです。setClientIdentifierの使用に関する問題は、この値を設定し、依存するOracleテクノロジ・スタックがあることです。アプリケーション・コードでもこの値を設定すると、問題が発生する場合があります。これは、setClientInfoメソッドを権限が付与された操作で使用することで解決します。適切に管理されたコンテナで、Javaセキュリティ・ポリシー付与を特定のネームスペースおよびコード・ベースに制限すること、および制御不能のユーザー・コードからコンテナを保護することができます。Javaセキュリティ・マネージャでの実行時に、次についてJavaセキュリティ・ポリシー・ファイルでパーミッションを付与する必要があります。

permission "oracle.jdbc.OracleSQLPermission" "clientInfo.OCSID.CLIENTID";

OCSID.CLIENTIDという名前を使用すると、値を取得するために、上位互換性のあるselect sys_context('USERENV','CLIENT_IDENTIFIER') from DUALの使用、またはJDBC標準APIのjava.sql.getClientInfo(”OCSID.CLIENTID")の使用が可能になります。

- Oracle USERENVコンテキストでのこの値の設定を使用して、Oracle Virtual Private Database (VPD)機能を実行できます。これにより、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できます。基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。『Oracle Databaseセキュリティ・ガイド』のOracle Virtual Private Databaseを使用したデータ・アクセスの制御に関する項を参照してください。このデータ・ソース機能を使用すると、このコンテキストを設定するために、WebLogic側ではプログラミングは必要ありません。このコンテキストは、WebLogicデータ・ソース・コードにより設定およびクリアされます。

- IBM DB2ドライバでは、古いリリース(バージョン9.5よりも前)についてはcom.ibm.db2.jcc.DB2Connection.setDB2ClientUser(client)が使用されます。これにより、接続に対し現在のクライアント・ユーザー名が指定されます。現在のクライアント・ユーザー名は接続中に変更できるので注意してください(ユーザーとは異なります)。この値は、CURRENT CLIENT_USERID特殊レジスタでも使用可能です。select CURRENT CLIENT_USERID from SYSIBM.SYSTABLESなどの文を使用して、これを選択できます。

- JDBC 4.0でIBM DB2ドライバ(バージョン9.5以降)を実行する場合、java.sql.Connection.setClientInfo(”ClientUser”, client)が使用されます。DB2独自のAPIのかわりに、java.sql.Connection.getClientInfo(”ClientUser”)を使用して値を取得できます(setDB2ClientUser()を使用する場合でも)。

Oracleプロキシ・セッション

Oracleプロキシ認証により、1つのJDBC接続が、Thinドライバを使用するOracleデータベースへの複数の(シリアル)軽量ユーザー接続のプロキシとして機能できます。クライアントがプロキシ・ユーザーとしてアプリケーション・サーバーを通じてデータベースに接続できるようにWebLogicデータ・ソースを構成できます。クライアントはアプリケーション・サーバーで認証され、アプリケーション・サーバーはOracleデータベースで認証されます。これにより、クライアントのユーザー名を、データベースとの接続で保持できます。

注意:
この機能は、Oracle ThinドライバおよびサポートされるOracleデータベースを使用した場合にのみサポートされます(データベースurlにoracleを含める必要があります)。

Oracleデータベースへの接続でプロキシ認証を構成するには、次の手順を使用します。

1. 必要なデータベース・ユーザーを作成していない場合は作成します。

2. Oracleデータベースで、CONNECT THROUGH権限を用意します。次に例を示します。

SQL> ALTER USER connectionuser GRANT CONNECT THROUGH dbuser;

ここで、connectionuserは認証を受けるアプリケーション・ユーザーの名前で、dbuserはOracleデータベース・ユーザーです。

3. 汎用またはActive GridLinkデータ・ソースを作成し、ユーザーをdbuserの値に設定します。

4. 次を行います。

- WebLogic資格証明を使用するには、前の説明に従い、wlsuserの値をdbuserの値にマップする資格証明マップにエントリを作成します。

- データベース資格証明を使用するには、前の説明に従い、「データベース資格証明の使用」を有効化します。

5. Oracleプロキシ認証を有効化します。Oracle WebLogic Server管理コンソール・ヘルプの「Oracleパラメータの構成」を参照してください。

6. wlsuserまたはdbuserの値を使用して、WebLogic Serverインスタンスにログオンします。

7. getConnection(username, password)を使用して接続を取得します。資格証明は、「データベース資格証明の使用」の設定に基づき、データベース・ユーザーにマップされたWebLogicユーザーに基づくか、データベース・ユーザーに直接基づきます。

次を実行することで、現在のユーザーおよびプロキシ・ユーザーを確認できます。

select user, sys_context('USERENV','PROXY_USER') from DUAL

注意:
「データベース資格証明の使用」が有効化されておらず、WebLogicユーザーのユーザー/パスワードの値が有効ではない場合、getConnectionは失敗します。反対に、「データベース資格証明の使用」が有効化されていて、データベース・ユーザーのユーザー/パスワードの値が有効ではない場合も失敗します。

プールに対し接続リクエストが実行されるたびに、ユーザーに基づき接続でプロキシ・セッションがオープンします。接続がプールに戻されると、プロキシ・セッションはクローズされます。プロキシ・セッションのオープンまたはクローズは、JDBCオブジェクトに次の影響を与えます。

- 元の接続からの既存の文(結果セットを含む)がクローズされます。

- WebLogic Server文キャッシュがクリアされます。

- クライアント識別子が設定されている場合はクリアされます。

- すべてのプロキシ・セッションに対し、接続用のWebLogic Serverテスト文が再作成されます。

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

use-database-credentialsが有効化され、getConnection(user, password)がコールされると、Oracleプロキシ・セッションも暗黙的に有効化されます。

oracle-proxy-sessionの正確な定義は次のようになります。

- プロキシ認証が有効化され、IDベースのプールも有効化されると、エラーが発生します。

- getConnection()でユーザーが指定され、identity-based-connection-pooling-enabledがfalseの場合、oracle-proxy-sessionは暗黙的にtrueとして扱われます(明示的にtrueにすることもできます)。

- getConnection()でユーザーが指定され、identity-based-connection-pooling-enabledがtrueの場合、oracle-proxy-sessionはfalseとして扱われます。

IDベースの接続プール

IDベースのプールでは、接続の異種プールが作成されます。これにより、アプリケーションは、各種DBMS資格証明を持つ物理接続をプールすることで、特定のDBMS資格証明でJDBC接続を使用できます。DBMS資格証明は、use-database-credentialsに基づき、データベース・ユーザーにマップされたWebLogicユーザーに基づくか、データベース・ユーザーに直接基づきます。use-database-credentials=trueにより、一部の実装で、getConnection(user,password)で指定されたユーザーにおいて、JDBC標準に基づく異種プールを解釈する方法が決まります。

データ・ソースで「IDベースの接続プールを有効化」属性が有効化されている場合、接続の割当てはさらに複雑になります。アプリケーションがデータベース接続をリクエストすると、WebLogic Serverインスタンスは既存の物理接続を選択するか、リクエストしたDBMSアイデンティティとの新規物理接続を作成します。

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

1. 接続プールの初期化時に、データ・ソースの構成済デフォルトDBMS資格証明を使用して、構成済またはデフォルトの初期容量に基づく物理JDBC接続が作成されます。

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

3. 次が行われます。

- use-database-credentialsが有効化されていない場合、先に説明したように、getConnectionで指定されているユーザーがDBMS資格証明にマップされます。資格証明マップに一致するユーザーがない場合、データ・ソース・ディスクリプタからデフォルトのDBMS資格証明が使用されます。

- use-database-credentialsが有効化されている場合、getConnectionで指定されているユーザーおよびパスワードが直接使用されます。

4. 接続プールが検索され、一致するDBMS資格証明を持つ接続が検出されます。

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

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

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

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

一致する接続の検出に、同種プールよりもコストがかかることは明白です。接続の破棄と新しい接続の取得には、非常にコストがかかります。可能な場合は、通常の同種プールまたはいずれかの軽量オプション(クライアントIDまたはOracleプロキシ接続)を使用してください。これらは、IDベースのプールよりも効率的であるためです。

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

この機能を構成するには、「IDベースの接続プールを有効化」を選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースのIDベースの接続プールの有効化」を参照してください。

関連するトランザクション表に複数のユーザーがアクセスする問題に対処するために、次の変更を行って、IDベースのプールでロギング・ラスト・リソース(LLR)トランザクションの最適化を使用する必要があります。

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

- データベース固有の管理ツールを使用して、名前を付けたLLR表にアクセスするためのパーミッションを、グローバル・トランザクションを通じてこの表にアクセスできるようにするすべてのユーザーに付与します。デフォルトでは、LLR表は、データ・ソース内の接続に対し構成されているユーザーにより、ブート中に作成されます。ほとんどの場合、データベースにより、このユーザーへのアクセスのみ許可され、マップされたユーザーへのアクセスは許可されません。

トランザクション内の接続

特定のWebLogic Serverインスタンスのデータ・ソースのトランザクション・コンテキストに関連付けられている接続は、次のように動作します。

- グローバル・トランザクションで非XA LLRまたは1PC (JTSドライバ)が構成されたデータ・ソースとの接続を取得すると、指定されたユーザー名/パスワードの値に関係なく、および関連するプロキシ・ユーザー・セッション(ある場合)から独立して、トランザクション内で取得された最初の接続が、後続の接続リクエストで返されます。LLRまたは1PCを使用する場合、接続を接続のすべてのユーザー間で共有する必要があります。接続は、最初にアクセスされたサーバーに格納され、他のサーバーは戻されます。

- XAデータ・ソースでは、指定されたユーザー名/パスワードの値に関係なく、および関連するプロキシ・ユーザー・セッション(ある場合)から独立して、グローバル・トランザクション内で取得された最初の接続が、アプリケーション・サーバー内の後続の接続リクエストで返されます。アプリケーション・サーバー/JVM内のグローバル・トランザクション内において、接続を接続のすべてのユーザー間で共有する必要があります。接続は、データ・ソースにアクセスしたサーバーごとに、トランザクション・コンテキストとともにキャッシュされます(データ・ソース単位で格納されます)。

要約すると、トランザクション内で接続を取得すると、その接続は、特定のWebLogic Serverインスタンスのトランザクション・コンテキストに関連付けられます。

WebLogicデータ・ソース・リソースのパーミッション

オプションで、JDBCデータ・ソースへのアクセスを制限できます。WebLogic Serverでは、WebLogicデータ・ソース・リソースへのアクセス権を誰が持っていますか、という質問に対して、セキュリティ・ポリシーが解答を出します。WebLogicデータ・ソース・リソースとユーザー、グループまたはロール間の関係を定義すると、セキュリティ・ポリシーが作成されます。セキュリティ・ポリシーにWebLogicデータ・ソース・リソースを割り当てるまで、このリソースは保護されません。パーミッションのポリシーを1つ追加すると、他のすべてのユーザーがただちに制限を受けます。たとえば、weblogicが接続を予約できるというポリシーを追加すると、他のすべてのユーザーは、明示的に追加されるまで、接続を予約しようとしても失敗します。検証は、データベース・ユーザー資格証明ではなく、WebLogicユーザー資格証明に対して実行されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「リソース・インスタンスのポリシーの作成」を参照してください。

管理者がJDBCデータ・ソースに対して実行できるアクションを制限できる管理者用メソッドを割り当てることで、JDBCリソース操作を保護できます。これらのリソースは、データ・ソースに関連する「セキュリティ」タブの「ポリシー」タブで定義できます。個々のデータ・ソースを保護する場合、次の1つ以上の管理者メソッドを使用して、JDBC操作を保護するかどうか選択できます。

- admin: JDBCDataSourceRuntimeMBeanの次のメソッドは、admin操作として呼び出されます: clearStatementCache、suspend、forceSuspend、resume、shutdown、forceShutdown、start、getPropertiesおよびpoolExists。

- reserve: アプリケーションは、データ・ソースをルックアップし、getConnectionをコールすることで、データ・ソース内の接続を予約します。ユーザーにreserveパーミッションを付与すると、ユーザーはベンダー固有の操作を実行できます。データベース・ベンダーによっては、これらの一部の操作でデータベースのセキュリティが影響を受ける場合があります。「WebLogicデータ・ソース・セキュリティのオプション」を参照してください。

- shrink: データ・ソース内の接続の数を、現在予約されている接続の最大数、または初期サイズまで削減します。

- reset: すべての物理データベース接続をシャットダウンして再確立することで、データ・ソース接続をリセットします。これにより、各接続の文キャッシュもクリアされます。正常に実行されているデータ・ソース接続のみリセットできます。

- All: 個々のデータ・ソースが、Admin、reserve、shrinkおよびreset管理者メソッドの組合せにより保護されます。

注意:
次のことに注意してください。

- セキュリティ・ポリシーにより、マルチ・データ・ソース内の接続へのアクセスが制御される場合、JDBCリソース階層の両方のレベル(マルチ・データ・ソース・レベルおよび個々のデータ・ソース・レベル)でアクセス・チェックが実行されます。すべてのタイプのWebLogicリソースに関して、この2重チェックにより、ほとんどの特定セキュリティ・ポリシーでアクセスが確実に制御されます。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のJava DataBase Connectivity (JDBC)リソースに関する項を参照してください。

次の表では、reserve管理者メソッド使用時のパーミッション・チェック対象のユーザーについて情報を提供します。

表13-2 reserve管理者メソッド使用時のユーザーの決定

API

Use-database-credential

パーミッション・チェック対象のユーザー

getConnection()

TrueまたはFalse

現在のWebLogicユーザー

getConnection(user,password)

False

APIからのユーザー/パスワード

getConnection(user,password)

True

現在のWebLogicユーザー

要約すると、getConnection()が使用される場合、またはデータベース資格証明が有効化されている場合、WebLogicシステムに対して認証される現在のユーザーがチェックされます。データベース資格証明が有効化されていない場合、APIのユーザーおよびパスワードが使用されます。この機能は、データベースにアクセスできるコードおよびユーザーを制限する場合に非常に便利です。

すべてのWebLogic Serverリソースに対してセキュリティを設定する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロールおよびポリシーを使用したリソースの保護に関する項を参照してください。サーバー・リソースの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

データ・ソース・セキュリティの例

次は、identity-based-connection-pooling-enabled、oracle-proxy-sessionおよびuse-database-credentialsの間の相互作用の実例です。

データベース側で、次のオブジェクトを構成します。

- ユーザー: scott、jdbcqa、jdbcqa3

- alter user jdbcqa3 grant connect through jdbcqa;

- alter user jdbcqa grant connect through jdbcqa;

次のWebLogicユーザーを構成します。

- weblogic

- wluser

次のWebLogicデータ・ソース・オブジェクトを構成します。

- weblogicからscottへの資格証明マッピング

- wluserからjdbcqa3への資格証明マッピング

- ユーザーjdbcqaが構成されたデータ・ソース

- クライアントIDの設定をtrueに設定してすべてのテストを実行します。

- oracle-proxy-sessionをfalseに設定してすべてのテストを実行します。

テスト・プログラム:

- サーブレットで実行

- ユーザーweblogicとしてWebLogicに対して認証

表13-3 ID、プロキシおよびデータベース資格証明の比較

DB資格証明の使用

IDベース

getConnection (scott,***)

getConnection (weblogic,***)

getConnection (jdbcqa3,***)

getConnection()

true

true

ID scott

クライアントweblogic

プロキシnull

weblogicは失敗: dbユーザーではない

ユーザーjdbcqa3

クライアントweblogic

プロキシnull

デフォルトjdbcqa

クライアントweblogic

プロキシnull

false

true

scottは失敗: WebLogicユーザーではない

ユーザーscott

クライアントscott

プロキシnull

jdbcqa3は失敗: WebLogicユーザーではない

ユーザーscott

クライアントscott

プロキシnull

true

false

scottのプロキシは失敗

weblogicは失敗: dbユーザーではない

ユーザーjdbcqa3

クライアントweblogic

プロキシjdbcqa

デフォルトjdbcqa

クライアントweblogic

プロキシnull

false

false

scottは失敗: WebLogicユーザーではない

ユーザーjdbcqa

クライアントscott

プロキシnull

jdbcqa3は失敗: WebLogicユーザーではない

デフォルトjdbcqa

クライアントscott

プロキシnull

次が行われます。

- クライアントIDの設定がfalseに設定されている場合、すべてのケースでクライアントはnullに設定されます。

- Oracle Thinドライバが使用されない場合、非nullプロキシを使用する1つのケースでは、例外がスローされます。これは、Oracle Thinドライバでのみプロキシ・セッションがサポートされるためです。

oracle-proxy-sessionがtrueに設定されている場合、成功するケースは次のみです(jdbcqaのプロキシを使用)。

- use-database-credentialsがtrueに設定されていて、getConnection(jdbcqa3,…)またはgetConnection()を使用する場合。

- use-database-credentialsがfalseに設定されていて、getConnection(wluser, …)またはgetConnection()を使用する場合。

暗号化された接続プロパティの使用

セキュアな構成の一環として、クリア・テキストとして表示されない接続プロパティ値を、データ・ソース・ディスクリプタ・ファイルの接続プロパティに1つ以上設定することをお薦めします。これらのプロパティはEncrypted Properties属性を使用して追加できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続プロパティの暗号化に関する項を参照してください。

注意:
WebLogic Server管理コンソールでデータ・ソースを作成するとき、接続プロパティは暗号化できません。暗号化できるのは、既存のデータ・ソース構成を更新する場合のみです。

管理コンソールの使用時に接続プロパティを暗号化するためのベスト・プラクティス

次の項では、WebLogic Server管理コンソールで接続プロパティを暗号化するときのベスト・プラクティスとヒントについて説明します。

- データ・ソースの作成時:

- 暗号化されたプロパティなしで作成し、データ・ソースをターゲットに指定しないでください。

- 暗号化されたプロパティなしでは接続をテストできない可能性があります。一時的にクリア・テキスト・プロパティでテストして、後でそのクリア・テキスト・プロパティを暗号化されたプロパティに置き換えることをお薦めします。

- 「JDBCデータ・ソースのサマリー」ページに移動してデータ・ソースを編集し、「データ・ソース」を選択して、「構成」タブに移動し、「接続プール」タブを選択します。

- クリア・テキスト値を画面に表示せずに値を入力するには:

- このページに対する他のすべての変更を保存して、「暗号化されたプロパティ」テキスト・ボックスの横の安全に追加ボタンをクリックします。

- 暗号化されたプロパティの新規追加ページで、プロパティ名とマスクされた値を入力して、「OK」をクリックします。

- その他の暗号化されたプロパティ値に対して手順を繰り返します。

- 暗号化されたプロパティの入力が終了したら、「保存」をクリックします。

- ご使用の環境で変更を保存するまで暗号化された値を画面に表示することが適している場合は、複数の値を一度に入力できます。

- 「暗号化されたプロパティ」フィールドに、各property=valueのペアを別の行にしてリストします。

- 「保存」をクリックして値を暗号化します。

- 次のように変更をアクティブ化します。

- データ・ソースがターゲット指定されていない場合: 「ターゲット」タブに移動して、データ・ソースをターゲット指定し、「保存」をクリックします。

- 暗号化されたプロパティ値が追加されたときに、データ・ソースがすでにアクティブ化されていた場合: 「ターゲット」タブに移動し、データ・ソースのターゲット指定を解除して「保存」をクリックし、データ・ソースを再度ターゲット指定して、「保存」をクリックします。

接続プロパティを暗号化するためのWLSTの例

次の各項では、接続プロパティを暗号化するWLSTスクリプトの例を示します。

- WLSTを使用して、暗号化されたプロパティで既存のデータ・ソースを更新する方法

- WLSTを使用して、暗号化されたプロパティを作成する方法

WLSTを使用して、暗号化されたプロパティで既存のデータ・ソースを更新する方法

次のオンラインWLSTスクリプトは、genericdsという名前の既存のデータ・ソースに暗号化されたプロパティを追加する方法を示しています。

connect('admin','password','t3://localhost:7001')
edit()
startEdit()
cd('JDBCSystemResources/genericds/JDBCResource/genericds/JDBCDriverParams/genericds/Properties/genericds/Properties')
create('encryptedprop','Property')
cd('encryptedprop')
cmo. setEncryptedValueEncrypted(encrypt('foo'))
save()
activate()

WLSTを使用して、暗号化されたプロパティを作成する方法

次のWLSTスクリプトでは、暗号化されたプロパティを作成しています。

. . .
create('myProps','Properties')
cd('Properties/NO_NAME_0')
. . .
# Create other properties
. . .
p=create('javax.net.ssl.trustStoreType', 'Property')
p.setValue('JKS')

p=create('javax.net.ssl.trustStorePassword', 'Property')
p.setEncryptedValueEncrypted(encrypt('securityCommonTrustKeyStorePassPhrase'))
. . .

データ・ソースおよびOracleドライバでのSSLと暗号化の使用

Oracle Advanced Securityは、データベース・サーバーへのネットワーク接続に対して、データ暗号化と強力な認証機能を提供します。次の各項では、WebLogic Serverでこれらの機能を使用する方法の詳細を説明します。

- データ・ソースおよびOracleドライバでのSSLの使用

- データ・ソースおよびOracleドライバでのデータ暗号化の使用

詳細は、『Oracle® Database JDBC開発者ガイド』のJDBCクライアント側のセキュリティ機能に関する項を参照してください。

データ・ソースおよびOracleドライバでのSSLの使用

この項では、データ・ソースおよびOracleドライバでSSLを使用する各種オプションの追加情報について説明します。

SSL使用時の一般要件は、オプションに関係なく、urlでプロトコルとしてtcpsを指定する必要があることです。

OracleドライバでのSSLの構成方法および使用方法の詳細は、次を参照してください。

- http://www.oracle.com/technetwork/middleware/weblogic/index-087556.html

- http://www.oracle.com/technetwork/database/enterprise-edition/wp-oracle-jdbc-thin-ssl-130128.pdf.

javax.net.ssl.trustStorePassword、javax.net.ssl.keyStorePasswordなどのパスワードを必要とするプロバイダを使用している場合は、この値を暗号化されたプロパティとして保存する必要があります。「暗号化された接続プロパティの使用」を参照してください。

OracleウォレットでのSSLの使用

SSLでOracleウォレットを使用することもできます。これを正しく使用することで、パスワードをJDBC構成から排除でき、ウォレットを構成することでクライアント/サーバー構成を簡素化できます。次は、OracleウォレットでSSLを使用するための基本要件のリストです。

- ウォレットの場所についてsqlnet.oraおよびlistener.oraファイルを更新します。これらのファイルは、SSL_CLIENT_AUTHENTICATIONが使用されるかどうかも示します。

- 自動ログイン・ウォレット・タイプを使用する場合、ウォレットを開くためのデータ・ソース構成にパスワードは必要ありません。自動ログイン・ウォレットのストア・タイプはSSO (JKSまたはPKCS12ではない)で、ファイル名はcwallet.ssoです。別のプロバイダ・タイプを使用する場合は、暗号化されたプロパティ・タイプを使用して、パスワードを暗号化された値としてデータ・ソース構成に保存します。

- 次を使用して、WebLogic Server起動クラスでOracle PKIプロバイダを有効化します。

Security.insertProviderAt(new oracle.security.pki.OraclePKIProvider (), 3);

- 暗号化およびサーバー認証のために、次のデータ・ソース接続プロパティを使用します。

javax.net.ssl.trustStore=location of wallet
javax.net.ssl.trustStoreType=”SSO”

- クライアント認証のために、次のデータ・ソース接続プロパティを使用します。

javax.net.ssl.keyStore=location of wallet
javax.net.ssl.keyStoreType=”SSO”

- ウォレットはorapkiを使用して作成します。ウォレットは、使用方法(暗号化または認証)に基づいて作成する必要があります。

一般的な使用例を次に示します。

- 信頼ストアを必要とする、暗号化およびサーバー認証。

- 信頼ストアおよび鍵ストアを必要とする、両方の層(クライアントおよびサーバー)の暗号化および認証。

Active GridLink ONS over SSL

SSLを使用して、Active GridLink (AGL)データ・ソースとOracle Notification Service (ONS)の間の通信を保護できます。ONSは、ロード・バランシング情報およびノードのアップ/ダウン・イベントの通知を提供するために使用されます。

次の基本手順を使用します。

- 自動ログイン・ウォレットを作成し、クライアントおよびサーバーでウォレットを使用します。次は、ONSで使用するテスト・ウォレットを作成するためのサンプル・シーケンスです。

orapki wallet create -wallet ons -auto_login -pwd ONS_Wallet
orapki wallet export -wallet ons -dn "CN=ons_test,C=US" -cert ons/cert.txt -pwd ONS_Wallet
orapki wallet export -wallet ons -dn "CN=ons_test,C=US" -cert ons/cert.txt -pwd ONS_Wallet

- データベース・サーバー側:

1. ファイル$CRS_HOME/opmn/conf/ons.configでウォレット・ファイル・ディレクトリを定義します。

2. onsctl stop/startを実行します。

- AGLデータ・ソースを構成する場合、ONSへの接続を定義する必要があります。ホストおよびポートに加えて、ウォレット・ファイル・ディレクトリを指定する必要があります。パスワードを指定しない場合、SSOウォレットと見なされます。

データ・ソースおよびOracleドライバでのデータ暗号化の使用

Oracle Thinドライバでデータ暗号化を使用するには、複数の接続プロパティを指定する必要があります。『Oracle® Databaseセキュリティ・ガイド』のThin JDBCネットワーク実装の構成パラメータに関する項を参照してください。表13-4は、暗号化およびチェックサムの構成パラメータと、管理コンソールまたはWLSTを使用してデータ・ソース・ディスクリプタを構成するときに必要とされる文字定数とのマッピングを示しています。

表13-4 接続の暗号化パラメータとWebLogic構成の定数

クライアント構成パラメータ

WebLogic Server構成の文字定数

OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL

oracle.net.encryption_client

OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES

oracle.net.encryption_types_client

OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL

oracle.net.crypto_checksum_client

OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES

oracle.net.crypto_checksum_types_client

14 Oracleウォレットの作成および管理

この章では、WebLogic Serverデータ・ソース定義のデータベース資格証明を格納するOracleウォレットの作成方法および管理方法を説明します。

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

- Oracleウォレットとは

- ウォレットを保持する場所

- 外部パスワード・ストアの作成方法

- ウォレットを使用するWebLogic Serverデータ・ソースの定義

- DB接続文字列のかわりにTNS別名を使用

Oracleウォレットとは

Oracleウォレットにより、複数のドメインにわたりデータベース資格証明を管理する簡単な方法が提供されます。ウォレットを更新することでデータベース資格証明を更新できます。このとき、個々のデータ・ソース定義を変更する必要はありません。これは、ウォレット内のエントリにより解決される、データ・ソース定義内のデータベース接続文字列を使用することで実現されます。

Oracle TNS (Transparent Network Substrate)管理ファイルを使用して、データ・ソース定義のデータベース接続文字列の詳細(ホスト名、ポート番号およびサービス名)を非表示にし、かわりに別名を使用することでも、この機能を拡張できます。接続情報を変更する場合、多数のデータ・ソース定義を変更する必要はなく、tnsnames.oraファイルのみ変更すればすみます。

ウォレットを使用すると、異なるドメイン間で共通の資格証明を保持できます。これには、2つの異なるWebLogic Serverドメイン間、またはWebLogic Serverとデータベース間での資格証明の共有が含まれます。ウォレットを正しく使用すると、データ・ソース構成でパスワードを保持する必要はなくなります。

ウォレットを保持する場所

データベース環境にウォレットを作成し、管理することをお薦めします。この環境で、$ORACLE_HOME/oracle_common/bin/mkstoreコマンドなど、必要なすべてのコマンドおよびライブラリを提供します。通常、このタスクはデータベース管理者が実行し、クライアントが使用するために用意します。構成済のウォレットは、安全なウォレット・ディレクトリに格納された2つのファイル、cwallet.ssoおよびewallet.p12で構成されます。

注意:
Oracle Client Runtimeパッケージをインストールして、Oracleウォレットの作成および管理に必要なコマンドおよびライブラリを用意することもできます。

外部パスワード・ストアの作成方法

コマンド行で次の構文を使用して、クライアント上にウォレットを作成します。

mkstore -wrl <wallet_location> -create

ここで、wallet_locationは、ウォレットを作成して格納するディレクトリのパスです。

このコマンドにより、指定した場所にOracleウォレットが作成され、自動ログイン機能が使用可能になります。自動ログインにより、クライアントは、パスワードを指定しなくてもウォレットの内容にアクセスでき、クライアントのクリア・テキスト・パスワードが露出されるのを回避できます。

mkstoreコマンドでは、後続コマンドに使用されるパスワードを要求するプロンプトが表示されます。パスワードは、8文字以上で、アルファベットと、数字または特殊文字の組合せを含んでいる必要があります。次に例を示します。

mkstore -wrl /tmp/wallet –create
Enter password: mysecret
PKI-01002: Invalid password.
Enter password: mysecret1  (not echoed)
Enter password again: mysecret1 (not echoed)

注意:
Oracleウォレットを使用すると、データ・ソース構成ファイル内のクリア・テキスト・パスワードのかわりにウォレット・ファイル内の暗号化パスワードが使用され、セキュリティの脆弱性が取り除かれます。ウォレット・ファイルは安全な場所に保管する必要があります。

1つのクライアント・ウォレットに、複数のデータベースの複数の資格証明を格納できます。同じウォレットに、同じデータベースの(複数のスキーマにログインするための)複数の資格証明は格納できません。同じデータベースに対する複数のログイン資格証明がある場合、別のウォレットに格納する必要があります。

既存のクライアント・ウォレットにデータベース・ログイン資格証明を追加するには、コマンド行で次のコマンドを指定します。

mkstore -wrl <wallet_location> -createCredential <db_connect_string> <username> <password>

説明:

- wallet_locationは、ウォレットを作成したディレクトリのパスです。

- db_connect_stringは、データ・ソース定義で使用されるURLで指定する接続文字列(@の後の文字列部分)と同一である必要があります。短い形式または長い形式のURLを使用できます。次に例を示します。
myhost:1521/myserviceまたは

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))

注意:
シェルから特殊文字をエスケープするために、この値は引用符で囲む必要があります。通常、この名前は長く複雑な値であるため、かわりにTNS別名を使用します。「DB接続文字列のかわりにTNS別名を使用」を参照してください。

- usernameとpasswordは、データベース・ログイン資格証明です。

- WebLogicデータ・ソースで使用するデータベースごとに繰り返します。

自動ログインの使用およびウォレット・パスワードの保持の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

ウォレットを使用するWebLogic Serverデータ・ソースの定義

Oracleウォレットを使用するようにWebLogic Serverデータ・ソースを構成するには、次の手順を使用します。

- ウォレット・ファイルのコピー

- データ・ソース構成の更新

ウォレット・ファイルのコピー

ウォレット・ファイルのcwallet.ssoとewallet.p12をデータベース・マシンからクライアント・マシンにコピーし、安全なディレクトリに配置します。

データ・ソース構成の更新

Oracleウォレットを使用するようにWebLogicデータ・ソースを構成するには、次の手順を使用します。

1. データ・ソースを作成するとき、WebLogic Server管理コンソールでユーザー名またはパスワードは入力しないでください。または既存のデータ・ソースからこれらを削除してください。ユーザー名、パスワードまたは暗号化パスワードが構成に含まれる場合、それらによりOracleウォレット値はオーバーライドされます。

2. /を@の前に配置してURLを変更します。たとえば、短い形式のURLの場合、jdbc:oracle:thin:/@mydburl:1234/mydbのようになります。

3. 接続プロパティに次の値を追加する必要があります。
oracle.net.wallet_location=wallet_directory

ここで、wallet_directoryは、手順1「ウォレット・ファイルのコピー」の安全なディレクトリの場所です。別の方法は、-Doracle.net.wallet_locationシステム・プロパティを使用し、それをJAVA_OPTIONSに追加する方法です。接続プロパティを使用することをお薦めします。

DB接続文字列のかわりにTNS別名を使用

URLおよびOracleウォレットで一致するデータベース接続文字列を指定するかわりに、URL情報をマップする別名を作成できます。接続文字列情報は、関連する別名とともにtnsnames.oraファイルに格納されます。別名はURLとウォレットの両方で使用されます。

1. システム・プロパティ-Doracle.net.tns_admin=tns_directoryを指定します。ここで、tns_directoryは、tnsnames.oraファイルのディレクトリの場所です。

注意:
接続プロパティとしてtns_directoryの場所を使用しないでください。

2. tns_directoryで指定されているディレクトリ内にtnsnames.oraファイルを作成します。または、このファイルを変更します。エントリの形式を次に示します。
alias=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service)))

ここで、hostはデータベース・リスナーのURL、portはデータベース・リスナーのポート、serviceは接続する先のデータベースのサービス名です。

構成できる追加属性があります。『Database Net Servicesリファレンス』のtnsnames.oraファイルのローカル・ネーミング・パラメータに関する項を参照してください。単一行に文字列を入力することをお薦めします。

3. 接続文字列を別名に置き換えることで、データ・ソース定義URLで別名を使用します。たとえば、管理コンソールの「接続プール」タブでURL属性をjdbc:oracle:thin:/@aliasに変更します。

作成後、別名またはデータ・ソース定義を再変更する必要はありません。ユーザー資格証明を変更するには、ウォレットを更新します。接続情報を変更するには、tnsnames.oraファイルを更新します。どちらの場合も、データ・ソースを再デプロイする必要があります。データ・ソースを再デプロイする最も簡単な方法は、WebLogic Server管理コンソールでデータ・ソースをターゲット指定解除し、ターゲット指定する方法です。この構成は、Oracleリリース10.2以上のドライバでサポートされます。

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

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

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

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

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

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

サーバーまたはクラスタにデータ・ソースをデプロイするには、デプロイメント・ターゲットとしてサーバーまたはクラスタを選択します。サーバーにデータ・ソースがデプロイされると、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メソッドが実装されている場合、データベース接続の作成試行の待機時間は、指定されているタイムアウト時間のみです。

別の方法として、データ・ソースの「初期容量」を0に設定する方法があります。これは、データ・ソースがデプロイされ、データベースをその時点で使用可能にする必要がない場合には、接続が作成されないことを意味します。アプリケーションが接続を必要とするまで、それらの接続の作成は延期されます。

16 WebLogic ServerでのOracle RACの使用

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

Oracle WebLogic Serverは、Oracle 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データベース管理システム。『Oracle® Fusion Middlewareライセンス情報』を参照してください。

- オペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアとクラスタ構成については、Oracleドキュメントを参照してください。

- Oracle自動ストレージ管理(ASM)などの共有ストレージ・ソフトウェア。クラスタリング・ソフトウェアの中にはファイル・ストレージ・ソリューションが組み込まれているものがあり、その場合は共有ストレージ・ソフトウェアを追加する必要がありません。

注意:
最新のWebLogic Serverハードウェア・プラットフォームとオペレーティング・システムのサポート、およびWebLogic Serverの各種バージョンとサービス・パックによりサポートされるOracle RACバージョンについては、『Oracle WebLogic Serverの新機能』 12.2.1のサポートされる構成に関する項を参照してください。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構成の選択

次の選択肢を考慮します。

- Active GridLink (AGL)データ・ソースの使用。『Oracle® Fusion Middlewareライセンス情報』を参照してください。AGLは、Oracle RACインスタンスの自動追加および削除をサポートしています。ノードがダウンし、アップするとき、接続の失敗および成功を待機することなく、自動的に処理が行われます。第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。

- グローバル・トランザクション(XA)使用時に複数のOracle RACインスタンスに接続するために、トランザクション対応WebLogic JDBCマルチ・データ・ソースを使用してOracle RACノードに接続することをお薦めします。このマルチ・データ・ソースは、フェイルオーバーおよびロード・バランシングをサポートしています。詳細は、「グローバル・トランザクションを使用したマルチ・データ・ソースの使用」を参照してください。

- XA不使用時に複数のOracle RACインスタンスに接続するために、(トランザクション非対応の)マルチ・データ・ソースを使用してOracle RACノードに接続することをお薦めします。フェイルオーバーおよびロード・バランシングをサポートする標準マルチ・データ・ソース構成を使用します。詳細は、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。

- WebLogicでは、Oracle Data Guardとマルチ・データ・ソースおよびAGLとの併用をサポートしています。

- プライマリおよびスタンバイの単一インスタンスとマルチ・データ・ソースを併用する場合、アルゴリズム・タイプをFAILOVERに設定する必要があります。プライマリのインスタンスに障害が発生した場合、プライマリの接続は失敗し、スタンバイで接続が作成されます。

次の表は、特定のアプリケーションにどの構成が適切か判別するのに役立ちます。

表16-1 Oracle RACを使用するための構成の選択

ロード・バランシングが必要ですか

フェイルオーバーが必要ですか

グローバル・トランザクション(XA)が必要ですか

Oracle RACサービスの使用

参照先

はい

はい

はい

はい

Active GridLinkデータ・ソースの使用方法

はい

はい

はい

いいえ

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

はい

はい

はい

はい

Oracle RACノード上のサービスへの接続の構成

はい

はい

いいえ

はい

Oracle RACノード上のサービスへの接続の構成

はい

はい

いいえ

いいえ

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

プライマリおよびスタンバイのOracle RACクラスタとマルチ・データ・ソースを併用する場合、インスタンスごとにデータ・ソースを作成する必要があります。SCANが唯一の構成済ネットワークであるため、それを使用する必要がある場合、各データ・ソースが唯一のインスタンスにマップされるように、インスタンスごとにINSTANCE_NAMEを指定する必要もあります。アルゴリズム・タイプは、Load BALANCEに設定する必要があります。最初は、サービスはプライマリ・クラスタのインスタンスでのみ使用できます。そのため、ロード・バランシング・アルゴリズムは、すべてのプライマリ・インスタンスとすべてのセカンダリ・インスタンスから同等の接続を取得しようと試みます。スタンバイ・インスタンスに対する接続が失敗すると、それらのデータ・ソースは中断されます。マルチ・データ・ソースのテスト頻度の間隔は、可用性を高頻度でテストできるように、デフォルトの120秒から約5秒に短縮する必要があります。プライマリが停止すると、プライマリのサービスは停止され、バックアップに移動されます。マルチ・データ・ソースは、プライマリ・インスタンスで接続の障害を認識し、それらを中断します。マルチ・データ・ソースは、バックアップ・インスタンスで接続を取得し、それらのデータ・ソースで作業を再開します。

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

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

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

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

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

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

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

- JDBCドライバのサポート

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

- WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加

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

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

JDBCドライバのサポート

WebLogic Serverでは、次の要件を満たすJDBC対応ドライバ-を使用した、任意のデータベースへのアプリケーション・データ・アクセスがサポートされます。

- ドライバはスレッドセーフであることが必要です。

- トランザクションをサポートする環境でドライバを使用する場合は、標準のJDBCトランザクション・コール(setAutoCommit()およびsetTransactionIsolation()など)を実装する必要があります。

- SerializableまたはRemoteインタフェースを実装しない場合、ドライバはRMIクライアント・アプリケーションにオブジェクトを渡すことができません。

WebLogic Serverの機能によってデータベースが内部データ記憶に使用される場合は、アプリケーション・データ・アクセスに使用される場合よりもデータベースのサポートが制限されます。次のWebLogic Serverの機能では、内部データ記憶が必要です。

- コンテナ管理の永続性(CMP)

- 行セット

- JMS/JDBC永続性、およびWebLogic JDBCストアの使用

- JDBCセッション永続性

- RDBMSセキュリティ・プロバイダ

- (シングルトン・サービスおよびサーバーの移行用)データベース・リース

- JTAロギング・ラスト・リソース(LLR)最適化

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

Oracle Thinドライバのバージョン12cは、Oracle WebLogic Serverとともにインストールされます。

- ojdbc7.jar、ojdbc7_g.jar、ojdbc7dms.jar (JDK7の場合)

- ojdbc6.jar、ojdbc6_g.jar、ojdbc6dms.jar (JDK 6の場合)

注意:
WebLogic Serverとともに、WebLogicブランドのDataDirectのドライバもインストールされます。詳細は、『Oracle WebLogic Server JDBCアプリケーションの開発』のWebLogicブランドのDataDirectドライバの使用に関する項を参照してください。

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

このドライバは、$ORACLE_HOME/oracle_common/modulesのサブディレクトリにインストールされます。weblogic.jarのマニフェストには、このファイルがリストされており、そのためこのファイルはweblogic.jarのロード時(サーバーの起動時)にロードされます。したがって、このJDBCドライバをCLASSPATHに追加する必要はありません。WebLogic ServerとともにインストールされないサードパーティJDBCドライバを使用する予定がある場合、それらのドライバをインストールする必要があります。インストール作業には、ドライバ・ファイルへのパスでCLASSPATHを更新することが含まれます。また、データベース・クライアント・ファイルへのパスでPATHを更新することも含まれる場合があります。『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項 12.2.1を参照してください。

WebLogic Serverとともにインストールされるドライバの異なるバージョンを使用する予定の場合は、新しいファイルをCLASSPATHの前に追加できます。

注意:
WebLogic Serverではまた、WebLogic ServerサンプルとともにDerby DBMSのバージョンがWL_HOME\common\derbyディレクトリにインストールされます。Derbyは、すべてJavaで作成されたDBMS製品で、WebLogic ServerサンプルのデモンストレーションをサポートするためにWebLogic Serverディストリビューションに含まれています。Derbyの詳細は、http://db.apache.org/derbyを参照してください。

WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加

WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバを使用するには、それらをDOMAIN_HOME/libディレクトリに追加します(DOMAIN_HOMEは、WebLogic Serverドメインが構成されているディレクトリを表します)。デフォルトのパスは、ORACLE_HOME/user_projects/domainsです。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のドメイン/libディレクトリへのJARの追加に関する項を参照してください。

注意:
以前のリリースでは、新しいJDBCドライバを追加する場合、または置き換えるJARの名前が元のJARと異なるJDBCドライバを更新する場合、WebLogic Serverのクラスパスを更新してJDBCドライバ・クラスの場所を含める必要がありました。これは必要なくなりました。

DOMAIN_HOME/libのサード・パーティJARファイルの使用

DOMAIN_HOME/libのサード・パーティJARファイルの使用は、WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバでのみサポートされます。WebLogic Serverとともにインストールされるドライバの詳細は、「WebLogic ServerとともにインストールされるJDBCドライバ」を参照してください。

DOMAIN_HOME/libディレクトリのサード・パーティJARファイルを使用する場合、次の点に注意してください。

- 作成されるクラス・ローダーは、WebLogic Serverのシステム・クラスパス・クラス・ローダーの子です。

- このディレクトリのJARに含まれるクラスは、サーバーのJava EEアプリケーション(EARファイルなど)にのみ認識されます。

- WebLogic Server管理コンソールおよびWLSTオンラインを使用して、JARファイルを構成および管理できます。(データ・ソースはデプロイされないため、WLSTオフラインを使用することも可能です。)

- これらのJARファイルは、スタンドアロン・クライアント(t3 RMIクライアントなど)やスタンドアロン・アプリケーション(java utils.Schemaなど)から実行すると動作しません。

- これらのJARファイルは、アプリケーション・データ・アクセスではサポートされません。『Oracle WebLogic Server 12.2.1の新機能』のデータベースの相互運用性に関する項を参照してください。

- 複数のドメイン・ディレクトリ(共有ファイル・システムのない複数のマシン)が関連する場合、各ドメイン・ディレクトリの/libにJARファイルをインストールする必要があります。

- WebLogic Serverでは、サード・パーティ・ドライバで呼び出されるメソッド(TimesTen abortやDB2 setDB2ClientUserなど)を使用できます。

データ・ソースのサポート

/libにインストールされたサード・パーティJARファイルは、次のものと組み合せて使用できます。

- WebLogic Serverシステム・リソースでサポートされるすべてのデータ・ソース・タイプ(汎用、マルチ・データ・ソース、Active GridLink、プロキシ・データ・ソースなど)。UCP JARはサード・パーティではないため、UCPデータ・ソースは適用されません。

- EARまたはWARでパッケージ化されたデータ・ソース。

- EARまたはWARで定義されたJava EE 6データ・ソース定義。

JDBCメソッドではありませんが、/libのサード・パーティJARファイルを使用すると、マルチ・データ・ソースのフェイルオーバー、接続、リプレイおよび収集のように、WebLogic Serverデータ・ソース・コールバックに適用されます。

/libのサード・パーティJARファイルの使用の例

次の例は、getversion.warというスタンドアロンWARファイルに含まれるファイルを示しています。Derby JARファイルは、WEB-INF/libまたはDOMAIN_HOME/lib (あるいはその両方)にあります。クラス・ファイルは、コンパイルされてWEB-INF/classes/demo/GetVersion.classにインストールされます。

例17-1 /libディレクトリのサード・パーティJARファイルの使用の例

<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<display-name>GetVersion</display-name>
<servlet>
<description></description>
<display-name>GetVersion</display-name>
<servlet-name>GetVersion</servlet-name>
<servlet-class>
demo.GetVersion
</servlet-class>
</servlet>
<!-- Data source description can go in the web.xml descriptor or as an annotation in the java code - see below
<data-source>
<name>java:global/DSD</name>
<class-name>org.apache.derby.jdbc.ClientDataSource</class-name>
<port-number>1527</port-number>
<server-name>localhost</server-name>
<database-name>examples</database-name>
<transactional>false</transactional>
</data-source>
-->
</web-app>

WEB-INF/weblogic.xml

<weblogic-web-app>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>

Java file

package demo;

import java.io.IOException;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.SQLException;
import javax.annotation.Resource;
import javax.annotation.sql.DataSourceDefinition;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;

@DataSourceDefinition(name="java:global/DSD",
className="org.apache.derby.jdbc.ClientDataSource",
portNumber=1527,
serverName="localhost",
databaseName="examples",
transactional=false
)
@WebServlet(urlPatterns = "/GetVersion")
public class GetVersion extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet {
@Resource(lookup = "java:global/DSD")
private DataSource ds;

public GetVersion() {
super();
}

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
doPost(request, response);
}

protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");

PrintWriter writer = response.getWriter();
writer.println("<html>");
writer.println("<head><title>GetVersion</title></head>");
writer.println("<body>" + doit() +"</body>");
writer.println("</html>");
writer.close();
}

private String doit() {
String ret = "FAILED";
Connection conn = null;
try {
conn = ds.getConnection();
ret = "Connection obtained with version= " +
conn.getMetaData().getDriverVersion();
} catch(Exception e) {
e.printStackTrace();
} finally {
try {
if (conn != null)
conn.close();
} catch (Exception ignore) {}
}
return ret;
}
}

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

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

orai18n.jarおよびorai18n-mapping.jarは、WebLogic Serverインストールにより、ORACLE_HOME\oracle_common\modules\oracle.nlsrtl_12.1.0フォルダに格納されます。これらのファイルは、weblogic.jar manifestマニフェスト・ファイルからは参照されないため、使用前にCLASSPATHに追加する必要があります。

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

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

18 WebLogic JDBCリソースのモニタリング

この章では、稼働中のサーバー、およびコンテナ内にデプロイされたアプリケーションで生成される診断データを作成、収集、分析、アーカイブする方法、およびそのデータにアクセスする方法について説明します。

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

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

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

- 実行時統計の表示

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

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

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

実行時統計の表示

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

データ・ソースの統計

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

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

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

プロファイル・ロギング

WebLogic Serverでは、イベントを記録するためにデータ・ソース・プロファイル・ログが使用されます。プロファイル・ログには次の利点があります。

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

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

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

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

- サーバー上のすべてのデータ・ソースに対して単一のログ・ファイルが使用されます。各プロファイル・レコードには、フィルタ処理のための修飾されたデータ・ソース名があります(該当する場合、application@module@componentで完全修飾されます)。Oracle WebLogic Server MBeanリファレンスの「DataSourceLogFileMBean」を参照してください。

WebLogicのロギング・サービスの詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデータ・ソース・プロファイル・ログの有効化および構成に関する項。

- 『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のWebLogicロギング・サービスの理解に関する項。

プロファイル情報の収集

確認中の統計において、WebLogic Serverドメインになんらかの問題があることが示された場合、データ・ソースを構成して、原因究明の手がかりとなるプロファイル情報を収集できます。収集されたプロファイル情報は、プロファイル・ログのレコードに格納されます。次の項で説明するように、各フィールドには、プロファイル タイプごとに異なる情報が格納されます。

プロファイリングのためにデータ・ソースを構成する場合、プロファイル・データを収集する間隔(収集間隔(秒))を指定する必要があります。間隔を0に設定すると、データ収集は無効化されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの診断プロファイルの構成に関する項を参照してください。

プロファイル・タイプ

この項のプロファイル・タイプごとに、「ユーザー」情報で、接続が割り当てられ、プロファイリング対象の操作に関連するスレッドのスタック・トレースが提供されます。デフォルトでは、この情報の追跡で発生するオーバーヘッドのため、値は設定されません。この情報を取得するには、追跡するプロファイル・タイプに加えて、接続リークのプロファイリングを有効にする必要があります。接続リークのプロファイリングの詳細は、「接続リーク(WEBLOGIC.JDBC.CONN.LEAK)」を参照してください。

このドキュメントの次の項で説明するように、データ・ソースおよびプリコンパイルされた文のキャッシュについて、次の情報をプロファイリングすることを選択できます。

- 接続使用状況(WEBLOGIC.JDBC.CONN.USAGE)

- 待機中の接続予約(WEBLOGIC.JDBC.CONN.RESV.WAIT)

- 失敗した接続予約(WEBLOGIC.JDBC.CONN.RESV.FAIL)

- 接続リーク(WEBLOGIC.JDBC.CONN.LEAK)

- 接続の最終使用状況(WEBLOGIC.JDBC.CONN.LAST_USAGE)

- マルチスレッド接続使用状況(WEBLOGIC.JDBC.CONN.MT_USAGE)

- 文キャッシュ・エントリ(WEBLOGIC.JDBC.STMT_CACHE.ENTRY)

- 文使用状況(WEBLOGIC.JDBC.STMT.USAGE)

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

- クローズ済JDBCオブジェクトの使用状況(WEBLOGIC.JDBC.CLOSED_USAGE)

- ローカル・トランザクション接続リーク(WEBLOGIC.JDBC.CONN.LOCALTX_LEAK)

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

接続使用状況(WEBLOGIC.JDBC.CONN.USAGE)

接続使用状況のプロファイリングを有効にすると、データ・ソース内の接続プールからの接続を現在使用しているスレッドについて情報が収集されます。このプロファイル情報の支援により、アプリケーションがデータ・ソースから接続を取得できない理由を特定できます。

レコードには、次の情報が格納されます。

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

- ID: 接続ID

- User: 接続を使用しているスレッドのスタック・トレース

- Timestamp: 接続がスレッドにいつ割り当てられたか示すタイム・スタンプ

待機中の接続予約(WEBLOGIC.JDBC.CONN.RESV.WAIT)

待機中の接続予約のプロファイリングを有効にすると、データ・ソースからの接続を予約するのを現在待機しているスレッドついて情報が収集されます。このプロファイル情報の支援により、アプリケーションがデータ・ソースから接続を取得できない理由、または接続を待機できない理由を特定できます。レコードには、次の情報が格納されます。

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

- ID: スレッドID

- User: 接続を待機しているスレッドのスタック・トレース

- Timestamp: スレッドが接続をいつ待機し始めたか示すタイム・スタンプ

失敗した接続予約(WEBLOGIC.JDBC.CONN.RESV.FAIL)

失敗した接続予約のプロファイリングを有効にすると、データ・ソースからの接続を予約しようとしたけれども、その接続を取得できなかったスレッドについて情報が収集されます。このプロファイル情報の支援により、アプリケーションが、接続を予約したにもかかわらず、その接続をデータ・ソースから取得できない理由を特定できます。レコードには、次の情報が格納されます。

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

- ID: スレッドID

- User: 接続を待機しているスレッド、および予約リクエストが失敗したときに受け取る例外のスタック・トレース

- Timestamp: 予約リクエストがいつ失敗したか示すタイム・スタンプ

接続リーク(WEBLOGIC.JDBC.CONN.LEAK)

接続リークのプロファイリングを有効にすると、データ・ソースからの接続を予約し、その接続がリークした(接続プールに正常に戻されなかった)スレッドついて情報が収集されます。このプロファイル情報の支援により、JDBC接続を正しく閉じていないアプリケーションを特定できます。いずれかのプロファイル・タイプのユーザー・スタック・トレース情報を取得するには、接続リークのプロファイリングを有効にする必要があります。レコードには、次の情報が格納されます。

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

- ID: 接続ID

- User: 接続を待機しているスレッドのスタック・トレース

- Timestamp: 接続リークがいつ検出されたか示すタイム・スタンプ

予約済の接続がリークしているとみなすまでの時間の長さを指定するには、次のいずれかを実行します。

- Inactive Connection Timeout Secondsを0 (ゼロ)より大きい値に設定します。WebLogicでは、JDBCプール接続が予約された場所のスタック・トレースが出力されます。Inactive Connection Timeout Secondsの時間が経過した後、スタック・トレースが出力されます。

- Connection Leak Timeout Secondsを0より大きい値に設定します。この値は、接続リークの診断プロファイリング・レコードをトリガーするまでにアプリケーションでJDBC接続を保持する時間(秒数)を指定します。0に設定されている場合、タイムアウトは無効です。

接続の最終使用状況(WEBLOGIC.JDBC.CONN.LAST_USAGE)

接続の最終使用状況のプロファイリングを有効にすると、接続を最後に使用した前スレッドについて情報が収集されます。この情報は、保留中のトランザクションが原因で、接続で後続のXA操作が失敗した場合など、接続の問題をデバッグする場合に役立ちます。レコードには、次の情報が格納されます。

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

- ID: スローされたXA例外のスタック・トレース

- User: 接続を最後に使用したスレッドのスタック・トレース

- Timestamp: 例外がいつスローされたか示すタイム・スタンプ

マルチスレッド接続使用状況(WEBLOGIC.JDBC.CONN.MT_USAGE)

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

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

- ID: 接続を使用していることが検出された他のスレッドのスタック・トレース

- User: 接続を予約したスレッドのスタック・トレース

- Timestamp: 複数のスレッドによる接続の使用がいつ検出されたか示すタイム・スタンプ

文キャッシュ・エントリ(WEBLOGIC.JDBC.STMT_CACHE.ENTRY)

文キャッシュ・エントリのプロファイリングを有効にすると、文キャッシュに追加されたプリコンパイルされた文と呼出し可能文について、およびキャッシュされた文から発生したスレッドについて情報が収集されます。この情報の支援により、キャッシュがどのように使用されているか特定できます。レコードには、次の情報が格納されます。

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

- ID: 文の文字列表現

- User: 文を使用しているスレッドのスタック・トレース

- Timestamp: 文がキャッシュにいつ追加されたか示すタイム・スタンプ

文使用状況(WEBLOGIC.JDBC.STMT.USAGE)

文使用状況のプロファイリングを有効にすると、文キャッシュ内のSQL文を現在実行しているスレッドについて情報が収集されます。この情報の支援により、文がどのように使用されているか特定できます。レコードには、次の情報が格納されます。

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

- ID: 文を通じて実行されているSQL文

- User: 文を使用しているスレッドのスタック・トレース

- Timestamp: 文の実行期間

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

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

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

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

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

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

クローズ済JDBCオブジェクトの使用状況(WEBLOGIC.JDBC.CLOSED_USAGE)

JDBCオブジェクト使用状況のプロファイリングを有効にすると、close()メソッドが呼び出された後にアクセスされたJDBCオブジェクト(Connection、StatementまたはResultSet)についてプロファイル情報が収集されます。この情報は、最初にオブジェクトをクローズしたスレッドと、クローズ済のオブジェクトにアクセスしようとしたスレッドの両方を特定するために役立ちます。レコードには、次の情報が格納されます。

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

- ID: オブジェクトのクローズを試みている現在のスレッドのスタック・トレース

- User: オブジェクトをクローズしたスレッドとクローズが実行された場所のスタック・トレース

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

ローカル・トランザクション接続リーク(WEBLOGIC.JDBC.CONN.LOCALTX_LEAK)

JDBCローカル・トランザクション接続リークのプロファイリングを有効にすると、ローカル・トランザクションのリークが発生するアプリケーション・コンポーネント(起動するがトランザクションをコミットまたはロールバックしない)についてプロファイル情報が収集されます。ログ・レコードには、接続を解放しているスレッドに関するコール・スタックおよび詳細が含まれます。レコードには、次の情報が含まれます。

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

- ID: 接続を解放しているスレッドのスタック・トレース

- User: 予約スレッドのスタック・トレースと、接続がクローズされたときのスレッドのスタック・トレース

- Timestamp: 接続がいつクローズされたか示すタイム・スタンプ

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

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

####<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 Server管理コンソール。次の項を参照してください。

- 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. WebLogic Server管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックしていない場合は、これを行います(『Oracle WebLogic Serverの理解』のチェンジ・センターの使用に関する項を参照)。

2. コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

4. 「デバッグ」をクリックします。

5. 「デフォルト」を展開します。

6. 変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。

7. 「有効化」を選択して、選択したデバッグ・スコープまたは属性を有効化します(または「無効化」を選択して無効化します)。

8. これらの変更を有効にするために、WebLogic Server管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

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ファイルに反映されます。例18-1を参照してください。

例18-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): Oracle 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のデバッグの設定

次の項では、UCP/ONSのデバッグの設定方法について説明します。

UCPのデバッグ

UCPのデバッグは、次を使用して直接設定します。

oracle.ucp.level = FINEST;
oracle.ucp.jdbc.PoolDataSource = WARNING;

ONSのデバッグ

ONSデバッグを有効化するには、Java Util Loggingを構成する必要があります。これを行うには、コマンド行で次のプロパティを設定します。

-Djava.util.logging.config.file=configfile
-Doracle.ons.debug=true

このコマンドで、configfileは、ログ出力のフォーマットとロギング・レベルを制御するために標準のJDKロギングで使用される構成プロパティ・ファイル・プロパティのパスとファイル名です。configfileに次の行を含める必要があります。

oracle.ons.level=FINEST

詳細は、Java Platform Standard Edition 7 API仕様のjava.util.loggingに関する項を参照してください。

リクエストのDye処理

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

19 WebLogic JDBCリソースの管理

この章では、WebLogic Server管理コンソール、コマンド行、JMXプログラムまたはWebLogic Scripting Tool (WLST)スクリプトを使用して、ドメイン内のJDBCデータ・ソースを管理する方法について説明します。

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

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

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

- 接続プールの縮小

- 接続プールのリセット

- 接続プールの中断

- 接続プールの再開

- データ・ソースの停止

- データ・ソースの起動

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

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

JDBCDataSourceRuntimeMBean.testPool

データ・ソースのデータベース接続が常に正常であるように、接続を定期的にテストすることをお薦めします。WebLogic Serverでは、2種類の基本的なテストを使用できます。データ・ソースの属性を使用して構成する自動テストと、データ・ソースをトラブルシューティングするために実行できる手動テストです。

WebLogic Serverがプール接続の一貫性を自動的に維持できるようにすることで、DBMS接続のほとんどの問題を防止できます。自動接続テストの構成の詳細は、「データ・ソースの接続テスト・オプション」を参照してください。

データ・ソースからの接続を手動でテストするために、WebLogic Server管理コンソールの「JDBCデータ・ソース: 監視: テスト」ページの「データ・ソースのテスト」機能(JDBCデータ・ソースのテストに関する項を参照)、またはJDBCDataSourceRuntimMBeanのtestPool()メソッドを使用できます。データ・ソースからのデータベース接続をテストするには、データ・ソース構成で「予約された接続のテスト」を有効にし、「テスト対象の表名」を定義する必要があります。どちらも、WebLogic Server管理コンソールを使用してデータ・ソースを作成した場合には、デフォルトで定義されます。

データ・ソースをテストする場合、WebLogic Serverは接続を予約し、「テスト対象の表名」で定義した問合せを使用してそれをテストし、その後、接続を解放します。

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

システムのデータ・ソース内の接続ごとに、WebLogic Serverは文キャッシュを作成します。接続でプリコンパイルされた文または呼び出し可能文が使用されると、WebLogic Serverはその文をキャッシュして、再利用できるようにします。文キャッシュの詳細は、「文キャッシュによるパフォーマンスの向上」を参照してください。

データ・ソース内の接続ごとに専用の文キャッシュがありますが、構成設定はデータ・ソース内のすべての接続に対して行われます。WebLogic Server管理コンソールを使用してデータ・ソースのすべての接続について文キャッシュをクリアすることも、プログラムを介して個々の接続について文キャッシュをクリアすることもできます。

注意:
プリコンパイルされた文のキャッシュが有効になったWebLogicデータ・ソースに対して、JDBC 4.0 setPoolable(false)メソッドがコールされると、ドライバ・オブジェクトでメソッドがコールされるのに加え、文がキャッシュから削除されます。

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

JDBCDataSourceRuntimeMBean.clearStatementCache

データ・ソース内のすべての接続について文キャッシュを手動でクリアするには、WebLogic Server管理コンソールを使用するか(Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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のリソースを解放できます。WebLogic Server管理コンソールの「JDBCデータ・ソース: 制御」ページの「縮小」オプション(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース内の接続プールの縮小に関する項を参照)、またはJDBCDataSourceRuntimeMBeanのshrink()メソッドを使用できます。データ・ソースを縮小すると、WebLogic Serverは、プール内の接続の数を、minCapacityと現在使用中の接続数のうち、大きい方の数まで削減します。スラッシングを最小限にするために、プールは徐々に削減されます。自動縮小が実行されるたびに、未使用接続の数は半分に削減されます。

接続プールのリセット

JDBCDataSourceRuntimeMBean.reset

データ・ソース内の使用可能なすべてのデータベース接続を閉じて再作成するために、WebLogic Server管理コンソールの「JDBCデータ・ソース: 制御」ページの「リセット」オプション(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース内の接続のリセットに関する項を参照)、またはJDBCDataSourceRuntimeMBeanのreset()メソッドを使用できます。これは、たとえば、DBMSが再起動された後に必要になることがあります。データ・ソース内の1つの接続が失敗したとき、多くの場合、プール内のすべての接続が不良です。

接続プールの中断

JDBCDataSourceRuntimeMBean.suspend
JDBCDataSourceRuntimeMBean.forceSuspend

データ・ソースを中断するために、WebLogic Server管理コンソールの「JDBCデータ・ソース: 制御」ページの「中断」および「強制中断」オプション(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの中断に関する項を参照)、またはJDBCDataSourceRuntimeMBeanのsuspend()およびforceSuspend()メソッドを使用できます。

データ・ソースを中断すると(強制中断ではない)、データ・ソースは無効とマークされ、アプリケーションはプール内の接続を予約できません。データ・ソース中断時にそのデータ・ソースからの接続をすでに予約していたアプリケーションは、その接続を予約しようとしたときに例外を受け取ります。データ・ソース内のすべての接続は、データ・ソースが中断される前とまったく同じ状態で保持されます。

データ・ソースを強制中断すると、すべてのプール接続が破棄され、予約した接続を使用する以後の操作はすべて失敗します。クローズされた接続上のトランザクションはすべてロールバックされます。

接続プールの再開

JDBCDataSourceRuntimeMBean.resume

中断したデータ・ソースを再有効化するために、WebLogic Server管理コンソールの「JDBCデータ・ソース: 制御」ページの「再開」オプション(Oracle WebLogic Server管理コンソール・オンライン・ヘルプの中断したJDBCデータ・ソースの再開に関する項を参照)、またはJDBCDataSourceRuntimeMBeanのresume()メソッドを使用できます。データ・ソースを再開すると、WebLogic Serverはデータ・ソースを有効とマークし、アプリケーションはデータ・ソースからの接続を予約できます。データ・ソースを中断した場合(強制中断ではない)、すべての接続が、中断前とまったく同じ状態で保持されます。データ・ソースの中断前に接続を予約していたクライアントは、中断が発生した時点の状態から作業を継続できます。データ・ソースを強制中断した場合、クライアントは、続行するために新しい接続を予約する必要があります。

注意:
たとえば、データベース・サーバーが使用不可の場合など、正しく起動しなかったデータ・ソースは再開できません。

データ・ソースの停止

JDBCDataSourceRuntimeMBean.shutdown
JDBCDataSourceRuntimeMBean.forceShutdown

データ・ソースを停止するために、WebLogic Server管理コンソールの「JDBCデータ・ソース: 制御」ページの「停止」および「強制停止」オプション(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの停止に関する項を参照)、またはJDBCDataSourceRuntimeMBeanのshutdown()およびforceShutdown()メソッドを使用できます。

データ・ソースを停止すると(強制停止ではない)、WebLogic Serverはデータ・ソース内のデータベース接続を閉じ、データ・ソースを停止します。データ・ソースのいずれかの接続が使用中の場合、この操作は失敗します。

データ・ソースを強制停止すると、WebLogic Serverはデータ・ソース内のデータベース接続を閉じ、データ・ソースを停止します。現在の接続ユーザーはすべて強制的に接続解除されます。

データ・ソースの起動

JDBCDataSourceRuntimeMBean.start

データ・ソースを停止した後、WebLogic Server管理コンソールの「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)秒に設定すると、サーバーは無限に待機します。

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

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

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

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

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

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

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

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

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

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

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

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

- メンテナンス・タイマーのチューニング

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

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

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

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

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

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

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

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

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

- 固定

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

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

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

固定

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

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

文キャッシュ・サイズ

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

- 多くの場合、DBMSには、開いている文ごとにリソース・コスト(カーソルなど)が設定されています。これは、文キャッシュ内にあるプリコンパイルされた文およびコール可能文に当てはまります。たとえば、キャッシュする文が多すぎると、データベース・サーバーでのオープン・カーソルの限度を超過する場合があります。サーバー2台に10個の接続をデプロイしているデータ・ソースがあり、文キャッシュ・サイズが10(デフォルト)に設定されている場合、キャッシュされた文に対してデータベース・サーバーで開くことのできるカーソルは200 (10 x 2 x 10)となります。

- 一部のドライバでは、開いている文ごとに大容量メモリー要件を課している場合があります。サーバーの場合、メモリー使用率(データ・ソース数 * 接続数 * 文数)が基準になります。

- 一部のDBMSでは、接続ごとの文数/カーソル数に制限を課している場合があります。

文キャッシュ・サイズは、使用するアプリケーションによって異なります。理想的には、データ・ソースからの接続ごとに処理されるプリコンパイルされた文またはコール可能文の合計数です。アプリケーションで使用される最大サイズの近似値を求める方法の1つとして、キャッシュ・サイズを非常に大きい数値に設定し、アプリケーションのプール統計を監視して、確認された最大値よりも若干大きい値を採用します。WebLogicデータ・ソースから見た場合、アプリケーションで必要とされるよりも大きいキャッシュ・サイズを持つことでパフォーマンスが低下することはありません。

ただし、キャッシュ・サイズが小さすぎる場合は、新しい文を受け入れようとする間のキャッシュ・ターンオーバーが高くなり、古い文が再使用されないうちにフラッシュされてしまうため、パフォーマンスに悪影響を及ぼします。すべての文、または大半の文を保持できるだけ十分な大きさの文キャッシュが使用できない場合には、再使用率が低いために文キャッシュのないほうがシステム・パフォーマンスが向上することがあります。

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

文キャッシュの使用によりパフォーマンスが大幅に向上することがありますが、その使用を決定する前に、制約を考慮する必要があります。文キャッシュを使用する場合は、次の制約に注意してください。

文のキャッシングに関連して、ここには記載していないその他の問題も考えられます。プリコンパイルされた文またはコール可能文に関連してシステムにエラーが生じた場合は、文キャッシュ・サイズを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でプリコンパイルされた文またはコール可能文がキャッシュされると、その文によってデータベースにカーソルが開かれることがあります。キャッシュする文が多すぎると、接続に対するオープン・カーソルの限度を超過する場合があります。接続に対するオープン・カーソルの限度を超過しないようにするには、データベース管理システムで限度を変更するか、データ・ソースの文キャッシュ・サイズを縮小します。

文キャッシュを使用する際のその他の考慮事項

oracle.jdbc.implicitstatementcachesizeがデータ・ソースの接続プロパティに設定されている場合、WebLogic Serverの文キャッシュ・サイズは自動的に0 (ゼロ)に設定されます。

文キャッシュに関して特別な考慮を必要とする場合がいくつかあります。

- データ・ソースがDRCPを使用するように構成されている場合、アプリケーションによって接続が閉じられるときには必ずキャッシュがクリアされます。「データベース常駐接続プーリング」を参照してください。

- データ・ソースがリプレイ・ドライバを通じてアプリケーション・コンティニュイティを使用するように構成されている場合、WebLogic Serverの文キャッシュ・サイズは自動的に0 (ゼロ)に設定されます。

- oracle.jdbc.implicitstatementcachesizeが、データ・ソースの接続プロパティに設定されます。

- プリコンパイルされた文のキャッシュが有効になったWebLogicデータ・ソースに対して、JDBC 4.0 setPoolable(false)メソッドがコールされると、ドライバ・オブジェクトでメソッドがコールされるのに加え、文がキャッシュから削除されます。

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

データ・ソースのデータベース接続が常に正常であるように、接続を定期的にテストすることをお薦めします。WebLogic Serverには、次の2つの基本的なテストが用意されています。

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

- 手動テスト: データ・ソースのトラブルシューティングを実行できます。「データ・ソースおよびデータベース接続のテスト」を参照してください。

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

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

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

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

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

- フラッシュされるまでのテストの失敗数 - (JDBCConnectionPoolParamsBean内のCountOfTestFailuresTillFlush): このオプションは、さらなるデータベース・テストによって発生する遅延を最小限に抑えるためにWebLogic Serverが接続プール内のすべての接続を閉じるまでの間許可される、テストの失敗数の指定に使用します。このパラメータは、マルチ・データ・ソースのメンバーが失敗したときのフェイルオーバーの許容時間を最小限に抑えます。「データベース接続切断後の接続テスト遅延の最小化」を参照してください。

- 無効化されるまでリフレッシュに失敗した接続の数 - (JDBCConnectionPoolParamsBean内のCountOfRefreshFailuresTillDisable): このオプションは、データベースの失敗によって発生する接続リクエストの処理の遅延を最小限に抑えるためにWebLogic Serverが接続プールを無効にするまでの間許可される、テストの失敗数の指定に使用します。「DBMS接続の切断後の接続リクエスト遅延の最小化」を参照してください。

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

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

次の各項では、自動接続テスト・オプションについて説明します。

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

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

- デフォルトのテスト対象の表名を使用したデータベース接続テスト

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

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

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

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

これは非常にまれなケースであり、ネットワーク・ケーブルの切断や、ソケットでコールを実行中のJVMスレッドをロックする可能性のあるその他の問題により発生する果てしなく続く中断により、JVMがOS TCPの限度(通常は10分)に到達するまでブレークできないと判断される可能性を軽減することを意図しています。

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

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

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

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

- 定期的な接続テスト

- 予約済の接続のテスト

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

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

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

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

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

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

定期的な接続テスト

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

予約済の接続のテスト

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

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

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

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

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

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

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

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

使用不能のデータベース接続のテスト中における遅延を最小化するには、接続プールに対してCountOfTestFailuresTillFlush属性を設定します。この機能を有効にするには、TestConnectionsOnReserveをtrueに設定する必要もあります。

接続テストの構成済、またはデフォルトの連続失敗数が確認されると、プール内で現在使用されていない接続はすべて破棄され、後続の接続リクエストに新しい接続が渡されます。アクティブな接続は中断しませんが、アクティビティに関してモニターされます。アクティビティが60秒以内に検知されなかった場合、その接続は破棄されます。

通常は、デフォルト値で十分です。次のような環境では、この値を増やす必要がある場合もあります。

- JDBCアクティビティを数分間示さないことのある実行速度の遅いアプリケーションを使用している

- ネットワーク/ファイアウォールの問題が発生して、常に1つまたは2つの接続が強制終了される

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

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

データベースが使用できない間にクライアント・アプリケーションに対して発生する遅延を最小化するには、接続プールに対してCountOfRefreshFailuresTillDisable属性を設定します。デフォルト値は2です。この機能を有効にするには、TestConnectionsOnReserveをtrueに設定し、InitialCapacityを0より大きい値に設定する必要もあります。

使用不能の接続の置換に関して構成済、またはデフォルトの連続失敗数が確認されると、接続プールが中断されます。アプリケーションが中断された接続プールからの接続をリクエストした場合は、接続が使用できないことをクライアントに通知するためにPoolDisabledSQLExceptionがスローされます。

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

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

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

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

注意:
データ・ソースがマルチ・データ・ソースに追加されている場合、そのマルチ・データ・ソースはデータ・ソースの無効化および再有効化の責任を引き受けます。デフォルトでは、マルチ・データ・ソースは2分ごとに(構成可能)チェックを行い、接続を再確立できるデータ・ソースをすべて再有効化します。マルチ・データ・ソースのレベルでtest frequency secondsを使用して構成します。この設定のセマンティクスは、データ・ソース・レベルとは異なる点に注意してください。

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

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

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

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

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

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

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

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

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

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

AGLおよびFANを有効にして実行する場合:

- ONSはデータベース・インスタンスが停止したときに停止イベントを送信するため、「予約時に接続をテスト」を使用して実行する必要はありません。これによって、データベースでのテストのオーバーヘッドを除去する(または低減する)ことにより、パフォーマンスが大幅に向上する場合があります。ただし、「予約時に接続をテスト」では、ネットワークの接続性やデータベースへのアプリケーションのアクセスなど、その他の障害に関してテストします。オラクル社は、「予約時に接続をテスト」を指定して実行し、SecondsToTrustAnIdlePoolConnectionおよびTestFrequencySeconds(またはその一方)を使用してオーバーヘッドを低減させることをお薦めします。

- CountOfTestFailuresTillFlushおよびCountOfRefreshFailuresTillDisableは無視されます。Oracle RACインスタンス全体の無効化は、インスタンスが停止していることを示すFANイベントが受信された時点で発生します。

デフォルトのテスト対象の表名を使用したデータベース接続テスト

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

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

このパラメータを定義する2番目の方法では、接続をテストするために任意のSQL文字列を実行できるようにします。このオプションを使用するには、パラメータを"SQL"に設定し、さらに目的のSQL文字列を指定します。たとえば、SQL select 1はSQLServerに対して機能します。これは定数を選択する問合せに表を必要としません。このオプションは、WebLogic Serverプール接続テストのDBMS側の制御を追加して、テストの高速化を図る場合に役立ちます。

表20-1 DBMSによるデフォルトのテスト対象の表名

DBMS

デフォルトのテスト対象の表名(問合せ)

DB2

SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES

Microsoft SQL Server

SQL SELECT 1

MySQL

SQL SELECT 1

Oracle

SQL ISVALID

Sybase

SQL SELECT 1

データベース接続テストのオプション

Oracleデータベースを使用するアプリケーション、特にOracle RAC環境が組み込まれているアプリケーションの場合は、「テスト対象の表名」属性のデフォルト値を使用することで、全体のパフォーマンスを最適化できます。

SQL PINGDATABASEおよびSQL SELECT 1 FROM DUALは、引き続きサポートされています。デフォルト値SQL SELECT 1 FROM DUALを使用する場合ほど完全ではありませんが、SQL ISVALIDを使用すると、処理のオーバーヘッドを大幅に削減し、SOAワークロードのパフォーマンスを向上させることができます。

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

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

デフォルトでは、「接続作成の再試行間隔」は0秒です。この値が0に設定されている場合、接続作成の再試行は無効になり、データベースが使用できない場合はデータ・ソースの作成が失敗します。

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

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

JDBCデータ・ソースには2つの属性、「接続予約のタイムアウト」(ConnectionReserveTimeoutSeconds)および「接続の最大待機数」(HighestNumWaiters)があり、接続リクエストを有効化してデータ・ソースからの接続を待機するように設定できます。この2つの属性を同時に指定すると、大量のスレッドをブロックしてシステムを無効にすることなく、接続リクエストを有効化して接続を待機するように設定できます。

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

管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化に関する項も参照してください。

接続予約のタイムアウト

アプリケーションがデータ・ソースからの接続をリクエストしたときに、データ・ソース内の接続がすべて使用中であり、データ・ソースが最大容量まで拡大している場合、接続使用不可のSQL例外がアプリケーションに送られます。これを回避するには、「接続予約のタイムアウト」の値(秒)を、接続リクエストが接続が使用可能になるまで待機するように設定します。「接続予約のタイムアウト」が期限切れになった後で使用可能になる接続がない場合、リクエストは失敗し、PoolLimitSQLException例外がアプリケーションに送られます。

「接続予約のタイムアウト」を-1に設定すると、使用可能な接続が存在しない場合は、接続リクエストが即時にタイムアウトになります。「接続予約のタイムアウト」を0に設定すると、接続リクエストは無期限に待機します。デフォルト値は10秒。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化に関する項を参照してください。

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

接続を待機する接続リクエストによって、スレッドがブロックされます。接続を同時に待機している接続リクエストが多すぎて、スレッドがブロックされると、システム・パフォーマンスが低下することがあります。これを回避するには、「接続の最大待機数」(HighestNumWaiters)属性を設定して、接続を同時に待機できる接続リクエスト数を制限します。

「接続の最大待機数」(HighestNumWaiters)をMAX-INT(デフォルト)に設定すると、接続を待機できる接続リクエスト数の限界が効果的に除去されます。「接続の最大待機数」を0に設定すると、接続リクエストは接続を待機できません。最大リクエスト数に達すると、アプリケーションが接続をリクエストしたときにSQLExceptionがスローされます。

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

リークした接続とは、データ・ソース内の接続プールに適切に戻されなかった接続です。リークした接続を自動的にリカバリするには、WebLogic Server管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページで、「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」の値を設定すると、指定した秒数の間に予約された接続に対してアクティビティが発生しなかった場合、接続がデータ・ソースに強制的に戻されます。0(デフォルト値)に設定した場合、この機能は無効になります。

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

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

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

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

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

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

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

このオプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」ページを参照してください。

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

データ・ソースからのデータベース接続の予約にかかるアプリケーションの時間を最小化し、データベース接続に対するスレッド間の競合を除去するには、JDBCデータ・ソースで「スレッドに固定」オプションをtrueに設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」ページを参照してください。

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

注意:
「スレッドに固定」機能は、IdentityPoolを指定した場合は使用できません。WebLogic Serverリリース12.1.2以降、この組合せを使用する構成では、データ・ソースのデプロイが失敗します。

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

PinnedToThreadが有効になっている場合の接続プール管理操作の変更

PinnedToThreadが有効になると接続プール動作の性質が変更されるため、次のように、一部の接続プールの属性または機能の動作が変わったり、動作の変更に適合できなくなる場合があります。

- 最大容量が無視されます。接続プール内の接続数は、初期容量または、接続プールから予約された接続数のいずれか大きい方に等しくなります。

- 縮小は、接続が接続プールに戻されなくなるため、PinnedToThreadを有効にした場合は接続プールに適用されません。事実上、接続は常に予約されています。

- 接続プールをリセットすると、接続プールからリセットされた接続は「テストが必要」とマークされます。接続が次回に予約されると、接続がテストされ、必要に応じて再作成されます。接続プールをリセットした場合、接続は同期にテストされません。この機能では、「予約時に接続をテスト」を有効にして、テスト対象の表名または問合せを指定する必要があります。

PinnedToThread機能を使用する場合は、次の点を考慮してください。

- Dベースの接続プールを有効化をtrueに設定して使用すると、エラーがスローされて、データ・ソースはデプロイされません。

- 「データベース資格証明の使用」をtrueに設定して使用すると、すべての接続はJDBCディスクリプタで定義されたデフォルト・ユーザーにより所有されますが、OracleプロキシはgetConnection(user, password)で指定されたユーザーとパスワードに設定されます。同様に、Oracleプロキシをtrueに設定すると、ユーザーとパスワードはデータベース資格証明にマップされ、Oracleプロキシが設定されます。これは、PinnedToThreadを使用しない場合と同じ動作です。

- PinnedToThreadの使用時に接続ラべリングはサポートされないため、labelプロパティを使用して接続を取得しようとすると、例外がスローされます。

- マルチ・データ・ソースを使用する場合は、マルチ・データ・ソースにより選択されるメンバー・データ・ソース別に接続が維持されます。たとえば、アルゴリズム・タイプとしてFailoverが指定された場合、接続は、最初はMDSのプライマリ・メンバーに対してのみ維持されます。フェイルオーバーが発生した場合、接続はMDSの次のメンバーに対して維持されます。アルゴリズム・タイプとしてLoad-Balancingを指定した場合、接続はMDSの各メンバーに対して維持されます。

- Active GridLinkを使用する場合、AffinityおよびRuntime Load Balancingは、インスタンスの選択に関連して、引き続き以前と同じように機能します。スレッドごとに1つのインスタンスにつき最大1つの接続が保存されます(OnePinnedConnectionOnly=trueの設定と同じですが、インスタンスごとのベースです)。グラビテイションはサポートされていません(あまり使用されないノードへの接続の移行は行われません)。

PinnedToThreadが有効になっている場合のデータベース・リソースの追加コスト

PinnedToThreadが有効になっている場合、接続プールの最大容量(接続プールに作成されたデータベース接続の最大数)は、接続のリクエストに使用された実行スレッド数に、各スレッドが予約する同時実行接続数を乗じた値になります。この値は、接続プール用に指定された 最大容量を超過することもあります。システム設計の際にこのように超過する接続数を考慮して、オープン・カーソルなどの追加の関連リソースがデータベースで許容できることを確認する必要があります。

また、接続は接続プールに戻されません。つまり、接続数と使用中の関連リソース数を低減するために接続プールを縮小することはできません。このコストを最小化するには、追加のドライバ・パラメータ、onePinnedConnectionOnlyを設定します。onePinnedConnectionOnlyがtrueに設定されている場合は、最初にリクエストされた接続のみがスレッドに固定されます。スレッドが要求した追加の接続はすべて取り除かれ、必要に応じて接続プールに戻されます。次のようにProperties属性を使用して、onePinnedConnectionOnlyを設定します。

Properties="onePinnedConnectionOnly=true;user=examples"

システムで追加のリソース要件を処理できる場合は、PinnedToThreadオプションを使用してパフォーマンスを高めることをお薦めします。

システムで追加のリソース要件を処理できない場合、またはPinnedToThreadを有効にした後でデータベース・リソース・エラーが表示される場合は、PinnedToThreadを使用しないことをお薦めします。

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

WebLogic Serverから返されるドライバのJDBCオブジェクトの中には、デフォルトによりラップされているものがあります。データ・ソース・オブジェクトをラップすることにより、WebLogic Serverでは次の機能が使用できます。

- すべてのメソッド・コールからデバッグ出力を生成します。

- 接続の使用率を追跡して、接続が適切にタイムアウトできるようにします。

- 透過的なトランザクションの自動リスト化と、セキュリティ認証を提供します。

WebLogic Serverには、オブジェクトのラップを無効にする機能があり、次のような利点をもたらします。

- WebLogic Serverでは、ラッパーを通して表示されるインタフェースを実装するベンダー・メソッドに対して動的プロキシが生成されますが、データ型の中にはインタフェースを実装しないものがあります。たとえば、Oracleデータ型のArray、Blob、Clob、NClob、Ref、SQLXML、およびStructは、インタフェースを実装しないクラスです。ラップを無効にすると、アプリケーションはネイティブのドライバ・オブジェクトを直接使用できます。

注意:
これらの具体的なクラスを使用しないで、かわりに標準のSQL型または対応するOracleインタフェースを使用することをお薦めします。『Oracle WebLogic Server JDBCアプリケーションの開発』のOracle JDBCタイプのAPI拡張機能の使用方法に関する項を参照してください。

- ラップのオーバーヘッドを除去すると、パフォーマンスが大幅に向上する場合があります。

ラップを無効にすると(wrap-types要素はfalse)、次のデータ型はラップされません。

- Array

- Blob

- Clob

- NClob

- Ref

- SQLXML

- Struct

- ParameterMetaData

- 接続テストは実行されません。

- ResultSetMetaData

- 接続テストは実行されません。

- 結果セット・テストは実行されません。

- JDBC MTプロファイリングは実行されません。

ラップを無効にする方法

WebLogic Server管理コンソールとWLSTを使用して、データ型のラップを無効にできます。

管理コンソールを使用したラップの無効化

JDBCデータ型オブジェクトのラップを無効にするには:

1. WebLogic Server管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックしていない場合は、クリックします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 「データ・ソースのサマリー」ページで、データ・ソース名をクリックします。

4. 「構成: 接続プール」タブを選択します。

5. 画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。

6. 「データ型のラップ」で、チェック・ボックスを選択解除してラップを無効にします。

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

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

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

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

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

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

メンテナンス・タイマーのチューニング

次の項では、WebLogic JDBCで使用される調整可能なタイマーのプロパティについて説明します。

- weblogic.jdbc.gravitationShrinkFrequencySeconds - 接続は、GridLinkデータ・ソース上で定期的に停止する場合があります。様々なOracle RACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシング率と一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティweblogic.jdbc.gravitationShrinkFrequencySecondsを使用します。0以下の値を設定すると、リバランス・プロセスが無効になります。

- weblogic.jdbc.harvestingFrequencySeconds - 接続収集により、データ・ソースが使用可能な接続数の指定値になったときにアプリケーションにより収集可能とマークされた予約済の接続がリリースされます。デフォルトでは、このチェックは30秒ごとに実行されます。このシステム・プロパティを使用して、データ・ソースによる収集頻度の時間(秒)を変更できます。0以下の値を設定すると、接続収集が無効になります。収集された接続のリカバリを参照してください。

- weblogic.jdbc.securityCacheTimeoutSeconds - WebLogic Serverユーザーの資格証明が予約接続のリクエストごとにチェックされるため、接続プールから接続を予約する際にパフォーマンスが影響を受けます。これを解決するには、このシステム・プロパティを使用してチェックを制御します。0以下の値を設定すると、キャッシュが無効になり、ユーザー認証がそのつど実施されます。0よりも大きい値を設定した場合は、指定された時間(秒)内でユーザーごとに1回だけ、ユーザー認証が実施されます。その後、値がキャッシュされます。プール・アクセス制限が動的に変更された場合は、キャッシュがクリアされた後で、一度に1回ずつユーザーがプールによって再認証されます。デフォルト値は10分です。

A Oracle 12cデータベースの使用

この付録では、WebLogic Serverリリース12.1.2以上をOracle 12cデータベースとともに使用する方法について説明します。特にOracle 12cデータベースとOracle 12c JDBCドライバの使用を必要とする新機能がいくつか提供されています。

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

- Oracle 12cデータベースに対するWebLogic JDBC機能

- WebLogic Serverでの12Cデータベース機能サポートのサマリー

Oracle 12cデータベースに対するWebLogic JDBC機能

次の各項では、Oracle 12cデータベースに対するWebLogic JDBC機能のリストを示します。

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

- アプリケーション・コンティニュイティのサポート

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

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

- Global Database Servicesのサポート

- 自動ONSリスナー

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

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

注意:
Java SE 7のgetParentLoggerメソッドの使用に必要な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といいます。

アプリケーション・コンティニュイティのサポート

アプリケーション・コンティニュイティはOracleデータベース機能の1つであり、アプリケーションに依存しない汎用インフラストラクチャを提供して作業のリカバリを可能にし、システム、通信およびハードウェアの多くの障害をユーザーからマスクします。「アプリケーション・コンティニュイティ」を参照してください。

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

データベース常駐接続プーリング(DRCP)はOracleデータベース・サーバーの機能で、これにより中間層システムをまたぐ可能性のある複数の接続プール間の接続を共有できます。「データベース常駐接続プーリング」を参照してください。

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

コンテナ・データベース(CDB)はOracleデータベース機能の1つであり、多数のデータベースを、単一CDBに含まれる複数のプラガブル・データベース(PDB)を使用して単一データベースに統合することにより、多数のデータベースを持つ場合のオーバーヘッドを最小限に抑えます。プラガブル・データベースを使用するコンテナ・データベースを参照してください。

Global Database Servicesのサポート

Global Database Services (GDS)はOracleデータベース・サーバー機能の1つであり、ロード・バランシングの自動化、フォルト・トレランス、および分散データベース環境でのリソース使用率に対応します。「Global Database Services」を参照してください。

自動ONSリスナー

WebLogic Serverリリース12.1.2以降でOracle 12cデータベースを使用している場合は、Active GridLinkデータ・ソース構成の一部としてONSリスナーのリストを指定する必要はありません。ONSリストはデータベースからドライバに自動的に提供されます。「ONSクライアント構成」を参照してください。

WebLogic Serverでの12Cデータベース機能サポートのサマリー

この項では、Oracle 12cデータベース機能がWebLogic Serverの各リリースでどのようにサポートされているかを説明します。

表A-1 WebLogic Serverでの12cデータベース機能サポートのサマリー

機能

11gドライバおよび11gR2 DBを使用するWebLogic Server 10.3.6/12.1.x

11gドライバおよび12c DBを使用するWebLogic Server 10.3.6/12.1.x

12cドライバおよび11gR2 DBを使用するWebLogic Server 10.3.6/12.1.1

12cドライバおよび11gR2 DBを使用するWebLogic Server 12.1.2以上

12cドライバおよび12c DBを使用するWebLogic Server 10.3.6/12.1.1

12cドライバおよび12c DBを使用するWebLogic Server 12.1.2以上

JDBCリプレイ(読取り/書込み)

いいえ

いいえ

いいえ

いいえ

はい(Active GridLinkによる読取り/書込みのみ、XAトランザクションなし)

はい(Active GridLinkおよび汎用データ・ソースによる読取り/書込み、XAトランザクションなし)

プラガブル・データベース(PDB)

いいえ

はい(Set Containerを除く)

いいえ

いいえ

はい

はい

PDBの動的切替え

いいえ

いいえ

いいえ

いいえ

いいえ

はい(XAなし)

データベース常駐接続プーリング(DRCP)

いいえ

いいえ

いいえ

はい

いいえ

はい

Oracle Notification Service (ONS)の自動構成

いいえ

いいえ

いいえ

いいえ

いいえ

はい(Active GridLinkのみ)

Global Database Services (GDS)

いいえ

はい(Active GridLinkのみ)

いいえ

いいえ

はい(Active GridLinkのみ)

はい(Active GridLinkのみ)

JDBC 4.1 (ojdbc7.jarファイル& JDK 7を使用)

いいえ

いいえ

はい

はい

はい

はい

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

この付録では、エンタープライズ・アプリケーションで使用するためのデータ・ソースのパッケージ化およびスコープ設定の方法と、パッケージ化されたJDBCモジュールの詳細について説明します。

注意:
この章では、DatasourceDefinition機能がJava EE 6に導入される前にWebLogic Serverで提供されていた固有のメカニズムについて説明します。『Oracle WebLogic Server JDBCアプリケーションの開発』のJava EE DataSourcesリソースの定義に関する項を参照してください。

エンタープライズ・アプリケーションをパッケージ化する際、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モジュールをデプロイし、管理します。

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

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

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

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

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://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手できます。

- -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-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、min-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に関する項を参照してください。

例B-1に、代表的な構成オプションを使用するデータ・ソースのJDBCモジュールの例を示します。

例B-1 汎用データ・ソース・モジュールのサンプル

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

Active GridLinkデータ・ソース・モジュールの作成

AGLデータ・ソース・モジュールは、汎用データ・ソース・システム・モジュールに類似しています。AGLデータ・ソースには、ONSおよびFANを含むjdbc-oracle-paramsセクションが含まれます。

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

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に関する項を参照してください。

例B-2に、代表的な構成オプションを使用するデータ・ソースのJDBCモジュールの例を示します。

例B-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 Server WLSTコマンド・リファレンス』のencryptに関する項を参照してください。

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

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

- 特に新規ドメイン用に暗号化されたパスワードが含まれるデプロイメント・プラン内の古い暗号化パスワードをオーバーライドします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデプロイメント・プランの更新に関する項を参照してください。

- 新規ドメイン用に、パスワードを再暗号化します。「JDBCモジュールでのデータベース・パスワードの暗号化」を参照してください。

- Oracleウォレットを使用している場合は、ウォレットを参照して、ウォレット・ファイルを新規ドメインにコピーするだけです。第14章「Oracleウォレットの作成および管理」を参照してください。

パッケージ化された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

図B-1に、EJBアプリケーションに対する各種ディスクリプタ・ファイルのエントリ間の関係と、それらのエントリがアプリケーションでパッケージ化されたJDBCモジュールを参照する方法を示します。

図B-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>)にマップされています。

図B-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();

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

この付録では、WebLogic ServerでOracle Real Application Clusters (Oracle RAC)を使用する際のマルチ・データ・ソースの構成および使用方法について説明します。Oracleでは、Oracle RACを使用するレガシー・アプリケーション環境に対してマルチ・データ・ソース構成を引き続きサポートしています。

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

- Oracle Real Application Clustersの概要

- ソフトウェア要件

- JDBCドライバ要件

- ハードウェア要件

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

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

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

- Oracle RACノード上のサービスへの接続の構成

- マルチ・データ・ソースを使用したSCANアドレスの使用

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

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

Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを同時に使用するには、それぞれのシステムで特定の構成が必要なだけでなく、ソフトウェアと共有ストレージ・ソリューションのクラスタ化も必要になります。この項では、高水準で必要とされる構成について説明します。Oracle RACの構成、クラスタリング・ソフトウェア、オペレーティング・システム、およびストレージ・ソリューションの詳細は、それぞれのベンダーのドキュメントを参照してください。

注意:
新規のOracle RACアプリケーションを開発する場合、および従来のアプリケーションでマルチ・データ・ソースが使用されない場合は、Active GridLinkデータ・ソースの使用をお薦めします。第16章「WebLogic ServerでのOracle RACの使用」を参照してください。

Oracle Real Application Clustersの概要

Oracle Real Application Clusters (Oracle RAC)は高可用性ソリューションに追加できるソフトウェア・コンポーネントであり、複数のマシンを使用しているユーザーは単一のデータベースにアクセス可能になり、さらにパフォーマンスの向上も実現できます。Oracle RACは、2台以上のクラスタ化マシンで実行しており、クラスタ・テクノロジを使用して共有ストレージ・デバイスにアクセスする2つ以上のOracleデータベース・インスタンスで構成されています。このアーキテクチャをサポートするために、これらのデータベース・インスタンスをホストするマシンが高速のインターコネクトによってリンクされてクラスタを構成します。インターコネクトは、クラスタのノード間の通信手段として使用される物理ネットワークです。クラスタ機能は、オペレーティング・システムであるOracle Automatic Storage Management (ASM)、または互換性のあるサード・パーティのクラスタリング・ソフトウェアにより提供されます。図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によってWebLogic Serverを使用するには、Oracle RACのノードごとに次のソフトウェアをインストールする必要があります。

- Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleのリリース・ノートを参照してください。

- Oracle 11gデータベース管理システム

- オペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアとクラスタ構成については、Oracleドキュメントを参照してください。

- 共有ストレージ・ソフトウェア(Oracle自動ストレージ管理(ASM)など)。クラスタリング・ソフトウェアの中にはファイル・ストレージ・ソリューションが組み込まれているものがあり、その場合は共有ストレージ・ソフトウェアを追加する必要がありません。

注意:
最新のWebLogic Serverハードウェア・プラットフォームとオペレーティング・システムのサポート、およびWebLogic Serverの各種バージョンとサービス・パックによりサポートされるOracle RACバージョンについては、『Oracle WebLogic Serverの新機能』 12.2.1のサポートされる構成に関する項を参照してください。Oracle RACソフトウェアの実行に必要なハードウェア要件およびソフトウェア要件については、Oracleドキュメントを参照してください。

JDBCドライバ要件

Oracle RACによってWebLogic Serverを使用するには、WebLogic汎用データ・ソースで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ドメインがOracle RACインスタンスと相互作用して、予想どおりに実行できるようにWebLogicドメインを構成する必要があります。次の各項では、構成オプションと要件について説明します。

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

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

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

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

- リモート・リスナー有効時または無効時のマルチ・データ・ソースの構成

- 構成に関する追加の考慮事項

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

WebLogic Serverのマルチ・データ・ソースは、Oracle RACで使用できるようにいくつかの構成オプションをサポートしています。

- グローバル・トランザクション(XA)を使用する場合に複数のOracle RACインスタンスに接続する方法については、「グローバル・トランザクションを使用したマルチ・データ・ソースの使用」を参照してください。

- グローバル・トランザクション(XA)を使用しない場合に複数のOracle RACインスタンスに接続する方法については、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。

- また、Oracle RACノード上で実行している特定のサービスに接続するようにマルチ・データ・ソースを構成することもできます。XAドライバと非XAドライバはどちらもサポートされています。「Oracle RACノード上のサービスへの接続の構成」を参照してください。

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

マルチ・データ・ソースを使用してWebLogic Serverを複数のOracle RACノードに接続するには、まず、Oracle RACクラスタでOracle Thinドライバを使用して、Oracle RACインスタンス別に汎用データ・ソースを構成します。次に、ロード・バランシングとフェイルオーバーいずれかのアルゴリズムを使用してマルチ・データ・ソースを構成し、それに汎用データ・ソースを追加します。

図C-2に、標準的なマルチ・データ・ソース構成を示します。

図C-2 マルチ・データ・ソース構成

WebLogic Server管理コンソール、またはドメインの構成に優先的に使用したいその他の手段、たとえばWebLogic Scripting Tool (WLST)またはJMXプログラムが使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。Oracle RACノード上で実行するサービスに接続するためにマルチ・データ・ソースに汎用データ・ソースを構成する方法については、「Oracle RACノード上のサービスへの接続の構成」を参照してください。

この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つ検索してから、接続をリクエストします。マルチ・データ・ソースによって、接続リクエストへの対応に使用する汎用データ・ソースが、構成で指定されたアルゴリズムのタイプ(フェイルオーバーまたはロード・バランシング)に基づいて決定されます。

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

マルチ・データ・ソースには、システム・ロード・バランシングまたはフェイルオーバーでのOracle RACのロールに応じて、次の属性を割り当てることができます。

- AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"
Load-Balancingオプションを指定した場合、接続リクエストは使用可能な汎用データ・ソースの間で分散されます。Failoverオプションを指定した場合、接続リクエストはリスト内で最初に使用可能なプールにより対応されます。汎用データ・ソースが使用できない場合は、リスト内の次の汎用データ・ソースが接続リクエストに対応します。

- FailoverRequestIfBusy="true"
フェイルオーバー・アルゴリズムを使用している場合、この属性により、汎用データ・ソース内のすべての接続が使用中のときにフェイルオーバーが有効になります。

- TestFrequencySeconds="120"
この属性は、接続が再作成可能かどうか、および汎用データ・ソースが再有効化できるかどうかを判別するために、以前に異常とマークされた汎用データ・ソースのヘルスをWebLogic Serverがチェックする頻度を制御します。詳細は、第5章「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再試行の間隔も短くなります。ほとんどの場合、デフォルト値で十分です。

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で使用する場合、ユーザー・プロセスは通常はデータ・ソースです。

マルチ・データ・ソースが作成されると、アプリケーションで流用できるようにデータベース接続プールの作成が試みられます。プールされたデータベース接続が操作不能になったり、汎用データ・ソースが容量が増加するように構成されている場合、データ・ソースは、構成ファイルで指定された最大値まで追加のデータベース接続を作成しようと試みます。これらのすべてのインスタンスで、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。

図C-3は、Oracleリスナー・プロセスの機能を示しています。

図C-3 Oracleリスナー・プロセスの機能

この機能を有効にするには、次の2つのオプションが使用できます。

- ローカル・リスナーの使用。Oracleクラスタ内のOracle RACインスタンスごとにリスナー・プロセスを構成します。WebLogic Serverでは、Oracle RACインスタンスごとにローカル・リスナーを構成する必要があります。各データベース・インスタンスは、そのローカル・リスナーのみに登録されるように構成します。
Oracleインスタンスは、listener.oraファイル内で静的にリスナーに登録されるか、インスタンス初期化パラメータlocal_listenerを使用して動的に登録されるか、またはその両方で登録されるように構成できます。動的登録の使用をお薦めします。

リスナーは、共有ディスパッチャ・プロセスまたは専用プロセスのいずれかを開始できます。WebLogic Serverで使用する場合は、専用プロセスの使用をお薦めします。

- リモート・リスナーの使用。WebLogic Serverでは、マルチ・データ・ソース内の汎用データ・ソースの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.country.myCorp.com)(INSTANCE_NAME=orcl1)))

次のコード・スニペットは、汎用データ・ソース構成の一例です。

<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.country.myCorp.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.country.myCorp.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

注意:
Active GridLinkデータ・ソースを使用していない場合は、XA環境と非XA環境のOracle RACインスタンス全体にわたるフェイルオーバーおよびロード・バランシングに対して、マルチ・データ・ソースを使用することをお薦めします。非XA環境でのマルチ・データ・ソースの使用方法の詳細は、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。

グローバル・トランザクションを使用する場合のマルチ・データ・ソース内のデータ・ソースの必須属性

マルチ・データ・ソース内の汎用データ・ソースは、それぞれ次の属性を持っている必要があります。

- Oracle JDBC Thinドライバ。次に例を示します。

<url>jdbc:oracle:thin:@host1: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:@host1: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:@host2: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ドライバ。次に例を示します。

<url>jdbc:oracle:thin:@host1:1521:SNRAC1</url>
<driver-oracle.jdbc.OracleDriver/driver-name>

- TestConnectionsOnReserve="true"

- アプリケーションが汎用データ・ソースから接続を予約したときに、データベース接続のテストを有効にします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。

- フェイルオーバーと接続リクエストのルーティングのマルチ・データ・ソース内での有効化に必要です(実際には、別のOracle RACノードにフェイルオーバーします)。

- TestTableName="name_of_small_table"

- 物理データベース接続のテストに使用する表の名前。この属性に関する詳細は、「データ・ソースの接続テスト・オプション」を参照してください。

構成コードのサンプル

WebLogic JDBCマルチ・データ・ソースの構成コードのサンプルと、関連する汎用データ・ソースを次に示します。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:sec="http://xmlns.oracle.com/weblogic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://xmlns.oracle.com/weblogic"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
<name>jdbcPool</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@host1: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:@host2: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、WebLogic Server管理コンソールまたは構成ウィザードを使用)、Oracle RACノード上で稼働中のサービスに接続するように汎用データ・ソースを構成します。ただし、次の例外があります。

- initial-capacity="0"
これにより、WebLogic Server起動時の非アクティブなプールに対するプール作成の失敗が回避でき、WebLogic Serverがノード上のサービスに接続できないときでも汎用データ・ソースを作成できます。このオプションを0に設定しないと、汎用データ・ソースの作成が失敗して、サーバーは通常にブートできない場合があります。

WebLogic Server管理コンソールで、汎用データ・ソースを作成した後で編集し、「初期容量」を0に設定します。

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

WebLogic Server管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストから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)))"

WebLogic Server管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストからRACサービス・インスタンス接続用のOracleのドライバ(Thin XA)を選択し、「サービス名」フィールドでサービスを指定します。

注意:
SERVICE_NAMEは、指定されたマルチ・データ・ソース内のすべての汎用データ・ソースで同じである必要があります。
指定されたマルチ・データ・ソース内の汎用データ・ソースごとに異なるHOST NAMEおよびポート(またはその一方)を指定します。

- 接続プールに対してmax-capacity (WebLogic Server管理コンソールでは「最大容量」)を指定する際、構成内の各Oracle RACノードの接続容量と、すべての汎用データ・ソースからの接続総数を考慮に入れる必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。

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

サービス接続のシナリオでは、マルチ・データ・ソースの構成にロード・バランシング・アルゴリズムを使用することをお薦めします。ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成した場合、その接続プールはラウンドロビン方式で使用されます。この場合、関連するサービスが現在アクティブになっているすべてのOracle RACノードにわたって、ワークロードがロード・バランシング処理されます。

マルチ・データ・ソースの構成にフェイルオーバー・アルゴリズムを使用した場合は、接続の試行が失敗するまで(たとえば、Oracle RACノードが使用できなくなったり、使用可能な接続が汎用データ・ソースになくなるなどの理由で)、関連するOracle RACノード上のサービスへの接続に最初の汎用データ・ソースが使用されます。失敗した時点で、関連するOracle RACノード上のサービスへの接続に2番目の汎用データ・ソースが使用され、これが順次続行されます。この場合、最初の汎用データ・ソースの接続先であるOracle RACノードは、サービスが稼働中であるその他のノードよりも多く使用されることになります。

サービス接続の構成

次の機能を提供できるように構成を設計できます。

- ワークロード管理

- ロード・バランシング

ワークロード管理

ワークロード管理構成では、接続しているサービスが特定のOracle RACノードでアクティブか、または非アクティブかどうかに関係なく、各マルチ・データ・ソースでは、それぞれ1つの汎用データ・ソースが各Oracle RACノードの特定のサービス用に構成されています。このため、計画外ダウンタイムやスケジュールされたメンテナンスなどにより別のノードが使用できなくなった場合に、ノード上で非アクティブなサービスをすばやく開始して、そのサービスへの接続を作成できます。また、ワークロード需要に基づいて、指定されたサービスの使用可能容量をすばやく増加または削減することもできます。

ノード上でサービスが開始すると、関連付けられた汎用データ・ソースはサービスがアクティブになっていることを検出し、必要に応じてそのノードへの接続を開始します。指定されたノード上のサービスが停止すると、関連付けられた汎用データ・ソースはそのノードへの接続ができなくなり、サービスが再開始されるまで非アクティブになります。

WebLogic Server汎用データ・ソースは、接続テストを実行します。このため、汎用データ・ソースは、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ノードで複数のサービスが同時に稼働しています。各WebLogic Serverマルチ・データ・ソースには、各ノードの指定されたサービスに接続するように構成されたアクティブな接続プールが1つ割り当てられています。このシナリオでは、ロード・バランシング・アルゴリズムを使用するように各マルチ・データ・ソースを構成します。

図C-5 マルチ・データ・ソースを使用したロード・バランシング

この例では、サービス1およびサービス2は使用可能なすべてのOracle RACノード上でそれぞれアクティブに稼働しています。その結果、各マルチ・データ・ソース内のすべての接続プールは、5つのノードの間でワークロードのバランスを取りながら、ラウンドロビン方式でアクティブに接続を行います。

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

汎用データ・ソースに指定した最大容量の値によって、特定のOracle RACノードの接続容量を超過することがあります。汎用データ・ソース別にこの値を設定する際、次の要因を考慮する必要があります。

- 1つのOracle RACノードでサポートできる同時接続の最大数。これは、1つのOracle RACノードで使用可能なメモリーと、各サービス接続の消費メモリー量(これはサービスごとに異なる場合があります)に基づきます。各接続のメモリー消費量は、WebLogic Serverから生成できる作業量に対する主な制約要因です。WebLogic Server汎用データ・ソースからOracle RACノードへの接続が多すぎるために使用可能メモリー量を超えた場合、Oracle RACノードのパフォーマンスが低下し、接続失敗につながることがあります。
ノードの使用可能メモリーは、PGAターゲット属性(セッション・メモリーごと)に基づいていることが望ましいです。

- 特定のOracle RACノードに対して潜在的に接続を作成できる汎用データ・ソースの最大数、および各汎用データ・ソース/マルチ・データ・ソースをターゲットに指定するWebLogic Serverインスタンス数。たとえば、3つのWebLogic Serverのターゲットとして指定された汎用データ・ソースが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つのWebLogic Serverがあるため、このOracle RACノードに対して接続リクエストを作成する汎用データ・ソースが5つ存在することになります。したがって、1つの汎用データ・ソースからの接続に使用可能なメモリーは1GB (5GB/5)になります。各接続では10MBのメモリーが必要なため、クラスタ1のターゲットとなる汎用データ・ソースごとの最大容量値は100以下になります。

クラスタ2には4つのWebLogic Serverがあるため、この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 generic data sources targeted to each instance x Number of active Oracle RAC services configured x Number of Oracle RAC Nodes)

説明:

Oracle RACノードの最大接続数は、すべてのノードで使用可能なメモリー合計を各接続の消費メモリーで割って決定されます。

WebLogic Serverインスタンス数は、汎用データ・ソースをターゲットとするサーバー・インスタンス数です。汎用データ・ソースのターゲットがWebLogic Serverクラスタである場合、これはクラスタ内のサーバー数になります。

図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 generic data sources x 2 services x 5 Oracle RAC nodes)

この場合、汎用データ・ソースごとの最大容量値は16になります。

図C-6 マルチ・データ・ソースの接続構成例

この式は、汎用データ・ソースの構成に関する一般的なガイドラインにすぎないことを念頭に置いてください。多数の構成になると複雑すぎて、このように簡単な計算を使用できないためです。

使用する最大容量値を計算する際、構成全体を対象とした最悪ケースのシナリオを常に考慮してください。最悪ケースのシナリオを展開する際に、この値を通常操作に対して過大構成するのではなく、過少構成するのが最善です。Oracle RACノードを常にモニターしていると、汎用データ・ソースの最大容量値を高くしても安全かどうかが判別できます。

マルチ・データ・ソースを使用したSCANアドレスの使用

単一クライアント・アクセス名(SCAN)は、マルチ・データ・ソースでの使用にはお薦めできません。使用している構成がSCANを使用するように設定されている場合に、問題が生じることがあります(たとえば、データベース・リスナーがSCANを使用するように設定されている場合、非SCANアドレスが使用できません)。

SCANは、次の2つの目的で使用されます。

- 接続時刻のリスナー・フェイルオーバー機能を提供します。

- 接続ロード・バランシング機能を提供します。

マルチ・データ・ソースは接続ロード・バランシングとフェイルオーバーの処理を制御できる必要があるため、接続ロード・バランシング機能をマルチ・データ・ソースで使用することはできません。この機能を無効にするには、INSTANCE_NAME属性が指定されているURLを使用します。マルチ・データ・ソース内の各汎用データ・ソースは、それぞれ異なるインスタンスを指している必要があります。最初の汎用データ・ソース上でインスタンスが停止しているとマルチ・データ・ソースが認識した場合、マルチ・データ・ソースは停止していない最初の汎用データ・ソース上のインスタンスに接続を転送します。INSTANCE_NAME属性を指定してSCANを使用している場合、マルチ・データ・ソースは接続のロード・バランシングとフェイルオーバーを指定して、引き続き、より信頼性の高い方法でリスナーに到達できるようにします。

マルチ・データ・ソース用にSCANアドレスを構成する必要がある場合は、異なるINSTANCE_NAME値が設定されているURLを使用して汎用データ・ソースの各メンバーを構成します。次に例を示します。

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scanname)(PORT=scanport))(CONNECT_DATA=(SERVICE_NAME=myservice)(INSTANCE_NAME=myinstance)))

注意:
ノードを追加する場合は、汎用データ・ソースのメンバーを手動で追加し、そのメンバーをマルチ・データ・ソースに追加する必要があります。

SCANによる接続ロード・バランシングの実行を回避する別の方法は、単一インスタンス上で使用できるサービス名を指定し、インスタンス名を省略することです。各メンバー・データ・ソースは、独自の一意のサービス名を持つ必要があり、各サービス名は、他のメンバー・データ・ソースと重複しない単一インスタンスでのみ使用できる必要があります。

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クラスタの同一インスタンスで開始、準備、および完結させる必要があります。汎用データ・ソース構成で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ストアの構成

- JMS接続に対する自動再試行

JDBCストアを使用する主要サービスのリストについては、『Oracle WebLogic Serverサーバー環境の管理』のストア接続のモニタリングに関する項を参照してください。

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

JDBCストアの動作方法により、Oracle RACで使用するJDBCストアの構成に使用できるオプションが制限されます。グローバル・トランザクションのサポートのために構成された汎用データ・ソースを使用するようにJDBCストアを構成することはできません。JDBCストアでは、非XA JDBCドライバを使用する汎用データ・ソースを使用する必要があります。この構成オプションの詳細は、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。

JDBCストアは接続が失敗するまでその接続を保持しており、失敗した時点で次の接続に移動して、プロセスを繰り返します。したがって、ロード・バランシングのマルチ・データ・ソースも含め、JDBCストアでロード・バランシング機能を実装することはできません。JDBCストア用のマルチ・データ・ソースは、フェイルオーバー・アルゴリズムを使用するように構成する必要があります。

要するに、JDBCストアに対して次の処理を行います。

- 非XAドライバを使用します。

- フェイルオーバー・モード用にマルチ・データ・ソースを構成します。

JMS接続に対する自動再試行

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を再起動するか、シングルトン・サービスに対して自動サービス移行(ASM)のrestart-in-placeオプションを設定することです。そうしないと、I/Oエラーが発生したときに、トランザクションはJMSサーバーが再起動されないかぎりリカバリできないようにマークされてしまいます。

自動接続再試行ロジックは、現在はWebLogic Serverによって次のように管理されています。

-Dweblogic.store.jdbc.IORetryDelayMillis=x

この場合、xはデータベースへの接続が再試行されるまでの経過時間(ミリ秒)です。デフォルト値は、1000ミリ秒です。この値は0から15000ミリ秒の範囲に制限されており、再試行は1回のみ試みられます。2回目の試みで失敗すると、コール・スタックまで例外が伝播され、失敗したトランザクションに関連するメッセージをリカバリするには手動での再起動が必要になります。

注意:
自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。シングルトン・サービスに対する自動サービス移行(ASM)のrestart-in-placeオプションを使用して、失敗したJMSサービスの自動再起動をトリガーすることができます。
自動再試行の遅延は、接続再試行メカニズムのみに適用されます。JDBCストアのI/Oエラーに使用できる構成可能な再試行の遅延はありません。

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

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

WebLogic Serverは、高速接続フェイルオーバーをサポートしています。これは、無効な接続の検出とクリーンアップ、使用可能な接続のロード・バランシング、およびアクティブなOracle RACインスタンス上での作業の再配信などのOracle RACイベント通知を実装するために、アプリケーション非依存の方法を提供するOracle機能の1つです。

詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』の高速接続フェイルオーバーの使用に関する項を参照してください。

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

データ・ソースで高速接続フェイルオーバーを有効化するには、次の接続プールのプロパティを設定します。

- ドライバ・クラス名内: クラス名をoracle.jdbc.pool.OracleDataSourceに設定します。

- プロパティ内: Oracle RACノードをリモートにサブスクライブするONS構成文字列をOracle FAN/ONSイベントに設定します。例: ONSConfiguration=nodes=hostname1:port1,hostname2:port2

注意:
OracleのOracleDataSourceクラスはXA対応ではないため、結果として生じるデータ・ソースではXA接続プールは実装されません。

E JDBCのスマート・アップグレードのサポート

この付録では、JDBC用のWebLogic Server SmartUpgradeのサポートについて説明します。WebLogic Server SmartUpgradeは、Oracle JDeveloper拡張機能のコマンド行ユーティリティです。このユーティリティでは、Oracle OC4Jにデプロイしていたアプリケーションを分析します。これを使用すると、Oracle WebLogic Serverにアプリケーションを正常に再デプロイするために役立つアドバイスが提示され、アクションが実行されます。アプリケーション・アーカイブを分析することも、Oracle JDeveloperで開いているアプリケーションやプロジェクトを分析することもできます。さらに、SmartUpgradeは、アプリケーションをデプロイしたOC4Jサーバーを分析して、Oracle WebLogic Serverで同様の構成を設定する方法についてのアドバイスを提示します。

SmartUpgradeでは、各アプリケーションに関する特定の結果を包括的にレポートするだけでなく、アップグレード・タスクの一部を自動化することもできます。JDBCの場合、OC4J J2EE_HOME\home\config\data-sources.xmlファイルおよび、アプリケーション用に定義された各データ・ソースの構成ファイル(ear)を、対応するWebLogic Server JDBCデータ・ソース定義に合わせてアップグレードできます。

Smart Upgradeでは、次の機能の変換をサポートしています。

- OC4Jデータ・ソースがOracle RACサービス(長い形式)のURLで構成されており、fastConnectionFailoverEnabled=trueまたはONSConfigurationが設定されている場合、Active GridLinkデータ・ソースが構成されます。

- fastConnectionFailoverEnabled=trueは、fan-enabledがtrueに設定されていることを示します。

- ONSConfiguration(ノードおよびオプションのウォレット情報、たとえばnodes=racnode1:4200,racnode2:4200\nwalletfile=/mydir/Wallet\nwalletpassword=mypasswd)が解析されて、ノード・リストとオプションのウォレット情報を取得します。その後、この情報はノード・リスト、ウォレット・ディレクトリ、およびウォレット・パスワードの設定に使用されます。

- Remove-infected-connectionsは、OC4Jの動作に合わせるために、常にfalseに設定されます。

- Wrap-typesは、OC4Jの動作に合わせるために、常にtrueに設定されます。

- OC4Jのproxy-sessionsがtrueに設定されている場合、Oracle-proxy-sessionはtrueに設定されます。

- OC4Jのfatal-error-codesと値が使用可能な場合は、fatal-error-codesリストが設定されます。

- Min-capacityはOC4Jのmin-connections(使用可能な場合)に設定されます。

- Identity-based-connection-pooling-enabledおよびuse-database-credentialsは、OC4Jの動作に合わせるために、常にtrueに設定されます。

Smart UpgradeはWebLogic Serverに同梱されていませんが、http://www.oracle.com/technetwork/middleware/downloads/smartupgrade-085160.htmlから別途ダウンロード可能です。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork 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を参照してください。