OEP製品技術資料 - CQL

<Insert Picture Here>

Oracle Complex Event Processing 11g

プログラミングモデルにおけるCQL

日本オラクル株式会社Fusion Middleware 事業統括本部


Agenda

• CQLの重要性

• CQLのコンセプト

•基本パターン

Copyright© 2012, Oracle. All rights reserved.

CQLの重要性

• 標準化• 行ベースのパターンマッチング仕様は既に公開されている

• ANSIへ標準化としての申請中

• 形式的な(そして完全な)モデルを開発

• リレーショナルモデルにおける厳格さをイベントストリームの処理へ拡張


へ拡張

• より幅広いアプリケーションでのより強いインプリメンテーションの結果

オラクルとCQLの歴史

• ”連続的な”問い合わせ言語を完成させるためのイニシアティブ

• SQL 99仕様における “継続的な”問い合わせの拡張として開始される• スタンフォード大学での研究がベース

• 業界標準としてのディスカッション


• 業界標準としてのディスカッション• Event Processing Technical Society (EPTS)

• ANSI SQL

• OMG

• 現在の採用状況• CQL パターンマッチングとして ANSI SQL 標準化への提案

• Oracle, IBM, スタンフォード大学

• OpenSourceにおけるCQLの採用

• Oracle Complex Event Processor (CEP) のリリース

CEP で使用されている言語

inference

rules

ECA

State-oriented

SQL-idioms

TIBCO

Streambase

Oracle CEP

Oracle CEP


Script-oriented

Agent-oriented

Apama

RuleCore

AgentLogic

IBM (AptSoft)

Source: EPTS/DEBS Tutorial 2009


Agenda

• CQLの重要性


•基本パターン

• 集約やパターンマッチング


CQLのコンセプト

• “連続的な”問い合わせをサポートするリレーショナルモデルの拡張• 時間、ストリームとリレーション時間、ストリームとリレーション時間、ストリームとリレーション時間、ストリームとリレーションを記述する形式的なモデル

• イベントストリームに対する”ウィンドウ”の定義が可能• 時間やカウントでの制限 (APIで拡張可能)

• 値ベースのパーティション化


• 値ベースのパーティション化

• バッチもしくは増分処理

• 問い合わせを適用する”ワーキングセット”の定義• イベントのフィルタリング、集約、相関

• パターンマッチングの追加• トラック/トレースシナリオのサポート(例:消失イベント検出)

• 無制限のデータ・カートリッジによるドメイン固有の拡張性

ストリームからリレーションへの演算子

SELECT *

FROM stream [NOW]

WHERE attribute = ‘value’

STREAM 演算子

WINDOW 演算子

Copyright© 2012, Oracle. All rights reserved. 8

WHERE attribute = ‘value’

CQL – ストリームとリレーション

• リレーションからリレーションへの演算子:

• これらの演算子は、入力として1以上のリレーションを取得し(特定の演算子によると)、出力としてリレーションを生成する

• 例：Join, Select(フィルタ)

• ストリームからリレーションへの演算子:

• これらの演算子は入力としてストリームを取得し、出力としてリレーションを生成する

• CQLは6つのウィンドウをサポート:


• CQLは6つのウィンドウをサポート:

• Time, Row, Partition, Predicate, Extensible や Landmark

• リレーションからストリームへの演算子:

• これらの演算子は入力としてリレーションを取得し、出力としてストリームを生成する

• CQLは3つのリレーションからストリームへの演算子をサポート:

• 挿入ストリーム (IStream),

• 削除ストリーム (DStream),

• リレーションストリーム (RStream).

演算子

ISTREAM | DSTREAM | RSTREAM

(

SELECT acct, sum(amt) AS total

FROM Transactions

[PARTITION BY acct ROWS 5 RANGE 5]

GROUP BY acct

)

ストリーム To リレーション演算子

リレーション To ストリーム演算子


timestamp acct amt

1 100 1.25

2 200 2.50

3 300 6.75

トランザクションとしてのストリーム

timestamp -> schema (acct, amt)

トランザクションをサマリーしたストリーム

timestamp-> schema (acct, total)

タイムスタンプは、システムもしくはアプリケーションで定義される

“時間によって変化する”リレーション

時間ベースとタプルベースのウィンドウ比較

E1 E2 E3 E4


Event1から Event4は、 time1 と time7 の間で発生します

t1 t3t2 t4 t6t5 t7 時間

一定の時間間隔


E1 E2 E3 E4

時間ベースのウィンドウ



• 一定の時間間隔

• リレーション内のイベント数は変化

• イベントは時間が経つとリレーションから外れる

ストリームからリレーションの演算子

CQL: SELECT * FROM MyEvent [RANGE 3 SECONDS]


E1 E2 E3 E4










E1 E2 E3 E4










E1 E2 E3 E4










E1 E2 E3 E4

タプルベースのウィンドウ一定のイベント数



• リレーション内のイベント数は一定

• イベントはリレーションから置き換わるまで失効しない

CQL: SELECT * FROM MyEvent [ROWS 2]

ストリームからリレーションへの演算子


E1 E2 E3 E4

タプルベースのウィンドウ一定のイベント数


t1 t3t2 t4 t6t5 t7




時間

一定のイベント数


E1 E2 E3 E4

タプルベースのウィンドウ


t1 t3t2 t4 t6t5 t7




時間

増分とバッチのウィンドウ比較

• イベントは継続的にウィンドウに入り、出る

• イベントは増分もしくはバッチで処理されるN

• 増分• 問い合わせはそれぞれの変化毎に評価される

• バッチ


• 問い合わせは定義した変更数が発生した時にだけ評価される

• 増分処理はCQLのデフォルト処理

スライディングとバッチのウィンドウ比較

入力入力入力入力出力出力出力出力

Prices1 Sum1

Prices2

Prices3

Prices4


Prices1

Prices2

Prices3

Prices4

3イベントの集計を計算

増分ウィンドウバッチウィンドウ


Prices4

Prices5

Prices6

Prices7

Prices4

Prices5

Prices6

Prices7

SELECT SUM(price)

FROM Prices [ROWS 3]

SELECT SUM(price)

FROM Prices [ROWS 3 SLIDE 3]CQL



Prices1 Sum1

Prices2 Sum1+2

Prices3

Prices4


Prices1

Prices2

Prices3

Prices4




Prices4

Prices5

Prices6

Prices7

Prices4

Prices5

Prices6

Prices7

SELECT SUM(price)


SELECT SUM(price)




Prices1 Sum1

Prices2 Sum1+2

Prices3 Sum1+2+3

Prices4


Prices1

Prices2

Prices3 Sum1+2+3

Prices4




Prices4

Prices5

Prices6

Prices7

Prices4

Prices5

Prices6

Prices7

SELECT SUM(price)


SELECT SUM(price)




Prices1 Sum1

Prices2 Sum1+2

Prices3 Sum1+2+3

Prices4 Sum2+3+4


Prices1

Prices2

Prices3 Sum1+2+3

Prices4




Prices4 Sum2+3+4

Prices5

Prices6

Prices7

Prices4

Prices5

Prices6

Prices7

SELECT SUM(price)


SELECT SUM(price)




Prices1 Sum1

Prices2 Sum1+2

Prices3 Sum1+2+3

Prices4 Sum2+3+4


Prices1

Prices2

Prices3 Sum1+2+3

Prices4




Prices4 Sum2+3+4

Prices5 Sum3+4+5

Prices6

Prices7

Prices4

Prices5

Prices6

Prices7

SELECT SUM(price)


SELECT SUM(price)




Prices1 Sum1

Prices2 Sum1+2

Prices3 Sum1+2+3

Prices4 Sum2+3+4


Prices1

Prices2

Prices3 Sum1+2+3

Prices4




Prices4 Sum2+3+4

Prices5 Sum3+4+5

Prices6 Sum4+5+6

Prices7

Prices4

Prices5

Prices6 Sum4+5+6

Prices7

SELECT SUM(price)


SELECT SUM(price)




Prices1 Sum1

Prices2 Sum1+2

Prices3 Sum1+2+3

Prices4 Sum2+3+4


Prices1

Prices2

Prices3 Sum1+2+3

Prices4




Prices4 Sum2+3+4

Prices5 Sum3+4+5

Prices6 Sum4+5+6

Prices7 Sum5+6+7

Prices4

Prices5

Prices6 Sum4+5+6

Prices7

SELECT SUM(price)


SELECT SUM(price)



Agenda

• CQLの重要性


•一般的なパターン


1. イベント・フィルタリング

• 課題:

• ストリーム上の特定のデータを探し、不要なデータをなくす

• シナリオ:

• STOCKSTREAMを株式イベント(symbol,lastBid,last,Ask)のストリームとみなす


リームとみなす

• 全ての株式から株式表示記号が’AAA’のものを探す


時間入力出力

1 {“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}


1

2

3

{“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}


• 解答:

SELECT *

FROM stockstream [NOW]

WHERE symbol = ‘AAA’

STREAM ソースの指定

WINDOW 演算子の指定


フィルタリングの述語を定義


• なぜウィンドウ演算子 [NOW]が必要なのか？

• フィルタリングはリレーションで機能するので、株式のストリームをリレーションに変換する必要がある

• いくつかのケースでは省略することも可能です

• 例：いくつかのクエリーではストリームで実行可能


• 例：いくつかのクエリーではストリームで実行可能

• SELECT * FROM stockstream

2. 新しいイベントの検出

• 課題:

• ストリーム上の特定のデータを探し、新しいデータである場合に通知する

• シナリオ:

• 価格が変更された最後の株式イベントだけをレポートする


• 価格が変更された最後の株式イベントだけをレポートする


時間入力出力

1 {“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}


1

2

3

{“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}

{“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5} {“BBB”, 11.0, 12.5}


• SELECT * FROM stockstream [NOW]

• 生成されるのはリレーション？ストリーム？

• リレーション（時間 t にすべてのイベントを含む）を生成

• 時間tに存在し、時間( t - 1 )には存在しないイベント

• リレーションからストリームへの演算子ISTREAM(挿入ストリーム)

を使用


を使用

• 最後のイベントについて調べたいので、[NOW]の代わりにウィンドウ演算子[ROWS 1]を使用


• 回答：

ISTREAM(

SELECT *

FROM stockstream [ROWS 1]

)


)

3. イベント・パーティショニング

• 2の回答における課題

時間入力出力

t=2のイベントと同じように見えるが、 t=3のイベントによって”!=”となっている


1

2

3

4

{“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}

{“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}

{“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}


• 株式表示記号によってウィンドウを分割する必要がある

ISTREAM (

SELECT *

FROM stockstream

[PARTITION BY symbol ROWS 1]



)


時間入力出力

1 {“AAA”, 10.0, 10.5} {“AAA”, 10.0, 10.5}


1

2

3

4

{“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}

{“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}

4. 古いイベントの検出

• 課題:

• ストリーム上から特定のデータを探し、もしそれが削除されたら通知する

• シナリオ:

• 株式表示記号毎の株価が古くなったらレポートする


• 株式表示記号毎の株価が古くなったらレポートする


時間入力出力

1 {“AAA”, 10.0, 10.5}


2

3

4

{“AAA”, 11.0, 12.5} {“AAA”, 10.0, 10.5}

{“BBB”, 11.0, 12.5}

{“BBB”, 10.0, 10.5} {“BBB”, 11.0, 12.5}


• 削除されたイベント、すなわち、時間( t - 1 ) に存在し時間t に存在しないイベントだけを含むストリームが必要

• リレーションからストリームへの演算子:DSTREAM(削除ストリーム)を使用

DSTREAM (

SELECT *


SELECT *

FROM stockstream


)

5. イベントの拡充

• 課題:

• リレーションからの静的なデータで、ストリームからのイベントを拡充する.

• シナリオ:


• STOCKRELATION (リレーション)を次とみなす:

symbol,

company full-name,

headquarters' location

• lastBidが5.0より大きいSTOCKSTREAMからの株式のイベントごとに、その会社の場所を見つける


株式表示記号正式名称所在地

AAA The AAA company San Francisco

BBB The BBB company San Jose

STOCKRELATION

クエリーは、リレーションではなく、ストリームによって引き起こされる


時間入力 (STOCKSTREAM) 出力 (QUERY)

1

2

3

{“AAA”, 10.0, 10.5} {“AAA”, “San Francisco”}

{“BBB”, 11.0, 12.5} {“BBB”, “San Jose”}

{“AAA”, 4.0, 4.5}


• 解答:

SELECT event.symbol, location

FROM stockstream [NOW] AS event,

stockrelation AS data

WHERE event.symbol = data.symbol AND

event.lastBid > 5.0


event.lastBid > 5.0

� なぜリレーションではなく、ストリームにウィンドウ演算子を指定したのでしょう？

� リレーションは瞬間的なので、既に時間t に固定されている

6. イベントの集約とグルーピング

•ユースケース:•株式表示記号毎の最新2ティックにおける価格の移動平均を計算•数量が1000を超える価格だけを含む

CQL


REGISTER VIEW StockTickMinVolumeView (symbol char(10), volume integer, price float) AS

SELECT symbol, volume, price FROM CqlxStockTick WHERE volume > 1000

CREATE QUERY MovingAvg AS

SELECT symbol, AVG(price) as average

FROM StockTickMinVolumeView [PARTITION BY symbol ROWS 2]

GROUP BY symbol

ウィンドウの前にフィルタリングCQL –ビューを使用する


Input (StockTick) Output (MovingAvg)

symbol price volume symbol average






GROUP BY symbol



GOOG 500.0 4200 GOOG 500.0

ORCL 25.0 2000

ORCL 27.0 500

GOOG 520.0 5000

ORCL 23.0 1500









GROUP BY symbol



GOOG 500.0 4200

ORCL 25.0 2000 ORCL 25.0

ORCL 27.0 500

GOOG 520.0 5000

ORCL 23.0 1500









GROUP BY symbol



GOOG 500.0 4200

ORCL 25.0 2000

ORCL 27.0 500

GOOG 520.0 5000

ORCL 23.0 1500









GROUP BY symbol



GOOG 500.0 4200

ORCL 25.0 2000

ORCL 27.0 500

GOOG 520.0 5000 GOOG 510

ORCL 23.0 1500









GROUP BY symbol



GOOG 500.0 4200

ORCL 25.0 2000

ORCL 27.0 500

GOOG 520.0 5000

ORCL 23.0 1500 ORCL 24.0

7. イベントのバッチング

• 課題:• ストリームからのいくつかの(単純な)イベントを、１つの新しい（複雑な）イベントに集約するが、１度に１つのイベントを処理する代わりにバッチで処理する

• シナリオ:• 5秒ごとに、直近の10秒の株価（bidとask）の平均を出力


• 5秒ごとに、直近の10秒の株価（bidとask）の平均を出力


時間入力出力 (W/O BATCHING) 出力 (WITH BATCHING)

1s {“AAA”, 10.0, 12.0} {“AAA”, 10.0, 12.0}

AAAのイベントは、スライドウィンドウによって移動されているので、表示されない


4s

5s

9s

10s

{“AAA”, 12.0, 14.0}

{“AAA”, 11.0, 13.0}

{“BBB”, 4.0, 5.0}

{“BBB”, 4.0, 5.0}

{“AAA”, 11.0, 13.0}

{“AAA”, 11.0, 13.0}, {“BBB”, 4.0, 5.0}


• 解答:SELECT symbol, AVG(lastBid), AVG(lastAsk)

FROM stockstream [RANGE 10 seconds SLIDE 5 seconds]

GROUP BY symbol


� RANGE演算子にSLIDEを指定できる

� デフォルトでは、1のSLIDE.

8. イベントの相関

• 課題:• 値の共通集合上で、１つあるいはいくつかのストリームからイベントを相関させる(これは一般的なパターン)

• シナリオ:• それぞれbid(symbol, bidPrice, customer) と ask(symbol,

askPrice, customer) を含むようにBIDSTREAM と


askPrice, customer) を含むようにBIDSTREAM とASKSTREAMを検討する

• AskによるBidの相関は同じ表示記号に関連し、互いに10秒以内に起きている;古いものなら、失効するとみなす


時間入力(BIDS) 入力(ASKS) 出力

1s {“AAA”, 12.0, cust1} {“BBB”, 9.0, cust2}


5s

15s

20s

{“AAA”, 10.0, cust3} {“AAA”, 10.0, cust2}

{“AAA”, 10.0, cust3, 10.0, cust2}

{“AAA”, 12.0, cust1, 10.0, cust2}

{“BBB”, 10.0, cust4} {“CCC”, 11.0, cust5} {“AAA”, 10.0, cust3, 10.0, cust2}

{“BBB”, 10.0, cust6} {“BBB”, 10.0, cust4, 10.0, cust6}

> 10s


• 解答:

SELECT bid.symbol, bidPrice, bid.cust, askPrice, ask.cust,

FROM bidstream [RANGE 10 seconds] AS bid,

askstream [RANGE 10 seconds] AS ask

WHERE bid.symbol = ask.symbol


• 外部結合を含むストリーム間で、通常の結合操作を行うことができます

9. アプリケーション時間

• 課題:• CPUのwall-clockの代わりに、アプリケーション視点の時間を使用する必要があります

• イベントが異なる機器から発生し、何らかの方法で同期をする必要があるとき、これは非常に役に立ちます

• シナリオ:• 再び、bidとaskのストリームを検討するN


• しかし、bidやaskの注文は、注文が出された時点でのトレーダー側の時間です


• 売り手は、2つのask リクエストをそれぞれ、8:00:00と8:00:12に出します。

• 買い手は、8:00:11に時間に1つのbid リクエストを出します



• どのオーダー情報も古くなるので、10秒のウィンドウを使用して相関したいという要件を思い出して下さい。

• それゆえに、売り手からの最初のイベントは考慮されずに、11.0のask価格と9.5のbid価格に相関させなれればなりません



• しかし、現実では、やりとりの中で最初の2つのイベントが同時に到着してしまい、3番目が遅れてしまう可能性がある



• このケースでは、9.5のbid価格は10.0のask価格に相関し、より低いスプレッドでの為替差額が発生します



• 解答:

• クエリーは変化なし

• しかし、ストリームはいくつかのイベントプロパティにおいて、システム・タイムスタンプの代わりに、アプリケーション・タイムスタンプを使用するように構成しなければならないN


BidEventType

symbol string

customer string

bidPrice float

orderTime dateTime

10. パターンマッチング

�複雑なイベントパターンを識別する強力な概念

�正規表現として定義される

PATTERN (X+ Y+)

１以上の X イベントN １以上の Y イベントが続くN.


くN.

10. パターンマッチングの例株式取引 “W” パターン

X

YW

Z


SELECT FIRST(x.time), LAST(z.time)

FROM ticker MATCH_RECOGNIZE (ONE ROW PER MATCH PARTITION BY

name

PATTERN (X+ Y+ W+ Z+)

DEFINE X AS (price < PREV(price))

Y AS (price > PREV(price))

W AS (price < PREV(price))

Z AS (price > PREV(price)))

1 9 12 19

days

10. 消失イベント –時間による制限

SELECT

"DelayedShipment" as alertType,

orders.ts,

orders.orderId,

orders.amount

FROM OrderTracking MATCH_RECOGNIZE

(

PARTITION BY orderId

INCLUDE TIMER EVENTS

MEASURES一致を報告するのを待つために、非一致と期間をパターンに記述します


MEASURES

CustOrder.ts AS ts,

CustOrder.orderId AS orderId,

CustOrder.amount AS amount

PATTERN (CustOrder NotTheShipment*) DURATION 10 MINUTES

DEFINE

CustOrder AS (eventType = ‘O’),

NotTheShipment AS (eventType != ‘ S’)

) AS orders

期間をパターンに記述します

10. 消失イベント – イベントによる制限

SELECT

orders.orderId,

orders.amount,

"MissingApproval" as alertType


(

PARTITION BY

orderId

Orderの直後がShipmentのイベントであるので、パターンは消失したApprovalを意味

します。このケースでは、消失したApprovalは明確に定義される必要はありません。


orderId

MEASURES



PATTERN (CustOrder Shipment)

DEFINE

CustOrder AS (eventType = 'O'),

Shipment AS (eventType = 'S')

) AS orders

ません。

「他の」イベントタイプがOrderとShipment

の間に発生するならば、このアプローチは機能しない

10. 消失イベント – イベントによる制限

SELECT

orders.orderId,

orders.amount,

"MissingApproval" as alertType


(

PARTITION BY

orderId

除外（すなわち Approval でないすべて）によって、このパターンは、Approval を記述します。

このアプローチは、「他の」イベントタイプがOrderとShipmentの間に発生することが起こりえるならば機能します。*?演算子は「気乗りしない」(つまり、できるだけわずかなNotheApprovalと一致)ですこれは、ShipmentがNotTheApprovalとしてではなくShipmentとして一致することを


orderId

MEASURES



PATTERN (CustOrder NotTheApproval*? Shipment)

DEFINE

CustOrder AS (eventType = 'O'),

NotTheApproval AS (NOT (eventType = 'A')),

Shipment AS (eventType = 'S')

) AS orders

可能にします

10. 消失イベントの検出

• PATTERN (CustOrder NotTheShipment*) DURATION

10 MINUTES

• パターンにマッチしないなら:

• 10分以内のshipment が顧客のOrderの後に続きます

• パターンにマッチするなら:


• パターンにマッチするなら:

• 10分にShipmentではない他の何かが、顧客のOrderの後に続きます

まとめ

• 最初に、いくつかのウィンドウ演算子を使ってストリームからリレーションに変換する• RANGE, RANGE m SLIDE n, NOW, ROW, など.

• リレーションを処理するときは、標準のRDBMSにおける演算子を使用する• Projection, join, filtering, union, etc.


• Projection, join, filtering, union, etc.

• 必要に応じて、最後にリレーションからストリームに戻す• ISTREAM, DSTREAM, RSTREAM

• そして忘れずに適切な時間領域をモデル化する

オラクルのミドルウェア関連情報

最新情報つぶやき中最新情報つぶやき中

OracleMiddle_jpOracleMiddle_jp

twitter.com/OracleMiddle_jp/

�最新情報最新情報最新情報最新情報

�おすすめ情報おすすめ情報おすすめ情報おすすめ情報

�セミナ情報セミナ情報セミナ情報セミナ情報

などなどなどなどなどなどなどなど


slideshare.net/slideshare.net/OracleMiddleJPOracleMiddleJP

�製品資料製品資料製品資料製品資料

�顧客事例顧客事例顧客事例顧客事例

�ホワイトペーパーホワイトペーパーホワイトペーパーホワイトペーパー

などなどなどなどなどなどなどなど


■パフォーマンス診断サービス

•Webシステムボトルネック診断サービス

•データベースパフォーマンス診断サービス

NEW

■システム構成診断サービス

•Oracle Database構成相談サービス

•サーバー統合支援サービス

•仮想化アセスメントサービス

•メインフレーム資産活用相談サービス

•BI EEアセスメントサービス

•簡易業務診断サービス

■バージョンアップ支援サービス

■移行支援サービス

•SQL Serverからの移行支援サービス

•DB2からの移行支援サービス

•Sybaseからの移行支援サービス

ITプロジェクト全般に渡る無償支援サービス

Oracle Direct Conciergeサービス


オラクル社のエンジニアが直接ご支援しますお気軽にご活用ください!

オラクル無償支援検索

■バージョンアップ支援サービス

•Oracle Databaseバージョンアップ支援サービス

•Weblogic Serverバージョンアップ支援サービス

•Oracle Developer/2000(Froms/Reports)Webアップグレード相談サービス

•MySQLからの移行支援サービス

•Postgre SQLからの移行支援サービス

•Accessからの移行支援サービス

•Oracle Application ServerからWeblogicへ移行支援サービス

NEW

NEW

インストールすることなく、すぐに体験いただけます

製品無償評価サービス提供シナリオ一例

・データベースチューニング

・アプリケーション性能・負荷検証

・無停止アップグレード

・Webシステム障害解析

1日5組限定！

• サービスご提供までの流れ


http://www.oracle.com/jp/direct/services/didemo-195748-ja.html

Web問い合わせフォーム「ダイデモ」をキーワードに検索することで申し込みホームページにアクセスできます

※サービスご提供には事前予約が必要です

• サービスご提供までの流れ

1. お問合せフォームより「製品評価サービス希望」と必要事項を明記し送信下さい

2. 弊社より接続方法手順書およびハンズオン手順書を送付致します

3. 当日は、弊社サーバー環境でインターネット越しに製品を体感頂けます

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せくださいまずはお問合せください

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。


http://www.oracle.com/jp/direct/inquiry-form-182185-ja.html

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096

※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。


Technology

OEP製品技術資料 - CQL