Oracle WebLogic Serverと高可用性Oracle Database：オラクルの統合

Oracleホワイト・ペーパー
2012年2月
Oracle WebLogic Serverと高可用性
Oracle Database：オラクルの統合
Maximum Availabilityソリューション
概要 ..................................................................................................................................... 3
概要 ..................................................................................................................................... 5
Oracle WebLogic ServerとJDBCデータ・ソース ......................................................... 5
Oracle WebLogic Serverでのトランザクション・ログ（TLOG）のデータベース永続性
....................................................................................................................................... 6
計画外停止向けのOracle Database高可用性ソリューション ....................................... 7
Data Guard向けのWebLogic Serverデータ・ソースの構成............................................... 9
クライアント・フェイルオーバー................................................................................. 9
前提条件 ....................................................................................................................... 11
セットアップ手順 ......................................................................................................... 11
JDBCデータベース・サービスの構成 ......................................................................... 12
Oracle WebLogic Serverデータ・ソースの構成 ......................................................... 13
以前のOracleリリースにおける考慮事項 ......................................................................... 21
結論 ................................................................................................................................... 22
参考資料............................................................................................................................ 22
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
概要
コスト効率の良いソリューションで顧客アプリケーションを実現するさまざまなシステムでは、し
ばしば、高い可用性とスケーラビリティが重要になります。また、Java EE中間層とバックエンド・
データベースを伴う複雑な異種環境には、さまざまな既知の問題が存在します。たとえば、データ
ベース・ノードが停止すると、すべてのアプリケーション・リクエストが長時間ブロックされるこ
とがあります。アプリケーションがSQLExceptionを受信した後に、新しい接続を取得するべきかど
うかを判断するのは容易ではありません。中間層アプリケーションは、新しいデータベース・ノー
ドであるのか再起動されたデータベース・ノードであるのかを認識しておらず、また、処理を実行
しているデータベース・ノードが低速であるのか、ハングしているのか、または無効になっている
のかも確認できないため、多くの場合、TCP/IPタイムアウトに頼らざるをえません。その他に、エ
ンタープライズ・デプロイメントを予期せぬ障害や天災から保護する必要もあります。
Oracle WebLogic Server 11gおよび12cは、Oracle Databaseの高可用性（HA）機能の統合を強力にサポー
トします。これにより、データベースへのアクセス時間を最小限に抑えるとともに、充実したプー
リング管理機能への透過的なアクセスを通じて、接続パフォーマンスとアプリケーション可用性を
最大限に高めます。Oracle Databaseは、Oracle Real Application Clusters（Oracle RAC）、Oracle Data Guard、
Oracle RestartなどのHA機能に加えて、Oracle GoldenGateなどの補完製品を提供しています。Oracle
Maximum Availability Architecture（Oracle MAA）1の必須コンポーネントであるOracle WebLogic Server
とOracle Databaseに組み込まれた高可用性機能が一体となって堅牢なソリューションを提供するこ
とで、計画外停止を防止および検出し、短い平均リカバリ時間での回復を可能にします。
Oracle WebLogic ServerとOracle Data GuardはMAAソリューション・セット内で連携することで、本番
サイトとは地理的に異なる場所でのスタンバイ・サイトのセットアップを含む、包括的なデータ保
護ソリューションを実現します。スタンバイ・サイトに含まれるサービスおよびリソースは本番サ
イトと同等か、少なくなる場合があります。アプリケーション・データ、メタデータ、構成データ、
セキュリティ・データを含む、あらゆるデータがスタンバイ・サイトに複製されます。通常、スタ
ンバイ・サイトはパッシブ・モードで構成され、本番サイトが使用できなくなった場合に開始され
ます。
Oracle Database 11g Enterprise Editionで利用できるActive Data Guardオプションを使用すると、REDO
Applyが本番データベースからスタンバイ・データベースに変更を継続的に適用している間、フィジ
カル・スタンバイ・データベースをオープンして、レポート作成のための読取りアクセス、単純ま
たは複雑な問合せ、ソートやWebベースのアクセスを実行できます。フィジカル・スタンバイ・デー
タベースから読み取られる問合せはすべてリアルタイムで実行され、最新の結果を返します。Active
Data Guardを使用すると、最新の読取り専用アクセスに必要な操作をすべてスタンバイ・データベー
スにオフロードできるため、リカバリ・ポイント目標やリカバリ時間目標において妥協することな
く、本番データベースのパフォーマンスを向上させ、保護できます。
このホワイト・ペーパーでは、高可用性データベースに対するOracle WebLogic Server配置の構成ベス
ト・プラクティスについて詳しく確認していきます。
1
http://www.oracle.com/technetwork/jp/database/features/availability/index.html
3
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
Oracle WebLogic Serverはスケーラブルなエンタープライズ対応のJava Platform, Enterprise Editionアプ
リケーション・サーバーであり、データベース・インタラクションは通常、中間層のデータ・ソー
ス実装によって処理されます。Oracle WebLogic Serverでは、WebLogic汎用データ・ソース、GridLink
データ・ソース、およびマルチ・データソースを構成することでデータベース接続を提供します。
そして、これらのJDBCリソースはWebLogic Serverドメイン内のサーバーまたはクラスタに対して配
置されます。構成される各データ・ソースには、データソース・インスタンスの作成、配置、また
は割当て時に作成されたデータベース接続プール、あるいはサーバーの起動時に作成されたデータ
ベース接続プールが含まれます。
Oracle WebLogic Server 11g、および12cのOracle RAC統合ソリューションは、Oracle MAA開発チーム
によって共同で設計、実装、テストが実施されています。Oracle WebLogic Serverは、Java EE実装に
含まれるセキュリティ、トランザクション、接続プーリングなどの豊富な管理機能を損なうことな
く、Oracle Database RAC 11gに完全統合され、サーティファイされた唯一のアプリケーション・サー
バーです。
Oracle WebLogic Serverには、Oracle Real Application ClustersおよびOracle Data Guardをサポートするた
めに次の2つのデータ・ソースが実装されています。

マルチ・データソース・ソリューションは、WebLogic Server 8.1 SP5以降の顧客の本番配置
で順調に使用されています。

Oracle WebLogic 11g Release 1、および12cで新しく実装されたOracle WebLogic Active
GridLinkは、市場をリードする中間層の統合ソリューションであり、Oracle RACのさらなる
技術進歩を利用しています。
Oracle WebLogic Server Active GridLink for Oracle RACはOracle Real Application ClustersとOracle Data
Guardをサポートするための戦略的ソリューションであり、オラクルのMAAベスト・プラクティスで
推奨されています。このソリューションは実現しうる最善のミドルウェアおよびデータベースの統
合であり、他のベンダーでは使用できない機能を備えています。
Oracle WebLogic Serverのデータ・ソースおよび接続プーリング・ソリューションとOracle RACの組み
合わせによって、高いパフォーマンスとスケーラビリティおよび高可用性機能を備えたハイエンド
なミッション・クリティカル環境が提供されます。ロードバランシングおよびアフィニティ機能に
より、オンライン・トランザクションの処理シナリオのパフォーマンスが大幅に向上し、スループッ
トおよび全体の応答時間も向上します。フェイルオーバー・ソリューションによってエンド・ツー・
エンドの迅速な障害検出が可能になるため、Oracle RACノードの計画停止および計画外停止に対し
て正常な停止がサポートされます。
WebLogic Active GridLinkはOracle Universal Connection Poolを使用して実装された統合ソリューショ
ンを通じて、Data Guardを完全にサポートしています。
このホワイト・ペーパーでは、Oracle WebLogic Server 11g（10.3.6）とOracle Database 11g Release 2（11.2）
をベースにして、障害の発生したプライマリ・データベースから新しいプライマリ・データベース
へと自動的にアプリケーション接続を移行するためのベスト・プラクティスについて説明します。
Web Logic Active GridLinkとマルチ・データソースの両方に対して、Data Guardと連携するための詳し
い構成が含まれています。
4
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
概要
Oracle WebLogic ServerとJDBCデータ・ソース
WebLogic Serverでは、WebLogicドメインにデータ・ソースを追加することでデータベース接続を構
成します。WebLogicのJDBCデータ・ソースによってデータベース・アクセスとデータベース接続管
理が提供されます。各データ・ソースには、データ・ソースの作成時に作成されたデータベース接
続プールと、サーバーの起動時に作成されたデータベース接続プールが含まれます。アプリケーショ
ンはJNDIツリーまたはローカル・アプリケーション・コンテキストでデータベース・ソースを検索
し、getConnection()を呼び出すことでデータ・ソースからデータベース接続を予約します。接続が完
了すると、アプリケーションはできるだけ早くconnection.close()をコールする必要があります。これ
により、データベース接続がプールに戻され、その他のアプリケーションから使用できるようにな
ります。
WebLogic Server JDBCデータ・ソースの種類
WebLogic Serverでは、次の3種類のデータ・ソースが提供されています。

汎用データ・ソース - 汎用データ・ソースとその接続プールは接続管理プロセスを提供するこ
とで、システムが効率的な実行を維持できるようにします。アプリケーションや環境に合わせ
て、データ・ソースに構成オプションを設定できます。

GridLinkデータ・ソース - Oracle RACまたはData GuardからのOracleイベント通知に基づき、ス
テータス変更に適応して応答する単一データ・ソースです。

マルチ・データソース - マルチ・データソースは汎用データ・ソースのグループを抽象化した
ものであり、ロードバランシングまたはフェイルオーバー処理を提供します。
WebLogic ServerのJDBCデータ・ソースについて、詳しくは『Oracle Fusion Middleware Oracle WebLogic
Server JDBCデータ・ソースの構成と管理 11g Release 1 (10.3.5)』 2を参照してください。
Oracle WebLogic ServerとOracle RAC
Oracle WebLogic Server 10.3.4には、Oracle RACクラスタをサポートするための単一データ・ソース実
装が導入されています。このデータ・ソースはFANイベントに応答して、高速接続フェイルオーバー
（FCF）、ランタイム接続ロードバランシング（RCLB）、およびOracle RACインスタンスの正常終了
を提供します。XAアフィニティは、グローバル・トランザクションIDレベルでサポートされていま
す。WebLogic Active GridLink for RACと呼ばれる新機能は、WebLogic Server内でGridLinkデータ・ソー
スとして実装されています。
WebLogic ServerのGridLinkデータ・ソース実装はUniversal Connection Pool（UCP）のOracle RAC統合
機能を利用して、FCF、RCLB、およびアフィニティ機能を提供します。
2
http://docs.oracle.com/cd/E24001_01/web.1111/b60997/jdbc_datasources.htm#i1204742
5
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
Oracle RACとの緊密な統合を提供するための重要な基盤を利用することで、Oracle WebLogic Server
内のこの単一データ・ソース実装は、データベース・サービスをデータ・ソースの接続ターゲット
として無制限かつ全面的に使用できるようにします。プール内の接続に対するアクティブ管理は、
接続プール自体に構成された静的な設定（最小容量/最大容量、タイムアウトなど）と、Oracle RAC
クラスタ内の状態変化を"クライアント"に伝えるOracle Notification Serviceサブシステムから接続
プールが受け取るリアルタイム情報に基づいて実行されます。
Oracle WebLogic Serverでのトランザクション・ログ（TLOG）のデータベース永続性
WebLogic Server 10.3.6および12cでは、WebLogicトランザクション・ログのデータベース永続性機能
がサポートされています。この新機能によって柔軟性が高くなるため、ユーザーはデフォルトの永
続ファイル・ストアではなく別の永続ファイル・ストアにプライマリTLOGを保存できます。また、
WebLogicサーバーがJava Transaction API（JTA）のプライマリTLOGを保存する場所も柔軟に構成で
きます。この構成はサーバーごとに設定されます。ユーザーがデータベース・ストア・オプション
を選択すると、Logging Last Resource（LLR）参加者なしのトランザクション・コミット決定、リソー
ス・チェック・ポイント、サーバー・チェック・ポイントなどの、すべてのJTAプライマリTLOG情
報がデータベース内に保存されます。
これによって、次のように多数の利点がもたらされます。
3
1.
基盤のデータベース・システムに固有のレプリケーション機能やその他のHA機能を活用で
きます。
2.
障害時リカバリ・シナリオの処理が改善されます。JMS、TLOG、およびアプリケーション
が同じデータベース内にあり、レプリケーションがData Guardによって処理される場合、サ
イト間の同期について気にする必要はありません。以前のリリースでは、いずれかがNAS
などのストレージ・システム上にある場合、特別な配慮またはソリューションが必要でし
た。
3.
NASやSANなどの共有ストレージ・サブシステムの必要性が軽減されています。ほとんど
の場合、データベースはあらかじめ通常のランタイム処理やアプリケーション処理に対応
しているため、データベースを使用することでもシステム全体の複雑さが軽減されます。 3
この機能はOC4J 10.1.3.0に含まれる機能と類似しています。
6
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
図2：WebLogicのデータベースTLOGとData Guardを使用した障害時リカバリ・アーキテクチャ
計画外停止向けのOracle Database高可用性ソリューション
Oracle Restart
Oracle RestartはOracle Database 11g Release 2（11.2）の新機能であり、単一インスタンスの（クラスタ
化されていない）Oracle Databaseとそのコンポーネントの可用性を向上させます。Oracle Restartは単
一インスタンス環境でしか使用できません。
Oracle Restartをインストールすると、ハードウェアまたはソフトウェアにおける障害の発生後や、
データベースのホスト・コンピュータの再起動時に、データベース、リスナー、およびその他のOracle
コンポーネントが自動的に再起動されます。また、コンポーネントの依存関係に従って、正しい順
序でOracleコンポーネントが起動されます。
Oracle Restartは、SQL*Plus、Listener Controlユーティリティ（LSNRCTL）、ASMCMD、Oracle Data Guard
などの、Oracle Restartに統合されたコンポーネントの状態を定期的に監視します。コンポーネントに
対するヘルス・チェックが失敗すると、Oracle Restartはそのコンポーネントを停止してから再起動し
ます。Data Guard Brokerを使用したData Guard構成では、ロール移行後に適切なデータベース・サー
ビスがアクティブになり、適切なFast Application Notification（FAN）イベントが公開されるようにす
るため、非Oracle RACデータベースでOracle Restartを使用する必要があります。
7
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから
実行されます。
参考資料：
Oracle Restart機能のインストールと構成については、『Oracle Database管理者ガイド』4を参照してく
ださい。
Oracle Real Application Clusters
Oracle RACおよびOracle Clusterwareを使用すると、あらゆるパッケージ・アプリケーションやカスタ
ム・アプリケーションを、クラスタ化されたサーバー全体にわたってOracle Database上で実行できる
ようになります。この機能により、最高レベルの可用性ともっとも柔軟なスケーラビリティが得ら
れます。クラスタ化されたサーバーに障害が発生すると、Oracle Databaseは残りのサーバーで実行を
継続します。より高い処理能力が必要になった場合、データへのアクセスを中断することなく別の
ノードを追加できます。
Oracle RACを使用すると、インターコネクトによって関連付けられた複数のインスタンスでOracle
Databaseへのアクセスを共有できます。Oracle RAC環境では、Oracle Databaseはクラスタ内の複数シ
ステム上で実行されますが、1つの共有データベースへ同時にアクセスします。その結果、単一デー
タベース・システムが複数のハードウェア・システムにまたがるため、クラスタ内に障害が発生し
た場合もOracle RACによって高可用性と冗長性が提供されます。
Oracle RAC One Node
Oracle Real Application Clusters One Node（Oracle RAC One Node）はOracle RACデータベースの単一イ
ンスタンスであり、クラスタ内の単一ノードで実行されます。Oracle RAC One Nodeはオンライン・
データベース再配置と呼ばれるOracleテクノロジーを利用することで、単一インスタンス・データ
ベースに対するコールド・フェイルオーバーよりも優れた可用性を実現しています。オンライン・
データベース再配置は、データベースのインスタンスと接続をインテリジェントな方法で別のクラ
スタ・ノードに移行することで、高可用性とロードバランシングを提供するテクノロジーであり、
Server Control Utility（SRVCTL）を使用して実行されます。
Oracle Data Guard
Oracle Data Guardは、Oracle Databaseのデータ保護、データ可用性、および障害時リカバリを実現す
るソリューションです。Data Guardは、Oracle Database Enterprise Editionに含まれる機能であり、1つ
以上の同期スタンバイ・データベースを作成および維持するための、管理、監視、および自動化ソ
フトウェアを提供することで、障害、災害、人為的エラー、およびデータ破損からOracleデータを保
護します。
Data Guardの疎結合アーキテクチャは、最適なデータ保護と可用性を提供します。

4
データベース変更はメモリから直接送信されるため、プライマリで発生しているI/O破損が
スタンバイから分離されます。
http://docs.oracle.com/cd/E16338_01/server.112/b56301/restart001.htm#BAGJGIDC
8
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database

スタンバイ・データベースはプライマリとは異なるソフトウェア・コードパスを使用する
ため、プライマリ・データベースに影響を与えるファームウェアやソフトウェアのエラー
がスタンバイから分離されます。

Oracleの破損検出機能によって、スタンバイ・データベースにデータが適用される前に、論
理的かつ物理的にデータの整合性が確認されます。

Data Guardは、ハードウェア・エラー（メモリ、CPU、ディスク、NIC）やデータ転送障害
によって引き起こされたサイレント障害を検出し、スタンバイ・データベースへの影響を
阻止します。

スタンバイ・データベースを使用して、ローリング方式で計画保守が実行されるため、停
止時間が最小化され、本番環境へ変更を適用する際に付きまとうリスクが排除されます。

Data Guardは、1つの構成で、1つのプライマリ・データベースと最大30のスタンバイ・デー
タベースをサポートする能力を備えています。また、ローカル・スタンバイ・データベー
スとリモート・スタンバイ・データベースの両方を含むData Guard構成が配置されることも
珍しくありません。前者はHAおよびデータ損失ゼロの保護を実現する目的で、また後者は
広い地域に影響を与える障害から保護するために配置されます。
Oracle Active Data Guard
Oracle Active Data Guard 11gはOracle Database Enterprise Editionのオプションであり、基本的なData
Guard機能を拡張したものです。この機能を利用すると、プライマリ・データベースから変更が適用
されている間、フィジカル・スタンバイ・データベースを読取り専用でオープンできます。これに
より、非定型の問合せやWebベースのアクセス、レポーティング、バックアップをプライマリ・デー
タベースからオフロードすることで、パフォーマンスと投資収益率が向上するとともに、障害時の
保護機能が提供されます。
Oracle GoldenGate
Oracle GoldenGate は 、 デ ー タ 分 散 と デ ー タ 統 合 に 対 す る オ ラ ク ル の 戦 略 的 製 品 で す 。 Oracle
GoldenGateはパフォーマンスの高いソフトウェア・アプリケーションであり、ログ・ベースの双方向
データ・レプリケーションを使用して、異種システムにまたがるデータベース・トランザクション
をリアルタイムで取得、変換、ルーティング、および配信します。
Data Guard向けのWebLogic Serverデータ・ソースの構成
クライアント・フェイルオーバー
Data Guard構成でのクライアント・フェイルオーバーを計画する場合、いくつかの考慮事項がありま
す。ローカルのOracle Data Guardスタンバイ・データベースを含む環境では、応答時間に顕著な影響
を与えることなく、WebLogic Serverの中間層からプライマリ・データベースまたはスタンバイ・デー
タベースへ接続できます。また、WebLogic Serverを再起動することなく、Data Guardのデータベース・
ロール移行（スタンバイ・データベースから新しいプライマリ・データベースへの移行）を実行で
きます。ローカルのスタンバイ・データベースは、同じデータセンター内や敷地全域、または隣町
など、ネットワークがアプリケーションの負荷要件と応答時間要件に対応できる限りどこにでも配
置できます。このため、プライマリ・データベースのみに影響を与える局所的な障害が発生してい
る間の可用性を維持するためや、最小限の停止時間で計画保守を実行するために、ローカル・スタ
ンバイ・データベースは理想的です。
9
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
対照的に、リモート・スタンバイ・データベースのみが含まれる構成では、プライマリ・サイトと
スタンバイ・サイト間のネットワーク待機時間によってパフォーマンスに影響が及ぶため、Oracle
WebLogic Serverの中間層をスタンバイ・データベースにも配置する必要があります。この例では、
Data Guardのロール移行時に、スタンバイ・サイトのOracle WebLogic Serverを再起動する必要があり
ます。
上記の2つの例から、Data Guardスタンバイ・データベースとWebLogic Server中間層に対する各種の
配置戦略によって、フェイルオーバーの発生後に、どれだけ迅速にユーザーが作業を再開できるか
が決まることが分かります。
10
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
ここからは、Oracle Database 11g Release 2（11.2）のクライアント・フェイルオーバー向けにWebLogic
Serverデータ・ソースを構成する方法について説明します。
前提条件
このホワイト・ペーパーで説明するベスト・プラクティスでは、Data Guard Brokerを使用してData
Guard構成を管理する必要があります。Data Guard Brokerは、Oracle Database Enterprise Editionに含ま
れるネイティブのData Guardコマンドライン・インタフェースです。Data Guard Brokerを使用すると、
Data Guard構成に含まれる任意のデータベースを使用して、より効率的にData Guard構成を一元管理
できます。また、Data Guard Brokerはデータベースへの接続をクリーンアップし、新しい本番データ
ベースに再接続するために、クライアント・アプリケーションにFANイベントを送信する役割を担っ
ています。こうすることで、TCP/IPタイムアウトによって可用性に影響が及ぶ懸念が解消されます。
さらに、単一インスタンス（Oracle Restartを使用）とOracle RACデータベースの両方に対して、プラ
イマリ・サイトとスタンバイ・サイトでOracle Clusterwareをインストールしてアクティブにする必要
があります。Data Guard BrokerはOracle Clusterwareと連携することで、Data Guardフェイルオーバー
の発生後、新しいプライマリ・データベースに対して適切にロール・ベース・サービスをフェイル
オーバーします。
セットアップ手順
この項では、データベース障害の発生中に停止時間を最小化するために、クライアント・フェイル
オーバーを構成し、WebLogic Serverデータ・ソースとスタンバイ・データベースをセットアップす
るための手順について段階的に説明します。次に、おおまかな手順を示します。
1.
データベース接続のためのデータベース・サービスを作成し、適切なサービス属性を構成
します。
2.
クライアント側のOracle Net構成がサービスを指し、すべてのプライマリおよびスタンバイ・リ
スナーが構成に含まれるようにします。これによって、どこでサービスが起動されたかに関係
なく、データ・ソースに接続できるようになります。
データベース・サービスとApplication Notification Framework
データベース・サービスは、このホワイト・ペーパーで説明するアプリケーション・フェイルオー
バー・ベスト・プラクティスの基盤となります。データベース・サービスについて十分に理解して
いない場合は、次へ進む前に『Oracle Database Net Services管理者ガイド』 5を参照してください。同
様に、単一インスタンス・データベース（Oracle Restartを使用）、Oracle RACデータベース、および
Oracle Data Guardに対してOracleが提供している高可用性のアプリケーション通知フレームワークに
ついて理解している必要があります。このフレームワークについて、詳しくは『Automatic Workload
Management with Oracle Real Application Clusters 11g Release 2』6および『Oracle Real Application Clusters
管理およびデプロイメント・ガイド』 7を参照してください。
5
6
7
http://docs.oracle.com/cd/E16338_01/network.112/b56288/concepts.htm#CIHGGHEE
http://www.oracle.com/technetwork/database/clustering/overview/awm11gr2-130711.pdf
http://docs.oracle.com/cd/E16338_01/rac.112/b56290/hafeats.htm#sthref505
11
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
ロール・ベースのデータベース・サービス
Data Guard 11g Release 2 以 降 で は 、 各 サ ー ビ ス に デ ー タ ベ ー ス ・ ロ ー ル [ -l {[PRIMARY] |
[PHYSICAL_STANDBY] | [LOGICAL_STANDBY] | [SNAPSHOT_STANDBY]}]を割り当てることで、
プライマリ・データベースとスタンバイ・データベースでのデータベース・サービスの起動を自動
的に制御できます。サービスの管理ポリシーがAUTOMATICに設定されており、サービスに割り当て
られたロールのいずれかが現在のデータベース・ロールと一致している場合、データベースの起動
時にデータベース・サービスが自動的に開始されます。
これらのサービスは、Server Control Utilityを使用して、Data Guard構成に含まれるすべてのデータベース
上でまったく同じように構成される必要があります。次の例では、データベースAustinがプライマリ・ロー
ル（-l PRIMARY）にある場合、oltpworkloadという名前のサービスがアクティブになるよう構成されてい
ます。同じサービスがスタンバイ・データベースHouston上にも構成されており、Houstonがプライマリ・
ロールとして機能する場合はいつでもこのサービスが開始されるようになっています。
同 様 に 、 デ ー タ ベ ー ス Austin ま た は Houston が ス タ ン バ イ ・ デ ー タ ベ ー ス ・ ロ ー ル （ -l
PHYSICAL_STANDBY）として機能する場合、reportsという名前の2番目のサービスが開始されるよ
う構成されています。reportsサービスはActive Data Guardを使用して、リアルタイムのレポーティン
グを提供します（プライマリ・データベースから受信したREDOをスタンバイ・データベースに適用
している間、スタンバイ・データベースは読取り専用でオープンされます）。
JDBCデータベース・サービスの構成
FANを有効にしたJDBCデータベース・サービスに対して、透過的アプリケーション・フェイルオー
バー（TAF）を有効化しないでください。次の例は、JDBCデータベース・サービスに対してデータ
ベース・サービスを作成する方法を示したものです。この例では、Oracle RACのプライマリ・デー
タベースおよびスタンバイ・データベースを使用しています。Oracle Restartを使用した単一インスタ
ンス・データベースに対しても、同じ手順を適用できます。
1.
プライマリ・ホストとスタンバイ・ホスト上で、読取り/書込みワークロード・サービス
（oltpworkload）を作成します。このサービスは、WLSデータ・ソースがデータベースへ接続す
るために使用されます。また、データベースが'PRIMARY'データベース・ロールである場合に、
このデータベース上でサービスが実行されるように関連付けて作成します。
プライマリ・クラスタ - JDBC読取り/書込みサービス：
srvctl add service –d Austin –s oltpworkload –r ssa1,ssa2 –l PRIMARY
–q FALSE –e NONE –m NONE –w 0 –z 0
スタンバイ・クラスタ - JDBC読取り/書込みサービス：
srvctl add service –d Houston –s oltpworkload –r ssb1,ssb2 –l
PRIMARY –q FALSE –e NONE –m NONE –w 0 –z 0
2.
Active Data Guardスタンバイ・データベースに対して、読取り専用のデータベース・サービスを
作成します。
プライマリ・クラスタ - JDBC読取り専用サービス：
srvctl add service –d Austin –s reports –r ssa1,ssa2 –l
PHYSICAL_STANDBY –q FALSE –e NONE –m NONE –w 0 –z 0
12
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
スタンバイ・クラスタ - JDBC読取り専用サービス：
srvctl add service –d Houston –s reports –r ssb1,ssb2 –l
PHYSICAL_STANDBY –q FALSE –e NONE –m NONE –w 0 –z 0
両方のクラスタ上でサービスを作成したら、サービス定義がスタンバイ・データベースに
も適用されるように、プライマリ・データベース上で次のSQL文を実行する必要があります。
EXECUTE DBMS_SERVICE.CREATE_SERVICE (
service_names => ‘reports’
network_name => ‘reports’
goal => ‘NULL’
dtp => ‘NULL’
aq_ha_notifications => ‘FALSE’
failover_method => ‘NONE’
failover_type => ‘NONE’
failover_retries => 0
failover_delay => 0
clb_goal => ‘NULL’);
3.
適切なサービス目標に合わせてサービスを変更します。ランタイム接続をロードバランシング
するには、Oracle RAC Load Balancing Advisoryを使用して、ロードバランシングを有効化する
サービスに対してサービス・レベル目標を設定する必要があります。Oracle RAC Load Balancing
Advisoryは、SERVICE_TIMEまたはTHROUGHPUTを使用して構成できます。接続ロードバラン
シング目標は、SHORTに設定してください。
SERVICE_TIMEを使用したOracle RAC Load Balancing Advisoryの構成：
srvctl modify service –d <database name>
SERVICE_TIME –j SHORT
–s <service name> –B
THROUGHPUTを使用したOracle RAC Load Balancing Advisoryの構成：
srvctl modify service –d <database name>
THROUGHPUT –j SHORT
–s <service name> –B
Oracle WebLogic Serverデータ・ソースの構成
この構成では、3種類のデータ・ソースを使用できます。汎用データ・ソースは、単一データベース・
アクセス向けの実装です。マルチ・データソースはOracle RAC統合向けのWebLogicのネイティブ中
間層実装であり、この統合ではOracle Notification Serviceは利用されません。GridLinkデータ・ソース
は新しいActive GridLink実装であり、Oracle RACでサポートされている高速接続フェイルオーバー、
ランタイム接続ロードバランシング、およびアフィニティを利用します。また、この構成ではSingle
Client Access Name（SCAN）の使用がサポートされています。
Data Guard向けのWebLogic Active GridLink
WebLogic Active GridLinkはOracle Universal Connection Poolを使用して実装された統合ソリューショ
ンを通じて、Data Guardを完全にサポートしています。WebLogic Active GridLinkの特徴は次のとおり
です。
13
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database

FANの使用が統合されています。

Data Guard固有のFANイベントを消費できます。

Oracle Database 11.2のSCANアドレスに対するベスト・プラクティスが統合されています。
図3：Data Guard向けのWebLogic Active GridLink
構成を実行するには、2つのSCANアドレス（プライマリ・データセンターを表すものとスタンバイ・
データセンターを表すもの）を接続URLに指定します。バックエンドでは、どのアドレスがプライ
マリ向けで、どのアドレスがスタンバイ向けかを認識しています。障害イベントは、Oracle Notification
Serviceを介して中間層に通知されます。
プライマリおよびスタンバイがOracle RAC 11g Release 2である場合の読取り/書込みの接続URL例
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE = off)
(FAILOVER = on)(DESCRIPTION = (CONNECT_TIMEOUT =
10)(TRANSPORT_CONNECT_TIMEOUT = 3)(RETRY_COUNT = 3)
(ADDRESS_LIST = (LOAD_BALANCE = on)(ADDRESS =
(PROTOCOL = TCP)(HOST = PRMY_SCAN)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME =
oltpworkload)))(DESCRIPTION = (CONNECT_TIMEOUT =
10) (TRANSPORT_CONNECT_TIMEOUT = 3)(RETRY_COUNT = 3)
(ADDRESS_LIST = (LOAD_BALANCE = on)(ADDRESS = (PROTOCOL =
TCP)(HOST = STBY_SCAN)(PORT = 1521)))(CONNECT_DATA =
(SERVICE_NAME = oltpworkload))))
上記の接続URLを使用して新しい接続が実行される場合、次のロジックが使用されます。
a)
Oracle NetはDNSを参照してPRMY_SCANを解決し、合計3つのIPアドレスを取得します。
b)
Oracle Netは3つのIPアドレスから1つを無作為に選択し、接続を試行します。このIPアドレ
スへの接続試行に対して3秒以内（TRANSPORT_CONNECT_TIMEOUT）に応答がない場合、
14
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
次のIPアドレスが試行されます。3つすべてのIPアドレスに対して4回（最初の試行と上記例
のRETRY_COUNTの合計数）の試行が行われます。
c)
プライマリ・サイトへの接続が成功しない場合、DNSを参照してSTBY_SCANを解決し、3
つのIPアドレスを取得します。
d)
PRMY_SCANに対して実行されたものと同じシーケンスが、STBY_SCANに対して実行され
ます。
上記が当てはまるのはOracle Database 11g Release 2クライアントのみである点に注意してください。
SCANについて、詳しくはテクニカル・ホワイト・ペーパー『Oracle Real Application Clusters 11g Release
2 Overview of SCAN』 8を参照してください。
プライマリおよびスタンバイがOracle RAC 11g Release 2でActive Data Guardを使用している場合の
読取り/書込みの接続URL例
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE = off)
(FAILOVER = on)(DESCRIPTION = (CONNECT_TIMEOUT =
10)(TRANSPORT_CONNECT_TIMEOUT = 3)(RETRY_COUNT = 3)
(ADDRESS_LIST = (LOAD_BALANCE = on) (ADDRESS = (PROTOCOL =
TCP)(HOST = STBY_SCAN)(PORT = 1521)))(CONNECT_DATA =
(SERVICE_NAME = reports)))(DESCRIPTION = (CONNECT_TIMEOUT =
10)(TRANSPORT_CONNECT_TIMEOUT = 3)(RETRY_COUNT = 3)
(ADDRESS_LIST = (LOAD_BALANCE = on)(ADDRESS = (PROTOCOL =
TCP)(HOST = PRMY_SCAN)(PORT = 1521)))(CONNECT_DATA =
(SERVICE_NAME = reports))))
8
http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdf
15
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
プライマリがOracle RAC 11g Release 2でスタンバイが単一インスタンス（11g Release 2のOracle
Restartを使用）である場合の接続URL例
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE = off)
(FAILOVER = on)(DESCRIPTION = (CONNECT_TIMEOUT =
10)(TRANSPORT_CONNECT_TIMEOUT = 3)(RETRY_COUNT = 3)
(ADDRESS_LIST = (LOAD_BALANCE = on) (ADDRESS =
(PROTOCOL=TCP)(HOST = PRMY_SCAN)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME =
oltpworkload)))(DESCRIPTION = (ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)(HOST = STBYHOST)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME = oltpworkload))))
プライマリおよびスタンバイが単一インスタンス（11g Release 2のOracle Restartを使用）である場
合の接続URL例
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE = off)
(FAILOVER = on)(DESCRIPTION =(ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = PRMYHOST)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME =
oltpworkload)))(DESCRIPTION = (ADDRESS_LIST = ADDRESS =
(PROTOCOL = TCP)(HOST = STBYHOST)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME = oltpworkload))))
JDBC GridLinkデータ・ソースを作成するには、次の手順を実行します。
1.
作成していない場合は、管理コンソールのChange Centerで「Lock & Edit」をクリックします。
2.
Domain Structureツリーで、「Services」→「Data Sources」の順に展開します。
3.
Summary of JDBC Data Sourcesページで「New」→「GridLink Data Source」の順にクリックし
ます。
4.
JDBC Data Source Propertiesページで、次の情報を入力（または選択）します。

Name - このJDBCデータ・ソースの名前を入力します。この名前は構成ファイル
（config.xml）で使用され、管理コンソール全体を通じてこのデータ・ソースを参照す
る際に使用されます。

JNDI Name - このJDBCデータ・ソースをバインドするJNDIパスを入力します。接続を
予約する際、アプリケーションはこの名前を使用してJNDIツリーでデータ・ソースを
検索します。

Database Type – 「Oracle」を選択します。

XA Driver - 選択しないままにしておきます。
16
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
「Next」をクリックして続けます。
5.
Transaction Optionsページで、次の手順を実行します。

「Global Transaction」オプションを選択します。
°

Supports Global Transactions – このオプションを選択（デフォルト）すると、この
データ・ソースでのグローバル・トランザクション・サポートが有効化されます。
ほとんどの場合、このオプションは選択されたままにします。
Supports Global Transactionsを選択した場合、トランザクション処理用のオプションを
選択します。
°
One-Phase Commit – このオプションを選択すると、非XA接続が唯一のトランザク
ション参加者としてグローバル・トランザクションに参加できます。
「Next」をクリックして続けます。
6.
GridLink data source connection Properties Optionsページで、「Enter Complete JDBC URL」を選択
します。
「Next」をクリックして続けます。
7.
Connection Propertiesページで、次のプロパティの値を入力します。
Complete JDBC URL – URL.を入力します。

プライマリおよびスタンバイがOracle RAC 11g Release 2である場合は、次を入力しま
す。
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE =
off)(FAILOVER = on)(DESCRIPTION = (CONNECT_TIMEOUT = 10)(RETRY_COUNT
= 3)(ADDRESS_LIST = (LOAD_BALANCE = on)(ADDRESS = (PROTOCOL =
TCP)(HOST = PRMY_SCAN)(PORT = 1521)))(CONNECT_DATA =
(SERVICE_NAME=oltpworkload)))(DESCRIPTION =
(CONNECT_TIMEOUT=10)(RETRY_COUNT=3)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = STBY_SCAN)(PORT=1521)))
(CONNECT_DATA = (SERVICE_NAME = oltpworkload))))
JDBC URLでは、DESCRIPTION_LIST内にプライマリ・データベースとスタンバイ・
データベースの両方のSCAN名が含まれている必要があります。

プライマリがOracle RAC 11g Release 2でスタンバイが単一インスタンスである場合
は、次を入力します。
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE =
off)(FAILOVER = on)(DESCRIPTION =
(CONNECT_TIMEOUT=10)(RETRY_COUNT=3) (ADDRESS_LIST = (LOAD_BALANCE
= on) (ADDRESS = (PROTOCOL = TCP)(HOST = PRMY_SCAN)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME = oltpworkload)))(DESCRIPTION
=
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =
STBYHOST)(PORT = 1521)))(CONNECT_DATA = (SERVICE_NAME =
oltpworkload))))

プライマリおよびスタンバイが単一インスタンス（Oracle Restartを使用）である場合
は、次を入力します。
jdbc:oracle:thin:@(DESCRIPTION_LIST = (LOAD_BALANCE =
off)(FAILOVER = on)(DESCRIPTION = (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = PRMYHOST)(PORT=1521)))(CONNECT_DATA =
(SERVICE_NAME = oltpworkload)))(DESCRIPTION = (ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = STBYHOST)(PORT =
1521)))(CONNECT_DATA = (SERVICE_NAME = oltpworkload))))
17
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database

Database User Name – データ・ソース内の各接続に対して使用するデータベース・ユーザー
のアカウント名を入力します。

Password/Confirm Password – データベース・ユーザー・アカウントのパスワードを入力
します。
「Next」をクリックして続けます。
8.
Test Database Connectionページで接続パラメータを確認し、
「Test All Listeners」をクリックします。

Test Table Name - Active Data Guardを使用する場合、データベース接続のテストに使用する
SQL文は、現在のスタンバイ・データベースに対しては失敗するものである必要がありま
す。行と列がそれぞれ1つだけの表に対して更新を実行する、軽量な文が最適です。
「Next」をクリックして続けます。
9.
ONS Client Configurationページで、次のプロパティの値を入力します。

「Fan Enabled」を選択してOracle FANイベントをサブスクライブします。

各Oracle Notification Serviceノードに対してホスト名とポートをコロンで区切って入力し、
「add」ボタンをクリックします。
次に例を示します。
PRMYHOST:6200
STBYHOST:6200
「Next」をクリックして続けます。
10. Test ONS client configurationページでパラメータを確認し、「Test All ONS Nodes」をクリックしま
す。個々のノードをテストするには、Oracle Notification Serviceのホストおよびポートに対して
「Test ONS Node」をクリックします。「Next」をクリックして続けます。
11. Select Targetsページで、データ・ソースを配置するサーバーまたはクラスタを選択します。
12. 「Finish」をクリックしてJDBCデータ・ソース構成を保存し、選択したターゲットにデータ・
ソースを配置します。
13. これらの変更を有効にするには、管理コンソールのChange Centerで「Activate Changes」をクリッ
クします。
マルチ・データソース
WebLogicマルチ・データソースでのOracle Data Guardサポートの詳細は、次のとおりです。

WebLogicマルチ・データソースはFANを使用する代わりにプーリング・メカニズムを使用しま
す。マルチ・データソース内で、障害の発生したデータ・ソースのリカバリを自動的に再び有
効化します。これらのテストの頻度は、マルチ・データソースのTest Frequency Seconds属性に
よって制御されます。Test Frequency Secondsのデフォルト値は120秒です。特定の値が設定され
ていない場合、マルチ・データソースは無効化されたデータ・ソースを120秒ごとにテストしま
す。マルチ・データソースの作成後に、管理コンソールを使用してマルチ・データソースのTest
Frequency intervalを5秒に設定すると期待する効果が得られます。
18
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database

プライマリ・サイトとセカンダリ・サイト向けの両方のデータ・ソースが含まれています。

このサポートを使用するには、プライマリ・サイトのみでデータベース・サービスが提供され
ている必要があります。

各データソース・レベルで接続タイムアウトが構成されている必要があります。
JDBCマルチ・データソースとロードバランシング・ポリシー

Algorithm Type – Oracle RACデータベースの場合は「Load-Balancing」を選択し、単一インスタ
ンス・データベースの場合は「Failover」を選択します。

マルチ・データソースのTest Frequency intervalを120秒から5秒に変更します。
1.
次の手順に従って、JDBCデータ・ソースを作成します。
a)
まだの場合は、管理コンソールのChange Centerで「Lock & Edit」をクリックします。
b)
Domain Structureツリーで、「Services」→「Data Sources」の順に展開します。
c)
Summary of JDBC Data Sourcesページで「New」→「Generic Data Source」の順にクリッ
クします。
d)
JDBC Data Source Propertiesページで、次の情報を入力（または選択）します。

Name - このJDBCデータ・ソースの名前を入力します。この名前は構成
ファイル（config.xml）で使用され、管理コンソール全体を通じてこのデー
タ・ソースを参照する際に使用されます。

JNDI Name - このJDBCデータ・ソースをバインドするJNDIパスを入力し
ます。接続を予約する際、アプリケーションはこの名前を使用してJNDI
ツリーでデータ・ソースを検索します。

Database Type – 「Oracle」を選択します。

Oracle Driver – データベース接続に使用するJDBCドライバを選択します。

単一インスタンス・データベースの場合 - 「Oracle’s Driver (Thin) for
Service connections; Versions: 9.0.1 and later」を選択します。

Oracle RACデータベースの場合 - 「Oracle’s Driver (Thin) for RAC
Service-Instance connections; Versions: 10 and later」を選択します。
「Next」をクリックして続けます。
e)
Transaction Optionsページで、次の手順を実行します。

Global Transactionオプションを選択します。

Supports Global Transactions – このオプションを選択（デフォルト）
すると、このデータ・ソースでのグローバル・トランザクション・
サポートが有効化されます。ほとんどの場合、このオプションは選
択されたままにします。

Supports Global Transactionsを選択した場合、トランザクション処理
用のオプションを選択します。

One-Phase Commit – このオプションを選択すると、非XA接続が唯一
のトランザクション参加者としてグローバル・トランザクションに
参加できます。
19
Oracle Maximum Availability Architecture
Oracle WebLogic Serverと高可用性Oracle Database
「Next」をクリックして続けます。
f)
Connection Propertiesページで、次のプロパティの値を入力します。

Service Name（Oracle DriverにOracle’s Driver (Thin) for RAC Service-Instance
connections; Versions: 10 and laterが選択されている場合のみ表示されます）
- 接続先のデータベース・サービス（service_names初期化パラメータ）を
入力します。

Database Name

単一インスタンス・データベースの場合 - 接続先のデータベース・
サービス（service_names初期化パラメータ）を入力します。

Oracle RACデータベースの場合 - 接続先のデータベース・インスタ
ンス（instance_name初期化パラメータ）を入力します。

Host Name – データベースのホスト・サーバーのDNS名を入力します。

Port – データベース・サーバーが接続リクエストをリスンするポートを入
力します。

Database User Name – データ・ソース内の各接続に対して使用するデータ
ベース・ユーザーのアカウント名を入力します。

Password/Confirm Password – データベース・ユーザー・アカウントのパス
ワードを入力します。
「Next」をクリックして続けます。
g)
Test Database Connectionページで接続パラメータを確認し、「Test Configuration」をク
リックします。

Test Table Name - Active Data Guardを使用する場合、データベース接続のテ
ストに使用するSQL文は、現在のスタンバイ・データベースに対しては失
敗するものである必要があります。行と列がそれぞれ1つだけの表に対し
て更新を実行する、軽量な文が最適です。
「Next」をクリックして続けます。
h)
Select Targetsページで、データ・ソースを配置するサーバーまたはクラスタを選択しま
す。
i)
「Finish」をクリックしてJDBCデータ・ソース構成を保存し、選択したターゲットに
データ・ソースを配置します。
j)
これらの変更を有効にするには、管理コンソールのChange Centerで「Activate Changes」
をクリックします。
2. 次の手順に従って、JDBCマルチ・データソースを作成します。
a)
作成していない場合は、管理コンソールのChange Centerで「Lock & Edit」をクリック
します。
b)
Domain Structureツリーで、「Services」→「Data Sources」の順に展開します。
c)
Summary of JDBC Data Sourcesページで「New」→「Multi Data Source」の順にクリッ
クします。
20
Oracle Maximum Availability Architecture
d)
e)
Oracle WebLogic Serverと高可用性Oracle Database
JConfigure the Multi Data Sourceページで、次の情報を入力（または選択）します。

Name - このJDBCマルチ・データソースに一意の名前を付けます。この名前
は構成ファイル（config.xmlおよびJDBCモジュール）で使用され、管理コン
ソール全体を通じてこのデータ・ソースを参照する際に使用されます。

JNDI Name - このJDBCデータ・ソースをバインドするJNDIパスを入力します。
接続を予約する際、アプリケーションはこの名前を使用してJNDIツリーで
データ・ソースを検索します。

Algorithm Type – アルゴリズム・オプションを選択します。Oracle RACデータ
ベースの場合は「Load-Balancing」を選択し、単一インスタンス・データベー
スの場合は「Failover」を選択します。

Failover – マルチ・データソースはリスト内の最初のデータ・ソー
スに接続リクエストをルーティングし、このリクエストが失敗す
るとリスト内の次のデータ・ソースにリクエストを送信し、同様
の処理を続行します。

Load-Balancing – マルチ・データソースはメンバー・データソース
に対して均等に接続リクエストを分散します。
Select Targetsページで、マルチ・データソースを配置するサーバーまたはクラスタを選択しま
す。
選択するターゲットによって、マルチ・データソースの一部として選択できるデータ・ソースが制
限されます。マルチ・データソースと同じターゲットに配置されたデータ・ソースのみを選択でき
ます。
f)
Select Data Source Typeページで「Non-XA Driver」を選択します。マルチ・データソースは、非
XA JDBCドライバを使用してデータベース接続を作成したデータ・ソースのみを使用します。
g)
Add Data Sourcesページで、マルチ・データソースが接続リクエストを処理する際に使用する
データ・ソースを選択します。

単一インスタンス・データベースの場合 - すべてのデータベースに対するデータ・
ソースを選択します（SSA1およびSSB1）。

Oracle RACデータベースの場合 - すべてのデータベースに対するデータ・ソースを選
択します（SSA1、SSA2、SSB1、SSB2）。
h)
「Finish」をクリックしてJDBCマルチ・データソース構成を保存し、選択したターゲットにデー
タ・ソースを配置します。
i)
これらの変更を有効にするには、管理コンソールのChange Centerで「Activate Changes」をクリッ
クします。
以前のOracleリリースにおける考慮事項
Oracle Database 11g Release 2では、クライアント・フェイルオーバーの構成および操作が以前のOracle
リリースに比べて大幅に簡素化されています。新しいプライマリ・データベースへサービスをフェ
イルオーバーし、データベース・ロールに従ってサービスを開始/停止し、クライアントがTCPタイ
ムアウトから抜け出せるよう通知するために必要なすべての手順は自動化されています。
Oracle Database 11g Release 2以前のリリースに対しては、次の考慮事項が追加で必要でした。
1.
正しいデータベース・ロールに対してデータベース・サービスを開始/停止するためのデー
タベース・トリガーを作成します。
2.
JDBCクライアントに通知するためのcfo実行可能ファイルに対して、ラッパー・スクリプト
と構成ファイルを構成します。
21
Oracle Maximum Availability Architecture
3.
Oracle WebLogic Serverと高可用性Oracle Database
cfoラッパー・スクリプトを実行するため、DB_ROLE_CHANGEシステム・イベントに基づ
くデータベース・トリガーを作成します。
以前のリリースについて、詳しくは『Client Failover Best Practices for Oracle Database 10g Release 2』9を
参照してください。
その他に、次の点に注意する必要があります。

RETRY_COUNTはOracle Database 11g Release 2でのみ使用できます。以前のリリースでは、場合
によって、新しい接続試行に対して追加の再試行（ADDRESS_LISTをすべて確認する回数）を
個別にコーディングする必要があります。

Oracle Database 11g Release 2以前では、アウトバウンド接続タイムアウトを設定できるのは
SQLNET.ORAファイル内のみです。つまり、すべてのOracle Netの別名に同じ値が引き継がれま
す。Oracle Database 11g Release 2では、Oracle Netの別名レベルでこの値を指定できます。
結論
連携を前提に設計されたOracle WebLogicとOracle高可用性データベースは、ミッション・クリティカ
ルなソリューションの提供を通じて、高可用性、スケーラビリティ、および障害時リカバリを含む
エンタープライズ・デプロイメントの保護を実現するとともに、ビジネス上の高いパフォーマンス
要件に対応します。
Oracle WebLogic Server Active GridLink for RACは、Oracle Database 11gのReal Application Clusters機能
に対して最善のサポートを提供します。このソリューションは、Oracle Data Guardを使用する際に推
奨されているソリューションです。
参考資料
Oracle Database 11g Release 2ドキュメント 10
Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11
Single Client Access Name ホワイト・ペーパー 12
Oracle Real Application Clusters One Node:データベースに最適な仮想化 ホワイト・ペーパー 13
Oracle WebLogic ServerでJDBC GridLinkデータ・ソースを使用する方法 14
Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2 15
Oracle WebLogic Server Active GridLink for Oracle Real Application Clusters ホワイト･ペーパー 16
Oracle WebLogic Server Active GridLinkデモ 17
9
http://otndnld.oracle.co.jp/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf
http://docs.oracle.com/cd/E16338_01/index.htm
11
http://docs.oracle.com/cd/E24001_01/web.1111/b60997/toc.htm
12
http://www.oracle.com/technetwork/jp/database/enterprise-edition/scan-1-129657-ja.pdf
13
http://www.oracle.com/technetwork/jp/database/enterprise-edition/twp-rac1nodev1-134451-ja.pdf
14
http://www.oracle.com/technetwork/jp/middleware/weblogic/wls-jdbc-gridlink-howto-333331-ja.html
15
http://docs.oracle.com/cd/E21764_01/web.1111/e13737/toc.htm
16
http://www.oracle.com/technetwork/jp/middleware/weblogic/gridlink-rac-wp-1394921-ja.pdf
17
http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/513398.mp4
10
22
高可用性データベース向けのOracle WebLogic
Serverデータ・ソース
2012年2月
著者：Susan Kornberg、Frances Zhao
共著者：Michael T. Smith、Pradeep Bhat
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載され
る内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示
または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や
条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的また
は間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目
的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
海外からのお問い合わせ窓口：
電話：+1.650.506.7000
ファクシミリ： +1.650.506.7200
www.oracle.com
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel Xeon
はIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の
商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010