※本ページは、”Ten Tips for Database Performance Tuning (on Exadata, and in general) from Performance Expert Cecilia Grant“の翻訳です。

最近、いくつかのパフォーマンス調整セッションが提示され、ブログに掲載されていることに気付いたので、最高のデータベースパフォーマンス調整手法のソースであるExadata Engineeringチームにアクセスしてブログに追加すると考えました（彼らはこれを生計のために行っています！） 。

そして、2019年の Oracle Openworld San Francisco で行われた人気のある（一瞬で終わってしまった）セッション「Exadata Performance Diagnostics」シアタートークのプレゼンターである、私たち自身のCecilia Grantをおいて、パフォーマンスチューニングのヒントを提供する資格のある人は誰もいません。セシリアは、ここオラクルに常駐するパフォーマンスチューニングの専門家の1人です。 Ceciliaに、データベースのパフォーマンスを調整するための10のヒントを教えてもらいました。

1.パフォーマンスを測定するための主要なアプリケーションメトリックを特定すること

パフォーマンスを測定するときは、アプリケーションのパフォーマンスを反映する、またはエンドユーザーエクスペリエンスの優れたプロキシとなる主要なアプリケーションメトリックを特定します。このメトリックは、データベースの外部にある必要があります。たとえば、1秒あたりに処理される注文やバッチジョブの経過時間などです。アプリケーションレベルのメトリックを使用すると、パフォーマンスが重要な部分で向上しているかどうかを客観的に測定できます。

主要な指標に基づいて、成功基準を定義します。これにより、進行状況を測定でき、いつ停止できるかを知ることもできます。変更を加え続けたくなることもありますが、すでに目標を達成していて、変更しても重大な影響がない場合は、中止してください。

重要な指標は1つだけにする必要があります。指標が多すぎると、改善するものもあれば、後退するものもあるため、パフォーマンスの変化を明確に評価することはできません。複数の測定が必要な場合は、互いに完全に独立しており、個別に評価できるように測定してください。

2.パフォーマンスの問題を定義し、その範囲を理解すること

パフォーマンスの問題においては、具体的には何が遅いのか、そしてどれくらい遅いのかを明確に定義することが必要であり、重要です。

パフォーマンスの問題を定義する一環として、問題の範囲も理解してください。それは一連のクエリに限定されているのでしょうか、それとも一連のユーザーに限定されているのでしょうか。それとも、データベースインスタンス内のすべてのユーザーに影響を及ぼしているのでしょうか、それとも複数のデータベースに影響を及ぼしているのでしょうか。問題の範囲を理解することにより、問題の範囲に一致する診断データを使用できます。問題が少数のユーザーに限定されている場合、システム全体の統計を使用することが適切ではない可能性があります。

同様に、どのソリューションも問題の範囲と一致する必要があります。たとえば、問題が少数のクエリまたは少数のユーザーに限定されている場合、ソリューションはそれらのユーザー/クエリのみに焦点を当てる必要があります。たとえば、システムのすべてのユーザーに悪影響を与える可能性のあるinit.oraパラメーターの変更はするべきではありません。

3.一度に1つずつ変更すること

まず第一に、これは、パフォーマンスの問題が最初から再現可能であるか、少なくとも既知の許容範囲内で再現可能であることを前提としています。問題が再現できない場合は、加えられた変更の影響を測定することはできません。したがって、戻って、結果が再現できるようにワークロードまたはテストケースを構成します。再現可能なパフォーマンスの問題があることを確認したら、一度に1つだけ変更して、変更が役に立ったかどうかを識別できるようにします。

時間の都合上、複数のものを変更する必要がある場合があります（特に、必要なダウンタイムや停止を減らしたい場合）。その場合は、同じエリアに影響を与えず、個別に評価できるものを変更してください。たとえば、単一のSQLステートメントに影響を与えるSQLプロファイルと、接続プールの動作を制御する中間層の変更は同時に実装できます。

4.パフォーマンスチューニングは反復プロセスです

パフォーマンスチューニングは反復的なプロセスであることを忘れないでください。人々は焦り、すぐに改善が見られることを望んでいる傾向があります。ただし、行った変更の中には役立つものと役に立たないものがあることを理解してください。場合によっては、修正しているもののすぐ後ろにボトルネックがある可能性があります。これは、修正が役に立たないことを意味するのではなく、単にさらなる改善が必要であることを意味します。データベース、OS、およびExadataによって提供されるパフォーマンス統計を分析して、ボトルネックがどこにあるか、および改善すべき領域を特定するのに役立ててください。主要なアプリケーションメトリックは、パフォーマンスを測定するのに役立つ全体的な測定値であり、個々の統計は、パフォーマンスの調整作業に集中するのに役立ちます。

これは、最初のヒントで述べたように、成功基準を事前に定義することが重要である理由でもあります。目標が達成されたときに変更を加え続けると、リグレッションが発生するリスクがあります。

5.パフォーマンスレポートと、それらをいつ使用するかをよく理解してください。スコープを考慮に入れること

Oracleデータベースは、多数のパフォーマンス統計とパフォーマンスレポートを提供します。 AWRレポートは、最も一般的に使用されるパフォーマンス診断ツールです。実際には、AWRレポートのファミリー全体（Global, single, compare period, global compare period, AWR SQL report, PDB report）があります。）。 AWRレポートは、問題が広範囲に及ぶ場合に役立つ傾向があります。

問題がユーザーまたはクエリのサブセットに影響を及ぼしている場合は、AWR SQL report、SQL Monitor report、さらには SQL Details report が非常に役立つ傾向があります。

ASH (Active Session History) レポートは、次のどちらの場合にも使用できます。インスタンス/データベース全体のアクティブなセッション履歴があり、特定のユーザー、SQLステートメント、またはセッションの他のディメンションに基づいてフィルタリングすることもできます。

AWRレポートで使用可能な Exadata セクション (Exadata Configuration and Statistics) には、ストレージサーバーによって維持および収集された統計が表示されます。つまり、インスタンスやデータベースに関係なく、ストレージサーバーでのアクティビティが表示されます。したがって、Exadata統計の範囲は通常、AWRレポートの範囲よりも大きく、そのため、AWR PDB report または AWR SQL reportには含まれません。

6.パフォーマンスデータソースを理解すること

パフォーマンスレポートは、V$ Views とも呼ばれる動的パフォーマンスビューを通じて、データベースですぐに利用できるパフォーマンスデータを要約します。ただし、データベースビューによって公開される測定値と統計にはさまざまな種類があります。

a. 測定/カウント-これには、Exadata情報を含む、AWRで公開されているもののほとんどが含まれます。

b. 抽出（メトリック）-これらの統計は、1秒あたりまたはトランザクションレートごとに算出される測定/カウントされた統計に基づいて抽出または計算され、通常は V$*METRIC* ビュー（V$SYSMETRIC、V$SYSMETRIC_HISTORY など）で公開されます。

c. サンプリング – ASH(Active Session History) など。アクティブなセッションは定期的にサンプリングされ、データベース内の時間がどのように費やされているかを判断するために使用できます。 ASHは非常に便利なユーティリティですが、サンプリングされているため、賢く使用する必要があります。特に、John BeresniewiczとGraham Wood によって広範に提示された「悪いASH」に注意してください。

Exadataには、次のような追加のデータソースもあります。

a. ExaWatcher – これにはOS統計とcellsrv統計の両方を含む詳細なデータ（5秒ごと）が含まれます

b. Cell Metric History (Storage Server のメトリック履歴)-これには、Storage Server Software によって測定された、累積の統計と抽出（1秒あたり、要求ごと）の両方の統計が含まれます

7. Exadataでも、パフォーマンスチューニング方法は同じです

DB時間(DB Time) を最初に確認します。 Exadata統計 (Exadata Statistics) はAWRレポートで公開されていますが、Exadata統計を確認する前に、データベース待機イベント(Wait Events Statistics)に反映されているI/Oの問題が発生しているかどうかを最初に確認してください。

優れたデータベース設計原則の実践を続けます。Exadataが提供するスマートな機能により、ほとんどの場合、ユーザーはそれを回避できるため、優れたデータベース設計原則を無視するアプリケーションのケースがますます増えています。ただし、優れたデータベース設計の原則に従えば、システムからより多くのものを得ることができます。たとえば、Exadataで実行されているからといって、すべてがスマートスキャンである必要があるとは限りません。スキーマを確認して、SQLステートメントのアクセスパターンに基づいてインデックスまたはパーティション分割が適切かどうかを確認します。

また、Exadataのストレージで改善を行っても、ストレージに関連しない問題に対処するのには役立ちません。たとえば、不十分な接続管理や繰り返しのパースは、優れたストレージソリューションを使用しても発生するアプリケーションレベルの問題です。同様に、一行ごとの処理（または、Tom Kyteによって造られた「行ごと=遅い行ごと」）は、セット処理と比較して多大なオーバーヘッドがあり、必ずしもより優れたストレージソリューションによって改善されるとは限りません。

8.悪いSQLは悪いSQLです

不適切に記述されたSQLステートメントは、実行されている環境に関係なく、実行が不十分になります。コストベースのオプティマイザは、記述されているSQLの最適な実行プランを見つけることしかできません。 Exadataで不適切に記述されたSQLステートメントを実行すると、オフロード処理またはI / Oの高速化の点で性能向上される可能性はありますが、それでも、適切な実行プランを備えた適切に記述されたSQLステートメントほどパフォーマンスは高くありません。

たとえば、SQLステートメントがテーブルに複数回アクセスすると、1回で実行できる場合と比べると、テーブルへのアクセス中に不要な余分な処理が発生します。もう1つの例は、フィルター述語を指定しないSQLステートメントを実行するアプリケーションですが、代わりにアプリケーションに依存してデータをフィルターで除外します。このような場合、データのフィルタリングをアプリケーションに依存するよりも、データベースによって事前に処理してデータセットを減らす方がよいでしょう。アプリケーションに依存すると、通常、データベース内の大きなデータセットの不要な処理が発生します。

9.データ駆動型で分析すること

多くの場合、ユーザーは、利用可能な多数のパフォーマンスデータを確認せずに、直感に基づいて変更を加え、問題がどこにあるかを推測します。または、ユーザーは利用可能なデータを無視することを選択します。特に、発生していると信じていることがサポートされていない場合はそうです。代わりに、利用可能なデータを使用して、パフォーマンスの問題が発生している理由に関する仮説を立てます、それに基づいてチューニングの推奨事項を作成します。

10.車輪の再発明をしないこと、カートを更新すること

データベースが提供する新機能に遅れずについていき、従来のようにチューニングを行うのではなく、それらを賢く使用してください。たとえば、DB 19cのリアルタイム統計と自動インデックスを使用すると、データベースは機械学習を使用して統計を自動インデックスに登録して保持できるため、統計のロックや保存されたアウトラインの使用などの手動介入への依存を減らすことができます。

同様に、Oracle Database用のExadataなど、ベンダーが提供する最高クラスのソリューションを使用する機会がある場合は、それを使用してください。このシステムは専門家によって設計されており、多くの推測作業を排除し、日常的なタスクの量を減らし、より価値の高いプロジェクトやイノベーションに集中して価値を高めることができます。

これで、これらの10のヒントがお役に立てば幸いです。質問やコメントがある場合は、Ceciliaが2020年3月のExadata Office HoursでGavinとCrisが参加するので、必ず登録してください。見逃した場合は、録​​音へのリンクがあります。