<Insert Picture Here>
Oracle
Direct Seminar
オラクルコンサルタントが語る性能分析の真髄 Part2
•
はじめに
•
目的とゴール
•
Part1の振り返り
•
AWRを使用した性能分析
•
AWR概要
•
AWRに格納される情報
•
AWRレポートにおける分析アプローチ
•
AWR確認ポイント
•
Case Study
•
AWRとアーキテクチャの関係
•
まとめ
•
Part2のポイント
•
まとめ
Agenda
<Insert Picture Here>
•
性能分析の重要性を理解する
•
性能分析の具体的な手法を習得する
はじめに
•
AWRレポートのどのセクションでどのような情報を確認するか
理解する
•
AWRレポートの内容とOracle内部アーキテクチャを結びつける
ことができる
本シリーズ目的
Part2のゴール
<Insert Picture Here>
性能分析とは？
性能分析の種類として以下の2パターンが挙げられます。
•
Reactive
な性能分析
•
システムを利用しているサービスのレスポンス遅延・スループット低下などの性能問題が発
生した際に、それら性能問題が発生している原因（ボトルネック）を特定する。
•
問題が発生してから対応するという、事後的な
性能分析。
•
Proactive
な性能分析（能動的な性能分析）
•
システムを利用しているサービスにおいて、レスポンス遅延・スループット低下などの性能問
題やリソース不足による予期せぬ障害を未然に防ぐために、定期的に実施する。
•
問題が発生する前に対応するという、
事前的な
性能分析。
性能分析とは？
2つの性能分析が重要な理由
Reactive
な通院
Proactive
な通院
なんだか体調
が悪いな。。。
インフルエンザな
ので、薬を出しま
しょう！
月に一回の
定期検診だ。
悪くなりそうな所
がないかをチェッ
クしましょう！
人の健康に例えると・・・
「人」を「システム」、「通院」を「性能分析」に置き換えると
性能分析では2つのパターンが重要であることがわかります
性能分析の手法
Reactiveな性能分析
なんだか性能が
出ないなぁ・・・
性能が出ない原因を分
析し、解決しましょう！
正しいアプローチ
1.状況把握
2.考察・分析
3.解決
取得する情報を決定する 分析結果を元に原因追究 問題解決方法の考察正しくないアプローチ
性能が改善する可能性のある策を手
当たり次第に実施
性能が出ないトラブルのため、落ち着
いて対応できない
3.未解決
性能分析の手法
Proactiveな性能分析
チェックポイント
ベースライン活用
キャパシティ・プランニング
パフォーマンスを比較するために、正常に動作している情報を取得。ベースラインによって、 障害時に正常時との違いを比較して、問題点を把握することが可能月に一回の
性能分析だ。
普段から定期的に性能分析を行うことで、将来的なリソースの枯渇を予測し、将来的なリソ ース不足に備えて、事前に準備することが可能問題が発生する前
に事前に性能分析
しておきましょう
問題が発生した時の為
に事前に性能分析して
おきましょう
性能分析における必要情報
性能分析を実施するのに必要な情報
インター ネットデータベース
ファイアー ウォール SQL Java HTML HTML Web サーバー アプリケーション サーバーWebシステム
ネットワークが 狭い？ リクエストが十分 受け付けられない？ AP Serverの負荷は？ メモリ、CPUが足りない？ ネットワーク の負荷は？ DBの負荷は？特定のシステムだけでなく、システム全体の性能情報を取得
各レイヤー毎に網羅的な
リソース情報（CPU、メモリ、Disk、ネットワーク、DB）の取得
今回の焦点
<Insert Picture Here>
AWRレポートを使用した性能分析
検診結果はどう見
ればよいのだろ
う？
定期健診の結果
をお返しします
Proactiveに定期健診を受けた後、重要なのは検診結果を理解し、
現在の健康状態を知ることです。AWRレポートを使用した性能分析では
何を理解すればシステムの状態を理解できるのでしょうか？
Proactiveな通院
月に一回の
定期検診だ。
悪くなりそうな所
がないかをチェッ
クしましょう！
定期健診後
AWRレポートを使用した性能分析
AWR(Automatic Workload Repository) -
概要-
•
DB内部の統計情報(スナップショット)を取得する機能
•
ある2点間で取得したDB内部の統計情報(スナップショット)の差分を元に、その間の
パフォーマンス統計データをレポート出力可能
A
B
スナップショットA スナップショットB AB間のAWRレポート MMON MMON ※ AWRを使用するにはDiagnosticPackライセンスが必要です•
スナップショットの管理方法は2つ
• EM • PL/SQL(DBMS_WORKLOAD_REPOSITORY) AWR スナップショット1 スナップショット2 スナップショット3 スナップショット4 スナップショット5SYSAUX
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に特化した性能分析情報
スナップショット管理
•
AWRレポートの生成方法は2つ
• EM • SQL スナップショットA スナップショットB AB間のAWRレポート $ORACLE_HOME/rdbms/admin/awrrpt.sql•
期間比較
• 異なる期間の間でのAWRレポートを比較することにより、詳細 なパフォーマンスを分析することが可能です • ベースラインとの比較をすることも可能A
C
スナップショットA スナップショットB スナップショットCB
スナップショットDD
AB間のAWRレポート CD間のAWRレポートMMON MMON MMON MMON
Oracle Databaseに特化した性能分析情報
AWRに格納される情報
AWRに格納される情報には、主に下記があります。
データベース・セグメントのアクセス情報
•
セグメント使用量、I/O情報など
時間モデルの情報
（10gからの新しい統計情報）
•
どの処理でどのくらい時間を消費したかの情報
•
V$SYS_TIME_MODELや、V$SESS_TIME_MODEL動的パフォーマンス・ビ
ューから収集
システム、セッションの統計
•
V$SYSSTATやV$SESSTAT動的パフォーマンス・ビューから収集
負荷の高いSQLの情報
•
実行時間やCPUを消費した時間などに基づく
最新のセッション・アクティビティの履歴を表すASH統計
•
1秒毎にサンプリングしている、アクティブなセッション情報
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レポートの項目には、以下の情報が格納されます。
<Insert Picture Here>
①
Load Profile
•
DBの処理量を表示します。
②
Instance Efficiency
•
Oracleインスタンスの使用効率を表示します。
③
Top5 Timed Events
•
処理時間の長い上位５番目までのイベントを表示します。
④
SQLセクション
•
各処理におけるSQL文のランキング表示します。
AWR確認ポイント
まず確認すべきポイント
AWRには、たくさんの情報が格納されますが、まず確認ポイントとして下記があります。
確認ポイント
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から、システムの処理負荷を確認します。定常時の性能分析では、
普段システムにどの程度処理が流れているのかを確認し、障害時の性能分析時に処理負荷を比
較します。
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
AWR確認ポイント
③Top5 Timed Event
AWR取得時の処理における上位5位までの待機イベントを把握することが可能です。
Event ：イベント名
Waits ：イベントのために待機した合計回数
Time(s) ：イベントの合計待機時間および合計CPU時間(秒) % Total Ela Time ：全体に対する、このイベントおよびCPU時間の割合 (各イベント待機時間／合計処理時間) 通常時：通常負荷時の上位待 機イベントを確認。 障害時：障害発生時の上位待 機イベントを確認可能。通常時 の待機イベントと比較。
ポイント
Top5待機イベントにて、CPUTimeが上位にある場合は、Oracleの処理として効率的にCPUが利
用できているという観点から、ほとんどのケースは特に問題ありません。
一方で、CPU Timeが下位の場合は待機イベントが多いことを意味します。
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実行時間の関係性を確認します。
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と比較し、傾向が変化し ていないか、実行回数や処理時間 が増加していないか比較。Case Study
概要
•
AWRレポートにおける分析アプローチ
A社では、プロアクティブな性能分析を行うために、
日頃からAWRを取得しています。
ある日、アプリ側から「『お客様から画面のレスポンスが遅くなった。』と
言われたのですが、DB側で問題はありませんか？
アプリ側では問題は発見できなかったので、DB側を調査して
いただけませんか？」とリクエストを頂きました。
遅くなったなぁ
AWRを使用して、
どのように性能分析を進めますか？
Case Studyのポイント
Case Study
AWRレポートにおける分析アプローチ
確認すべきポイントの１つである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セクション
Case Study
オラクルコンサルの分析アプローチのポイント
？
db file sequential readが 多発しているということは・・・？
「Summary→物理読み込みの多いセグメント」と分析を進められたのは、Oracle
のアーキテクチャを理解しているため
データ・ファイル 制御ファイル REDOログ・ ファイル サーバー プロセス メモリ（SGA） 共有プール DBバッファ・ キャッシュ REDOログ・ バッファ ライブラリ・ キャッシュ ディクショナリ・ キャッシュ SQL文と実行計画 データ・ディクショナリ 情報 変更履歴 X→Y COMMIT CKPT LGWR < SQL文 > の発行 DBWｎポイント
分析を進めるためには、Oracleのアーキテクチャの理解が重要です。
<Insert Picture Here>
Oracle内部アーキテクチャとAWRレポート
Select時の動き
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ Select ①検索要求 ユーザ・ プロセス サーバ・ プロセス ②検索要求を受け取り SQL文の構文チェック ⑦ソートが必要な 場合PGAで行うPGA
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(1/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ Select ①検索要求 ユーザ・ プロセス サーバ・ プロセス ②検索要求を受け取り SQL文の構文チェック ⑦ソートが必要な 場合PGAが行うPGA
SQLが実行されるので、実行回数がカウントされます。
- Load Profile：Executes
- Instance Activity Stats：execute count
- SQL ordered by Executions
etc…
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(1/6)
SQLが発行される度に増加するため、
SQLの発行回数の妥当性や傾向変化を
把握することができます。
また、先ほどの select 実行時のアーキ
テクチャより、構文エラーとなるSQLが発
行された際にもExecute値は増加するた
め、Instance Activity Stats : parse
count (failures) も合わせて確認します。
アプローチ
Load Profile からは個別SQL の詳細な実行回数はつかめ ません。リカーシブルコールも 含んでしまうためです。詳細 な傾向把握にはSQL order by ～ を確認する必要があり ます。Oracle内部アーキテクチャとAWRレポート
Select時のAWR(2/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ 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…
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(3/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ 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…
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 機 能による影響も考慮する必要が あります。(※)
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(4/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ 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
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(4/6)
前述の通り、Buffer Hit % が高くとも Buffer Nowait % が低い場合にはバッファキャッシュでの待機が
発生している可能性が大きいです。
そのような場合には Buffer wait Statistics などを確認して「どのブロックでバッファ待機が発生している
のか」を調査する必要があります。
アプローチ
Oracleのブロック管理アーキテク チャがわからないと、バッファ待 機が発生していても競合解消策 が立てられないです。 発生事象と対応策を結びつける ためにはアーキテクチャが大切で す。Oracle内部アーキテクチャとAWRレポート
Select時のAWR(5/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ Select ①検索要求 ユーザ・ プロセス サーバ・ プロセス ②検索要求を受け取り SQL文の構文チェック ⑦ソートが必要な 場合PGAで行うPGA
バッファ・キャッシュに取得対象となるブロックが存在しなければ、Diskから対象ブ
ロックの読み込みを行ないます。
- Load Profile: Physical reads
- Instance Activity Stats: physical readsなど
- Segments by Physical Reads
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(5/6)
バッファキャッシュヒット率が想定より低い場合には、
Segments by Physical Reads などから物理ブロッ
ク読み込みの多いセグメントを調査し、妥当性を判
断します。
KEEP句を利用して読み込みブロックをバッファキ
ャッシュに強制的に載せる際にはバッファキャッシ
ュを構成するブロックの傾向が大きく変わる可能性
がある為、他のSQLへの影響を考慮する必要があ
ります。
アプローチ
11gR2 から実装されたDatabase Smart Flash Cache 機能により Diskアクセスよりも高速なSSDを バッファキャッシュの拡張領域とし て利用することが可能になりまし た。新機能もアーキテクチャから 把握しておくことが大切です。Oracle内部アーキテクチャとAWRレポート
Select時のAWR(6/6)
データファイル
REDOログファイル
DBバッファキャッシュ
REDOログバッファ
共有プール
SGA
制御ファイル
③Parse結果が存在するかチェック 実行計画 ④実行計画を 作成・格納 （オプティマイ ザ） ⑤該当ブロックが 存在するかチェック データブロック ＵＮＤＯ 30 行3 20 行2 10 行1 ⑥データファイル を 読込む 30 行3 20 行2 10 行1 ⑧結果を返す 10 行１ 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…
Oracle内部アーキテクチャとAWRレポート
Select時のAWR(6/6)
メモリ内ソートではPGA (MTSでは共有プール or ラージプール)が利用されますが、PGA領域に
も限りがある為、システム特性に合わせたソート処理傾向を把握する必要があります。
アプローチ
場合によってはINDEXを上手く 利用することで、ソート処理を 避けられるケースもあります。 INDEXの構造をアーキテクチャ と紐付けて理解しておくことで、 発生事象と対応策が結びつき ます。AWRレポートにおける分析アプローチ
AWRレポートの項目を理解しているだけではなく、Oracleのアーキテクチャ
と関連させて理解すること
AWRとアーキテクチャを結び付けて考えることができると、より詳細な性能
分析が可能
データ・ファイル 制御ファイル REDOログ・ ファイル サーバー プロセス メモリ（SGA） 共有プール DBバッファ・ キャッシュ REDOログ・ バッファ ライブラリ・ キャッシュ ディクショナリ・ キャッシュ SQL文と実行計画 データ・ディクショナリ 情報 変更履歴 X→Y COMMIT CKPT LGWR < SQL文 > の発行 DBWｎ性能分析を進めるにあたり以下が重要です。
<Insert Picture Here>
AWRレポートのどのセクションでどのような情報を確認するか
理解すること
まず見るべき項目として以下を確認する。
ポイント1
Part2のポイント
ポイント2
AWRレポートの内容とOracle内部アーキテクチャを結びつけて
性能分析を進めること
1. Load Profile 2. Instance Efficiency3. Top5 Timed Events
