この短い投稿では、Oracle Exadata 上で実行されている AWR データベースの分析に関連する 10 つの誤解を払拭したいと思います。 約 XNUMX 年間、私は常に「Exadata Software は生産性に対してどのような貢献をしているのか?」という疑問に直面してきました。 または、新しい造語を使用すると、特定のデータベースの作業がどの程度「専門家」であるか?
私の意見では、この正しい質問は、AWR 統計を参照すると誤って回答されることがよくあります。 応答時間をプロセッサ (DB CPU) の動作時間とさまざまなクラスの待ち時間の合計として扱うシステム待機メソッドを示します。
Exadata の出現により、Exadata Software の操作に関連する特定のシステムの期待が AWR 統計に表示されるようになりました。 原則として、このような待機の名前は「セル」という単語で始まります(Exadata Storageサーバーはセルと呼ばれます)。最も一般的なのは、「セル・スマート・テーブル・スキャン」、「セル・マルチブロック」という一目瞭然の名前の待機です。 「物理読み取り」と「セル単一ブロック物理読み取り」です。
ほとんどの場合、合計応答時間に占めるこのような Exadata 待機の割合は小さいため、「合計待機時間別のフォアグラウンド イベントのトップ 10」セクションにも入りません (この場合、「フォアグラウンド待機」セクションでそれらを探す必要があります)イベントセクション)。 非常に苦労しましたが、お客様からの毎日の AWR の例を見つけました。この例では、Exadata の期待がトップ 10 セクションに含まれており、合計で約 5% に達しました。
イベント
待つ
合計待機時間 (秒)
平均待機時間
%DB 時間
待機クラス
DBCPU
115.2K
70.4
SQL*Net dblink からのその他のデータ
670,196
5471.5
8.16ms
3.3
ネットワーク
セル単一ブロックの物理読み取り
5,661,452
3827.6
676.07us
2.3
ユーザーI/O
同期ASMリバランス
4,350,012
3481.3
800.30us
2.1
その他
セルマルチブロック物理読み取り
759,885
2252
2.96ms
1.4
ユーザーI/O
ダイレクトパス読み取り
374,368
1811.3
4.84ms
1.1
ユーザーI/O
dblink からの SQL*Net メッセージ
7,983
1725
216.08ms
1.1
ネットワーク
セルスマートテーブルスキャン
1,007,520
1260.7
1.25ms
0.8
ユーザーI/O
ダイレクトパス読み取り温度
520,211
808.4
1.55ms
0.5
ユーザーI/O
enq: TM - 競合
652
795.8
1220.55ms
0.5
申し込み
多くの場合、このような AWR 統計から次の結論が導き出されます。
1. データベースのパフォーマンスに対する Exadata マジックの寄与は高くありません。5% を超えず、データベースの「拡張」が不十分です。
2. このようなデータベースを Exadata から従来の「サーバー + アレイ」アーキテクチャに移行した場合、パフォーマンスはあまり変わりません。 なぜなら、たとえこのアレイが Exadata ストレージ システムよりも 5 倍遅いことが判明したとしても (これは最新のオール フラッシュ アレイではほとんど不可能です)、15% に XNUMX を乗算すると、I/O 待機の割合は XNUMX% に増加することになります。 - データベースは確実にこれを生き延びます!
これらの結論は両方とも不正確であり、さらに、Exadata Software の背後にある考え方の理解を歪めます。 Exadata は高速 I/O を提供するだけでなく、従来のサーバー + アレイ アーキテクチャと比較して根本的に動作が異なります。 データベース操作が真に「適応」されている場合、SQL ロジックがストレージ システムに転送されます。 ストレージサーバーは、多くの特別なメカニズム (主に Exadata Storage Indexes ですが、それだけではありません) のおかげで、必要なデータを自ら見つけて、DB をサーバーに送信します。 これは非常に効率的に実行されるため、合計応答時間に占める一般的な Exadata 待機の割合は小さくなります。
このシェアはExadataの外ではどう変化するのでしょうか? これはデータベース全体のパフォーマンスにどのような影響を及ぼしますか? テストはこれらの質問に最もよく答えます。 たとえば、Exadata の外部で「セル スマート テーブル スキャン」を待機すると、非常に重いテーブル フル スキャンになり、I/O が応答時間全体を占有し、パフォーマンスが大幅に低下する可能性があります。 そのため、AWRを分析する際に、Exadataの期待値の合計パーセンテージをその魔法のパフォーマンスへの寄与として考慮するのは間違いであり、このパーセンテージをExadata以外のパフォーマンスの予測に使用するのはさらに間違っています。 データベースの動作がどの程度「正確」であるかを理解するには、「インスタンス・アクティビティ統計」セクションのAWR統計(わかりやすい名前の統計が多数あります)を調べ、それらを相互に比較する必要があります。
また、Exadata の外部のデータベースがどのように感じられるかを理解するには、ターゲット アーキテクチャ上のバックアップからデータベースのクローンを作成し、負荷がかかった状態でのこのクローンのパフォーマンスを分析するのが最善です。 Exadata 所有者には、原則として、この機会があります。
著者： Alexey Struchenko 氏、Jet Infosystems データベース部門責任者
出所： habr.com