オラクル・コンサルが語る！ oracle exadataの性能...

オラクル・コンサルが語る！Oracle Exadataの性能を引き出すアプリケーション設計/開発の勘所

日本オラクル株式会社テクノロジーコンサルティング統括本部武吉佑祐

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


Program Agenda Exadata向けアプリケーション設計の勘所

- 逐次処理から一括処理へ

- 一括処理の4つのTips- 一括処理にはできないバッチへの対応

- オブジェクト設計の勘所

コンサルが現場で使うチューニング技- SQLチューニングアドバイザを積極的に利用しよう

- Exadataのチューニングの際に見る情報

最後に


Exadata向けアプリケーション設計の勘所


主なExadata固有機能

機能名機能概要性能向上効果の高い処理

Smart Scan データのフィルタリング処理をStorage Serverが行い、Databaseに返すデータ量を削減

フルスキャン

Storage Index Storage Serverが対象外データをプルーニングし、Databaseに返すデータ量を削減

フルスキャン

Hybrid Columnar Compression

Storageの実効容量を増やすとともに、データスキャン帯域幅を最大10倍向上させる

フルスキャン

Smart Flash Cache / Write-Back

最大20倍IOPSを向上させ、ランダムI/Oのボトルネックを解消

データスキャン帯域幅を約2倍向上

物理I/Oが発生する全てのクエリ（フルスキャン、索引スキャン）/DBWRによるデータファイル書込み

Smart Flash Log Redoログ書き込みの高速化全てのCOMMIT

Exadata固有機能はI/Oの高速化に寄与するものが多い


処理タイプごとの基本方針まずは、これを押さえてください！

1. OLTPOLTP処理でボトルネックとなりやすいデータファイルI/OはSmart Flash Cache機能、COMMITはSmart Flash Log機能により透過的に高速化します。キャッシュフュージョンも、低レイテンシのInfiniBandにより自動的に高速になります。したがって、Exadataだからと言ってAP側で意識すべきポイントはありません。

2. DWH/BISmart Scan, Storage Index等のFull Scanを高速化するソリューションの恩恵を最大限享受するために、一意性を担保するための一意索引以外の索引を付与しないこと、およびパラレルクエリを使うことを基本方針として設計します。

3. バッチExadataの性能を最大限活用するために、いくつか設計上のポイントがあります！

本日のメイントピック


大幅に高速化するバッチとしないバッチがある！？Exadataへの移行でよくある話

A)バッチ処理1は、50倍高速化！B)バッチ処理2は、5倍高速化

【Question】なぜ、AとBのケースで高速化の程度に違いがあったのでしょうか？


逐次処理（ループ）はExadataの性能を引き出せないExadataの高いI/O性能を如何に引き出せるかが重要

【Question】なぜ、AとBのケースで高速化の程度に違いがあったのでしょうか？

Exadataの最大の特徴は、「広いI/Oバンド幅」と「Smart ScanやStorage IndexによるI/O削減機能」なので、1処理あたりのI/O量が小さいループによる逐次処理ではなく、1処理あたりのI/O量が大きい一括処理で性能を最大限に発揮できます。

【Answer】アプリケーションロジックがループ処理中心の逐次処理だったから


逐次処理と一括処理の例『PRODUCTS表のPRICE列を全て1.1倍にする』

①PRODUCTS表から『1行』取得

APサーバで演算実施

②取得したPRICE値を1.1倍にする

逐次処理の例一括処理の例

処理①-③をPRODUCTS表のレコード数分繰り返し実行

③UPDATE 文で、

①で取得したレコードを、②で計算したPRICE値に更新する

①PRODUCTS表のレコードを『一括』取得しつつ、DBサーバ側で演算を実施し、演算結果を一括で更新する。

UPDATE products SET price=price*1.1;

DBサーバで演算実施


大量データ処理の高速化には一括処理

1. I/Oバンド幅が広い（多くのDisk, InfiniBand, ASMによるストライピング）

2. Smart ScanやStorage Index、EHCCなどI/O量の削減機能を実装している

3. CPU, Memoryリソースが潤沢にあるため、パラレル実行処理による高速化の効果が大きい

4. Database ServerとApplication Server間のラウンドトリップ時間を減らせる

5. Application Server側の負荷をExadataにオフロードできる（ロジックの主体がAP Server側にある場合、AP Serverがボトルネックになりやすい）

Exadataが一括処理により大幅にパフォーマンスアップする理由


一括処理の4つのTips

Tips-1: ループ処理を単一のSQLで記述

Tips-2: PL/SQLで負荷をExadataにオフロード

Tips-3: INDEX RANGE SCANよりFULL SCAN、NESTED LOOP結合よりHASH結合

Tips-4: DMLエラーハンドリングの活用

バッチ処理の劇的な高速化を目指すために押さえておきたいこと


ループ処理を単一のSQLで記述まずは、ここからスタート

ループではなく、単一のDMLやCreate Table As Select（CTAS）で書けないかを意識してコーディングします。

ループ処理を単一SQLに書き換える際のPoint1. 最速は、CTASとInsert Append Select、続いて単一DML。2. リカバリ不要なCTAS/Insert Append Selectは、表をNOLOGGING属性にして実行する

3. パラレルDDL、パラレルDMLを利用する => 詳細はA-4のセッションで

4. 複雑な条件の更新やロードには、MERGE文やマルチテーブルINSERTを活用する

5. 複雑な条件分岐には、SQL「外」のIF文ではなく、SQL「内」のCASE句を活用する

6. 文字列変換は、可能な限りAP側で行うのではなく、ファンクション（SUBSTRなど）を活用し、SQL内で行う。組み込みファンクションで実現できなければ、PARALLEL_ENABLE属性を付与したストアドファンクションを作成し、利用する。

Tips-1


更新処理（UPDATE）の書き換え例

SQL> ALTER SESSION FORCE PARALLEL DML PARALLEL 8;SQL> UPDATE products SET price=price*1.1;

SQL> CRAETE TABLE product_temp NOLOGGING PARALLEL 8AS SELECT ・・・, price * 1.1 price FROM products;

SQL> RENAME products TO products_old;SQL> RENAME products_temp TO products;SQL> DROP TABLE products_old;

1件ずつフェッチ（INDEX UNIQUE SCAN）しながら、price列を1.1倍し、1件ずつUPDATEしていく処理

【CTASへの書き換え】更新処理中に別のアクセスがないことが

保証できる場合

GB単位の一括更新を行うDML実行時には、事前にパラレルDMLを有効化

CTASによるデータ洗い替えで更新を行う場合は、パラレルDDL + NOLOGGINGを使う

【単一のUPDATE文への書き換え】書き換え可能であれば常に

最速！

Tips-1

RENAMEで切り替え


0

10

20

30

40

50

60

70

80

90

100

ループで1件ずつUPDATE(INDEX UNIQUE SCAN)

一括UPDATE CTAS

書き換えパターンごとの処理時間比較1,000万件のテーブルの全件更新処理 on Exadata

6倍高速

100倍高速

ループ

UPD

ATEの

処理時間を

100と

した時の

相対処理時間

一括UPDATE, CTASはパラレルDML/DDLにすることで更なる高速化が簡単にできます！！※ ループ更新をパラレル化するためにはAP側で

Thread分割や対象レコードの配分などが必要

※上記は一例であり、表構造やデータ量、HW構成によって変動します。

100

170.9

Tips-1


PL/SQLで負荷をExadataにオフロード潤沢なExadataのHWリソースを最大限に活用

「扱うデータ量の大きいバッチ」については、業務ロジックをPL/SQLで組み、負荷をExadataにオフロードしバッチ時間の短縮を図ります。

■ 業務ロジックの主体がAPサーバにある場合

Exadata APサーバ

DB Server

Storage Server

Java

■ 業務ロジックの主体がDBサーバにある場合

DB Server

Storage Server

PL/SQL

DB-APサーバ間のNWラウンドトリップやAPサーバがボトルネックとなり、ExadataのI/O性能を生かしきれない。

結果セットのやり取りが断続的に発生

CPU/メモリを消費

Exadata APサーバ

ロジックの実行はDBサーバのリソースを使い、I/Oが発生してもExadata筺体内で完結するため、ExadataのI/O性能を生かすことができる。

PL/SQLのコールと成否確認のみ

I/Oはスカスカ

Tips-2

CPUはスカスカ

一括I/O


PL/SQLでバッチを書く場合のポイントPL/SQLのロジックも可能な限り一括処理にする

1. バルクフェッチ、バルクロードを可能な限り利用する。PL/SQLでもループ処理ではなく、一括処理形式にする。

SELECTprod_id

,price * 1.1BULK COLLECT INTO v_arry_productsFROM products;

バルクフェッチサンプル

FORALL i IN 1.. v_arry_procucts.COUNTINSERT /*+ APPEND_VALUES */INTO productsVALUES (v_arry_procucts(i).prod_id,

v_arry_procucts(i).price);

バルクロードサンプル

※ 注意： 11gR2のPL/SQLにて配列内に格納できるデータサイズの上限は、4GBです。4GBを超える場合には、LIMIT句を利用して分割格納するか、“_realfree_heap_pagesize_hint”パラメータにて上限を上げることで対応します（Note#1325100.1）。

Tips-2

FORALL内のINSERT VALUESはAPPEND_VALUESヒントでさらに高速化


INDEX RANGE SCANよりFULL SCANINDEX UNIQUE SCAN以外はFULL SCANの方が高速！？

INDEX SCANの方が高速と言われている「表データの10-15%未満」という閾値は、Exadataではより小さな割合（経験則：1%未満）となります。

理由

1. FULL SCAN（TABLE ACCESS FULL, INDEX FAST FULL SCAN）にて、Direct Path Readが行われた場合、Smart ScanとStorage Indexによる対象データのフィルタリングがStorage Server側で透過的に行われるため

2. FULL SCAN（TABLE ACCESS FULL, INDEX FAST FULL SCAN）では、パラレルクエリによるアクセスが可能であるため

実測値: 20GB/2.5億レコードの表に対する範囲検索時間の比較（物理I/O発生時）

検索範囲：10% 検索範囲：1%索引レンジ表フル索引レンジ表フル

SQL実行時間索引レンジスキャンの時間=100

100 0.4 100 10※上記は全て物理I/Oでデータを取得した場合の一例であり、表構造やデータ格納状態、HW構成によって変動します。

Tips-3

※注意！！OLTPのアプリケーションの場合、2回目以降の索引スキャンでは最

速であるバッファキャッシュからの読み取りが期待できるので、従来通り索引スキャンが推奨されます。


処理毎に「索引を見せる/見せない」を制御Optimizerに見せない「INIVISIBLE索引」の少しTrickyな使い方

SQL> ALTER SESSION SET optimizer_use_invisible_indexes=TRUE; （デフォルト： FALSE）

1. 索引アクセスが望ましいオンライン処理とフルスキャンが望ましいバッチ処理やDWH処理の両方がアクセスする表の索引については、全てINVISIBLE属性を付与した状態で作成する。

2. オンライン処理については、セッション開始時に下記のSQLを発行し、OptimizerにINVISIBLE索引を見せる設定とする（AP側でのセッション初期化時やDBのログイントリガー等で実行）。

顧客ID 購買日付商品ID98 05-01-01 1001

99 09-02-01 1002

100 11-01-15 1001

100 08-05-05 2000

101 13-11-01 3100

購買履歴表オンライン処理=> 索引を見せたい=> セッションレベルでINVISIBLE索引を

使うようにしてからSQL実行

バッチ処理 / DWH処理=> 索引を見せたくない（フルスキャンしたい）=> 索引はINVISIBLEなので、そのまま実行

INVISIBLE索引

select …from 購買履歴表where 顧客ID=…and 購買履歴 between …;

select sum(…)from 購買履歴表where …group by … ;

Tips-3


NESTED LOOP結合よりHASH結合大規模バッチ内のSQLはHASH結合が基本

結合アルゴリズムについても、逐次処理型のNESTED LOOP結合より一括処理型のHASH結合の方が高速に処理できる場合が多いです。理由

1. NESTED LOOP結合は索引スキャンすることを前提とした結合方法であり、FULL SCANやパラレルクエリに向いていないため

2. 「ハッシュテーブルのサイズが大きくなると一時表領域へのI/Oが発生し遅くなる」というHASH結合の弱点が、Exadataの高速なI/Oバスにより緩和されるため

HASH結合を選択させる方法（FULL SCANになれば、基本的にHASH結合になります）

2. 結合対象表から索引を取り除く

3. 主キー等の取り除けない索引がある場合- USE_HASHヒントを埋め込む- 上記が困難な場合、セッションレベルで、event 10093を有効にする（Note# 207434.1 ）

Tips-3

1. FULL SCANのコストを下げるExadata固有のシステム統計を取得する（DB稼働後一度だけで良い）

SQL> execute dbms_stats.gather_system_stats(‘EXADATA’);


一括更新処理でのエラーハンドリング「バッチは一括処理が基本です」とお客様に伝えたところ…

AP担当者今回、Exadata上で稼働させるバッチでは、データを更新する際に、チェック制約などでエラーとなった場合、エラーになった更新データを後ほど確認する必要があるため、一件ずつループしながら更新しないといけないんです…

FOR i LOOPUPDATE products SET price=X WHERE prod_id=iAND delflg=0;

END LOOP;Update error: 2013/11/01 12:00:00.001Error Code=ORA-nnn: prod_id=100

エラーログファイルへ出力

③更新失敗

④次の更新へ

①更新成功

②次の更新へ

Products表を1件更新お客様のやりたかったこと

Tips-4


DMLエラーハンドリング機能とは？一括処理の場合でもエラーになったデータと理由が分かります

UPDATE products SET price=X WHERE delflg=0;

DMLエラーハンドリングを使わない場合

1件更新失敗（チェック制約違反など）

全件ROLLBACKどのレコードでエラーになったか判別できない。

DMLエラーハンドリングを使う場合

UPDATE products SET price=X WHERE delflg=0LOG ERRORS INTO < ログ表 >REJECT LIMIT UNLIMITED;

9990件更新成功

9990件のレコードのみをUPDATE

10件更新失敗（チェック制約違反など）

10件のみROLLBACKエラーになった10件のレコードを値とともにエラーログ表に出力

delflg=0を満たすproducts表のレコード10,000件を一括更新する場合

Tips-4


DMLエラーハンドリング機能の特徴

1. DML処理中のエラーについて、エラーの発生原因や発生箇所をエラーログ表に書き出し、後からエラー箇所の特定を可能とする機能であり、一括更新処理のエラーロギングやDEBUGに最適。

2. エラーとなったレコードのみをエラーログ表に書き出し、更新が成功したレコードに関してはROLLBACKしない（REJECT LIMIT UNLIMITED指定時の動作）

※ エラーログ表は、DBMS_ERRLOG.CREATE_ERROR_LOGプロシージャにて事前に作成しておきます

列名格納される情報ORA_ERR_NUMBER$ 発生したORAエラー番号

（例）12899ORA_ERR_MESG$ 発生したORAエラーメッセージORA_ERR_ROWID$ エラーとなったレコードの

ROWID。UPDATE/DELETEのみ

ORA_ERR_OPTYP$ エラーとなったDMLオペレーションの種別（I/U/D）。

“I” : INSERT“U” : UPDATE“D” : DELETE

エラーロギング対象表の全ての列

エラーとなったレコードデータが、これらの列に含まれる。

■ エラーログ表の構成

SQL> DELETE FROM salesWHERE sold_date < sysdate -365LOG ERRORS INTO scott_emp_errortblREJECT LIMIT UNLIMITED;

Tips-4

プレゼンター

プレゼンテーションのノート

参考：エラーログ表にて確認できる情報エラーログ表に記録されるエラーは下記の通りである。なお、下記以外のエラーが発生した場合には、DML操作が終了するとともに、ロールバックされエラーログ表にエラーは記録されない（例：更新処理中にメモリ不足で処理が失敗した場合など）。 •　列の値が大きすぎる場合（精度違反） •　制約（NOT NULL制約、一意制約、参照制約、CHECK制約）違反の場合 •　トリガー実行時にエラーが発生した場合 •　副問合せの列と表内の対応列との間の型変換でエラーが発生した場合 •　パーティションマッピングエラーの場合 •　MERGE操作エラー（ORA-30926: MERGE操作の安定したセット行を取得できません。）


一括処理にはできないバッチへの対応ループがあっても修正できないパッケージ製品などへの対応ポイント

一括処理にしたくてもできないパッケージ製品などのバッチの場合、AP改修が不要なFlash Cache Write-Back機能とバッファキャッシュ拡大で高速化を図ります。

パッケージ製品のバッチでよくあるループ処理

① 対象データを1件フェッチ

② フェッチしたデータに演算実施（APサーバ側で実施）

③ 演算後データを1件INSERTそのあと、COMMIT

バッファキャッシュの拡大でキャッシュヒット率を上げ、漏れたものも高確率でFlash Cacheから取得できるように、対象表や索引にKEEP属性を付与

Flash Cache Write-Back機能を有効にし（デフォルト無効）、データファイルへの書き込みを高速化。COMMITはFlash Cache Log機能で透過的に高速処理可能

cell XXX physical readの待機が多発すると、ボトルネックに

対応策

対応策①が高速化し、free buffer waitsの待機が多発すると、ボトルネックに


オブジェクト設計の勘所（OLTP/DWH/バッチ共通）Exadata環境特有の考慮事項は、「索引/圧縮/Flash Cache」のみ

Exadataであっても、索引（前述の通り）/EHCC圧縮/Smart Flash Cache以外は通常のOracle Databaseと同様の考え方でオブジェクト設計を行います。

1. EHCC圧縮の採用を検討する表の条件- 原則として、当該表へのUPDATE/DELETE処理がかからない- データの投入方法がダイレクトパスロードのみである（INSERT APPEND SELECT等）- 表のサイズが十分に大きい（経験則として、5GB以上を対象にすると性能向上が大きい）- 表へのアクセスパスが、基本的にフルスキャンのみである※ 非常にサービスレベルの高いOLTP系AP（レスポンスタイム100ms以下保証など）がアクセスする表は

解凍のオーバーヘッドでレスポンスが悪化する可能性があるため、 EHCCで圧縮しないようにする

2. Smart Flash CacheへのKEEP設定を検討する表の条件- 総合試験時に物理I/Oの多い上位表（AWRのSegments by Physical Readsから確認）- 「Flash Diskの総量 > DBサイズ」の場合は、全オブジェクトをKEEPする

※参考：オラクルコンサルが語る！ Exadataの性能を最大限に引き出すための性能管理Tipshttp://www.oracle.com/technetwork/jp/ondemand/db-new/e-4-exatips-1448380-ja.pdf


コンサルが現場で使うチューニング技


SQLチューニングアドバイザを積極的に利用しようSQLチューニングアドバイザ、使ったことありますか？

SQLチューニングアドバイザ！？名前は聞いたことあるけど、使ったことないね。

そもそもチューニングアドバイザのアドバイスは信用できるの？

SQLチューニングエキスパート

「チューニングアドバイザなんて信用できない」と思っているチューニングエキスパートの皆さんは結構いらっしゃると思います。しかし、大規模かつミッションクリティカルなお客様を支援することの多いオラクルコンサルも、最近は現場でSQLチューニングアドバイザを使っています。

特に、これまで紹介してきたExadataの性能を引き出す一括処理のアプローチを徹底すると、SQLが長くなることが多くSQLチューニングアドバイザが大活躍します！！


SQLチューニングアドバイザを利用した運用フロー例

①高負荷SQLの抽出・リスト化

定期的（月次など）に高負荷SQLを抽出し、SQL管理台帳に起票します。

②チューニング要否検討

抽出したSQLについて業務/APチームとチューニング要否を検討します。

③チューニング案検討

SQLチューニングアドバイザにより、チューニングレポートを生成し、チューニングの可否と方針を決定します。

④効果試験

ステージング環境や本番環境にて、チューニング案の妥当性を試験します。

⑤本番へのインプリ

効果の確認できたものについて、本番へのインプリを実施します。

SQLチューニングアドバイザの活用により、チューニング工数の削減と、チューニング方針の属人化防止を図ります。


SQLチューニングアドバイザによる推奨事項

1. 取得漏れ、もしくは失効しているオプティマイザ統計情報対象のSQLがアクセスしている表や索引の中に、統計情報が取得されていないものや

失効しているものがあった場合、その表や索引名と、統計情報取得スクリプトの一例が出力されます。

2. SQLを高速化する新規索引の情報対象のSQLのレスポンスを高速化することが見込める索引の情報を出力します。不適切な索引が既に張られていた場合には、その索引の削除についても推奨事項が生成されます。

3. より最適な実行計画にするためのSQLプロファイルの情報SQLのレスポンスを高速化することが明らかな実行計画にするためのSQLプロファイル情報が出力されます。


SQLプロファイルとは？

Validation results ------------------The SQL profile was tested by executing both its plan and the original plan and measuring their respective execution statistics. A plan may have been only partially executed if the other could be run to completion in less time.

Original Plan With SQL Profile % Improved ------------- ---------------- ----------

Completion Status: COMPLETE COMPLETEElapsed Time (s): .29786 .001638 99.45 % CPU Time (s): .2975 .002 99.32 % User I/O Time (s): 0 0 Buffer Gets: 33797 81 99.76 %Executions: 1 1

Notes -----1. Statistics for the original plan were averaged over 4 executions. 2. Statistics for the SQL profile plan were averaged over 10 executions.

【アドバイザレポートSQLプロファイル評価部抜粋】 SQLチューニングアドバイザにより生成される、より性能を向上させる実行計画となる内部的なヒント句のセットが「SQLプロファイル」 SQLプロファイルは索引付与等のチューニングと異なり、対象のSQLのみに影響を与える SQLプロファイルは、別途手動で適用しなければ有効にはならない

SQLプロファイルは信用できるのか？ Exadataでも使えるのか？

元々の実行計画とSQLプロファイルを適用した場合の実行計画でそれぞれSQLを実行し平均値を取っている。実際に計測しているので信用できる！実際に計測しているのでExadataでも使える！

Completion StatusがCOMPLETEかどうかを確認する※INTERRUPTEDの場合は評価がタイムアウトし、途中で終わったことを示している


SQLプロファイルの効果を本番環境で確認する方法

下記の方法により、安全にSQLプロファイル適用後の性能評価を本番環境で行うことができます。

① CATEGORYパラメータに”DEFAULT”以外の文字列を渡してSQL Profileを適用※ DEFAULT以外のCATEGORYでSQLプロファイルを適用した場合、通常セッションで実行されるSQLに影響はありません。

SQL> execdbms_sqltune.accept_sql_profile (

task_name => ’<タスク名>’, アドバイザレポートから確認task_owner => ’<タスクオーナー名>’, アドバイザレポートから確認category => ‘PROF_TEST001’ カテゴリ名（任意の一意文字列）

);end;/

② 性能試験を行うセッションにてsqltune_category初期化パラメータを上記で設定したカテゴリ名に設定SQL> alter session set sqltune_category=‘PROF_TEST001’;③ 同一セッション内で試験対象SQLを実行し、性能計測④ 問題なければ、プロファイルのCATEGORY名をDEFAULTに変更（同一のSQL全てにプロファイルが反映される）SQL> exec dbms_sqltune.alter_sql_profile(name=>’<プロファイル名(*1)>’,attribute_name=>’CATEGORY’,value=>’DEFAULT’);

(*1): プロファイル名は、DBA_SQL_PROFILESから①で設定したCATEGORY名で検索します。SELECT name FROM dba_sql_profiles WHERE category=‘<カテゴリ名>’;

ステージングではなく、本番環境でプロファイルの評価を行いたい場合


Exadataのチューニングの際に見る情報Oracle Enterprise Managerをいかに使いこなすかが大切です

1. AWRレポート、ASHレポート（ともにEMからも確認可能）性能レ問題が起こったら、DB全体を把握するために、まずはAWRレポートから確認します。

分析観点は通常のOracle Databaseとほぼ同じですが、Exadata環境特有の待機イベント、パフォーマンス統計は押さえておく必要があります。

AWRポートからボトルネックの被疑箇所にあたりを付け、インスタンスチューニングを行うのか、SQLチューニングを行うのか（もしくは、その両方か）を判断します。

※参考：オラクルコンサルが語る！ Exadataの性能を最大限に引き出すための性能管理Tipshttp://www.oracle.com/technetwork/jp/ondemand/db-new/e-4-exatips-1448380-ja.pdf

2. EMの「SQL監視」画面従来のSQLトレース機能と同レベルか、それ以上の粒度で、かつSQLに追加負荷を与えずに、SQLの詳細な分析ができます。SQL*Plusからも出力できますが、グラフィカルでリアルタイムに状況を確認できるEMがおすすめです。


最後に


【おさらい】処理タイプごとの基本方針

3. バッチループによる逐次処理ではなく、単一のSQLやPL/SQLによる一括処理の方式を取り、ExadataのI/Oを最大限に利用します。

1. OLTPOLTP処理でボトルネックとなりやすいデータファイルI/OはSmart Flash Cache機能、COMMITはSmart Flash Log機能により透過的に高速化します。キャッシュフュージョンも、インターコネクトがInfiniBandなので自動的に高速になります。したがって、Exadataだからと言ってAP側で意識すべきポイントはありません。

2. DWH/BISmart Scan, Storage Index等のFull Scanを高速化するソリューションの恩恵を最大限享受するために、一意性を担保するための一意索引以外の索引を付与しないこと、およびパラレルクエリを使うことを基本方針として設計します。


本セミナーの内容に関する留意事項

バッチ処理がループ中心の逐次処理であっても、Exadataへの移行により

高速化しないという訳ではありません。

移行元の現行Databaseにて、I/Oがボトルネックとなっている場合などは、

APの改修を伴わない移行においても、数倍高速化することがあります。

Exadataへの移行に際し、バッチの改修を行う工数が

十分に確保できない場合、すべての一括処理化を狙うのではなく、

現行でクリティカルパスとなっている処理を中心に見直しを検討してください。

本資料内に掲載している性能情報については、一例であり、

Exadataの構成やデータ構成/量などによって変動しますので

参考情報として参照ください。

オラクル・コンサルが語る！ oracle exadataの性能...

Documents