51
<Insert Picture Here> Oracle Direct Seminar オラクルコンサルタントが語る性能分析の真髄 Part2 日本オラクル株式会社

Oracle Direct Seminar...負荷の高いSQLの情報 • 実行時間やCPUを消費した時間などに基づく 最新のセッション・アクティビティの履歴を表すASH統計

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

<Insert Picture Here>

Oracle Direct Seminar

オラクルコンサルタントが語る性能分析の真髄 Part2

日本オラクル株式会社

Copyright© 2012, Oracle. All rights reserved. 2

• はじめに

• 目的とゴール

• Part1の振り返り

• AWRを使用した性能分析

• AWR概要

• AWRに格納される情報

• AWRレポートにおける分析アプローチ

• AWR確認ポイント

• Case Study

• AWRとアーキテクチャの関係

• まとめ

• Part2のポイント

• まとめ

Agenda

Copyright© 2012, Oracle. All rights reserved. 3

<Insert Picture Here>

はじめに

Copyright© 2012, Oracle. All rights reserved. 4

• 性能分析の重要性を理解する

• 性能分析の具体的な手法を習得する

はじめに

• AWRレポートのどのセクションでどのような情報を確認するか理解する

• AWRレポートの内容とOracle内部アーキテクチャを結びつけることができる

本シリーズ目的

Part2のゴール

Copyright© 2012, Oracle. All rights reserved. 5

<Insert Picture Here>

Part 1の振り返り

Copyright© 2012, Oracle. All rights reserved.

性能分析とは?

性能分析の種類として以下の2パターンが挙げられます。

• Reactiveな性能分析

• システムを利用しているサービスのレスポンス遅延・スループット低下などの性能問題が発生した際に、それら性能問題が発生している原因(ボトルネック)を特定する。

• 問題が発生してから対応するという、事後的な性能分析。

• Proactiveな性能分析(能動的な性能分析) • システムを利用しているサービスにおいて、レスポンス遅延・スループット低下などの性能問題やリソース不足による予期せぬ障害を未然に防ぐために、定期的に実施する。

• 問題が発生する前に対応するという、事前的な性能分析。

6

Copyright© 2012, Oracle. All rights reserved.

性能分析とは? 2つの性能分析が重要な理由

7

Reactiveな通院 Proactiveな通院

なんだか体調が悪いな。。。

インフルエンザなので、薬を出しましょう!

月に一回の

定期検診だ。

悪くなりそうな所がないかをチェックしましょう!

人の健康に例えると・・・

「人」を「システム」、「通院」を「性能分析」に置き換えると

性能分析では2つのパターンが重要であることがわかります

Copyright© 2012, Oracle. All rights reserved.

性能分析の手法 Reactiveな性能分析

なんだか性能が出ないなぁ・・・

性能が出ない原因を分析し、解決しましょう!

正しいアプローチ

1.状況把握

2.考察・分析

3.解決

取得する情報を決定する

分析結果を元に原因追究 問題解決方法の考察

正しくないアプローチ

性能が改善する可能性のある策を手当たり次第に実施

性能が出ないトラブルのため、落ち着いて対応できない

3.未解決

8

Copyright© 2012, Oracle. All rights reserved.

性能分析の手法 Proactiveな性能分析

チェックポイント

ベースライン活用

キャパシティ・プランニング

パフォーマンスを比較するために、正常に動作している情報を取得。ベースラインによって、障害時に正常時との違いを比較して、問題点を把握することが可能

月に一回の

性能分析だ。

普段から定期的に性能分析を行うことで、将来的なリソースの枯渇を予測し、将来的なリソース不足に備えて、事前に準備することが可能

問題が発生する前に事前に性能分析しておきましょう

問題が発生した時の為に事前に性能分析しておきましょう

9

Copyright© 2012, Oracle. All rights reserved. 10

性能分析における必要情報 性能分析を実施するのに必要な情報

インター

ネット

データベース

ファイアー

ウォール

SQL

Java

HTML

HTML

Web

サーバー アプリケーション

サーバー

Webシステム

ネットワークが 狭い?

リクエストが十分 受け付けられない?

AP Serverの負荷は? メモリ、CPUが足りない?

ネットワークの負荷は?

DBの負荷は?

特定のシステムだけでなく、システム全体の性能情報を取得

各レイヤー毎に網羅的な

リソース情報(CPU、メモリ、Disk、ネットワーク、DB)の取得

今回の焦点

Copyright© 2012, Oracle. All rights reserved. 11

<Insert Picture Here>

AWRレポートを使用した性能分析

Copyright© 2012, Oracle. All rights reserved. 12

AWRレポートを使用した性能分析

検診結果はどう見ればよいのだろう?

定期健診の結果をお返しします

Proactiveに定期健診を受けた後、重要なのは検診結果を理解し、

現在の健康状態を知ることです。AWRレポートを使用した性能分析では

何を理解すればシステムの状態を理解できるのでしょうか?

Proactiveな通院

月に一回の

定期検診だ。

悪くなりそうな所がないかをチェックしましょう!

定期健診後

Copyright© 2012, Oracle. All rights reserved.

AWRレポートを使用した性能分析AWR(Automatic Workload Repository) -概要-

• DB内部の統計情報(スナップショット)を取得する機能

• ある2点間で取得したDB内部の統計情報(スナップショット)の差分を元に、その間のパフォーマンス統計データをレポート出力可能

13

A B

スナップショットA スナップショットB

AB間のAWRレポート

MMON MMON

※ AWRを使用するにはDiagnosticPackライセンスが必要です

Copyright© 2012, Oracle. All rights reserved.

• スナップショットの管理方法は2つ • EM

• PL/SQL(DBMS_WORKLOAD_REPOSITORY)

14

AWR

スナップショット1

スナップショット2

スナップショット3

スナップショット4

スナップショット5

SYSAUX

60分

SGA

MMON

MMON

8日間

CREATE_SNAPSHOT

DROP_SNAPSHOT_RANGE

MODIFY_SNAPSHOT_SETTINGS

パフォーマンス・テストを実施するため、自動スナップショット取得間隔をデフォルトの60分から10分に変更し、性能分析を実施したい

CASE2

begin

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(11520,10);

end;

手動でスナップショットを取得し、性能分析を実施したい

CASE1

begin

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

end;

SYSAUX表領域が圧迫されてきたため、スナップショットID1000 - 2000のスナップショット削除を実施したい

CASE3

begin

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(1000,2000);

end;

Oracle Databaseに特化した性能分析情報スナップショット管理

Copyright© 2012, Oracle. All rights reserved.

• AWRレポートの生成方法は2つ • EM

• SQL

15

スナップショットA スナップショットB

AB間のAWRレポート

$ORACLE_HOME/rdbms/admin/awrrpt.sql

• 期間比較

• 異なる期間の間でのAWRレポートを比較することにより、詳細なパフォーマンスを分析することが可能です

• ベースラインとの比較をすることも可能

A C

スナップショットA スナップショットC スナップショットB

B

スナップショットD

D

AB間のAWRレポート CD間のAWRレポート

MMON MMON MMON MMON

Oracle Databaseに特化した性能分析情報AWR レポートの作成

Copyright© 2012, Oracle. All rights reserved. 16

AWRに格納される情報

AWRに格納される情報には、主に下記があります。

データベース・セグメントのアクセス情報 • セグメント使用量、I/O情報など

時間モデルの情報(10gからの新しい統計情報)

• どの処理でどのくらい時間を消費したかの情報

• V$SYS_TIME_MODELや、V$SESS_TIME_MODEL動的パフォーマンス・ビューから収集

システム、セッションの統計 • V$SYSSTATやV$SESSTAT動的パフォーマンス・ビューから収集

負荷の高いSQLの情報 • 実行時間やCPUを消費した時間などに基づく

最新のセッション・アクティビティの履歴を表すASH統計 • 1秒毎にサンプリングしている、アクティブなセッション情報

Copyright© 2012, Oracle. All rights reserved. 17

AWRに格納される情報

• Main Report 1. Report Summary

2. 待機イベント統計

3. SQL

4. インスタンス統計

5. I/O統計

6. バッファ・プール統計

7. アドバイザ統計

8. Wait Statistics

9. Undo統計

10. ラッチ統計

11. セグメント統計

12. ディクショナリ・キャッシュ統計

13. ライブラリ・キャッシュ統計

14. メモリー統計

15. ストリーム統計

16. リソース制限統計

17. init.ora パラメータ(初期化パラメータ)

More RAC Statistics 18. RACに関する追加情報レポート

19. グローバル・エンキュー統計

20. グローバルCR 統計

21. 実行済のグローバル・カレント統計

22. グローバル・キャッシュの送信統計

AWRレポートの項目には、以下の情報が格納されます。

Copyright© 2012, Oracle. All rights reserved. 18

<Insert Picture Here>

AWRレポートにおける分析アプローチ

Copyright© 2012, Oracle. All rights reserved. 19

①Load Profile • DBの処理量を表示します。

②Instance Efficiency • Oracleインスタンスの使用効率を表示します。

③Top5 Timed Events • 処理時間の長い上位5番目までのイベントを表示します。

④SQLセクション • 各処理におけるSQL文のランキング表示します。

AWR確認ポイント まず確認すべきポイント

AWRには、たくさんの情報が格納されますが、まず確認ポイントとして下記があります。

確認ポイント

Copyright© 2012, Oracle. All rights reserved. 20

AWR確認ポイント ①Load Profile

Load Profileを確認すると、AWR取得時の時間帯におけるDBの処理傾向を把握することができます。

Redo size :生成されたREDOサイズ(Byte)

Physical reads :ディスクから直接読み出したブロック数

Physical writes :ディスクへ直接書き出したブロック数

Parses :解析コール数

Hard parses :コストの高い解析コール数

Logons :ログオン数

Executes : SQL文を実行するコール数

Transactions :トランザクション数

通常時:

Redoサイズや、ディスク読み込みがどの程度発生しているか等の確認。

障害時:

通常時の処理負荷と障害発生時の処理負荷の比較。

ポイント

SQLの実行回数や、DB CPUから、システムの処理負荷を確認します。定常時の性能分析では、普段システムにどの程度処理が流れているのかを確認し、障害時の性能分析時に処理負荷を比較します。

Copyright© 2012, Oracle. All rights reserved. 21

AWR確認ポイント ②Instance Efficiency

AWR取得時の処理におけるOracleインスタンス使用効率を把握することが可能です。

Buffer Nowait % :DBバッファに要求を出したときに、即座に使用可能だった割合 Redo NoWait % :redo logに要求を出したときに、即座に使用可能だった割合 Buffer Hit % :DBバッファキャッシュから読みとった割合 Soft Parse % :全ての解析のうち再利用可能なものの割合 Non-Parse CPU % :1-(解析CPU時間 / 全CPU時間)

通常時:バッファヒット率や、ソフトパースの割合等を確認。

障害時:

通常時とのヒット率の比較。

ポイント

OLTP系の処理であれば、Buffer Hit%、Library Hit%は90%程度あることを目安とします。

Buffer Hit%が低い場合は、その分IO処理が多い傾向があります。また、Library Hit%と、Soft Parse%は依存関係にあり、Library Hit%が低い場合は、Hard Parseが占める割合が多くなります。

Copyright© 2012, Oracle. All rights reserved. 22

AWR確認ポイント ③Top5 Timed Event

AWR取得時の処理における上位5位までの待機イベントを把握することが可能です。

Event :イベント名 Waits :イベントのために待機した合計回数 Time(s) :イベントの合計待機時間および合計CPU時間(秒) % Total Ela Time :全体に対する、このイベントおよびCPU時間の割合 (各イベント待機時間/合計処理時間)

通常時:通常負荷時の上位待機イベントを確認。

障害時:障害発生時の上位待機イベントを確認可能。通常時の待機イベントと比較。

ポイント

Top5待機イベントにて、CPUTimeが上位にある場合は、Oracleの処理として効率的にCPUが利用できているという観点から、ほとんどのケースは特に問題ありません。

一方で、CPU Timeが下位の場合は待機イベントが多いことを意味します。

Copyright© 2012, Oracle. All rights reserved. 23

AWR確認ポイント ④SQLセクション~SQL ordered by Gets

AWR取得時の処理における各SQLセクションを把握することが可能です。

SQL ordered by Getsは合計アクセスバッファ数が多いSQLのランキング(N位以上)を示しています。

Gets per Exec :アクセスされたバッファ数/実行回数 % Total :アクセスされたバッファの割合 CPU Time(s) :このSQL文実行に対する累積CPU時間(秒)<新> Elapsd Time(s):このSQL文の累積実行時間(秒)<新> Hash value :共有プール内のSQLテキストのハッシュ値

通常時:普段論理読み込みが多いSQLの把握が可能。また、それらがどの程度の実行回数を占めているのか等も確認。

障害時:通常時の論理読み込みの多いSQLと比較し、傾向が変化していないか、実行回数等が増えていないか比較。

ポイント

定常時のバッファ読み込みブロック数と、異常時のバッファ読み込み数を比較して、読み込みブロック数とSQL実行時間の関係性を確認します。

Copyright© 2012, Oracle. All rights reserved. 24

AWR確認ポイント ④SQLセクション~SQL ordered by Reads

AWR取得時の処理における各SQLセクションを把握することが可能です。

SQL ordered by Readsは合計Diskアクセス数が多いSQLのランキング(N位以上)を示しています。

Reads per Exec:ディスクへのアクセス回数/SQL文の実行回数 % Total :アクセスされたバッファの割合 CPU Time(s) :このSQL文実行に対する累積CPU時間(秒)<新> Elapsd Time(s):このSQL文の累積実行時間(秒)<新> Hash Value :共有プール内のSQLテキストのハッシュ値 ポイント

定常時のディスク読み込み数と、異常時のディスク読み込み数を比較して、ディスクへのアクセスが頻発していないかどうかを確認します。

通常時:普段物理読み込みが多いSQLの把握が可能。また、それらがどの程度の実行回数や、1回における処理時間等も確認。

障害時:通常時の物理読み込みの多いSQLと比較し、傾向が変化していないか、実行回数や処理時間が増加していないか比較。

Copyright© 2012, Oracle. All rights reserved. 25

Case Study 概要

• AWRレポートにおける分析アプローチ

A社では、プロアクティブな性能分析を行うために、

日頃からAWRを取得しています。

ある日、アプリ側から「『お客様から画面のレスポンスが遅くなった。』と

言われたのですが、DB側で問題はありませんか?

アプリ側では問題は発見できなかったので、DB側を調査して

いただけませんか?」とリクエストを頂きました。 遅くなったなぁ

AWRを使用して、 どのように性能分析を進めますか?

Case Studyのポイント

Copyright© 2012, Oracle. All rights reserved. 26

Case Study AWRレポートにおける分析アプローチ 確認すべきポイントの1つであるTop 5 Timed Eventsで待機イベント“db_file_sequential_read”

が多発していることがわかりました。

“Top 5 wait event” から待機イベント “db file

sequential read” が多発、物理読み込みの多いセグメントは”IO_NECK_TAB_IX” と呼ばれるINDEX であり、IO待機が発生している。

特定セグメントでのIO待機が発生しているということは・・・・

①Load Profile ②Instance Efficiency

③Top5 Timed Events ④SQLセクション

アセスメント

Copyright© 2012, Oracle. All rights reserved. 27

Case Study オラクルコンサルの分析アプローチのポイント

? db file sequential readが

多発しているということは・・・?

「Summary→物理読み込みの多いセグメント」と分析を進められたのは、Oracle

のアーキテクチャを理解しているため

データ・ファイル 制御ファイル REDOログ・ ファイル

サーバー

プロセス

メモリ(SGA) 共有プール DBバッファ・

キャッシュ REDOログ・ バッファ ライブラリ・

キャッシュ

ディクショナリ・ キャッシュ

SQL文と実行計画

データ・ディクショナリ

情報

変更履歴

X→Y

COMMIT

CKPT LGWR

< SQL文 >

の発行

DBWn

ポイント

分析を進めるためには、Oracleのアーキテクチャの理解が重要です。

Copyright© 2012, Oracle. All rights reserved. 28

<Insert Picture Here>

AWRとアーキテクチャの関係

Copyright© 2012, Oracle. All rights reserved. 29

Oracle内部アーキテクチャとAWRレポートSelect時の動き

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAで行う

PGA

Copyright© 2012, Oracle. All rights reserved. 30

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(1/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAが行う

PGA

SQLが実行されるので、実行回数がカウントされます。

- Load Profile:Executes

- Instance Activity Stats:execute count

- SQL ordered by Executions etc…

Copyright© 2012, Oracle. All rights reserved. 31

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(1/6)

SQLが発行される度に増加するため、

SQLの発行回数の妥当性や傾向変化を

把握することができます。

また、先ほどの select 実行時のアーキテクチャより、構文エラーとなるSQLが発行された際にもExecute値は増加するため、Instance Activity Stats : parse

count (failures) も合わせて確認します。

アプローチ

Load Profile からは個別SQL

の詳細な実行回数はつかめません。リカーシブルコールも含んでしまうためです。詳細な傾向把握にはSQL order

by ~ を確認する必要があります。

Copyright© 2012, Oracle. All rights reserved. 32

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(2/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAで行う

PGA

Parser により実行 SQL が Parse されます。 (Parse 結果が既に共有プールに存在する場合soft parse・存在しない場合hard parse)

- Load Profile:Parses

- Instance Efficiency Percentages (Target 100%) : Soft Parse %/Latch Hit %

- Instance Activity Stats: parse count (total)/ parse time cpu/ parse time elapsed

- SQL ordered by Parse Calls etc…

Copyright© 2012, Oracle. All rights reserved. 33

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(3/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAで行う

PGA

Parse 結果が共有プールへキャッシュされていない際はHard parseが行われます。

- Load Profile: Hard parses

- Instance Efficiency Percentages (Target 100%) : Parse CPU to Parse Elapsd %

- Time Model Statistics:hard parse elapsed time

- Instance Activity Stats: parse count (hard) / parse time cpu / parse time elapsed

- SQL ordered by Parse Calls etc…

Copyright© 2012, Oracle. All rights reserved. 34

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(2,3/6)

これらの値はSoft Parse / Hard Parse 処理頻度や処理時間を基に算出されています。

その為、Soft Parse/Hard Parse の割合は適切であるか、SQLの実行時間(Elapse

time)におけるParse 処理時間の割合は適切であるかといった点を確認したりします。

(※) 詳細説明は「オラクルコンサルが語る 新しいチューニング&運用アプローチ」で紹介しております。

アプローチ

実行SQLがバインド化されているにも関わらずHard Parse が多い場合にはCardinality Feedback

やAdaptive Cursor Sharing 機能による影響も考慮する必要があります。(※)

Copyright© 2012, Oracle. All rights reserved. 35

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(4/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAで行う

PGA

バッファ・キャッシュに取得対象となるブロックが存在するかを確認します。

(存在すればそのまま読込みを実施、しなければDiskからブロックを読込みます。)

- Instance Efficiency Percentages (Target 100%) : Buffer Hit % / Buffer Nowait %

- Buffer Pool Statistics:Buffer Gets/Buffer Busy Waits

- Buffer Pool Advisory

- SQL ordered by Gets etc…

Copyright© 2012, Oracle. All rights reserved. 36

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(4/6)

前述の通り、Buffer Hit % が高くとも Buffer Nowait % が低い場合にはバッファキャッシュでの待機が発生している可能性が大きいです。

そのような場合には Buffer wait Statistics などを確認して「どのブロックでバッファ待機が発生しているのか」を調査する必要があります。

アプローチ

Oracleのブロック管理アーキテクチャがわからないと、バッファ待機が発生していても競合解消策が立てられないです。

発生事象と対応策を結びつけるためにはアーキテクチャが大切です。

Copyright© 2012, Oracle. All rights reserved. 37

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(5/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAで行う

PGA

バッファ・キャッシュに取得対象となるブロックが存在しなければ、Diskから対象ブロックの読み込みを行ないます。

- Load Profile: Physical reads

- Instance Activity Stats: physical readsなど

- Segments by Physical Reads

- SQL ordered by Physical Reads etc…

Copyright© 2012, Oracle. All rights reserved. 38

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(5/6)

バッファキャッシュヒット率が想定より低い場合には、Segments by Physical Reads などから物理ブロッ

ク読み込みの多いセグメントを調査し、妥当性を判断します。

KEEP句を利用して読み込みブロックをバッファキ

ャッシュに強制的に載せる際にはバッファキャッシュを構成するブロックの傾向が大きく変わる可能性がある為、他のSQLへの影響を考慮する必要があります。

アプローチ

11gR2 から実装されたDatabase

Smart Flash Cache 機能によりDiskアクセスよりも高速なSSDをバッファキャッシュの拡張領域として利用することが可能になりました。新機能もアーキテクチャから把握しておくことが大切です。

Copyright© 2012, Oracle. All rights reserved. 39

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(6/6)

データファイル REDOログファイル

DBバッファキャッシュ 共有プール REDOログバッファ SGA

制御ファイル

③Parse結果が存在するかチェック

実行計画

④実行計画を 作成・格納 (オプティマイザ)

⑤該当ブロックが存在するかチェック

データブロック UNDO

30 行3

20 行2

10 行1

⑥データファイル を 読込む

30 行3

20 行2

10 行1

⑧結果を返す

10 行1

Select

①検索要求

ユーザ・ プロセス

サーバ・ プロセス

②検索要求を受け取りSQL文の構文チェック

⑦ソートが必要な場合PGAが行う

PGA

SQL文に応じて取得結果のソートを行います。メモリ領域(PGA)でソートを実施しようとしますが、PGA内で完了しない場合はDiskでソートを行います。

- Instance Efficiency Percentages (Target 100%) : In-memory Sort %

- Instance Activity Stats: sorts (disk) / sorts (memory) / sorts (rows) etc…

Copyright© 2012, Oracle. All rights reserved. 40

Oracle内部アーキテクチャとAWRレポートSelect時のAWR(6/6)

メモリ内ソートではPGA (MTSでは共有プール or ラージプール)が利用されますが、PGA領域にも限りがある為、システム特性に合わせたソート処理傾向を把握する必要があります。

アプローチ

場合によってはINDEXを上手く利用することで、ソート処理を避けられるケースもあります。

INDEXの構造をアーキテクチャと紐付けて理解しておくことで、発生事象と対応策が結びつきます。

Copyright© 2012, Oracle. All rights reserved. 41

AWRレポートにおける分析アプローチ

AWRレポートの項目を理解しているだけではなく、Oracleのアーキテクチャと関連させて理解すること

AWRとアーキテクチャを結び付けて考えることができると、より詳細な性能分析が可能

データ・ファイル 制御ファイル REDOログ・ ファイル

サーバー

プロセス

メモリ(SGA) 共有プール DBバッファ・

キャッシュ REDOログ・ バッファ ライブラリ・

キャッシュ

ディクショナリ・ キャッシュ

SQL文と実行計画

データ・ディクショナリ

情報

変更履歴

X→Y

COMMIT

CKPT LGWR

< SQL文 >

の発行

DBWn

性能分析を進めるにあたり以下が重要です。

Copyright© 2012, Oracle. All rights reserved. 42

<Insert Picture Here>

まとめ

Copyright© 2012, Oracle. All rights reserved. 43

AWRレポートのどのセクションでどのような情報を確認するか

理解すること

まず見るべき項目として以下を確認する。

ポイント1

Part2のポイント

ポイント2

AWRレポートの内容とOracle内部アーキテクチャを結びつけて

性能分析を進めること

1. Load Profile

2. Instance Efficiency

3. Top5 Timed Events

4. SQLセクション

Copyright© 2012, Oracle. All rights reserved. 44

• 性能分析の重要性を理解する

• 性能分析の具体的な手法を習得する

本シリーズ目的

まとめ

Part2のゴール

• AWRレポートのどのセクションでどのような情報を確認するか理解すること

• AWRレポートの内容とOracle内部アーキテクチャを結びつけること

Copyright© 2012, Oracle. All rights reserved. 45

http://blogs.oracle.com/oracle4engineer/entry/otn_ondemand_questionnaire

OTNオンデマンド 感想

OTNセミナーオンデマンド

コンテンツに対する ご意見・ご感想を是非お寄せください。

上記に簡単なアンケート入力フォームをご用意しております。

セミナー講師/資料作成者にフィードバックし、 コンテンツのより一層の改善に役立てさせていただきます。

是非ご協力をよろしくお願いいたします。

Copyright© 2012, Oracle. All rights reserved.

OTNセミナーオンデマンド 日本オラクルのエンジニアが作成したセミナー資料・動画ダウンロードサイト

掲載コンテンツカテゴリ(一部抜粋)

Database 基礎

Database 現場テクニック

Database スペシャリストが語る

Java

WebLogic Server/アプリケーション・グリッド

EPM/BI 技術情報

サーバー

ストレージ

例えばこんな使い方

• 製品概要を効率的につかむ

• 基礎を体系的に学ぶ/学ばせる

• 時間や場所を選ばず(オンデマンド)に受講

• スマートフォンで通勤中にも受講可能

100以上のコンテンツをログイン不要でダウンロードし放題

データベースからハードウェアまで充実のラインナップ

毎月、旬なトピックの新作コンテンツが続々登場

46

OTNオンデマンド

コンテンツ一覧 はこちら http://www.oracle.com/technetwork/jp/ondemand/index.html

新作&おすすめコンテンツ情報 はこちら http://oracletech.jp/seminar/recommended/000073.html 毎月チェック!

Copyright© 2012, Oracle. All rights reserved.

オラクルエンジニア通信 オラクル製品に関わるエンジニアの方のための技術情報サイト

47

オラクルエンジニア通信

技術コラム

アクセス ランキング

特集テーマ Pick UP

技術資料

性能管理やチューニングなど月間テーマを掘り下げて詳細にご説明

インストールガイド・設定チュートリアルetc. 欲しい資料への最短ルート

他のエンジニアは何を見ているのか?人気資料のランキングは毎月更新

SQLスクリプト、索引メンテナンスetc. 当たり前の運用/機能が見違える!?

http://blogs.oracle.com/oracle4engineer/

Copyright© 2012, Oracle. All rights reserved.

oracletech.jp ITエンジニアの皆様に向けて旬な情報を楽しくお届け

48

oracletech

Viva! Developer

セミナー

スキルアップ

製品/技術 情報

ORACLE MASTER! 試験頻出分野の模擬問題と解説を好評連載中

Oracle Databaseっていくら?オプション機能も見積れる簡単ツールが大活躍

基礎から最新技術まで お勧めセミナーで自分にあった学習方法が見つかる

全国で活躍しているエンジニアにスポットライト。きらりと輝くスキルと視点を盗もう

http://oracletech.jp/

Copyright© 2012, Oracle. All rights reserved. 49

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

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

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

0120-155-096

※月曜~金曜 9:00~12:00、13:00~18:00 (祝日および年末年始除く)

専用お問い合わせフォームにてご相談内容を承ります。 http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

※フォームの入力にはログインが必要となります。 ※こちらから詳細確認のお電話を差し上げる場合がありますので ご登録の連絡先が最新のものになっているかご確認下さい。

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。 ステム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

Oracle Direct

Copyright© 2012, Oracle. All rights reserved.

Copyright© 2012, Oracle. All rights reserved. 51