1

NEC and Oracle 共同ホワイトペーパー

2013年 6月

Active GridLink for Oracle RAC解説

高い可用性と運用性を実現する

Oracle WebLogic Serverと

Oracle Real Application Clustersの緊密な連携

2

目次

1. はじめに ......................................................................................................... 3

2. Oracle Real Application Clusters .................................................................... 5

Oracle RAC 11g Release 2での新しいサポート ............................................. 5

3. Oracle WebLogic ServerとOracle RAC .......................................................... 7

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

接続アフィニティ ........................................................................................... 8

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

4. 検証概要 ....................................................................................................... 12

検証の目的 ................................................................................................... 12

検証項目 ....................................................................................................... 12

検証結果サマリ ............................................................................................ 12

検証環境 ....................................................................................................... 13

5. ランタイム接続ロードバランシング（RCLB） ............................................ 15

RCLBの目標設定 .......................................................................................... 15

ロードバランシング・アドバイザリの内容 .................................................. 15

パフォーマンスの改善 .................................................................................. 16

6. Webセッション・アフィニティ ................................................................... 22

基本動作 ....................................................................................................... 22

パフォーマンスの改善 .................................................................................. 22

アフィニティの自動有効化／無効化 ............................................................. 24

アフィニティ情報の引き継ぎ ....................................................................... 24

7. 高速接続フェイルオーバー（FCF） ............................................................. 26

検知可能な障害の種類と障害時間の短縮効果の確認 .................................... 26

フェイルバックの動作について .................................................................... 28

8. 動的なOracle RACノード追加による性能改善 ............................................. 30

9. まとめ .......................................................................................................... 32

3

1. はじめに

高可用性とスケーラビリティは多くのシステムにおいて重要なテーマです。Java EEミドルウェアとデ

ータベースを伴う複雑な異種環境には、さまざまな課題が存在します。たとえば、データベース・ノー

ドが停止すると、アプリケーション・リクエストが長時間ブロックされることがあります。アプリケー

ションが SQLExceptionを受信した後に、接続をリフレッシュすべきかを判断するのは容易ではありま

せん。Java EEミドルウェアに、新規または再起動したデータベース・ノードを認識させるのも難しい

問題です。また、データベースの低速なノードやハング・ノード、あるいは障害ノードに処理が振り分

けられてしまう可能性についても考慮が必要です。そして多くの場合、TCP/IPタイムアウトを待たなけ

れば障害の判定は出来ません。

Oracle WebLogic Server 11g および 12cは、Oracle Database 11gの Oracle Real Application Clusters

（Oracle RAC）機能を強力にサポートします。Oracle WebLogic Server 11g および 12cを利用すると、

データベース処理の高速化、透過的なデータベースアクセス、強化したコネクションプーリング機能を

活用でき、パフォーマンスと可用性を最大限に高めることができます。

Oracle WebLogic Server Active GridLink for Oracle RACは、Oracle RACを最大限に活用できる、大変

優れた統合ソリューションであり、オラクルが推奨する戦略的ソリューションです1。これは、ミドルウ

ェアとデータベースが統合され、他のベンダーでは使用できない機能を備えた、最良のソリューション

です。

NECとオラクルは、Oracle WebLogic Server内に実装された Active GridLink for Oracle RAC ソリュー

ションの検証およびテストに共同で取り組んできました。これにより Oracle WebLogic Serverと Oracle

Database Real Application Clusters を高度に連携させ、両者の機能を最大限引き出すために必要なナレ

ッジと技術が市場にもたらされることが期待されます。Active GridLink for RACによって、高パフォーマ

1 Active GridLink for RACの詳細については、『Oracle Fusion Middlewareライセンス情報』ドキュメントも

参照ください。

4

ンス、高スケーラビリティ、高可用性を実現するミッション・クリティカル環境を構築できます。動的ロー

ドバランシングおよびアフィニティ機能により、オンライン・トランザクション処理のパフォーマンス: スル

ープットおよび全体の応答時間が向上します。高速接続フェイルオーバーにより、エンド・ツー・エンドの

迅速な障害検出が可能になり、Oracle RACノードの計画停止および計画外停止の際のアプリケーションの停

止時間を最小化するスムーズな停止が可能になります。

図 1-1

本書ではまず、Oracle RACの概説、及び Active GridLink for Oracle RACの機能の概要を紹介します。

その後、NECとオラクルが共同で実施してきた取組みに焦点を当て、その詳細について解説します。

NECによる Active GridLink for Oracle RACの機能検証の背景と概要、及び Active GridLink for Oracle

RACの諸機能:ランタイム接続ロードバランシング、Webセッション・アフィニティ、高速接続フェイ

ルオーバー、アプリケーションの停止時間を最小化する Oracle RACノードの削除および追加方法につ

いての詳細なテストとその結果、及び考察について、さまざまなユースケースを通じて詳細を解説しま

す。

5

2. Oracle Real Application Clusters

Oracle RACはOracleデータベースをクラスタリングするためのソリューションです。シングル・インスタ

ンスのOracleデータベースの場合、Oracleデータベースとインスタンスの関係は1対1です。Oracle RACを

利用することで、データベースとインスタンスの関係を1対多にすることが出来ます。

次の図は、Oracle RACと、それにアクセスする複数のアプリケーション/Webサーバを表しています。

Oracle RACでは、それぞれのOracleインスタンスは別々のサーバ上で実行されています。

図 2-1

Oracle RAC 11g Release 2 での新しいサポート

Oracle RAC 11g Release 2の新機能は以下のとおりです。

Single Client Access Name（SCAN）: SCANを使うことで、Oracle RACのノード群が持つ複数のIPア

ドレスを意識することなく、透過的に接続することが可能になります。SCANによりOracle RACの

ノード群のIPアドレスが動的に解決されます。

6

エディションベースの再定義では、SRVCTLを使用してデータベース・サービスにエディション

属性を指定でき、その後、サービスを指定するすべての後続の接続がこのエディションを初期セ

ッション・エディションとして使用します。

Oracle Enterprise ManagerによるOracle RACの監視および診断機能の拡張

Oracle RAC Configuration Assistantの機能拡張

Oracle Grid Infrastructureを管理するためのSRVCTLの機能拡張

Oracle RAC One Node: シングルインスタンス・データベースの高可用性ソリューションです。計

画停止および計画外停止からデータベースを保護します。

Oracle WebLogic Server 11g、12cとOracle 11g RACは、協調して動作し高可用性、スケーラビリティおよび

高パフォーマンスを実現します。フェイルオーバー、ランタイム接続ロードバランシング、アフィニテ

ィなどのOracle RACサービスは、Oracle WebLogic Server JDBCデータソースおよび接続プール実装で利用

できるよう構成されます。

7

3. Oracle WebLogic ServerとOracle RAC

Java EEアプリケーション・サーバでは、データベース・インタラクションは通常データソース実装によ

って処理されます。データベースへの接続をJDBCデータソースとして構成し、公開します。

Oracle WebLogic Serverには、Oracle Real Application Clustersをサポートするための次の2つのデータソースが

実装されています。1つは従来から活用されてきたマルチ・データソース・ソリューションです。もう1

つはOracle WebLogic Server Active GridLink for Oracle RACと呼ばれる、Oracle RACの最新かつ最大の進歩を

利用した、市場をリードする中間層統合ソリューションです。これはOracle WebLogic Server 11g Release 1

（10.3.4）からの新規実装で、12c（12.1.1）でさらに拡張されています。

Active GridLink for Oracle RACはOracle RACクラスタをサポートする単一のデータソース実装です。これ

は、FANイベントに対応し、高速接続フェイルオーバー（FCF）、ランタイム接続ロードバランシング

（RCLB）およびOracle RACインスタンスのスムーズな停止を提供します。XAアフィニティは、グローバ

ル・トランザクションIDレベルでサポートされます。Webセッション・アフィニティは、HTTPセッショ

ン・スコープ内でサポートされます。

Active GridLink for RACはOracle RACとのより深い統合を提供する重要な基盤であり、データソースの接

続先であるデータベース・サービスの完全な使用をサポートします。接続プールは、接続プール自体に

構成される静的設定（最小/最大容量、タイムアウトなど）と、"クライアント"であるWebLogic Serverに

対し、Oracle RACクラスタ内の状態の変更を知らせるRAC Oracle Notification Service（ONS）サブシステム

からの動的情報に基づき、動的に調整されます。

内部的には、Active GridLink for RACはUniversal Connection Pool Javaライブラリを利用しています。これに

より高速接続フェイルオーバー、ランタイム接続ロードバランシングおよびアフィニティ機能が提供さ

れています。

Oracle Databaseサービス（以下、サービス）は、Oracle Databaseのワークロードを論理的に抽象化したも

のです。サービスは、ワークロードをグルーピングし、論理的に分割します。各サービスは、一般的な

属性やサービス・レベルのしきい値および優先順位でワークロードを管理します。サービスはOracle

Databaseに組み込まれ、ワークロードの単一システム・イメージ、ワークロードの優先順位付け、実際の

トランザクションのパフォーマンス測定、およびパフォーマンス目標に違反があった場合の警告および

アクションを提供します。サービスにより、データベース管理者は、ワークロードの構成、ワークロー

ドの管理、ワークロードの有効化/無効化、および単一エンティティとしてのワークロードの測定が可能

になります。

Active GridLink for RACが管轄する接続プールにおいて、アプリケーションからのリクエストにより提供

される接続は、ONSから提供されるロードバランシングに基づき負荷分散が行われ、適切なものが提供

されるよう構成されています。

Active GridLink for Oracle RACを利用することで、WebLogic ServerとOracle RACデータベースの統合がより

簡単になり、Oracle RACを使用するために必要な構成および管理の複雑さが軽減されます。なお、マル

チ・データソース構成も引き続きサポートされます。マルチ・データソースからActive GridLink for RAC

へのアップグレードは簡単で、Active GridLink for RAC データソースをマルチ・データソースと同じ

JNDI名で作成するだけです。これにより設定すべきデータソース設定数を削減できます。

8

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

Active GridLink for RACはOracle RACデータベースが提供するロードバランシング機能を利用します。こ

れによりスループットの向上とリソースの効率的な使用が実現できます。ランタイム接続ロードバラン

シングの前提条件はOracle JDBCドライバおよびOracle RACデータベースの使用です。

オラクルのパフォーマンス分析では、静的ラウンドロビン・アルゴリズムと比較して、ランタイム接続

ロードバランシングによるパフォーマンスの優位性が明らかになっています。ランタイム接続ロードバ

ランシングは、Oracle RACクラスタのノードが同一の場合や、クラスタ上のノードに対する負荷に偏り

が無い場合でも有効です。負荷に偏りがある場合、ランタイム接続ロードバランシングはOracle RACク

ラスタに最適なロードバランシング・メカニズムになります。

オラクルデータベースのロードバランシング・アドバイザリ・サービスにより、接続の送信先に関する

アドバイスなど、クラスタの現在のステートをクライアントに知らせるFANイベントが発行されます。

Active GridLink for RACはこのFANイベントを受信し、以下の図に示すように負荷分散します（3つのイン

スタンスに対する接続を、3:1:6の割合で使用するよう動作します）

図 3-1

ランタイム接続ロードバランシングが提供する利点は以下の通りです。

パフォーマンスおよびスケーラビリティの向上

CPU容量や応答時間など、データベースの稼働に基づいた負荷分散

クラスタ再構成、アプリケーション・ワークロードの変化、過負荷、ハング等に対する迅速な対

応

Oracle RACロードバランシング・アドバイザリからのメトリックの受信。パフォーマンスが良好

なインスタンスへの接続がもっとも頻繁に使用されます。パフォーマンスの低いインスタンスへ

の新規および未使用の接続は、使用される割合が少なくなります。

接続アフィニティ

Active GridLink for RACは、Oracle RACデータベースが提供するアフィニティ機能を利用します（Oracle

RACデータベース version 11.1.0.6以上でサポート）

9

接続アフィニティにより、接続プールはOracle RACインスタンス毎の接続を識別し、それが有効である

場合、接続を偏らせることで、パフォーマンスを最適化します。Active GridLink for RACは、トランザク

ションベースのアフィニティ、およびWebセッション・アフィニティをサポートします。

トランザクションベースのアフィニティ

WebLogic上で分散トランザクションを利用する場合、あるOracle RACインスタンスへの接続をトランザ

クションスコープの中で維持します。分散トランザクション中に異なるOracle RACインスタンスに接続

をリダイレクトすることによる大幅なパフォーマンス・コストの発生を避けるためです。

トランザクションベースのアフィニティは、グローバル・トランザクションIDに基づいて確立されま

す。これにより、異なるデータソースから取得された接続もすべて同一のOracle RACインスタンスに関

連付けられます。

トランザクションベースのアフィニティは、クライアント・アプリケーションまたは障害イベントのど

ちらかによって解放されます。

図 3-2

Webセッション・アフィニティ

Webセッション・アフィニティを使用する一般的なユースケースは、ユーザー・セッション毎に、同じ

レコード・セットに対してオンライン・トランザクション処理（OLTP）を繰り返す場合です。操作を同

一のOracle RACインスタンスで処理することで、キャッシュの有効活用を図ります。オンライン・ショ

ッピングやオンライン・バンキングなどのビジネス・アプリケーションは、このパターンの典型的な例

です。

Active GridLink for RACは、Webセッション毎に、すべての操作が同一のOracle RACインスタンスに送られ

るようにします。あるWebセッションにおける最初の接続先Oracle RACインスタンスは、RCLBベースで

選択されますが、それ以降はアフィニティにより、同一インスタンスが選択されます。

Webセッション・コンテキストは、HTTPセッションCookieに格納されます。これはセッションの終了後

削除されます。Webセッション・コンテキストはHTTPセッション内で伝播させることが可能です。

Active GridLink for RACのWebセッション・アフィニティはデフォルトで常に有効になっていますが、デ

ータベースの稼働状況等により、セッション・アフィニティのメリットがないとデータベースによって

10

判断された場合、通常のRCLBベースの負荷分散モードに自動的に戻り、Webセッション・アフィニティ

機能はFALSEに設定されます。

Webセッション・アフィニティは一般に、Oracle RACクラスタの待機時間を短縮することで極めて高いパ

フォーマンスを実現します（以下グラフ参照）

図 3-3

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

高速接続フェイルオーバー（FCF）機能は、Universal Connection Poolを通じて実装された高速アプリケー

ション通知（FAN）クライアントにより提供されます。この機能はOracle JDBCドライバ、およびOracle

RACデータベース（または、Oracle Restartを利用するシングルインスタンス・データベース）の利用を前

提とします。

Active GridLink for RACはFCFと統合されており、FCFを利用して以下を実現します。

迅速な障害検出

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

Oracle RACノードのグレースフル・シャットダウンのサポート

ノードの追加または削除などのトポロジ変更に対する動的な対応

動的に追加、または復帰したノードを含むすべてのアクティブなOracle RACインスタンスを対象

とする負荷分散

Oracleデータベースが含むONS(Oracle Notification Service)は、Oracle RACデータベースの状態の変更を随時

配信します。Active GridLink for RACはこれを受信し、Oracle RACデータベースの状態変更を迅速に認識

します。この機構により、Active GridLink for RACの接続プールはOracle RACデータベースの状態の変更

に適切に追随し、データベース接続の維持とシステムの信頼性の向上を実現します。

11

この機構により、WebLogic Serverは、計画外停止によって停止または切り離されたOracle RACインスタン

スへの接続のみ迅速に終了および破棄し、停止に適切に対応します。Oracle RACインスタンスの死活確

認のための定期的なポーリングは不要ですし、停止インスタンスへの接続以外の接続は適切に維持し影

響を局所化します。これにより、死活監視のための追加のSQLアクセスは不要になりますし、障害によ

っては数分間にわたってクライアントのセッションがハングする可能性のあるOracle RACノード障害か

ら、無効な接続のみ迅速に排除できます。

さらに、Active GridLink for RACはOracle RACインスタンスが追加または再起動された場合のシナリオも

サポートできます。これにより、WebLogic ServerはOracle RACデータベース内のリソースを完全に使用で

きるようになります。RACインスタンスが追加または再起動され、クラスタに追加されると、WebLogic

Serverは自動的にこれに追随し、当該インスタンスの利用を開始します。さらに、データベース管理者は

Oracle RACサービス/インスタンスの割当てをオンラインで変更できますが、これについてもWebLogic

Serverは自動的にこれに追随します。つまり、マルチ・データソース構成の弱点である、Oracle RACデー

タベースの変更に追随するために複数のデータソースを冗長に事前設定する必要性を回避できます。

Active GridLink for RACの高速接続フェイルオーバー機能は、Oracle RACデータベース・サービスおよび

ノードのイベント（UP、DOWN）に対応して、接続プール内の接続が常に有効なデータベース・ノード

を指すようにします。これにより接続は使用可能なデータベース・ノードに適切に分散されます。

高速接続フェイルオーバー機能が有効化されている場合、以下のシナリオがサポートされます。

計画停止イベント – 計画停止は、データベースの保守またはその他のアクティビティとして実施

されます。計画停止においては、Oracle RACサービスを”正しく”停止する必要があります。Active

GridLink for RACの高速接続フェイルオーバー機能は、システムの利用者の作業が全て完了し、接

続が接続プールへ戻ったことを確認した後、計画停止を行います。使用中の接続が切断されるこ

とはありません。これにより、大規模な本番環境でもサービスを止めることなく計画停止を実現

できます。

計画外停止イベント – 計画外停止のサポートは、当該Oracle RACノードへの接続を検出して削除

することにより実現されます。削除対象の接続には、サービス停止やノード停止により、Oracle

RACインスタンス上に使用可能なサービスがなくなった場合を含みます。利用中の接続を含む、

計画外停止ノードへの接続が検出され、削除されます。

o 計画停止シナリオと計画外停止シナリオとのおもな違いは、利用中の接続に対する処

理の方針です。前者では処理完了まで待機しますが、後者では接続は削除されます。

アイドル状態の接続（利用中でない）は、双方とも同様に削除対象です。

UPイベント（Oracle RACノードの復帰、および新規追加シナリオ）– Oracle RACに新規、または

再起動後復帰したノードに対する接続ですが、接続プールはONSからの通知により当該ノードを

認識し、ノードへの接続を自動的に生成します。

12

4. 検証概要

検証の目的

NECではWebLogic Serverを利用した数多くのミッションクリティカルシステムを構築しており、SI実績に

裏付けられたOracle RACとの連携ノウハウがあります。本検証は従来からWebLogic Serverで提供されてい

たマルチ・データソースのノウハウをもとに、もうひとつのOracle RACへの接続ソリューションとして

新しく提供されたGridLinkデータソース（WebLogic Active GridLink for RACは、WebLogic Server内では

GridLinkデータソースとして実装されています）の優位点、および特長をシステムインテグレータの観点

で調査したものです。

過去の問題とベストプラクティスに基づき、構築時や運用時に課題となりそうな点を取り上げて検証内

容を策定し実機でのテストを行いました。またGridLinkデータソースがOracle RACとの連携で高い運用

性・柔軟性を有していることに注目し、既存のSIノウハウと組み合わせて高い運用性が得られること、

さらにその機能が容易に利用できることを実証することを目的としました。

検証項目

本検証ではGridLinkデータソースの以下機能の動作と効果について検証を実施しました。これらの検証の

詳細については5章以降で解説いたします。

ランタイム接続ロードバランシング（Runtime Connection Load Balancing; RCLB）

Webセッション・アフィニティ

高速接続フェイルオーバー（Fast Connection Failover; FCF）

動的なOracle RACノード追加によるパフォーマンス改善

検証結果サマリ

本検証での結果より、以下が確認できました。

1. RCLB により、Oracle RAC 側の負荷状況に応じて動的に負荷が分散されることが確認できました。

WebLogic Server が各 Oracle RAC ノードにリクエストを振り分ける割合は、Oracle RAC からの負

荷状況から計算された通知に従っています。負荷の高い Oracle RAC ノードへのレスポンスタイ

ムが改善され、システム全体のレスポンスタイムも改善されます。

2. Web セッション・アフィニティによりキャッシュ・ヒット率が向上することで、インターコネ

クト通信量が減少することによるレスポンスタイムの改善を確認しました。また Oracle RAC ノ

ードの負荷の偏りやクラスタの待機時間に応じて自動でアフィニティの有効／無効を切り替える

インテリジェンスがあることを確認しました。

3. FCF を使用することで、パブリックネットワーク障害とインターコネクト障害において生存

Oracle RAC ノードからの通知でエラーを検知できます。この効果により、従来クライアント側

13

のタイムアウトでしか検知できなかった障害を早期に検知しリトライを行う事で、業務継続が可

能となります。

4. FCF による Oracle RAC の構成変更の通知と RCLB の負荷分散を組み合わせ、動的なノード追加

により性能が向上することを確認できました。JDBC 接続に SCAN を利用することで、WebLogic

Server 側の設定を変更することなく稼働中のシステムに対し動的に Oracle RAC ノードを追加する

ことができました。

検証環境

: WebLogic 管理サーバ : WebLogic 管理対象サーバ

図 4-1 検証で使用したマシン構成

ハードウェア環境

本検証で使用したシステムの構成は次の通りです。

用途 ホスト名

クライアント CL01

APサーバ (WLS 12.1.1.0) AP01, AP02

DBサーバ (RAC 11.2.0.3) DB01, DB02, DB03, DB04

各マシンは全て同一のスペックとなり、NECのIAサーバであるExpress5800を使用しています。データベ

ースはNECのストレージ製品であるiStorage上に配置しており、4GbpsのFibre Channel（以降、FC）4本で

14

DBサーバと結線しました。アプリケーション・サーバにはOracle WebLogic Server 12c, DBサーバには

Oracle Database 11g Release 2をインストールしています。

また、WebLogic Serverの情報の採取にはJRockit Mission Controlを使用しています。

ハードウェアの詳細スペックは以下の通りです。

Express5800/B120a-d

CPU インテル®Xeon® プロセッサ

X5550(2.66GHz) [コア数：4]×2

Memory 48GB

OS Red Hat Enterprise Linux 5 Update7 x86-64

ストレージ：iStorage D3-10(FC)：1台

Hard Disk Drive SAS 300GB（15000rpm）× 36

(本体 ＋ ディスクエンクロージャ×2 の総数)

Cache Memory 4GB

Host interface Fibre Channel 4Gbps × 4

各マシンにインストール、使用した製品の詳細バージョンは以下となります。

アプリケーション・サーバ： 2台

Oracle WebLogic Server Oracle WebLogic Server 12c (12.1.1.0)

Oracle JRockit Oracle JRockit R28.2.5 for Java version 6

データベース・サーバ： 4台

Oracle Database Oracle Database 11g Release 2 Enterprise Edition (11.2.0.3)

Oracle Grid Infrastructure Oracle Database 11g Release 2 Grid Infrastructure (11.2.0.3)

Oracle Real Application Clusters

Oracle Diagnostics Pack

JDBC接続について

WebLogic Server から Oracle RAC への物理接続には SCANを利用し、同一の接続名で Oracle RACにア

クセスする構成としています。全ての WebLogic Server は同じ JDBC設定で Oracle RAC を利用すること

ができます。またこの機能により、Oracle RAC側の構成に変更があった場合でも WebLogic Server 側の

JDBCの接続設定を変える必要はありません。

15

5. ランタイム接続ロードバランシング（RCLB）

この章ではGridLinkデータソース機能の一つであるランタイム接続ロードバランシングについて、検証の

結果判明した動作や実際に測定した性能改善の効果を説明します。

RCLB の目標設定

Oracle RACは30秒に1回の間隔でONSを通じてWebLogic Serverにロードバランシング・アドバイザリを送

信します。WebLogic Serverはこのアドバイザリに含まれる情報を使用して、どのOracle RACノードの接続

を使用するかを決定します。

ロードバランシング・アドバイザリの内容はRCLBの目標（RLB_GOAL）の設定値に応じた統計情報を使

用して計算されます。以下にRCLBの目標と使用される統計情報の対応を示します。

RCLBの目標が SERVICE_TIMEの場合:

Oracle RAC が持つ「1 コール当たりの DB 処理時間」の値がロードバランシング・アドバイザリの

計算に使用されます。平均 DB 処理時間の小さい Oracle RAC ノードに多くのリクエストを振り分

けるように動作します。

RCLBの目標が THROUGHPUT の場合:

Oracle RAC が持つ「1秒当たりのユーザー・コールの数」の値がロードバランシング・アドバイザ

リの計算に使用されます。単位時間当たりのユーザー・コールの数が多い Oracle RAC ノードに多

くのリクエストを振り分けるように動作します。

RCLBの目標が NONEの場合:

Oracle RAC はロードバランシング・アドバイザリを送信しません。サービス作成時のデフォルト

となりますが、GridLink データソースを使用する際は通常使用しません。SERVICE_TIME, または

THROUGHPUT に変更することを推奨します。

ロードバランシング・アドバイザリの内容

RCLBの振り分け動作

Oracle RACから送信されるロードバランシング・アドバイザリには、WebLogic ServerがどのOracle RACノ

ードに何%の割合で接続を振り分けるかという情報が含まれています。

ロードバランシング・アドバイザリを受け取ったWebLogic Serverはその割合に従って各Oracle RACノード

への接続を使用します。この割合は、WebLogic Serverの実行時MBeanからCurrentWeight属性値を参照する

ことで確認することができます。

16

図 5-1 各Oracle RACノードに対するCurrentWeightの値

図 5-1の例では4ノードOracle RAC構成でRCLBの目標をSERVICE_TIMEに設定し、最初DB01～DB04に対

してWebLogic Serverから負荷をかけ、途中からDB02に対してのみWebLogic Server以外のプロセスから追

加の負荷をかけています。負荷の高いDB02は、他のDB01, DB03, DB04と比べてレスポンスタイムが大き

くなるため、CurrentWeightが大きく下がります。

DB02はCurrentWeightが大きく下がったため、WebLogic Serverから接続を使用される割合が小さくなりま

す。例えば図 5-1の16:36:00の時点では、WebLogic ServerはCurrentWeightの値に従い各Oracle RACノードへ

の接続を使用し、その割合はDB01が30%, DB02が7%, DB03が31%, DB04が32%となります。

パフォーマンスの改善

テスト内容

一部のOracle RACノードが別の業務で高負荷になった場合に、RCLBにより各ノードの負荷が平均化さ

れ、システム全体の性能が改善することを確認します。RCLBの目標がSERVICE_TIMEの場合、

THROUGHPUTの場合、比較のためにNONEの場合の3通りで測定します。

テストでは以下の手順で負荷をかけます。

手順1. WebLogic Server から負荷をかけ、Oracle RACの各ノードの CPU 使用率を 50%前後にする。この

負荷を 10分間続ける。全 Oracle RACノードに均等に負荷がかかるため、WebLogic Server からの

リクエストは均等に振り分けられる。

手順2. 手順 1. の負荷をかけ続けたまま、DB02で CPUを 75%使用する追加の負荷を発生させる。この

負荷を 15分間続ける。DB02に大きな負荷がかかるため、RCLBを使用している場合は、

WebLogic Server から DB02へリクエストが振り分けられる割合は減少する。WebLogic Server から

DB01, DB03, DB04 へリクエストが振り分けられる割合は、DB02への割合が減少した分だけ増加

する。

■:DB01 ■:DB02 ■:DB03 ■:DB04

17

手順3. 手順 2. の負荷だけを終了し、DB02の処理性能が向上する。手順 1. の負荷は続いており、全

Oracle RAC ノードに均等に負荷がかかる状態に戻る。

図 5-2 RCLBの動的負荷分散テストの構成

18

テスト結果

振り分けの割合について

図 5-3 WebLogic Serverから各Oracle RACノードへの振り分けの割合

図 5-3は、WebLogic Serverから各Oracle RACノードへの振り分けの割合を示したものです。具体的には

WebLogic Serverの各Oracle RACノードへのCurrentWeightの値です。SERVICE_TIME, THROUGHPUTとも

に、負荷の高いDB02インスタンスへの振り分けの割合が、他のノードと比較して低くなっています。

また、手順2. の負荷が終了すると各Oracle RACノードへの振り分けはほぼ均等に戻ります。

SERVICE_TIME

THROUGHPUT

NONEの場合、CurrentWeightの情報は送信されません。

■:DB01 ■:DB02 ■:DB03 ■:DB04

19

レスポンスタイムについて

図 5-4 RCLBの目標によるレスポンスタイムの比較

（ALLが全ノードの平均レスポンスタイム）

SERVICE_TIME

THROUGHPUT

NONE

20

図 5-4 はRCLBの目標によって、レスポンスタイムがどのように変化するかを示したグラフです。

SERVICE_TIME, THROUGHPUTの場合、手順2. でDB02に負荷をかけた直後はレスポンスタイムが悪化

するものの、時間が経過することで手順1. の段階と同程度のサービス・レベルを提供できています。

各目標における詳細な結果はそれぞれ以下となります。

SERVICE_TIMEの場合:

手順2. でDB02の負荷が大きくなると動的なロードバランシングが開始され、WebLogic ServerからDB02

へ送られるリクエストは少なくなります。NONEの場合はレスポンスタイムが悪化しましたが、

SERVICE_TIMEの場合はDB02の負荷が小さくなるため、レスポンスタイムが改善されます。また、シス

テム全体の平均レスポンスタイムは手順2. の負荷がかけられる前と同程度に抑えられており、リソー

スが効率的に利用できていると言えます。

THROUGHPUTの場合:

SERVICE_TIMEの場合と同様に、DB02に負荷が偏ると動的なロードバランシングが働き、WebLogic

ServerからDB02へ送られるリクエストは少なくなります。SERVICE_TIMEと比較してレスポンスタイム

の改善には時間がかかりますが、DB02のレスポンスタイムと負荷の低い他のノードのレスポンスタイム

が全て同程度になり、システム全体の平均レスポンスタイムは手順2. の負荷がかけられる前と同程度

に改善されました。リソースが効率的に利用できていると言えます。

NONE の場合:

RCLBを使用できないデータソースの場合、動的なロードバランシングは行われず、WebLogic Serverから

DB02に送信されるリクエストの割合は変化しません。このためDB02は過負荷の状態が継続し、レスポン

スタイムは他のノードの約170%となっています。全ノードの平均レスポンスタイムも手順1. の時点で

のレスポンスタイムの約120%となっています。

RCLBの効果とレスポンスタイムの比較

表 1は、DB02に追加の負荷をかけた後にRCLBによる振り分けが安定した区間（図 5-4の経過時間が1200

秒～1500秒の間）で平均レスポンスタイムを測定したものです。

Oracle RAC 4ノード全体で平均レスポンスタイムが最も改善されたのはSERVICE_TIMEの場合です。また

追加の負荷をかけたDB02のレスポンスタイムについては、THROUGHPUTの場合に最も改善され、負荷

の低いDB01, DB03, DB04と同程度のレスポンスタイムになりました。

SERVICE_TIME, THROUGHPUTの場合ともに、NONEと比較してレスポンスタイムの改善が見られま

す。RCLBを使用することで、負荷の高いOracle RACノードへのレスポンスタイムが改善され、システム

全体のレスポンスタイムも改善されたと言えます。

特定のノードで突発的な高負荷が発生した場合も、安定したレスポンスが実現できます。

21

RCLBの目標を SERVICE_TIMEにした際の課題

RCLBの目標をSERVICE_TIMEに設定しWebLogic Serverから各Oracle RACノードに著しい高負荷を継続し

て与えた際に、CurrentWeightが不安定になりレスポンスタイムが悪化するケースがありました。

現象が発生したテストケースは以下となります。

各Oracle RACノードのCPU使用率が著しく高くなるように継続して高負荷をかけました。

o Databaseの処理が限界に近づいた場合に、Oracle RACノードを動的に追加することでレスポ

ンスタイムを改善できるか、というテストを想定してかけた負荷です。

Oracle RACノードのCPU使用率が高くない場合は発生しません。今回のRCLBの検証やそれ以下の

CPU使用率の負荷ではこの現象は発生しませんでした。

テストで使用したSQLクエリは大きなテーブルに対して何度も検索をかけることでCPUを高騰さ

せる単純なものです。DB側の処理としてDisk I/Oはほとんどなく、DB処理時間の大部分をCPU処

理が占めています。

テストで使用したSQLのレスポンスタイムはOLTPとしては比較的長い処理となります。SQLの

DB処理時間が大きいほどこの現象は発生しやすくなります。DB処理時間の短いSQLを使用した

場合は偏りが発生し辛くなりますが、徐々に偏りが大きくなりレスポンスタイムに悪影響がでま

す。

当現象については引き続き調査を継続しており、回避策としてはRCLBの目標の設定をTHROGHPUTにす

ることを検討してください。

表 1 平均レスポンスタイム（ミリ秒）

RCLBの目標＼対象ノード 4ノード平均 DB02のみ

SERVICE_TIME 10.65 12.61

THROUGHPUT 10.70 10.65

NONE 11.47 17.12

22

6. Webセッション・アフィニティ

この章ではアフィニティ機能について、検証で判明した動作や性能改善の効果を説明します。GridLinkデ

ータソースのアフィニティ機能にはWebセッション・アフィニティとトランザクション・アフィニティ

がありますが、本検証ではAPサーバの利用法として一般的によく見られる、DBアクセスを伴うHTTPセ

ッション処理を想定し、Webセッション・アフィニティに着目してテストを実施しました。

基本動作

GridLinkデータソースではRCLBとアフィニティの2つの異なる接続選択アルゴリズムが存在します。デフ

ォルトでは両方が有効となっており、以下のように動作します。

1. HTTP セッションを使用する HTTP リクエストが初めて Oracle RAC ノードに接続する場合、

RCLBによって接続先の Oracle RACノードを選択します。

2. HTTP セッションは 2 回目以降の Oracle RAC ノードの接続時に、初回リクエストで選択した

Oracle RAC ノードを選択します。

パフォーマンスの改善

テスト内容

Webセッション・アフィニティありの場合と、Webセッション・アフィニティなしの場合で性能を比較し

ました。本検証の構成では、リクエストがどのOracle RACノードに送られるかは、GridLinkデータソース

の動作に依存して決定されます。

: WebLogic 管理サーバ : WebLogic 管理対象サーバ

図 6-1 Webセッション・アフィニティのテスト構成

つまりWebセッション・アフィニティありの場合は、HTTPセッションごとに常に同じOracle RACノード

に対してリクエストが送信されます。ローカルキャッシュにヒットしやすくなるため、キャッシュ・フ

ュージョンによるノード間のブロック転送が減少します。

23

Webセッション・アフィニティなしの場合は、同じHTTPセッションでも別々のOracle RACノードに対し

てリクエストが送信される可能性があります。キャッシュ・フュージョンによるOracle RACノードの間

のデータブロック転送が多発し、レスポンスタイムが悪化する可能性があります。

テスト結果

図 6-2 2ノードOracle RAC構成時のアフィニティ有／無での比較の左のグラフ（Response Time Avg –

2Node）がレスポンスタイムの比較、右のグラフ（Estd Interconnect traffic 2Node）がOracle RACノード間

のインターコネクト通信量の比較になります。Webセッション・アフィニティを使用することで、レス

ポンスタイムは約半分に、インターコネクト通信量は大幅に削減することができました。

図 6-2 2ノードOracle RAC構成時のアフィニティ有／無での比較

図 6-3は、同様のテストを4ノード構成で実施した結果となります。2ノード構成の場合と同様に、レス

ポンスタイムは約半分、インターコネクト通信量も大幅に削減、という結果が得られました。

図 6-3 4ノードOracle RAC構成時のアフィニティ有／無での比較

本検証で用いたアプリケーションではWebセッション・アフィニティにより、2ノードの場合も4ノード

の場合も、レスポンスタイムとインターコネクト通信量において大きな改善効果が得られました。

24

アフィニティの自動有効化／無効化

Webセッション・アフィニティはRCLBのバランス状況やキャッシュ・フュージョンの発生状況に応じ有

効／無効が自動で変わります。Oracle RACはロードバランシング・アドバイザリの内容にアフィニテ

ィ・フラグを含めてWebLogic Serverに送信しており、アフィニティ・フラグがtrueの場合はPage.22「基本

動作」で示した動作となります。falseの場合は常にRCLBで接続を選択します。

図 6-4 アフィニティの自動有効化／無効化

アフィニティの自動切り替えにより、通常時はアフィニティによるキャッシュ・フュージョンの削減に

よる性能の向上を目指し、アフィニティにより負荷が偏るとRCLBに切り替えて負荷を均等化し全体のパ

フォーマンスの悪化を抑止する動作を実現しています。

アフィニティ情報の引き継ぎ

WebLogicクラスタのセッション・レプリケーション機能でセッションを継続すると、WebLogic Serverが

フェイルオーバーした際にもHTTPセッションは同じOracle RACノードにアクセスします。

つまりWebLogic Server障害後もアフィニティは継続されており、キャッシュ・フュージョンの抑制効果

は続いています。この仕組みにより、WebLogic Server障害直後のDBアクセスで瞬間的に大量のキャッシ

ュ・フュージョンが発生してしまうことを防いでいます。

図 6-5はセッション・レプリケーションを利用した場合に、WebLogic Serverのフェイルオーバー後に

HTTPセッションが同じOracle RACノードにアクセスする動作を示したものです。

25

図 6-5 セッション・レプリケーションによるアフィニティの引き継ぎ

なお、Webセッション・アフィニティの情報はHTTPセッションが保持しているため、Coherence*Webを

利用してセッションを継続する場合もWebLogic Serverフェイルオーバー後のアフィニティが継続されま

す。

26

7. 高速接続フェイルオーバー（FCF）

検知可能な障害の種類と障害時間の短縮効果の確認

この章ではFCFの有効性を確認するために、様々な障害のケースでテストを実施し、リクエストが障害

から復旧する時間を測定します。

障害の種類やタイミングによっては、リクエストがDBからの応答を待ち続け長時間ハングすることにな

ります。FCFはOracle RACの生存ノードからWebLogic ServerにFANイベントを送信し、ハング状態のリク

エストに早期にエラーを通知します。

テスト内容

本テストでは、リクエストがRead待ち状態となったタイミングで障害が発生するケースを想定していま

す。従来この障害は、TCPタイムアウトを待つことでリクエストが障害を検知することでしか解決でき

ず、一般的にシステムへの影響が大きいケースと言えます。FCFによりこの障害の影響を最小化するこ

とを目的としています。

図 7-1はテストで疑似障害を発生させた箇所を示したものです。

図 7-1 障害の種類と障害箇所

以下の方法で疑似障害を発生させ、Read待ち状態のSQL実行について障害発生～エラー検知までの時間

がFCFで短縮されるかどうか確認します。

プロセスダウン障害:

27

Oracle RAC の主要プロセスを SIGKILL で強制終了させます。Oracle のインスタンスダウンを想定

しています。

プロセスストール障害:

WebLogic Server から送られる SQL が長時間ハングするように Oracle RAC のプロセスを選定し

SIGSTOP で強制終了させます。マシン障害や OS 障害に引き摺られて Oracle が正常に処理を実行

できなくなった状況を想定しています。

パブリックネットワーク障害:

Oracle RAC 3ノードから 1ノードのみパブリックネットワークを物理的に切断します。マシン障害

やネットワーク障害を想定しています。

インターコネクト障害:

Oracle RAC 3ノードから 1ノードのみインターコネクトを物理的に切断します。マシン障害やネッ

トワーク障害を想定しています。

WebLogic Server 側全ネットワーク障害:

WebLogic Server から Oracle RAC ノードへのネットワークを物理的に切断します。マシン障害やネ

ットワーク障害を想定しています。

テスト結果

表 2 は、テストを実施した障害の種類と、各障害でRead待ちのリクエストが停止していた時間を示し

たものです。FCFなしの場合と、FCFありの場合について、障害の発生からアプリケーションにエラーが

返されるまでの時間を比較しています。

表 2 障害の種類とエラー検知までの時間

FCFなし FCFあり

バックグラウンド

プロセスダウン 即時 即時

バックグラウンド

プロセスストール 6分20秒 6分10秒

パブリック

ネットワーク障害

9分30秒

TCP keep-aliveタイムアウト

15秒

生存ノードからのFAN

インターコネクト障害

（3ノード Oracle RAC）

5分

TCP keep-aliveプローブ1回目送出

33秒

全ノードからのFAN

WebLogic Server側

ネットワーク全損

9分30秒

TCP keep-aliveタイムアウト

9分30秒

TCP keep-aliveタイムアウト

TCP keep-alive タイムアウトはデフォルトの 2 時間から変更しテスト用の 9 分 30 秒を設定しています。

28

結果は以下となります。パブリックネットワーク障害とインターコネクト障害について、アプリケーシ

ョンにエラーが返るまでの時間を短縮することができ、この2つの障害について、FCFの効果が得られた

と言えます。

パブリックネットワーク障害:

パブリックネットワークに障害が発生すると VIP のフェイルオーバーが発生し、DB01 のサービス

がダウンします。生存ノードのパブリックネットワークを通じて、DB01 のサービスがダウンした

ことが通知されます。

インターコネクト障害:

インターコネクトを使用している Oracle RAC のハートビート機能により、ノード間通信ができな

い DB01が Oracle RACから排除されます。パブリックネットワークを通じて DB01がノードダウン

したことが通知されます。

FCFでアプリケーションの停止時間の短縮ができない障害の種類は以下となります。

WebLogic Server 側ネットワーク全損:

パブリックネットワークが全てダウンしており、Oracle RACから WebLogic Server に FAN イベント

を通知できるネットワークの経路が無いため、FCFで早期のエラー検知はできません。

プロセスストール障害:

今回実施したケースでは Oracle RAC 側でのストール検知に時間がかかり、FAN イベントが送信さ

れないため、FCFではアプリケーションが早期にエラーを検知することができません。

NEC ではこのような検出が困難なプロセスストール障害に対して、クラスタリングソフトウェア

製品である CLUSTERPRO MC ApplicationMonitor を用いたソリューションを提供しています。

NEC CLUSTERPRO MC ApplicationMonitorを用いたプロセスストール対策

CLUSTERPRO MC ApplicationMonitorの機能を使用すると、SQLがハングしたRACノードを強制終了させ

ることでFANイベントを飛ばし、アプリケーションでエラーを早期に検知することが可能となります。

CLUSTERPRO MC（HAシリーズ）の詳細は、以下のWebサイトをご確認ください。

http://www.nec.co.jp/pfsoft/clusterpro/mc_ha/index.html

フェイルバックの動作について

図 7-2はフェイルオーバー、フェイルバック、およびその後の物理接続の本数を示しています。フェイ

ルバック後、物理接続の本数はリバランス・プロセスにより各ノードに対し均等になります。2ノードの

Oracle RACの構成で、各Oracle RACノードに10本ずつの物理接続が作成されるようにしています。

29

図 7-2 フェイルオーバー～フェイルバック後の物理接続の本数

フェイルバックされる接続の本数は接続プールの容量の設定や、接続の使用状況などで変化します。接

続の使用状況によっては、フェイルバックの時点では各ノードへの物理接続が均等ではない可能性があ

りますが、その後のリバランス・プロセスにより物理接続がバランシングされることによって、物理接

続を均等にすることができます。それぞれの動作の詳細は以下となります。

フェイルオーバー発生（18:19:40頃）

Oracle RACから FANによる DOWNイベントを受け取り、WebLogic Server は障害ノード（DB01）

への物理接続を全てクローズします。

フェイルバック発生（18:23:10頃）

WebLogic Server は Oracle RACから FANによる UPイベントを受け取り、復帰ノード（DB01）への

物理接続を作成します。このとき作成される物理接続の本数は、接続の使用状況により変化します。

リバランス・プロセス

フェイルバック時には物理接続に偏りが発生していましたが、それ以降のリバランス・プロセスに

より、各 Oracle RACノードへの接続本数が 10本ずつになります。

■:DB01 ■:DB02

30

8. 動的なOracle RACノード追加による性能改善

FCFには障害検知だけでなく、Oracle RACの構成変更の通知という機能もあり、稼働中のシステムに対し

動的にOracle RACノードを追加・削除することが可能です。Oracle RACは構成変更時にFCFによる通知を

行い、WLSがOracle RACの構成変更を認識できます。これによりWebLogic ServerはOracle RACノードへの

接続を自動的に追加・削除できます。

テスト内容

CPUが高負荷になっているシステムに対し、動的にOracle RACノードを追加してリソースを増強し、性

能が改善することを確認します。

図 8-1は本テストの構成を示しています。まず3ノードのOracle RAC構成で各ノードのCPU使用率が約80%

になるようにWebLogic Serverから負荷をかけます。負荷をかけたまま、途中でDB04ノードをクラスタに

追加します。Oracle RACへの接続にはSCANを利用しているため、WebLogic ServerからはDB04の追加前と

同じ設定のままDB04にアクセスすることが可能です。

WebLogic ServerはFCFによりDB04が追加されたという通知を受け取り、DB04への物理接続を作成しま

す。物理接続作成後、リクエストはRCLBにより4ノードに分散されます。

図 8-1 Oracle RACノードを動的に追加するテストの構成

テスト結果

図 8-2はレスポンスタイム、CPU使用率、各Oracle RACノードへの振り分けの割合を示したものです。最

初、Oracle RAC 3ノード構成で負荷をかけていた場合の平均レスポンスタイムは170ms前後ですが、DB04

ノードを追加し、Oracle RAC 4ノード構成にすると負荷が分散され、レスポンスタイムが120ms前後にま

で改善されます。

31

また、振り分けの割合について着目すると、後から追加したDB04への振り分けの割合は他のノードと同

程度となるように推移しており、ノード追加後も上手く負荷がバランシングされている事が確認できま

す。

図 8-2 Oracle RACノードを動的に追加した時の結果

レスポンスタイム（ALLが全ノードの平均）

CPU使用率（Averageが稼働中の全ノードの平均）

振り分けの割合

■:DB01 ■:DB02 ■:DB03 ■:DB04

32

9. まとめ

本検証により、Oracle WebLogic Server 12cとOracle Real Application Cluster 11gR2の連携ソリューションであ

るGridLinkデータソースの有効性を示しました。

本検証では様々なユースケースを想定してGridLinkデータソースの各機能を確認しました。具体的には

GridLinkデータソースで以下が実現できます。

高性能:

RCLB により特定ノードへの負荷の集中はバランシングされ、局所的な高負荷が発生した場合でも

レスポンスタイムの悪化を防ぐことができます。また Web セッション・アフィニティによりキャ

ッシュミスが削減されることで、キャッシュ・フュージョンの発生が抑制されレスポンスタイムが

改善されます。これらの機能により、安定したサービスが提供できます。

可用性:

従来タイムアウトを待つしかなかった、リクエストが Read 待ちの状態での Oracle RAC ノードの障

害でも、アプリケーションに早期にエラーを返すことができます。障害検知までの時間が短くなり

システム利用者に早期に応答を返すことができます。

拡張性・柔軟性:

FCF によるトポロジ変更の通知を利用すると、稼働中のシステムに対し Oracle RAC ノードを動的

に追加・削除が可能となります。また WebLogic Server の DB 接続先設定に SCAN を利用している

ため、Oracle RAC ノードの追加・削除などの構成変更があった際にも WebLogic Server のデータソ

ース設定を変更する必要はありません。

これは運用面において優れた特長であり、NEC のマルチ・データソースの運用ノウハウと組み合

わせることで、複雑なオペレーションが必要となる Oracle RAC の構成変更などの要件を、より短

期で実現可能になります。

WebLogic Server と Oracle RACの緊密な連携

GridLink データソースを利用することにより、従来アプリケーションの作り込みや複雑な運用

で達成していた高度な動作を、製品機能として容易に実現することができます。

NECの強力なインテグレーション技術

本検証で実施したテストや環境は WebLogic Server および Oracle RACの NECノウハウを活用し

て策定しており、短納期で多くの優位点と一部の課題を見出すことができました。WebLogic

Server と Oracle RAC 双方の連携を考慮した NEC ノウハウにより安心安全なシステムを構築す

ることができます。

NECのシステム構築ノウハウの活用

GridLink データソースは新機能ですが、検証を通じて NEC の持つ従来のデータソースのノウ

ハウの多くを活用できることが分かっています。これらのノウハウと製品の高可用性・高運用

性を組み合わせることで、より大きな付加価値のあるシステムを短期間で実現可能です。

システムソフトウェア事業部

東京都港区芝5-7-1

NEC本社ビル

Copyright © 2013 NEC Corporation. All Rights Reserved.

本書の内容の一部または全部を無断で転載および複写することは禁止されています。

本書の内容は将来予告なしに変更することがあります。

日本電気株式会社は、本書の技術的もしくは編集上の間違い、欠落について、一切責任を負いません。

日本電気株式会社は、本書の内容に関し、その正確性、有用性、確実性その他いかなる保証もいたしません。

CLUSTERPROおよび iStorageは日本電気株式会社の商標および登録商標です。

Linuxは、Linus Torvalds氏の日本およびその他の国における商標または登録商標です。

Red HatおよびShadowman logoは、米国およびその他の国におけるRed Hat,Inc.の商標または登録商標です。

Intel、インテルおよびXeonは、米国およびその他の国におけるインテルコーポレーションおよび子会社の商標または登録商標です。

本書に記載のシステム名、会社名、製品名は、各社の登録商標もしくは商標です。

2013年6月

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

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の登録商標です。0113