Em12C

からのAWRレポートの操作私は最近、AWRレポートの操作に関する更新を書くように要求していましたので、約束どおり、ここにあります！

Automatic Workload Repository

Automatic Workload Repository(AWR)は、リリース10gのOracleにとって最高の機能強化の一つでした。

1. 以前のstatspackよりも大幅なパフォーマンスの推奨と待機イベントデータの機能強化を提供しました。

2. つまり、データベース管理者からの手動の介入なしに、データが継続的に収集されます。

3. 独自のバックグラウンドプロセスとメモリバッファ、指定された表領域(SYSAUX)を持つ、現在の処理には影響しません。

4. メモリバッファは、ユーザーが読み取る方向とは逆の方向に書き込み、並行性の問題を排除します。

他の多くの要件とともに、上記のすべてが自動ワークロードリポジトリで提供され、次のようなアーキテクチャになります:

pt5

AWRデータの使用AWRデータは、DBID(データベース識別子)とSNAP_ID(スナップショット識別子)によって識別され、begin_interval_timeとend_interval_timeがあり、データ収集の日付と時刻を分離します。 また、データベースに現在保持されているものに関する情報は、DBA_HIST_SNAPSHOTから照会することができます。 AWRデータには、ASH(アクティブセッション履歴)サンプルとスナップショットデータも含まれており、デフォルトでは10サンプルごとに約1

AWRデータを効果的に使用するという目標は、実際には次のことに関係しています:

1. パフォーマンスレビューの一環として、真のパフォーマンスの問題を特定しましたか？

2. ユーザーからの苦情やパフォーマンスの低下を調査する要求はありますか？

3. AWRが答えを提供できるビジネス上の課題や質問に答える必要がありますか？ (AWRと他の機能をいつ使用するかについて説明します…)

パフォーマンスレビュー

パフォーマンスレビューとは、問題を特定したか、パフォーマンスの問題を解決するための環境を調査するために割り当てられた場所です。 私はいくつかのEnterprise Manager環境を利用できますが、私はこの投稿の要件に合うように重い処理をすることを望んで、特に1つに出かけて指を交差させるこ

Em12Cからデータベース環境のワークロードを最も簡単に確認するには、ターゲット–>データベースをクリックします。 ロードマップ別に表示することを選択すると、ワークロード別にデータベースが表示されます。 特定のEnterprise Manager環境に行くと、私はそれが私の幸運な日であることを知りました！

pt1このEm12Cクラウド制御環境で監視されているデータベースを持っているKurtが誰であるかは本当にわかりませんが、少年は、今日の私の好きな人です！ 🙂

データベース名の上にカーソルを置くと、(kurt)現在テストデータベースで実行しているワークロードを表示できます:pt2

少年は、カートは今日私の好きな人です！

Em12Cデータベースのホームページ

データベースにログインすると、データベースのホームページからデータベースとホストの重要なIOとリソース使用量を確認できます:

pt3

トップアクティビティ（パフォーマンスメニュー、トップアクティビティ）に移動すると、処理とさまざまな待機イベントの詳細が表示されます:

pt4

Kurtはすべての種類の挿入を行っています（SQLタイプ「INSERT」によって、異なるSql_Idsによって見られます。 私は個々の文を掘り下げてこれを調査することができますが、実際にはたくさんの文とSQL_IDがここにありますが、AWRレポートでワークロードを表示する方が簡

AWRレポートの実行

パフォーマンス、AWR、AWRレポートをクリックすることを選択します。 今、私は選択肢があります。 新しいスナップショットをすぐに実行するように要求するか、このデータベースで間隔が毎時設定されているため、時間の先頭まで待つことができます。 このデモでは後者を選択しましたが、すぐにスナップショットを作成したい場合は、Em12Cから簡単にこれを行うか、DBMS_WORKLOAD_REPOSITORYのexecute権限を持つユーザーでSQLPlusか:

BEGINDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();END;/

この例では、ここでは急いでも心配もなく、前の時間と最新のスナップショットのレポートを要求したので、私は単に待っていました:

pt6

私はいつもトップテンの前景のイベントから始まり、一般的に高い待機率を持つものを見て:

pt7

直接パス書き込み、それはそれです。 🙂

Direct path writeには、挿入/更新、書き込まれるオブジェクト、書き込まれる表領域、および表領域を構成するデータファイルが含まれます。

これはIOでもあり、フォアグラウンドのWaitクラスですぐに検証します:

pt8

上のSQLを経過時間で見ると、すべての挿入で構成されるワークロードを処理していることが確認されます:

pt9

SQL IDをクリックすると、SQLテキストの完全なリストに移動し、Bad Boy Kurtがテストワークロードを生成するために何をしているのかを示します:

pt10

うわー、そのカートはかなり反逆者です、えっ？ 🙂

同じテーブルから1つのテーブルにループを挿入し、ロールバックしてループを終了します。 彼はいくつかのタイヤを蹴って、不安でそれをやっています！ 私が言ったように、人々を心配しないでください、Kurtは”Load Generator”と呼ばれるモジュールを使用して彼の仕事をしています。 私はこれを何かをテストするためのワークロードを生成すること以外のものとして認識しないように馬鹿になるでしょう。 🙂

今、これが本当の問題であり、このタイプのパフォーマンスがこのタイプの挿入が環境にどのような影響を与えているのかを調べようとしていたのであれば、AWRレポートの次の場所はどこですか？ 経過時間による上位SQLは、努力を集中させる場所である必要があるため、重要です。 SQLによって分解された他のセクションは便利ですが、「時間を調整していない場合は、時間を無駄にしている」ことを常に覚えておいてください。”作業を完了した後に時間の節約が見られない場合、最適化の練習は何も起こりません。 したがって、最初に経過時間で一番上のSQLを取得し、次に文を見ることで、文の一部であるオブジェクト（large_block149,191,194,145）を確認できます。また、問題がIOであることもわかっているため、SQLの詳細情報から飛び降りてオブジェクトレベルの情報に移動する必要があります。 これらのセクションは、xxxによってセグメントによって識別されます。

  • 論理読み取りによるセグメント
  • 物理読み取りによるセグメント
  • 読み取り要求によるセグメント
  • テーブルスキャンによるセグメント

など……

これらはすべて、トップSQLに表示されるオブジェクトのパターンとパーセンテージが非常によく似ています。 Kurtはこれらの各テーブルを読んでから、同じ行をテーブルに再度挿入してからロールバックしていたことを覚えておいてください。 これはワークロードシナリオであるため、私が見るほとんどのパフォーマンスの問題とは異なり、どの領域にも10％以上の影響を与える未解決のオブジェク

pt11

これはExadataであるため、オフロード、(スマートスキャン)フラッシュキャッシュなどを理解するのに役立つ情報がたくさんあります。 これは、エンジニアリングされたシステムで望むパフォーマンスを達成していることを確認するために必要な情報を中継するのに役立ちますが、別の投稿に保存して、テーブルスキャンを実行していたときにIOレポートのいくつかに触れたいので、それらがセルノードにオフロードされていることを確認したい（スマートスキャン）とデータベースノードで実行されていることを確認したいと思います。

データベースIOスループットのトップを見ることから始めることができます:

pt14

次に、セルのスループットごとの上位のデータベース要求（セルノード名を除く）を表示して、それらの比較方法を確認します:

pt12

Write a Comment

メールアドレスが公開されることはありません。