Oracle Event Processing - Exalogicにおけるパフォーマンスの調査

Oracle Event Processing

Exalogicにおけるパフォーマンス

の調査

Oracleホワイト・ペーパー

2011年9月

Oracle Event Processing Exalogicにおけるパフォーマンスの調査

2


Exalogicにおけるパフォーマンスの

調査

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

Oracle Event Processingのアーキテクチャ ....................................................................... 4

サーバーのアーキテクチャ ................................................................................................. 4

リアルタイム・イベント処理のインフラストラクチャ ..................................................... 6

JRockit JVM ........................................................................................................................ 7

ベンチマーク・アプリケーション ...................................................................................... 7

ベンチマークの構成とデータの収集方法 ......................................................................... 10

負荷の挿入 ................................................................................................................... 10

OEPサーバーの構成 .................................................................................................... 10

データの収集方法 ......................................................................................................... 11

ベンチマーク結果 ......................................................................................................... 11

結論 ................................................................................................................................... 15


3


Exalogicにおけるパフォーマンスの

調査

はじめに

Oracle Event Processing（OEP）は、イベント駆動型アーキテクチャに基づいたアプリケーションを

構築するためのモジュール・プラットフォームを提供します。そのOEPプラットフォームの中心と

なっているのが、Oracle Continuous Query Language（Oracle CQL）です。Oracle CQLはSQLに似た宣

言的な言語で、この言語を使用すると、アプリケーションからデータ・ストリームに対してフィル

タ､問合せ、パターン照合の各処理を実行できます。開発者は、Oracle CQLを軽量のJavaプログラミ

ング・モデルと組み合わせて使用し、アプリケーションを記述します。他のプラットフォーム・モ

ジュールとしては、機能豊富なIDE、管理コンソール､クラスタリング、分散キャッシュ、イベント・

リポジトリ、監視などがあります。

イベント駆動型アーキテクチャと複合イベント処理は、すでにエンタープライズ・コンピューティ

ング環境の大きな特徴となっているため、さらに多くの企業がOEPテクノロジーを使用してミッ

ション・クリティカルなアプリケーションの構築を開始しています。現在、ミッション・クリティ

カルなOEPアプリケーションは、さまざまな業界で見られます。たとえば、OEPテクノロジーは、

電力業界では電力需要の変化に瞬時に対応した電力設備の効率最適化のために使用されています。

また、クレジットカード業界では、不正取引をその発生時にリアルタイムで検出するために使用さ

れています。さらに、証券取引市場では、オーダー・ルーティングやアルゴリズム取引などのアプ

リケーションで使用されています。ミッション・クリティカルなOEPアプリケーションの数は、増

加し続けています。

Oracle Exalogic Elastic Cloudは、エンタープライズ・アプリケーション向けの完全なハードウェアお

よびソフトウェア・プラットフォームであり、設計・統合・テスト・最適化が行われた状態として、

計算ノード、ストレージ、ネットワーク、オペレーティング・システム、ソフトウェア製品の最善

の組合せを構成したものとして提供されています。Exalogicは、極めて高い信頼性、スケーラビリティ、

パフォーマンスを提供しながら、数千に及ぶ既存のアプリケーションをサポートするオープンな標

準ベースのプラットフォームの利点を維持できるように設計されています。

このホワイト・ペーパーに記載されているベンチマーク調査では、証券取引市場の金融フロント・

オフィス・アプリケーションにおける典型的なユースケースを取り上げ、単一のExalogic計算ノード

上で非常に高いスループットと短い待機時間の両方を実現するOEPの能力を実証します。ベンチ

マーク・アプリケーションは、市場データの複数の受信ストリームを監視するシグナル生成シナリ

オを実装し、何らかのアクションをトリガーする特定条件の発生を監視します。

このアプリケーションの場合、OEPは、単一のExalogic計算ノードで最大100万イベント/秒の挿入速

度に対応しつつ、短い平均待機時間と最大待機時間を維持することに成功しています。100万イベン

ト/秒の挿入速度でのサーバーにおける完全処理パスの平均イベント待機時間は32マイクロ秒であ

り、イベントの99.99%が2ミリ秒未満で処理されています。


4

その他、このホワイト・ペーパーでは、こうしたパフォーマンス水準を実現する製品機能に加え、

ベンチマークとその結果について詳しく説明します。

Oracle Event Processingのアーキテクチャ

基本的に、Oracle Event Processingは、Open Services Gateway initiative（OSGi™）をベースとした軽量

のモジュール・アーキテクチャを使用して実装されるJavaコンテナです。OEPは、複合イベント処

理エンジン（CEPエンジン）とContinuous Query Language（CQL）を提供するとともに、機能豊富な

開発プラットフォームと高性能ランタイムも提供します。

サーバーのアーキテクチャ

図1は、OEPサーバー・インスタンスのソフトウェア・アーキテクチャの概略を示しています。最下

位レベルには、Java仮想マシン（JVM）があります。このベンチマークでは、JVMとしてJRockit JVM

を使用しました。このJVMは、確定的ガベージ・コレクション機能（ガベージ・コレクションの休

止時間を短くするように制限）を備えており、最短の待機時間と最高の確定性を必要とするアプリ

ケーション向けに設計されています。

図1： OEPのソフトウェア・スタック

OEPアプリケーション

OEPサーバー・モジュール

JRockit / HotSpot


5

1つ上のレイヤーは、モジュール・フレームワーク（OSGiフレームワーク）で構成されています。

このフレームワークは、モジュール間におけるJavaパッケージの可視性を制御し、クラスのクラス・

ロードとバージョニングを管理します。サービス・フレームワークは、Spring Dynamic Modulesに基

づいており、サービスのインスタンス化と依存性の解決を管理します。サービス・フレームワーク

は、依存性注入（DI）を使用して、構成データおよび他の必要なサービスへの参照をサービス・イ

ンスタンスに提供します。

サーバー・モジュール・レイヤーは、OEPサーバーの中核機能を提供するOSGiベースのモジュール

のコレクション（OSGiの用語では"バンドル"）として実装されます。このレイヤーで実装されるモ

ジュールの例としては、CQLエンジン（CQL言語で記述された問合せをストリーミング・データに

対して実行）、サーバーの構成と管理、セキュリティ、ロギング、入力および出力データの転送と

マーシャリング/アンマーシャリングに対応するアダプタのコア・セットなどがあります。最上位に

あるアプリケーション・レイヤーは、OEPアプリケーションで構成されています。アプリケーショ

ン自体は、OSGiベースのモジュールとしてパッケージ化されています。サーバー・モジュール・レ

イヤーとアプリケーション・レイヤー内のアーキテクチャは統一されており、サーバー・モジュー

ルとアプリケーション・モジュールは同様にパッケージ化され、アーキテクチャの下位にあるレイ

ヤー（OSGiフレームワークとSpring DMサービス・フレームワーク）からは同じように扱われます。

図2： OEPサーバーの通常のデータ・フロー

図2は、OEPアプリケーションの通常のデータ・フローを示しています。インバウンド（左）側は、

1つまたは複数のイベント・ソースからのイベント・データ・ストリームを示します。受信データは、

受信後アンマーシャル化されて、アダプタ・モジュール内のイベントの内部表現に変換されます。

アダプタによりイベント・オブジェクトが作成されると、アダプタでリスナーとして登録されてい

るすべての下流コンポーネントにイベント・オブジェクトが送信されます。図2では、リスナー・コ

ンポーネントは"チャネル"コンポーネントとなっています。チャネル・コンポーネントとは、基本

的には、上流と下流のコンポーネントの相互の非同期操作を可能にする関連スレッド・プールを持っ

たキューのことです。チャネルは、同時実行性に限界があるアプリケーション（たとえば、単独接

続によるデータ・フィード）の同時実行性を向上させる場合に大いに役立ちます。図2のデータ・フ

ローで示されているもう1つのコンポーネントは、プロセッサ・コンポーネントです。

OEPサーバー


6

プロセッサは複合イベント処理エンジンのインスタンスを表し、Continuous Query Language（CQL）

で記述された問合せをホストします。CQL問合せは、イベント・ストリームおよび他のデータ・ソー

スのフィルタリング、集計、パターン照合、結合をサポートしています。設定されたCQL問合せの

出力は、任意の下流リスナーに送信されます。この例では、POJOがプロセッサ出力をリスニングす

るよう設定されています。POJOは、問合せにより出力されたイベントを追加処理し、アクションの

トリガーや、標準または独自のメッセージング・プロトコルを介して外部システムへの出力データ

の送信を行います。

相互接続されたアダプタ、チャネル、プロセッサ、POJOコンポーネントを総称して、イベント処理

ネットワーク（EPN）と呼びます。図2の例は一般的なトポロジを示していますが、任意の数のコン

ポーネントを任意の順序で相互接続して、任意のEPNグラフを作成できます。

リアルタイム・イベント処理のインフラストラクチャ

一般的なイベント駆動型アプリケーションの待機時間とスループットに関する厳しい要件を満たす

には、スレッド・スケジューリング、同期、およびI/Oに特化したサポートが必要です。OEPにより、

次のようなパフォーマンス関連の特殊機能が実装されます。

スレッド・スケジューリングは、待機時間に関するクリティカル・パスのブロッキングとコンテ

キスト切替えを最小限に抑えます。イベントは可能な限り、コンテキストの切替えなしで、同一

スレッド上の完全実行パスを経由して実行されます。これは短い待機時間の処理に最適なアプ

ローチで、順次処理が必要なアプリケーションでイベントを順次処理できます。ただし、スレッ

ド間でイベントを受け渡す方が適切な場合もあります。たとえば、単一の受信ネットワーク接続

からのデータを複数のスレッドで同時処理する場合が、これに該当します。ランタイムの柔軟な

スレッド・プールと受渡しメカニズムにより、総待機時間への影響を最小限に抑えて処理パスの

任意の場所に同時実行性を導入できます。

同期戦略により、高度に並列化されたワークロードを実行する場合に、待機時間発生のおもな原

因となるロック競合を最小限に抑えます。OEPリリース11.1.1.6の並列処理サポートでは、CQL

問合せでUNORDEREDまたはPARTITON_ORDERED制約の指定が可能になるなど、大幅な機能

強化が行われました。これにより、アプリケーションからCQLエンジンを構成して、イベント処

理の順序付けに関するアプリケーション要件を満たしながら並列度を最大化することが簡単に

できるようになりました。

オブジェクトの再利用や、CQL問合せ処理エンジンの保存時間枠の最適管理など、綿密なメモリ

管理を実施します。メモリの最適化により、割当て率とヒープ断片化の両方を削減してガベー

ジ・コレクタの休止時間を最小限に抑えられるようになったため、待機時間を短くすることが可

能となっています。

プラガブルなアダプタ・フレームワークを使用して、各種ネットワーク・プロトコル用の高性能

アダプタを作成できます。また、さまざまなマルチスレッディングとI/Oハンドラ・ディスパッ

チ・ポリシーをサポートしています。

Exalogicプラットフォームでは、多数のスレッドとスケーラブルなクラスタリングをサポートし

ているOEPの優れたスケーラビリティにより、Exalogicが提供する膨大な処理能力を完全に引き

出すことができます。また、OEPは、特にクラスタ構成およびOEPアプリケーションがOracle

CoherenceとWebLogic Serverと緊密に統合されているような一般的な状況では、Exalogicの内蔵

Infinibandサポートを直接活用できます。

JRockit JVMの使用については、次のセクションで説明します。


7

JRockit JVM

OEPはHotSpot JVMとJRockit JVMの両方で認定されていますが、このベンチマークでは待機時間を

最小化して最高レベルの確定性を実現するためにJRockitを使用しました。JRockitは、短い待機時間

と確定的ガベージ・コレクションを実現する拡張機能を備えたJVMです。一般的なスループット指

向のガベージ・コレクション・アルゴリズムでは、コレクション実行時にアプリケーションの全ス

レッドが停止します。そのため、環境によっては、"ガベージ・コレクションの休止時間"が非常に

長く（数秒以上に）なり、待機時間発生のおもな原因となる場合があります。JRockitの確定的ガベー

ジ・コレクタは、ガベージ・コレクションの休止時間を短縮し、予測可能性を高めるためのさまざ

まなアプローチを展開します。確定的ガベージ・コレクタは、アプリケーションの実行中にガベー

ジ・コレクションの大部分を処理し、重要な段階でのみ短時間休止します。さらに、JRockitコレク

タが、各休止時間を監視して、ガベージ・コレクションの所要時間がユーザーの指定した目標休止

時間を超過しないようにします。たとえば、ユーザーの指定した目標休止時間が10ミリ秒の場合、

確定的ガベージ・コレクタは各ガベージ・コレクションの休止時間を10ミリ秒以内に制限し、従来

のガベージ・コレクション・アルゴリズムよりも高い予測可能性を提供します。

ベンチマーク・アプリケーション

このベンチマーク調査で使用されるアプリケーションは、市場データの複数の受信ストリームを監

視する信号生成シナリオを実行し、何らかのアクションをトリガーする特定条件の発生を監視しま

す。これは、フロント・オフィスの取引環境ではごく一般的なシナリオです。図3は、イベント処理

ネットワーク（EPN）のコンポーネントを含む、ベンチマークの全体構造を示しています。


8

図3：ベンチマーク・アプリケーションの構造とEPN

受信データは負荷生成ツールを使用して生成されます。負荷生成ツールは、株式市場のシミュレー

ション・データを作成し、設定した計測速度で1つまたは複数のTCP接続を介してサーバーに送信し

ます。送信データの形式は、負荷生成ツールとアダプタの実装に固有の形式で、コンパクトに設計

されます。イベント・サーバー内では、アダプタがソケットから受信データを読み取り、アンマー

シャル化を実行し、各株式ティッカーにイベント・インスタンス（特定の規則に従うJavaオブジェ

クト）を作成して、プロセッサの入力チャネル経由でイベントをCQLプロセッサに転送します。CQL

プロセッサへのもう1つの入力は、ローカル・キャッシュ・インスタンス（Oracle Coherence）です。

このローカル・キャッシュは、入力された株式の中でCQLプロセッサによる監視が必要な特定銘柄

を表す株式記号の"ウォッチ・リスト"を保持しています。このベンチマーク構成では、負荷生成ツー

ルからの入力には合計で1470個の異なる株式記号が含まれ、キャッシュされたウォッチ・リストに

は300個の株式記号が含まれていました。CQLプロセッサは、図4に示す問合せを実行するように構

成されています。

OEPサーバー・インスタンス


9

図4： CQL問合せ

CQLエンジンによって実行される処理は、おもに2つの段階で構成されています。最初の段階では、

IDが"S"のビューによってCQLに実装された市場データの受信ストリーム（StockTickStream）を、

キャッシュからプルされた株式記号ウォッチ・リスト（SymbolsRelation）に追加し、ウォッチ・リ

ストの株式記号と一致した入力イベントのそれぞれに対応する出力イベントを生成します。その後、

この最初のフィルタリング段階からの出力を、IDが"perc"として登録された問合せによって実装され

たパターン照合段階に渡します。パターン照合の問合せは、特定銘柄の株価が直前価格から2%以上

上昇または下落したことを検出すると、出力イベントを生成します。パターン照合の問合せからの

出力は、EPN内の任意の下流リスナーに送信されます。この例では、下流リスナーは出力Bean（Java

POJO）から成っています。Java POJOは、受信した出力イベントに基づいて、ベンチマーク・アプ

リケーションの統計情報と待機時間データを集計します。


10

ここでは、ビューとそれに続く問合せの両方が、順序付け制約のPARTITION_ORDEREDを指定する

点に注意してください。この指定により、CQLエンジンに対して、イベントの到着順序（各イベン

トのタイムスタンプで示される）をパーティション内に保持する必要があることが指示されます。

この場合、パーティションは同じ株式記号を持つ一連のイベントから構成されます。この順序付け

制約を使用することで、CQLエンジンは、別のパーティションからのイベントを（順序に関係なく）

パラレル実行できるようになります。一般的に、異なるパーティション・キー（この事例では株式

記号）が多数ある場合は、結果としてCQLエンジン内での並列度が高くなります。このことは、後

で説明する結果からも明らかです。

ベンチマーク・アプリケーションの待機時間データは、図3に示すように、アダプタと出力Beanの取

得したタイムスタンプに基づいて計算されます。アダプタは、ソケットからのデータ読取り後、ア

ンマーシャル化前に初回タイムスタンプを取得します。初回タイムスタンプは、アダプタの作成す

る各イベントに挿入され、イベント・プロセッサ経由で渡されて、パターン照合の問合せにより生

成される出力イベントに挿入されます。出力Beanが出力イベントを受信すると、最終タイムスタン

プを取得して、アダプタの作成した初回タイムスタンプとの時間差からイベント処理の待機時間を

計算します。さらに、これらの待機時間を集計して、ベンチマーク・アプリケーションの実行時に

おける待機時間データの合計を算出します。

ベンチマークの構成とデータの収集方法

負荷の挿入

負荷生成ツールを構成して、OEPサーバーで開く接続数と、各接続のデータ送信速度を指定できる

ようにしました。ここでは、全接続の送信速度を合計した値を、"総挿入速度"と呼ぶことにします。

このベンチマークでは、負荷生成ツールが各イベントに送信するデータは、株式記号、シミュレー

ション価格、タイムスタンプから構成されています。送信データの平均サイズは1イベントあたり20

バイト（TCP/IPヘッダーを除く）です。株式記号は、1470個の異なる株式記号のリストを繰り返し

使用して作成されます。負荷生成ツールが複数の接続を開くように設定されると、株式記号リスト

は接続ごとに均等にパーティション化されます。価格データが動的に生成され、株式記号が送信さ

れるたびに価格が更新されます。

OEPサーバーの構成

このベンチマーク用のOEPサーバー構成は、単一のExalogic計算ノードを共有する2つのOEPサー

バー・インスタンス（2つのJVM）のクラスタから成ります。単一のExalogic計算ノードには、2.93GHz

で動作する6コアのインテルXeonプロセッサが2基搭載されています（合計で12コア、X2-2モデルの

場合）。なお、フルラックのExalogicには30個の計算ノードが含まれるため、このベンチマークでは

フルラックのExalogicで利用できる計算リソース全体の1/30だけを消費している点に注意してくだ

さい。

Exalogic計算ノードではNUMAメモリ・アーキテクチャを採用しているため、2基あるプロセッサの

それぞれに関連付けられている"ローカル"メモリのプールには、"リモート"メモリと比べて短い待

機時間でアクセできます。また、2つのOEPサーバー・インスタンスの使用の場合、Linuxのnumactl

コマンドを利用して、各インスタンスを2基あるプロセッサの1つとそれに関連付けられているロー

カル・メモリのプールにバインドできます。これは、NUMAアーキテクチャでJVMを実行する場合

に、メモリのパフォーマンスを最適化するためのベスト・プラクティスです。


11

アプリケーションをクラスタ配置にしたため、結果として、前述のEPNと問合せを含むアプリケー

ションの同じコピーが、それぞれのOEPサーバー・インスタンスで実行されました。負荷生成ツー

ルは別のマシンで実行され、株式記号に基づいてパーティション化された入力データを2つのOEP

サーバー・インスタンスに提供しました。OEPアプリケーションの入力アダプタは、1接続あたり1

スレッドのブロッキング・モデルを使用して受信データの読取りおよびサーバー内のイベントの

ディスパッチを実行するように構成しました。この結果、負荷生成ツールによって開かれた接続ご

とに、サーバー内で1つの処理スレッドがアクティブになりました。

データの収集方法

ベンチマーク・データの収集方法は、次のとおりです。

負荷生成ツールで、それぞれのOEPサーバー・インスタンスに対して接続を2つずつ開き、デー

タを1接続につき5万イベント/秒で送信して15分間の初期ウォームアップを実行します。

初期ウォームアップの完了後は、負荷生成ツールで、各サーバー・インスタンスへの接続数を1

～10の範囲で増加させながら、データをそれぞれの接続につき5万イベント/秒で送信する処理を

10回実行します。達成可能な最大挿入速度は、100万イベント/秒です（1つのインスタンスあた

り50万イベント/秒）。各実行時間は10分間です。

それぞれのOEPサーバー・インスタンスへの接続数を10に固定し、1接続あたりの挿入速度を5

千イベント～5万イベントの範囲で増加させながら、さらに10回実行します。達成可能な最大挿

入速度は、100万イベント/秒です（1つのインスタンスあたり50万イベント/秒）。各実行時間は

10分間です。

全実行での挿入速度、出力イベント速度、平均待機時間、待機時間の分布が収集されます。

ベンチマーク結果

表1と図5および図6は、各インスタンスへの接続数を1～10の範囲で増加させながら、1接続あたりの

挿入速度を5万イベント/秒にした場合の測定結果を示しています。平均および99.99パーセンタイル

の待機時間に関しては、2つのOEPサーバー・インスタンスに対して異なる値が報告されています。

すでに説明したように、待機時間の値は、条件に一致した場合に出力Beanに転送されるイベントに

対してのみ収集されます。また、これらの値は、アダプタの初回タイムスタンプ（アンマーシャル

化が実行され、内部イベント・オブジェクトが作成される前）からの待機時間、および出力Beanに

よってイベントが受信されたときのタイムスタンプを表しています。

表1を見ると、負荷増加時の出力イベント速度は一定で、挿入速度の5.2%となっています。平均待機

時間は、接続数と総挿入速度が増加するにつれわずかに増えています。10万イベント/秒から60万イ

ベント/秒への負荷増加時における99.99パーセンタイルの待機時間は200ミリ秒以下とほぼ一定で、

その後、総挿入速度が100万イベント/秒に近づくにつれ若干増加しています。このベンチマークの

最大負荷である100万イベント/秒においても、平均および99.99パーセンタイルの待機時間は引き続

きかなり低い値となっています。


12

表1： 1接続あたりの挿入速度を5万イベント/秒に固定して、1インスタンスあたりの接続数を1～10の範囲で増加させた場合

図5： 1インスタンスあたりの接続数を1～10の範囲で増加させた場合の平均待機時間（10万イベント/秒～100万イベント/秒）

OEPサーバー・インスタンスあたりの接続数


13

図6： 1インスタンスあたりの接続数を1～10の範囲で増加させた場合の99.99パーセンタイルの待機時間（10万イベント/秒～100万イベント/秒）

表2と図7および図8は、各インスタンスへの接続数を10に固定して、1接続あたりの挿入速度を増加

させた場合の測定結果を示しています。

表2：各インスタンスへの接続数を10に固定して、挿入速度を増加させた場合

OEPサーバー・インスタンスあたりの接続数


14

図7：各インスタンスへの接続数を10に固定した場合の平均待機時間

図8：各インスタンスへの接続数を10に固定した場合の99.99パーセンタイルの待機時間


15

それぞれのOEPサーバー・インスタンスへの接続数を10に固定した場合、負荷が増加しても平均待

機時間はほとんど一定でした。接続数を固定した状態で負荷を増加させた場合、負荷を増加させる

と99.99パーセンタイルの待機時間にわずかな増加がありました。データ速度が低い場合、このアプ

リケーションに一定の負荷をかけたときの待機時間は、接続数を減らして1接続あたりの挿入速度を

高くするほうが（接続数を増やして同じ速度を実現するよりも）わずかに短縮されました。

結論

このホワイト・ペーパーでは、OEPの全体のアーキテクチャと、Exalogicプラットフォームにおいて

イベント駆動型アプリケーションで高パフォーマンスを実現するための機能と設計特性について説

明しました。OEPのパフォーマンス特性は、ごく一般的なイベント処理のユースケースを使用して

調査しました。このアプリケーションでは、単一のExalogic計算ノード（フルラックExalogicの1/30）

によって、複合イベント処理で100万イベント/秒のスループットを達成すると同時に、非常に短く

予測可能な待機時間を維持することができました。この結果から、OEPがExalogic上で卓越したス

ループットと待機時間の大幅な短縮を実現し、企業におけるもっとも厳しいイベント処理要件に確

実に対応できることが実証されました。


Exalogicにおけるパフォーマンスの調査

2011年9月

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 © 2011, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載さ

れる内容は予告なく変更されることがあります。

本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に

対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル

社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとし

ます。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる

形式や手段によっても再作成または送信することはできません。Oracleは米国Oracle Corporationおよびその子会社、関連会社の

登録商標です。その他の名称はそれぞれの会社の商標です。

0109

Oracle Event Processing - Exalogicにおけるパフォーマンスの調査

Documents