【2018年3月時点】Oracle BI ベストプラクティス

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
Oracle BIの活用における
ベストプラクティス
2018年3月20日
日本オラクル株式会社
クラウドプラットフォームソリューション統括
Cloud Platformソリューション本部
Big Data & Analyticsソリューション部
吉川岳伸
Oracle BI Tips & Tricks

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.

アジェンダ
Oracle BIの基本
リポジトリ設計のベストプラクティス
カタログ設計のベストプラクティス
クエリーログの参照方法
1
2
3
Confidential – Oracle Internal/Restricted/Highly Restricted 3
4

本題に入る前に・・・

ベスト・プラクティスとは？
ベストプラクティス（英: best practice）は、ある結果を得るのに最も効率のよい技法、
手法、プロセス、活動などのこと。～中略～すなわち、適切なプロセスを確立し、
チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果
が得られると考える。
ベストプラクティス – Wikipedia
https://ja.wikipedia.org/wiki/ベストプラクティス

どんな効果があるのか？
効率よく物事を進められる問題の発生を予防できる
本日はどちらかというと、こちら

テクニックだけでいいの？

そんなことはありません

はじめに考えること
• 次の点を明確にする必要があります
– 何のために情報活用するのか（ゴールの設定）
– 目的地までのどうやって進んでいくのか（分析のシナリオ）
– どんな情報をどのように判断するか（評価指標と分析軸）
BIシステム導入の目的を明確にしましょう
リポジトリやカタログ開発を実施する前に、これらの事項を明確に
しなければなりません。
これらのどれか一つでも欠けていると、目隠ししたまま歩き続ける
ことになります。
9

Oracle BIの基本
Subtitle

Oracle BIの基本
• 優先度の高い順：
1. 正しい結果を得る
2. 結果を速く得る
3. 結果を容易に得る
11
Oracle BIのアプリケーションにおける3つの主要な目標

Oracle BIの基本
• これは当然の目標ですが、RPDの構成の誤りにより達成できていないケー
スがあります
• エンドユーザは、何の警告もなく長年にわたり誤った結果を得続けること
にもなります
• 潜在的な問題を特定するために、物理SQLを見てください
– フィルタが少なすぎる／多すぎる、不要なテーブルが含まれている等
12
正しい結果を得る

Oracle BIの基本
• ビジネスユーザは明確な期待値を持っていないことも多い
– 彼らは「許容できる」パフォーマンスを求めています
– 検索パフォーマンスは、プロジェクトの開始時には開発者の主な関心事ではありま
せん
• 実装の終盤あるいは大問題に直面してから、ようやく関心を振り向けることになります
– クリックするたびに2分待つとしたら、美しいレポートも無意味です
– パフォーマンスには、プロジェクトを開始した時から常に関心を払わなければなりま
せん
13
結果を速く得る

Oracle BIの基本
• 操作性、グラフ、階層、レポートの体裁・・・
• 誰もが（エンドユーザも開発者も）フォーカスするポイントです
– ”カッコいいレポートを作りたい”
– ”できるだけたくさんの情報を一度に取れるようにしよう”
• 多くのプロジェクトでの失敗や大トラブルの主な原因がこれです
• エンドユーザと表現方法についてディスカッションするときには、開発者は
いつもパフォーマンスへの影響を考慮しなければなりません
14
結果を容易に得る

Oracle BIの基本
• パフォーマンスは常に表現方法よりも高い優先度であるべきです
• 設計フェーズでは、この考えを受け入れることが（まだ）可能です（多少の
見た目の妥協）
• 実装が終了に差し掛かると、パフォーマンス課題のために見た目を変更
することをユーザに納得させるのは非常に困難です
15
プロジェクトを開始した最初の日から、パフォーマンス
に注意してください

Oracle BI Enterprise Edition（OBIEE）
• BI ServerおよびPresentation Servicesから構成され、独自の論理SQLを構
成し、高いユーザ親和性を持つBIツール
リポジトリ
Presentation
Services
クライアント BI Server DB
論理SQL
SQL結果
リクエスト物理SQL
カタログ
SQL結果結果HTML
16

論理->物理SQL・物理->論理結果に変換する情報
リポジトリ構成
プレゼンテー
ション層
• 画面上での論理名称決定
• 論理SQL上のオブジェク
ト名
ビジネスモデル
とマッピング
（論理）層
• 論理結合の生成
• 論理オブジェクトの生成
• 集計ルール
• Fact, Dimension
• 階層
物理層
• DB接続定義
• 物理結合定義
17

BIの基本となるデザイン
• スタースキーマ=1つのファクトのま
わりにディメンションが広がるように
１：多で配置された状態
• ディメンション=分析の切り口となる
属性項目（例：品目タイプ）
• ファクト=集計対象になるメジャー(数
値)項目（例：売上、数量、人数）
• OBIEEはスタースキーマを前提に設
計されています
スタースキーマ
ファクト
18
ディメンション

適切なキャッシュ設定をしましょう
• Oracle BI EE の高度なキャッシュ技術
– ユーザ間でのキャッシュの共有
– データソース単位（テーブル単位）でのキャッシュ設定
インテリジェントキャッシュの活用
Oracle BI Server
データソース
データソース利用者
キャッシュの共有
データソース単位の
キャッシュの設定
19

リポジトリ設計の
Subtitle

「不透明なビュー」の使用を避ける
• 不透明なビュー(Opaque View)機能を
使用すると副問い合わせが発生し、
SQLが複雑になります
• 不透明なビューに定義されたすべて
の表が必ずクエリーに含まれることに
なります（実際には不要であっても）
• 最後の手段としてのみ使用することと
し、可能な限りDB層でVIEW、MVIEWな
どを作成し代用ください
物理層で直接SQLを書くことでOBIEE内でビューを定義する機能
21

表の別名(Alias)を作成しましょう
• 全ての表に別名を作成し、「Dim_ 」, 「Fact_」,
「Fact_Agg」のような接頭辞をつけると可読性が向上します
• 物理表ではなく別名間で結合を行ってください
Original tables VS Aliases
22

接続プールの設定を適切に
• ODBCよりもネイティブDBドライバ(例：OracleならOCI)を使用する
• 最大接続数はDBの性能にあわせて設定する
– 推奨値例：
• ダッシュボード上のリクエスト数×同時ユーザ数の10%～20%
ただし、リポジトリ内の全接続の合計数は800未満にします
– 階層列や選択ステップを使用する場合、
多数のクエリーを同時実行することに
注意してください
• 初期化ブロックの接続プールは個別に
設定する
23

データベース「機能」タブの設定
• DB機能の設定によっては不適切なSQLが生成されパフォーマンスも大きく
低下する場合があります
• 特別な理由がなければ初期値(BI内でDBごとに決まっているデフォルト値)
の状態でご利用頂くことをお勧めします
デフォルトの状態が推奨
24

データベースでサポートされていない関数の使用
データベース「機能」タブの設定
Substring関数がDBでサポートされていないSubstring関数がDBでサポートされている
論理SQLの例
select substring(製品コード, 1, 3), sum(売上) from 実績
論理SQLの例
select substring(製品コード, 1, 3), sum(売上) from 実績
物理SQLの例
select substr(製品コード, 1, 3), sum(売上) from 実
績 group by substr(製品コード, 1, 3)
物理SQLの例
select 製品コード, 売上 from 実績
substring関数がDBでサポートされないため、
BIサーバで計算します。
BIサーバでGroup Byおよび集計されるため、
必要な全行が取得されます。
25

ログレベルは0に設定
• 本番環境ではBIサーバのシステム・ロギング・レベルを0に設定頂くとパ
フォーマンスへの影響が抑えられます
• ログレベルが高すぎると同時に複数の分析が表示される際、パフォーマ
ンスに影響を与える場合があります
「ツール->オプション->リポジトリ」画面で設定
26

クエリー制限する
• ユーザが大規模レコードを検索してBIサーバとDBに多大な負荷をかける
事象を回避するため、「管理->アイデンティティ->ユーザ/アプリケーション・
ロール権限->問い合わせ制限タブ」にて問い合わせ制限を有効にして頂く
ことをお勧めします
• 特別な要件が無い場合、目安として100,000件のレコードおよび10分～1
時間以内に設定
27

カタログ設計の
Subtitle

一般的なレポートのベストプラクティス
• ブラウザは一般的に新しいバージョンほど表示パフォーマンスが向上して
います
• 動作確認状況をチェックして、可能な限り最新またはオラクルの推奨バージョンを
ご利用いただくことをご検討ください
• 動作確認状況はブラウザベンダーのサポート状況などにより、随時変化します
• 特定の利用環境に強く依存した設定は、できるだけ避けてください
29
ユーザの利用環境について

• フィルタ演算子「別の分析の結果に基づく」の使用は避けてください
• 下記の項目は必要最小限にしてください
• 総計や小計
• 階層カラム
• 一つのダッシュボード・ページに表示する分析は6以内に
• ピボットやチャートが多いとバックエンドのDBから多くのデータを取得するリクエス
トが増えるため、表示が遅くなります。
不要な非表示セクションが無いかもあわせて確認してください
30
一つの分析に表示するカラム数は最大でも10～30以内に

• ダッシュボードあたりのページが多くならないように注意してください
すべてのページは表示されているべきです（非表示にしない）
• カラムセレクタ、ドリルダウン、ガイド付きナビゲーションを活用し可能な限
りインタラクティブなダッシュボードにしましょう
• 階層列の多用は多数の物理クエリを発行することになる(各レベルに最低
で一つのクエリが必要)ので避けましょう
31
効果的なダッシュボードのために

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 32
参考：階層列の使用によるSQLへの影響
SELECT s_0, s_1, s_2, s_3, s_4, s_5, s_6, s_7, s_8, s_9, s_10, s_11 FROM (
SELECT
0 s_0,
"SH"."時間"."年"s_1,
CAST(NULL AS VARCHAR(1)) s_2,
'製品全部's_5,
CAST(NULL AS DOUBLE) s_6,
CAST(NULL AS INTEGER) s_8,
IDOF("SH"."製品"."製品階層"."製品全部")s_9,
"SH"."売上"."コスト"s_10,
"SH"."売上"."売上金額"s_11
FROM "SH"
UNION ALL
SELECT
1 s_0,
"SH"."時間"."年"s_1,
"SH"."製品"."製品カテゴリ"s_2,
'製品全部's_5,
IDOF("SH"."製品"."製品階層"."カテゴリ")s_6,
FROM "SH"
WHERE
IDOF("SH"."製品"."製品階層"."製品全部")IN (1)
UNION ALL
SELECT
2 s_0,
"SH"."時間"."年"s_1,
"SH"."製品"."製品小カテゴリ"s_4,
'製品全部's_5,
IDOF("SH"."製品"."製品階層"."サブカテゴリ")s_7,
FROM "SH"
WHERE
IDOF("SH"."製品"."製品階層"."カテゴリ")IN (205)
UNION ALL
SELECT
3 s_0,
"SH"."時間"."年"s_1,
"SH"."製品"."製品名"s_3,
"SH"."製品"."製品小カテゴリ"s_4,
'製品全部's_5,
IDOF("SH"."製品"."製品階層"."サブカテゴリ")s_7,
IDOF("SH"."製品"."製品階層"."製品")s_8,
FROM "SH"
WHERE
IDOF("SH"."製品"."製品階層"."サブカテゴリ")IN (2051)
) djm ORDER BY 1, 6 ASC NULLS FIRST, 10 ASC NULLS FIRST, 3 ASC NULLS FIRST, 7 ASC NULLS FIRST, 5 ASC NULLS FIRST, 8 ASC NULLS FIRST, 4
ASC NULLS FIRST, 9 ASC NULLS FIRST, 2 ASC NULLS LAST
FETCH FIRST 10000000 ROWS ONL
SQL1
SQL2
SQL3
SQL4
union all
union all
union all
左のサンプルでは、SQL
は4つに分割されUnion
Allされます。階層列を展
開すればするほど、SQL
は複雑になります。
発行される論理SQL

不要なビューの削除
• 表ビューを含め、不要なものは削除してください
• レイアウトで複合ビューに含まれていないものもパフォーマンスに影響し
ます
33
ビューが増えるごとに負荷が高くなります

列の除外
• 取得データ量が増加してしまいます
• 「除外」にしても検索されます
• BIサーバが複数のレベルで集計を行うためDB、BIサーバ両方のリソー
スを消費します
34
不要な項目は削除してください

参考：列の除外（除外項目がない）
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3 from ( select distinct 0 as c1,
D1.c2 as c2,
D1.c1 as c3
from
(select sum(T430065.AMOUNT_SOLD) as c1,
T430073.CALENDAR_YEAR as c2
from
TIMES T430073,
CHANNELS T429983,
SALES T430065
where ( T429983.CHANNEL_CLASS = '直販' and T429983.CHANNEL_ID =
T430065.CHANNEL_ID and T430065.TIME_ID = T430073.TIME_ID )
group by T430073.CALENDAR_YEAR
) D1
order by c2 ) D1 where rownum <= 10000000
”チャネルカテゴリ”をフィルタとし
ては使用するが、「選択された
列」に含めない

参考：列の除外（除外項目がある）
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4, D1.c5 as c5 from ( select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
sum(D1.c5) over (partition by D1.c3) as c5
from
(select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
sum(D1.c4) as c5
from
(select distinct 0 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c1 as c4,
D1.c4 as c6
from
(select sum(T430065.AMOUNT_SOLD) as c1,
T429983.CHANNEL_CLASS as c2,
T430073.CALENDAR_YEAR as c3,
T429983.CHANNEL_CLASS_ID as c4
from
TIMES T430073,
CHANNELS T429983,
SALES T430065
where ( T429983.CHANNEL_CLASS = '直販' and T429983.CHANNEL_ID =
T430065.CHANNEL_ID and T430065.TIME_ID = T430073.TIME_ID )
group by T429983.CHANNEL_CLASS, T429983.CHANNEL_CLASS_ID,
T430073.CALENDAR_YEAR
) D1
) D1
group by D1.c1, D1.c2, D1.c3, D1.c4
) D1
order by c1, c3 ) D1 where rownum <= 10000000
表示される結果は、”チャネルカ
テゴリ”を「選択された列」に含め
ない場合と同じ
「選択された列」に含め、表のレイ
アウトで除外項目とする

グループと計算項目
• 計算項目
– Presentation Serverで計算
– BIサーバから返される結果セット（通常はごく少ない）に
対して計算が実行されます
– 大量のメモリを必要とする可能性があります
– 集計ルールはBIサーバによって決定されません
• グループ
– DBで計算
– DBに重大な影響を与える可能性があります
– BIサーバの集計ルールが適用されます
37
パフォーマンス上の考慮事項
新規グループ
新規計算項目

大規模レコードはできるだけ表示しない
• ダッシュボードプロンプトにはデフォルト値を設定しましょう
• ユーザが最も頻繁に選択する値がわかっている場合は、それをデフォルト値にします
• 不明な場合は、ダミーの値をデフォルト値として設定します
必要に応じて「結果なし」ビューをカスタマイズして、ユーザにプロンプトから値を選択するよ
うに促してください
• 一番良くないのはフィルタを設定せず、全件を取得する大規模なクエリー
を発行して、DBとBIサーバの両方に負荷をかけることです
• 大量データのエクスポートや大規模ピボットビューは高負荷になります
• 大規模データの表示パフォーマンスは、クライアントPCのスペックやブラウザの性能にも依
存します
38
大量のレコードがある場合は表示に工夫が必要です

メジャーの抽出方法
• ユーザはメジャーを何らかの条件でフィルタリングします
（例：仕掛かり/完成ごとの製品数）
• 実現するためには複数の方法がありますが、その方法ごとに負荷が大幅
に変わります
39

• 最初に取るべきアプローチ
– 分析で列フィルタを使用する方法
1. 分析フィルター
40

• 2つ目のアプローチ
– カラムで式の編集を行いCASE WHENを使用する方法
2. CASE WHEN
41

• 最後の手段
– 論理列の設定で“Filter Using”句を定義する
3. Filter Using
42

参考：Filter Usingを使用した分析の例
アンサーで、1つの分析を作成しダッ
シュボードページに表示したものです。
目的の違う複数のグラフを表示するた
めのデータを一度に取得するため、複
雑な定義となります。
この例では、Filter Usingを使用して計
数データの戻り値を制御しています。
43

前ページの「分析」のための物理SQL
参考：Filter Usingを使用した分析の例
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4 from ( select distinct 0 as c1,
D1.c3 as c2,
D1.c1 as c3,
D1.c2 as c4
from
(select sum(case when T430028.PROD_CATEGORY = 'ソフトウェア・その他' then T430065.AMOUNT_SOLD
end ) as c1,
sum(case when T429983.CHANNEL_CLASS = '直販' and T429991.COUNTRY_NAME = '日本' then
T430065.AMOUNT_SOLD end ) as c2,
T430073.CALENDAR_YEAR as c3
from
COUNTRIES T429991,
CUSTOMERS T430003,
TIMES T430073,
PRODUCTS T430028,
CHANNELS T429983,
SALES T430065
where ( T429991.COUNTRY_ID = T430003.COUNTRY_ID and T430003.CUST_ID = T430065.CUST_ID and
T429983.CHANNEL_ID = T430065.CHANNEL_ID and T430028.PROD_ID = T430065.PROD_ID and
T430065.TIME_ID = T430073.TIME_ID and (T429983.CHANNEL_CLASS in ('直販') or T430028.PROD_CATEGORY in
('ソフトウェア・その他')) and (T429991.COUNTRY_NAME in ('日本') or T430028.PROD_CATEGORY in ('ソフトウェ
ア・その他')) )
group by T430073.CALENDAR_YEAR
) D1
order by c2 ) D1 where rownum <= 10000000
実際に発行された物理SQLです。
Filter UsingがCASE文に変換されています。
必要なデータを一度に検索するため、結合する
表の数も多くなりパフォーマンスに影響を与え
る可能性があります。
44

メジャーの抽出方法比較
方法利点欠点お勧め度
分析フィルター • 柔軟
• 完全に最適化される
• エンドユーザ教育が簡単
• 分析の定義内容に依存するため、
常に使えるとは限らない
1 – 通常はこれを使
用
Case When • 比較的シンプルな物理ク
エリ
• ほとんどのケースに適用
できる
• WHERE句が必ずしも発生しない
• このフィルタを必要とするレポート
は、パフォーマンスが劣化する可
能性がある
2 – 必要に応じて要所
要所のみで使って下
さい
Filter Using • WHERE句が常に適用され
る
• WHERE句が簡単に巨大になって
しまい、問題発生時に原因特定に
時間がかかる
• 3種類の中では、一番パフォーマ
ンスが劣化する
3 – 特別な要件がな
ければ避けてください
45

クエリーログの参照方法
Subtitle

問い合わせロギング・レベル
ロギング・レベル記録される情報
レベル0 ロギングは行われません。
レベル1 クライアント・アプリケーションから発行されたSQL文が記録されます。次のものも記録されます。
• 物理問合せのレスポンス時間 - バックエンド・データベースで問合せが処理されるのにかかった時間。
• 物理問合せの数 - バックエンド・データベースで処理された問合せの数。
• 累積時間 - リクエストに関するすべての物理問合せの合計時間(すべてのバックエンド・データベース処理時間とDB接続時間の合計)。
• DB接続時間 - バックエンド・データベースへの接続にかかった時間。
• 問合せキャッシュの処理 - キャッシュからの論理問合せの処理にかかった時間。
• 経過時間 - BIサーバーに論理問合せが発行されてからユーザーに結果が返されるまでに経過した時間。経過時間には、論理問合せの準備が開始されてからBIサーバーに問合
せが発行されるまでにかかるわずかな時間も含まれるため、レスポンス時間より短くなることはありません。この時間の差が非常に短い場合は、経過時間とレスポンス時間
は等しくなります。
• レスポンス時間 - 論理問合せの準備、実行および最新レコードのフェッチにかかった時間。これは、使用状況トラッキングで記録されるTOTAL_TIME_SECに一致します。
• コンパイル時間 - 論理問合せのコンパイルにかかった時間。
• 各問合せについて、問合せのステータス(成功、失敗、終了またはタイムアウト)、ユーザーID、セッションIDおよびリクエストIDが記録されます。
• BIサーバーの合計時間 — 問合せ実行のみにBIサーバーで要した時間(つまり、コンパイル時間でない)。
レベル2 レベル1で記録されるすべてのものが記録されます。
加えて、各問合せについて、リポジトリ名、ビジネス・モデル名、サブジェクト・エリア名、物理データベースに対して発行されたSQL文、キャッシュに対して発行された問
合せ、物理データベースに対する問合せとキャッシュに対して発行された問合せからそれぞれ返された行数、およびクライアント・アプリケーションに返される行数が記録さ
れます。
加えて、キャッシュをシードする予定だった問合せがキャッシュに挿入されなかった場合、既存のキャッシュ・エントリを消去して現在の問合せ用の領域を作成する場合、お
よび完全一致のヒット・ディテクタを更新できなかった場合、論理問合せ計画のログ・エントリが追加されます。
Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。
加えて、問合せ実行計画が記録されます。Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。
加えて、実行計画内の様々な時点における中間の行数が記録されます。Oracleサポート・サービスの支援がない場合は、このレベルを選択しないでください。
レベル6および7 使用されません。
https://docs.oracle.com/cd/E80149_01/biee/BIESG/GUID-7C4C8FA8-C417-4091-A8E8-B1ED35EBB391.htm#GUID-D31EB685-D598-4F53-A33C-7AEF91A00C10
47

ログファイルの場所
• OAC: Oracle Analytics Cloud (OAC) のファイルの格納場所に関するクイッ
ク・リファレンス (Doc ID 2333937.1)
• [OBI12c] アーキテクチャ、ライフサイクル管理およびファイルの格納場所
に関するクイック・リファレンス (Doc ID 2095710.1)
• Oracle Business Intelligence Enterprise Editionシステム管理者ガイド
– 問い合わせログの管理
• https://docs.oracle.com/cd/E80149_01/biee/BIESG/GUID-7C4C8FA8-C417-4091-A8E8-
B1ED35EBB391.htm#GUID-7C4C8FA8-C417-4091-A8E8-B1ED35EBB391
48

ブラウザでのクエリーログの確認方法
「詳細」タブで論理SQL
をコピー
「管理」の「SQLの発行」
を選択
コピーした論理SQLを貼
り付ける
ログレベルを設定し
「SQLの発行」をクリック
49

クエリーログを読む
Timestamp: BIサーバによるクエリーの実行の開始時刻
TRACE: ログレベル
requestid: 論理クエリーのID。NQQuery.log内のこのクエリーのすべての要素を追跡す
るために使用されます。
username: クエリーを実行したユーザ
[2018-01-18T02:12:06.94-05:00] [OBIS] [TRACE:2] [] []
[ecid: d9f1e79f-38a8-48c0-bfcd-31cceb502f93-
00000686,0:1:36:3] [sik: bootstrap] [tid: 6e05a700]
[messageid: USER-0] [requestid: 2c90023] [sessionid:
2c90000] [username: cloud.user]
50

論理SQL
1
2
3
4
5
6
51

1. 変数：このクエリーに対する変数を設定。よく使われる変数は次の通り
• QUERY_SRC_CD クエリーの種別、プロンプト（Prompt）、レポート（Report）など
• SAW_SRC_PATH クエリーが既に保存されている場合、そのカタログパス
• SAW_DASHBOARD クエリーがダッシュボードに含まれる場合、そのカタログパス
• SAW_DASHBOARD_PG ダッシュボードページの名前
2. ユーザが選択した列
3. ソートキー：選択された列に対してRPDで定義したソートキー
4. REPORT_XXX または、何らかのAGGREGATE関数
BY句でメジャーの特定のレベルに対する集計要求が追加されます。これは通常ビュー定義に依
存します（小計、列の除外など）。ユーザは列の計算でこれらを設定できます。
5. From：使用するサブジェクトエリア
6. Fetch：取得する最大行数
52

• このidは物理クエリーを識別します。ログの中でこのクエリーのパフォーマンスを追跡す
るために使用できます。
• このクエリーの受信行数とバイト数です
• このクエリーのレスポンス時間です
• 物理クエリーの数です（複数に分割されている可能性があります）
• BIサーバからPresentationサーバへ返された行数です
53

• Elapsed Time：
クエリーの開始から終了までの合計時間です。すべての行のフェッチにかかる時間も含
まれます。
• Response Time：
クエリーの開始からPresentationサーバによるデータのフェッチの開始までの時間です。
Elapced TimeとResponce Timeに相違がある場合、それは通常、全行のフェッチに必
要な時間によるものです。検索結果は全行のフェッチを待たずに描画されることがありま
す。
• Compilation Time：
BIサーバがデータをコンパイルして送信する時間です。ほとんどの場合、2秒未満である
べきです。
54

【2018年3月時点】Oracle BI ベストプラクティス

【2018年3月時点】Oracle BI ベストプラクティス

More Related Content

What's hot

Similar to 【2018年3月時点】Oracle BI ベストプラクティス

More from オラクルエンジニア通信

Recently uploaded

【2018年3月時点】Oracle BI ベストプラクティス