ICT新事業創出に向けて - soumu.go.jp · Jubatus. リアルタイムビッグデータ処理技術. リアルタイム 処理 深い分析. バッチ. 処理. 単純な処理.
オラクル・コンサルが語る! Oracle Exadataの性能...
Transcript of オラクル・コンサルが語る! Oracle Exadataの性能...
オラクル・コンサルが語る!Oracle Exadataの性能を引き出すアプリケーション設計/開発の勘所
日本オラクル株式会社テクノロジーコンサルティング統括本部武吉佑祐
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.3
Program Agenda Exadata向けアプリケーション設計の勘所
- 逐次処理から一括処理へ
- 一括処理の4つのTips- 一括処理にはできないバッチへの対応
- オブジェクト設計の勘所
コンサルが現場で使うチューニング技- SQLチューニングアドバイザを積極的に利用しよう
- Exadataのチューニングの際に見る情報
最後に
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.4
Exadata向けアプリケーション設計の勘所
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.5
主な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の高速化に寄与するものが多い
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.6
処理タイプごとの基本方針まずは、これを押さえてください!
1. OLTPOLTP処理でボトルネックとなりやすいデータファイルI/OはSmart Flash Cache機能、COMMITはSmart Flash Log機能により透過的に高速化します。キャッシュフュージョンも、低レイテンシのInfiniBandにより自動的に高速になります。したがって、Exadataだからと言ってAP側で意識すべきポイントはありません。
2. DWH/BISmart Scan, Storage Index等のFull Scanを高速化するソリューションの恩恵を最大限享受するために、一意性を担保するための一意索引以外の索引を付与しないこと、およびパラレルクエリを使うことを基本方針として設計します。
3. バッチExadataの性能を最大限活用するために、いくつか設計上のポイントがあります!
本日のメイントピック
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.7
大幅に高速化するバッチとしないバッチがある!?Exadataへの移行でよくある話
A)バッチ処理1は、50倍高速化!B)バッチ処理2は、5倍高速化
【Question】なぜ、AとBのケースで高速化の程度に違いがあったのでしょうか?
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.8
逐次処理(ループ)はExadataの性能を引き出せないExadataの高いI/O性能を如何に引き出せるかが重要
【Question】なぜ、AとBのケースで高速化の程度に違いがあったのでしょうか?
Exadataの最大の特徴は、「広いI/Oバンド幅」と「Smart ScanやStorage IndexによるI/O削減機能」なので、1処理あたりのI/O量が小さいループによる逐次処理ではなく、1処理あたりのI/O量が大きい一括処理で性能を最大限に発揮できます。
【Answer】アプリケーションロジックがループ処理中心の逐次処理だったから
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.9
逐次処理と一括処理の例『PRODUCTS表のPRICE列を全て1.1倍にする』
①PRODUCTS表から『1行』取得
APサーバで演算実施
②取得したPRICE値を1.1倍にする
逐次処理の例 一括処理の例
処理①-③をPRODUCTS表のレコード数分繰り返し実行
③UPDATE 文で、
①で取得したレコードを、②で計算したPRICE値に更新する
①PRODUCTS表のレコードを『一括』取得しつつ、DBサーバ側で演算を実施し、演算結果を一括で更新する。
UPDATE products SET price=price*1.1;
DBサーバで演算実施
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.10
大量データ処理の高速化には一括処理
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が一括処理により大幅にパフォーマンスアップする理由
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.11
一括処理の4つのTips
Tips-1: ループ処理を単一のSQLで記述
Tips-2: PL/SQLで負荷をExadataにオフロード
Tips-3: INDEX RANGE SCANよりFULL SCAN、NESTED LOOP結合よりHASH結合
Tips-4: DMLエラーハンドリングの活用
バッチ処理の劇的な高速化を目指すために押さえておきたいこと
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.12
ループ処理を単一の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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.13
更新処理(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で切り替え
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.14
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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.15
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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.16
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ヒントでさらに高速化
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.17
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回目以降の索引スキャンでは最
速であるバッファキャッシュからの読み取りが期待できるので、従来通り索引スキャンが推奨されます。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.18
処理毎に「索引を見せる/見せない」を制御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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.19
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’);
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.20
一括更新処理でのエラーハンドリング「バッチは一括処理が基本です」とお客様に伝えたところ…
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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.21
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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.22
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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.23
一括処理にはできないバッチへの対応ループがあっても修正できないパッケージ製品などへの対応ポイント
一括処理にしたくてもできないパッケージ製品などのバッチの場合、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の待機が多発すると、ボトルネックに
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.24
オブジェクト設計の勘所(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
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.25
コンサルが現場で使うチューニング技
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.26
SQLチューニングアドバイザを積極的に利用しようSQLチューニングアドバイザ、使ったことありますか?
SQLチューニングアドバイザ!?名前は聞いたことあるけど、使ったことないね。
そもそもチューニングアドバイザのアドバイスは信用できるの?
SQLチューニングエキスパート
「チューニングアドバイザなんて信用できない」と思っているチューニングエキスパートの皆さんは結構いらっしゃると思います。しかし、大規模かつミッションクリティカルなお客様を支援することの多いオラクルコンサルも、最近は現場でSQLチューニングアドバイザを使っています。
特に、これまで紹介してきたExadataの性能を引き出す一括処理のアプローチを徹底すると、SQLが長くなることが多くSQLチューニングアドバイザが大活躍します!!
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.27
SQLチューニングアドバイザを利用した運用フロー例
①高負荷SQLの抽出・リスト化
定期的(月次など)に高負荷SQLを抽出し、SQL管理台帳に起票します。
②チューニング要否検討
抽出したSQLについて業務/APチームとチューニング要否を検討します。
③チューニング案検討
SQLチューニングアドバイザにより、チューニングレポートを生成し、チューニングの可否と方針を決定します。
④効果試験
ステージング環境や本番環境にて、チューニング案の妥当性を試験します。
⑤本番へのインプリ
効果の確認できたものについて、本番へのインプリを実施します。
SQLチューニングアドバイザの活用により、チューニング工数の削減と、チューニング方針の属人化防止を図ります。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.28
SQLチューニングアドバイザによる推奨事項
1. 取得漏れ、もしくは失効しているオプティマイザ統計情報対象のSQLがアクセスしている表や索引の中に、統計情報が取得されていないものや
失効しているものがあった場合、その表や索引名と、統計情報取得スクリプトの一例が出力されます。
2. SQLを高速化する新規索引の情報対象のSQLのレスポンスを高速化することが見込める索引の情報を出力します。不適切な索引が既に張られていた場合には、その索引の削除についても推奨事項が生成されます。
3. より最適な実行計画にするためのSQLプロファイルの情報SQLのレスポンスを高速化することが明らかな実行計画にするためのSQLプロファイル情報が出力されます。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.29
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の場合は評価がタイムアウトし、途中で終わったことを示している
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.30
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=‘<カテゴリ名>’;
ステージングではなく、本番環境でプロファイルの評価を行いたい場合
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.31
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がおすすめです。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.32
最後に
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.33
【おさらい】処理タイプごとの基本方針
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を高速化するソリューションの恩恵を最大限享受するために、一意性を担保するための一意索引以外の索引を付与しないこと、およびパラレルクエリを使うことを基本方針として設計します。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.34
本セミナーの内容に関する留意事項
バッチ処理がループ中心の逐次処理であっても、Exadataへの移行により
高速化しないという訳ではありません。
移行元の現行Databaseにて、I/Oがボトルネックとなっている場合などは、
APの改修を伴わない移行においても、数倍高速化することがあります。
Exadataへの移行に際し、バッチの改修を行う工数が
十分に確保できない場合、すべての一括処理化を狙うのではなく、
現行でクリティカルパスとなっている処理を中心に見直しを検討してください。
本資料内に掲載している性能情報については、一例であり、
Exadataの構成やデータ構成/量などによって変動しますので
参考情報として参照ください。
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.35
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.36