Oracle WebLogic ServerとOracle Database 12cの統合

Oracleホワイト・ペーパー 2013年6月

Oracle WebLogic ServerとOracle Database 12cの統合

免責事項以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます。


はじめに .................................................................................................................................................... 2

Active GridLink for RAC ..................................................................................................................... 3

Oracle RACとWebLogic Serverの簡素化された構成 ................................................ 3 Active GridLink：おもな機能の概要 .................................................................................. 3

Oracle WebLogic ServerとOracle Database 12cの統合 ................................................. 4

アプリケーション継続性とTransaction Guard ................................................................... 5

Oracle WebLogic Serverにおけるアプリケーション継続性の適用 ................. 7 オラクルのドライバとデータベースによるJDBCリプレイ ................................. 8

データベース常駐接続プール ....................................................................................................... 9

プラガブル・データベース ......................................................................................................... 11

自動ONS ................................................................................................................................................. 13

グローバル・データ・サービス ............................................................................................... 14

まとめ ...................................................................................................................................................... 15

参考資料 ................................................................................................................................................. 16


はじめに

Oracle WebLogic Server 11gでは、Active GridLink for Real Application Clusters（Oracle RAC）が導入されました。この強力なソフトウェア・テクノロジーをOracle Databaseとともに使用することにより、ランタイム接続、ロードバランシング、アフィニティなどの機能によって、管理が簡素化され、可用性が向上し、高速接続フェイルオーバーが確実に実行されるようになります。

Oracle WebLogic Server 12c（12.1.2）とOracle Database 12cの緊密な統合により、グローバル・クラウド環境の優れた可用性、強力なリソース共有、高度なスケーラビリティ、容易な構成、自動管理機能によって、それらの機能が強化されます。Oracle WebLogic Serverは、このレベルでのOracle Database 12cとの統合が可能な唯一のアプリケーション・サーバーです。

本書では、データベース、クラスタ、アプリケーション・サーバーに関するオラクル独自のテクノロジーが連携して動作することで得られる、企業向けの卓越した可用性、スケーラビリティ、パフォーマンスの仕組みについて説明します。最初に、Oracle Active GridLink for RACについて、その容易な構成、管理性、パフォーマンスを中心に簡単に説明します。次に、プラガブル・データベース（PDB）、データベース常駐接続プール（DRCP）、アプリケーション継続性、グローバル・データ・サービス（GDS）といったOracle Database 12cなどの複数の先進機能に与えるOracle WebLogic Serverの影響について説明します。

図1：Oracle WebLogic Server 12cとOracle Database 12cの統合

2


Active GridLink for RAC

Oracle WebLogic Server 11g（10.3.4）では、「Active GridLink for RAC」と呼ばれる、Oracle RACをサポートする単一のデータソース実装が導入されました。このデータソースは、高速アプリケーション通知（FAN）イベントに対応し、高速接続フェイルオーバー（FCF）、ランタイム接続ロードバランシング（RCLB）、およびOracle RACインスタンスのスムーズな停止を提供します。XAアフィニティは、グローバル・トランザクションIDレベルでサポートされます。Active GridLink for RACは、Oracle WebLogic Server内でGridLinkデータソースとして実装されています。

このOracle WebLogic Serverの単一データソース実装は、Oracle RACとのより深い統合により、データソースの接続先であるデータベース・サービスの完全で無制限な使用をサポートします。プール内の接続のアクティブな管理は、接続プール自体に構成される静的設定（最小/最大容量、タイムアウトなど）と、クライアントにRACクラスタ内のステート変更を知らせるRAC Oracle Notification Serviceサブシステムから接続プールが受信するリアルタイム情報に基づきます。

Universal Connection Pool（UCP）Javaライブラリは、Oracle WebLogic Serverと統合されています。このライブラリは、WebLogic GridLinkデータソースによって活用され、高速接続フェイルオーバー、ランタイム接続ロードバランシングおよびアフィニティ機能を実現します。

Oracle RACとWebLogic Serverの簡素化された構成

この新しい実装により、GridLinkデータソースを使用したOracle RACデータベースとOracle WebLogic Serverの統合が簡素化され、Oracle RACを使用するために必要な構成および管理の複雑さが軽減されます。オラクルは、Oracle RAC環境向けのWebLogicマルチ・データソース構成もサポートします。WebLogicマルチ・データソースからGridLinkデータソースへのアップグレードは簡単です。このアップグレードは、マルチ・データソースと同じJNDI名で単一のGridLinkデータソースを作成するだけで済みます。このアプローチにより、スループットが改善され、維持すべき構成アーチファクトの数も削減されます。

Active GridLink：おもな機能の概要

WebLogic GridLinkデータソースは、Universal Connection Poolからの高速接続フェイルオーバーと統合されました。これにより、以下のことが可能になりました。

• 迅速な障害検出

• 接続プールからの無効な接続の中断および削除

• Oracle RACノードの計画停止および計画外停止の際のスムーズな停止

• ノードの追加または削除などの、トポロジの変更への適応

• クラスタを再結合するものを含む、すべてのアクティブなOracle RACインスタンスへのランタイム作業リクエストの配信

3


Oracle RACデータベースがFAN通知によって提供するランタイム接続ロードバランシング機能をWebLogic GridLinkデータソースおよびJDBC接続プールが利用することにより、スループットが向上し、リソースの使用がより効率的になります。

図2：Active GridLink for RACのロードバランシング、XAアフィニティ、フェイルオーバー

Oracle WebLogic Server 11g（10.3.6）では、読取り専用操作のためのアプリケーション継続性、Webセッション・アフィニティなどのOracle Database 11gの機能がActive GridLink for RACによってサポートされます。

アプリケーション継続性は、機能停止時に作業をリカバリし、多数のシステム、通信、ハードウェア障害およびハングによる影響を表面化させない、汎用のアプリケーション非依存インフラストラクチャです。このバージョンでは、読取り専用操作のみがサポートされます。

Webセッション・アフィニティは、Webセッションで実行されたデータベース操作を同じOracle RACインスタンスに指示する、GridLinkデータソースの新しいポリシー・オプションです。この手法により、データベース使用率が改善されるとともに、全体的なアプリケーション・パフォーマンスが向上します。


統合されたテクノロジー・プラットフォームを提供することは、常にオラクルの全体的な戦略の主要な要素のひとつです。このため、Oracle WebLogic Server 12c（12.1.2）は、Oracle Database 12cをサポートしており、アプリケーション継続性、Transaction Guard、データベース常駐接続プール、プラガブル・データベース、マルチテナント、グローバル・データ・サービスなどの機能に関して特に、Oracle Database 12cに対して完全に認定されています。Oracle WebLogic Serverは、このレベルでのOracle Database 12cとの統合を可能にし、購入できる唯一のアプリケーション・サーバーです。表1に、Oracle WebLogic Server 12.1.2、12.1.1および10.3.6と統合されているOracle Database 12cの機能を示します。

データベース機能 WLS

10.3.6/12.1.1/12.1.2

11gドライバ

11gR2 DB

WLS

10.3.6/12.1.1/12.1.2

11gドライバ

12c DB

WLS

10.3.6/12.1.1

12cドライバ

11gR2 DB

WLS

12.1.2

12cドライバ

11gR2 DB

WLS

10.3.6/12.1.1

12cドライバ

12c DB

WLS

12.1.2

12cドライバ

12c DB

JDBC リプレイ

（読取り/書込み）

なしなしなしなしあり

（ Active GridLink

（非XA）による読

取り/書込み）

あり

（汎用データソー

スおよび Active

GridLink（非XA）

による読取り /書

込み）

4


プラガブル・デー

タベース（PDB）

なしありなしなしありあり

PDB間の動的切り

替え

なしなしなしなしなしあり

データベース常駐

接続プーリング

（DRCP）

なしなしなしありなしあり

Oracle

Notification

Service （ ONS ）

の自動構成

なしなしなしなしなしあり

（ Active GridLink

のみ）

グローバル・デー

タベース・サービ

ス（GDS）

なしあり

（ Active GridLink

のみ）

なしなしあり

（ Active GridLink

のみ）

あり

（ Active GridLink

のみ）

JDBC 4.1

（ojdbc7.jarファイ

ルおよびJDK 7）

なしなしありありありあり

表1：Oracle Database 12cによるOracle WebLogic Serverの認定

アプリケーション継続性とTransaction Guard

Oracle Database 12cが提供する重要な機能であるアプリケーション継続性は、機能停止時に作業をリカバリし、システム、通信、ハードウェア障害による影響をユーザーに与えない、汎用のアプリケーション非依存ソフトウェア・ユーティリティです。Oracle Databaseは、障害発生時のAt-Most実行セマンティクスを実現する汎用インフラストラクチャを提供する最初のデータベース管理システムです。この種の実行は、操作が1回実行されるか、部分的に実行されるか、またはまったく実行されない必要があることを意味します。たとえば、カレンダーの予定の追加または削除では、一般に、At-Most-Onceセマンティクスが使用されます。

アプリケーション継続性により、最小限の労力で、Oracle JDBCドライバまたはOracle OCIドライバによるトランザクションのリプレイを実現します。セマンティクスにより、エンドユーザーのトランザクションが、予定どおりに実行され、最大でも1回しか実行されないことが保証されます。エンドユーザーがサービスの中断に気付くのは、リカバリできない機能停止が発生した場合だけです。

データベースとのやり取りの中断は、ユーザーに影響を与えません。アプリケーション継続性により、システム内の他の場所で重複のリスクなくリクエストを安全に再試行できるようになり、アプリケーションの可用性が強化され、開発者の生産性が向上し、ユーザー・エクスペリエンスが改善されます。

Oracle Database 11gでは、読取り操作でのみアプリケーション継続性がサポートされます。Oracle Database 12cとTransaction Guardにより、ローカル・トランザクションのフェイルオーバーが可能になり、書込み操作もサポートされます。

5


アプリケーション継続性では、リカバリ可能なエラー、つまりフォアグラウンド、ネットワーク、ノード、ストレージ・デバイス、データベースの計画停止および計画外停止によって発生するエラーだけがリプレイされます。場合によっては、送信した最後の操作のステータスを明示しないエラー・コードをアプリケーションが受信することもありますが、アプリケーション継続性によってデータベース・セッションが再確立され、リカバリ可能なエラーのために保留になっている作業が再送信されます。無効なデータ値が送信された場合などのリカバリ不可能なエラーによるコール障害が発生した場合は、作業が再送信されません。

Transaction Guardは、各データベース・トランザクションに関して一意の論理トランザクション識別子（LTXID）を提供します。この識別子によって、トランザクションのコミット結果の問合せが行われ、トラン

ザクションが1回しか適用されないことが保証されます。Transaction Guardは、アプリケーション継続性によって使用されると自動的に有効化されますが、単独でも有効にできます。Transaction Guardは、アプリケーション継続性によってリプレイされるトランザクションが複数回適用されることを防止します。

Oracle WebLogic Serverでこの機能を使用するには、oracle.jdbc.replay.OracleDataSourceによってGridLinkデータソースをコネクション・ファクトリとして構成します（この接続は、迅速なエラー検出とスマートなリバランスのためにFAN/高速接続フェイルオーバーおよびランタイム・ロードバランシングをサポートします）。障害発生後にドライバによる異なるインスタンスへの再接続を可能にするには、単一データソース・プールを持つ必要があります。この単一データソース・プールは、XAトランザクションをサポートしません。また、この単一データソース・プールをPL/SQLプロキシ認証とともに使用することはできません。

6


図3：Oracle WebLogic Serverにおけるアプリケーション継続性の構成

Oracle WebLogic Serverにおけるアプリケーション継続性の適用

Oracle WebLogic Serverは、最初に接続を作成する際に、その接続に関するすべてのプロパティを設定し、リプレイを有効にします。プールへの後続の接続には“begin”文が含まれるため、JDBC操作が最後のコミットを通じて記憶されます。接続がプールに返されると、“end”文が発行されます。その他の重要な考慮事項は、以下のとおりです。

• 接続に関するリプレイの無効化：構成済みのOracle WebLogic ServerのActive GridLinkデータソースから接続を取得して、この接続をoracle.jdbc.replay.ReplayableConnectionに変換し、この接続に関してsetReplayableEnabled(false)をコールします。

• 再接続コールバックの使用：障害が中断された後に、新しい接続リクエストによってこの登録済みコールバックへのコールがトリガーされ、getNewPhysicalConnection()メソッドのWebLogic実装によって以前のデータソース・プロパティが新しい接続で再使用されます。プールによるper-RACインスタンスの統計と、場合によってはアフィニティ・コンテキストの更新もトリガーされます。

• リプレイの更新：タイムアウトを構成するには、replay-initiation-timeout MBeanパラメータを使用します。タイムアウトは、beginRequestの開始からリプレイの終了まで開始されます。replay-initiation-timeoutの値が0の場合は、タイムアウトが設定されません。デフォルト値は3,600秒です。HTTPタイム値と一致するように設定することをお勧めします。

7


オラクルのドライバとデータベースによるJDBCリプレイ

JDBC Replay Driverにより、各JDBCオブジェクトの内部状態に影響を与えるJDBC操作が、それらの操作に対する引数とともに格納されます。各Replay Driverオブジェクトは、後続のJDBC操作を実行できる他のプロキシ・オブジェクトも格納します。たとえば、Connectionオブジェクトは、それによって作成されたすべてのStatement、PreparedStatement、CallableStatementオブジェクトと、それらによって作成されたすべてのResultSetオブジェクトを格納します。

メモリ消費を節約するために、JDBC Replay Driverは、記録されている操作を必要に応じて消去します。アプリケーションは、標準のJDBCコールによって、ResultSetとStatementを使用後に適切に閉じます。

JDBC Replay Driverは、StatementまたはResultSetに関連する格納済み操作履歴とすべてのリプレイ固有オブジェクト（チェックサム、カーソル・リプレイ・コンテキストなど）を消去します。StatementまたはResultSet を閉じるときに隣接するアクティブなトランザクションがない場合は、この消去にPreparedStatementとCallableStatementが含まれます。接続が閉じる場合は、これらのオブジェクトも消去されます。

図4：アプリケーション継続性の仕組み

図4に示されているように、クライアント・アプリケーションのリクエストは、Oracle WebLogic Serverに渡され、その後にJDBC Replay DriverによってOracle Databaseに渡されます。

• JDBC Replay Driverにより、リクエストの各コールが発行されます。

• FAN計画外中断/計画中断またはリカバリ可能エラーが発生します。FAN/FCFにより、無効になった物理セッションが中断されます。

• アプリケーション継続性により、リプレイが開始され、以下の操作が実行されます。

無効になった物理セッションが新しい正常なセッションと置き換えられ、リプレイの実行時や実行後に後続のエラーが発生する場合はFANが接続しなおされます。

実行中のトランザクション（開いていた場合）の結果を判定するために、Transaction Guardを使用してリプレイが準備されます。

8


オプションとして、初期状態のラベリング・コールバックまたは再接続コールバックを使用してコールバックされます。

データベース・セッションが再構築されて、トランザクション状態および非トランザクション状態がリカバリされ、各段階で、クライアント・ドライバによって認識されるデータおよびメッセージが、クライアントが認識していたと推測されるものおよび判断の基準となる可能性のあるものと同じであることが検証されます。

リプレイが終了し、ランタイム・モードに戻ります。

最後にキューに追加されたコールが送信されます。

• これは、機能停止が検出されたときに最後に実行されたコールです。リプレイ中は、このコールだけがコミットを実行できます。セッションの再構築の最中にコミットが実行されると、リプレイが中断されます（自律型トランザクションを除く）。

• レスポンスがアプリケーションに返されます。

リプレイが正常に終了した場合は、アプリケーションが動作を継続でき、問題による影響を受けません。リプレイが正常に終了しなかった場合は、アプリケーションが元のエラーを処理します。

データベース常駐接続プール

中間層データソースは、ユーザーの高い要求に応えるために多数のアイドル状態の接続を作成します。これらの接続の作成および破棄により、大きなコストが発生します。データベース常駐接続プーリング（DRCP）により、複数のWeb層および中間層データソースはOracle Databaseサーバー・プロセスおよびセッション

（まとめて「プール・サーバー」と呼ばれる）を共有できるようになります。これにより、データベース・リソースの共有が改善され、アプリケーションのスケーラビリティが向上します。この効果は、データベース接続が常に使用中ではない場合に最大になります。

9


図5：データベース常駐接続プール

プール接続を使用している場合、それらは専用接続に相当します。Oracle WebLogic Serverデータソースから接続が要求されると、適切なプール接続が渡されます。Oracle WebLogic Serverは、すべてのデータベース・アクティビティに関して、プール接続を使用して直接通信します。プール接続は、データソースがそれをリリースすると返されます。

WebLogicとデータベース常駐接続プール（DRCP）の統合は、Active GridLink for RACの使用時に機能し、Oracle Database 12cおよびJDBCドライバ12cによって汎用データソースの使用時にも機能します。データソース接続プールからの接続は、“unattached”状態のプレースホルダです。接続がアプリケーションに渡される場合、attachConnection()をコールすることによって接続されます。接続がプールに返される場合、detachConnection()をコールすることによって切断されます。

プール接続がXAトランザクションで使用される場合、エンリスト時に接続がトランザクションで使用されていることを示すフラグが有効になります。このフラグは、トランザクション・コミットまたはロールバックが起動されると無効になります。このメカニズムは、XAトランザクションの最初から最後まで同じ接続が使用されることを保証します。

DRCPは、異なるユーザー間でプール接続を共有しないことを保証します。ただし、DRCPでは、同じアプリケーションの異なるインスタンス間で接続を共有およびプールできます。同じユーザーの場合でも、DRCPは、アプリケーションが選択した"接続クラス"に基づいて、プール・サーバーの論理的なグループを保存します。接続クラスは、プール接続を要求する際にクライアントが提供する論理名です。この論理名は、クライアントが、同じ論理名で他のクライアントによって使用されていたプール接続を再利用することを示します。

たとえば、すべてが同じデータベースをポイントする10のOracle WebLogic Serverデータソースがあり、各データソースの初期容量が10の接続の場合、起動時に100の接続/セッションが作成されます。それらの接続のすべてが常にアクティブである場合以外は、接続が無駄になります。DRCPによって、それらのデータソースのすべてが、構成可能な数の接続による単一の接続プールを共有できます。任意のタイプの仮想化を使用する場合と同様に、DRCPは、スペア容量があり、いずれかのデータソースによってすべてのリソースを一度に使用することが試みられない場合にのみ機能します。

10


DRCPを使用すると、データベースの永続的接続が最小限のコストで維持されるため、Oracle DatabaseとOracle WebLogic Serverのスケーラビリティが向上します。データベース・リソースは、アクティブな接続によってのみ使用されます。管理者は、プールのサイズを制御および設定することによって、使用率を調節できます。

プラガブル・データベース

Oracle Databaseの実装は、一般に次のカテゴリに分類されます。

• それぞれが個別のアプリケーションをサポートする小規模から中規模のデータベース

• アプリケーションの各モジュールが個別のデータベースを使用するビジネス・データベース

• 同じデータベースの複数のコピー（テナントごとに1つ）によるマルチテナント・データベース

• 個別のテナントをサポートするスキーマの異なるコレクションによるマルチテナント・データベース

プラガブル・データベースの実装により、単一の大規模データベース・インストール内で複数の個別データベースを使用できます。Oracle Database 12cのコンテナ・データベース（CDB）機能により、これらの複数データベース構成が単一コンテナ・データベース内の複数のプラガブル・データベース（PDB）によって単一のデータベースに統合されるため、複数データベース構成のオーバーヘッドが最小限に抑えられます。このタイプの“データベース内仮想化”には次のようなメリットがあります。

• Oracle Databaseを、単一コンテナ・データベースのコンテキスト内で新しいバージョンに透過的にアップグレードできる

• コンテナ・データベース内で複数のバージョンのOracle Database（テナントDB）を実行できる

• ハードウェア・リソースを効率的に使用できる

• セキュリティ管理が統合される

• 中間層およびデータ層の密度とスケーラビリティが向上するため、リソースの使用率が改善される

• 単一のデータベースで複数のテナントがサポートされる。

クライアントは、特定のコンテナ（PDB）に接続する場合に、ALTER SESSION SET CONTAINERを発行します。この新しいドライバは、コンテナが有効か既存のものであることと、現在のユーザーがそのコンテナに接続するための適切な権限を持っていることを確認します。これらのチェックに適合すると、そのセッションにおけるユーザー・データが新しいPDB名とIDによって更新されます。

PDBへの通常の接続は、サービスを通じて行われます。すべてのPDBは、今日のシングルトン・データベースのために存在するデータベース・サービスと同様に、そのPDBの作成時にデフォルトのサービスを持ちます。その他のサービスをPDBに関して明示的に作成できます。アプリケーションがサービスを使用して接続する際、データベース・セッションで正しいPDBコンテキストをセットアップするためにPDB属性が使用されます。

11


Oracle WebLogic Serverでは、単一のデータソースを構成して、複数のプラガブル・データベースへの接続をプールできます。ただし、PDBへの最初の接続またはPDB間での切り替えは、アプリケーションに対して透過的には実行されません。PDB間の切り替えを有効にするために、ALTER SESSION SET CONTAINERによる接続を変更して、他のプロパティを設定し、接続をラベル付けするコールバックを登録することをお勧めします。同じPDBへの接続に関する後続のすべてのリクエストについては変更不要です。このモデルにより、スケーラビリティと適応性を含むプール接続の真のメリットが得られます。

図6：Oracle WebLogic Serverとプラガブル・データベース

PDBごとに単一のデータソースを持つ別の有効なOracle WebLogic Server構成もあります。新しいPDBをCDBに追加する場合、WebLogic Serverで新しいデータソースを構成する必要があります。このモデルのメリットは、データ・レベルで得られます。

12


図7：プラガブル・データベースごとに1つのデータソースを示すOracle WebLogic Server構成

自動ONS

初期バージョンのActive GridLinkとOracle Database 11gを使用する場合は、FANを有効にする際にONSリスナー・リストを構成する必要があります。Oracle Database 12cを使用する場合、ONSリストはオプションになります。情報はデータベースからドライバに自動的に提供されます。自動ONS機能は、Oracle Database 12c RACまたは新しいグローバル・データベース・サービス（GDS）機能で使用した場合のみ、動作します。自動ONSは、単一インスタンスのOracle Databaseでは機能しません。

現時点では、FANを有効にする場合、Oracle WebLogic Admin Consoleは、GridLinkデータソース構成のONSリストを必要とします。Oracle WebLogic Server 12.1.2では、Oracle Database 12cとJDBC 12cドライバを使用している場合、ONSリストがオプションになります。

Oracle WebLogic Admin Consoleでの検証は、作成時にデータソースがターゲットになっている場合または更新時にターゲットが変更される場合にのみ実行されます。このアプローチは、URLなどの他の値に似ています。管理者がONSリストの入力を忘れると、ターゲティングが失敗します。ONSリストを更新する必要があり、ターゲティングをもう一度実行しなければなりません。

ONSリストは、デプロイ時に検証されます。リストが空の場合、システムは、Oracle Database 12cドライバが使用されていることを確認します。

13


グローバル・データ・サービス

グローバル・データ・サービス（GDS）により、データベース・サービスの世界規模での提供が効率化されます。これは、大規模クラウド・アーキテクチャへのデータベースのデプロイにとって鍵となる機能です。これらのテクノロジーは、レプリケーションおよびフェイルオーバーを監視すると同時に、データセンター内およびデータセンター間でのロードバランシングを実行し、リソースの使用率を最適化し、分散データベース環境におけるデータベース管理作業を効率化します。 GDS は、 Oracle Data Guard 、 Oracle GoldenGate、またはその他のレプリケーション・テクノロジーによって相互接続されるRACおよびシングル・インスタンスのOracle Database間のグローバル・サービスを有効にすることによって機能します。この分散インフラストラクチャへのクライアント・アクセスは、完全に透過的です。GDS実装は、最小限の変更によってOracle WebLogic Serverに簡単に適用できます。

Oracle Database 12cのグローバル・データ・サービスには次のようなメリットがあります。

• 分散データベース・クラウド全体にわたるデータベース・サービスの一元管理

• 負荷と可用性に基づくサービスの動的移行

• RACクラスタの追加によるスケーラビリティ

• 利用可能なデータベースで障害が発生したサービスの自動再起動

• Active GridLinkデータソースによるOracle WebLogic Serverとの容易な統合

GridLinkデータソースを構成する場合は、単に、グローバル・サービスへのアクセス元となるプライマリ・ローカル領域と、各領域のアドレスを指定します。この構成により、クラウドにおいて、RACと同様のOracle Databaseのフェイルオーバーが実現されます。領域からのグローバル・データベース・サービスへの接続が失われる場合、再接続は、FANイベントに基づいて実行されます。障害の発生時に中間層コンポーネントを再起動する必要がないため、ビジネス継続性が確保されます。

GDSは、グローバル・サービス全体にわたるデータベース負荷を本質的に分散できるように設計されています。読取り専用サービスで大きな負荷が発生した場合、グローバル・サービスを別の領域で利用できるときは、GDSフレームワークによってActive GridLinkに通知され、その別の領域のサービスへの新しい接続が実行されます（このフレームワークは、読取り/書込みサービスの領域間でのロードバランシングは実行できません。このタイプの処理は、プライマリ領域でのみ実行できます）。

Oracle WebLogic Server管理者は、Admin Consoleを使用して、GDSデータソースを次のように構成できます。

• 次の項目を示すことによって接続を指定します。

サービス名（グローバル・サービス名）

アドレス/ポート・ペア（各種グローバル・サービス・マネージャ用）

GDS領域（新規）

• GDSデータソースの構成後はリスナーをテストできません。

• 構成する必要のある複数のGSM addresses.service名の代わりに単一のSCANアドレスを使用することはできません。以下にサンプルURLを示します。

14


jdbc:oracle:thin:@(DESCRIPTION=

(ADDRESS_LIST=(LOAD_BALANCE=ON)(FAILOVER=ON)

(ADDRESS=(HOST=slc02wqh.us.oracle.com)(PORT=2711)(PROTOCOL=tcp))

(ADDRESS=(HOST=slc02wqh.us.oracle.com)(PORT=2709)(PROTOCOL=tcp)))

(CONNECT_DATA=(SERVICE_NAME=uniformdg1.pool1.oradbcloud)(REGION=EAST)))

図8：Oracle WebLogic Serverとグローバル・データ・サービス

更新操作が正常に処理されるために、更新用のサービスはプライマリ・データベースでのみ定義する必要があります。読取り専用操作は、プライマリおよびセカンダリ・データベースで定義されている別のサービスに送ることができます。単一のサービスはURLおよびデータソース構成上の単一のURLでのみ定義できるため、1つのデータソースを更新サービス用に定義し、別のデータソースを読取りサービス用に定義する必要があります。アプリケーションは、更新操作が更新データソースに送られ、読取り操作が読取り専用データソースに送られるように作成する必要があります。

まとめ

Oracle WebLogic Serverは、Oracle Database 12cと緊密に統合され、最高レベルの可用性、フェイルオーバー、マルチテナント、リソース共有、スケーラビリティ、構成/管理の容易さのすべてを、クラウド形態のインフラストラクチャのコンテキスト内で提供します。これにより、企業向けの卓越した可用性、スケーラビリティ、パフォーマンスを実現する完全なベスト・オブ・ブリードのデータ処理プラットフォームが提供されます。

15


参考資料

Oracle WebLogic Server Active GridLink for Oracle Real Application Clusters (RAC)

http://www.oracle.com/technetwork/jp/middleware/weblogic/gridlink-rac-wp-1394921-ja.pdf

Oracle WebLogic Serverと高可用性Oracle Database：オラクルの統合Maximum Availabilityソリューション

http://www.oracle.com/technetwork/jp/database/features/availability/wlsdatasourcefordataguard-1645083-ja.pdf

Database Resident Connection Pooling (DRCP)

http://www.oracle.com/technetwork/articles/oracledrcp11g-1-133381.pdf

16

http://www.oracle.com/technetwork/jp/middleware/weblogic/gridlink-rac-wp-1394921-ja.pdf

http://www.oracle.com/technetwork/jp/database/features/availability/wlsdatasourcefordataguard-1645083-ja.pdf

http://www.oracle.com/technetwork/articles/oracledrcp11g-1-133381.pdf


2013年6月

著者：Monica Riccelli、Frances Zhao-Perez 共著者：David Baum Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200

oracle.com

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

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りが

ないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保

証および条件などのいかなる保証および条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本

文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、い

かなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,

Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。

UNIXは、The Open Groupの登録商標です。

0613

Documents

Oracle WebLogic ServerとOracle Database 12cの統合