データベース・パフォーマンス・チューニング

データベース・パフォーマンス・チューニングの理解

図7-38 データベース・パフォーマンス・チューニングの理解

一般的なデータベース・パフォーマンスの問題は、2つのカテゴリのいずれかに分類されます。これらは、一般的なデータベース全体のパフォーマンスに影響するものか、問合せ固有ものかです。

データベース全体の問題の原因は、次のとおりです:

CPU、IO、メモリー、ネットワーク、プロセスなど、なんらかの形態のリソースでのボトルネック
ある種のデータベースの構成ミス
なんらかの形でのデータベースのハング
バグ

問合せ固有の問題の原因は、次のとおりです:

問合せの構造上、長時間を要する高価なSQL
不十分な問合せ最適化 – これは、不適切な索引、古い統計、実行計画の予期しない変更などが原因で発生する可能性があります。

データベース・パフォーマンス・チューニングのステップ

データベース・パフォーマンス・チューニングの基本的な修正フロー・ステップは次のとおりです:

データベース・パフォーマンス診断を収集します
Autonomous Health Frameworkインサイトを使用します
- 構成をベスト・プラクティスと比較します
- データベース異常およびリソースのボトルネックを見つけて修正します
- インサイト内でPerfHubレポートを使用して、パフォーマンスの低いデータベース・ワークロードを特定およびチューニングします
ノイジー・ネイバーを把握して保護します
診断収集を使用して新しいSRを記録します

Autonomous Health Frameworkを使用してデータベース・パフォーマンス診断を収集します

最初のステップでは、Autonomous Health Frameworkを使用してデータベース・パフォーマンス診断収集を生成します。

データベース・パフォーマンスの問題が発生したマシンにログインし、Oracleユーザーとして次のコマンドを実行します:

tfactl diagcollect srdc –dbperf –database <database_name>

Autonomous Health Frameworkは、現在パフォーマンスの問題があるかどうかプロンプトを表示し、一連の質問および回答を通して必要なすべての診断を収集できるようにガイドします。

たとえば:

$ tfactl diagcollect -srdc dbperf -database db23cdb1
Do you have a performance issue now [Y|N] [Y]: Y
Enter duration of the issue in hours [<RETURN>=1h]: 1h
As you have indicated that the performance issue is currently happening,
Performance Reports will be collected for the following periods:
Start time when the performance was bad: 2024-05-01 15:13:32
Stop time when the performance was bad: 2024-05-01 16:13:32
For comparison, it is useful to gather data from another period with similar load where problems are not seen. Typically this is likely to be the same time period on a previous day. To compare to the same time period on a previous day enter the number of days ago you wish to use. [<RETURN> to provide other time range]: 1
Start time when the performance was good 2024-04-30 15:13:32
Stop time when the performance was good 2024-04-30 16:13:32
Has any SQL been identified to contribute to the performance issue?[Y|N]: N
Do you wish to take an AWR Dump as part of this collection? [Y|N]: N

Ending AWR snapshot successfully created.
Found 3 snapshot(s) for Bad Performance time range in  ORCL
Found 3 snapshot(s) for baseline range in  ORCL
"Automatic Workload Repository (AWR) is a licensed feature. Refer to My Oracle Support Document ID 1490798.1 for more information"

Components included in this collection: DATABASE CHMOS CHA OS INSIGHT
Preparing to execute support diagnostic scripts.
 Executing DB Script srdc_db_lfsdiag.sql on db23cdb1 with timeout of 120 seconds...
 Executing DB Script srdc_real_time_addm.sql on db23cdb1 with timeout of 120 seconds...
 Executing DB Script srdc_statsadvisor_report.sql on db23cdb1 with timeout of 300 seconds...
 Executing DB Script collect_logon_logoff_triggers.sql on db23cdb1 with timeout of 300 seconds...
 Executing OS Script get_perfhub_report with timeout of 600 seconds...
Collecting data for all nodes
TFA is using system timezone for collection, All times shown in UTC.
Scanning files from 2024-05-01 15:13:32 UTC to 2024-05-01 16:13:32 UTC
Collection Id : 20240501161522machine1
Detailed Logging at : /u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/diagcollect_20240501161522_machine1.log
Waiting up to 120 seconds for collection to start
2024/05/01 16:15:43 UTC : NOTE : Any file or directory name containing the string .com will be renamed to replace .com with dotcom
2024/05/01 16:15:43 UTC : Collection Name : tfa_srdc_dbperf_Wed_May_01_16_15_26_UTC_2024.zip
2024/05/01 16:15:43 UTC : Collecting diagnostics from hosts : [machine1, machine3, machine2, machine4]
2024/05/01 16:15:45 UTC : Getting list of files satisfying time range [05/01/2024 15:13:32, 05/01/2024 16:13:32]
2024/05/01 16:15:45 UTC : Collecting Additional Diagnostic Information...
2024/05/01 16:16:48 UTC : Executing DB Script awr_reports on db23cdb1 with timeout of 3600 seconds...
2024/05/01 16:16:57 UTC : Completed Collection of Additional Diagnostic Information for Insights...
2024/05/01 16:18:56 UTC : Collecting ADR incident files...
2024/05/01 16:20:32 UTC : Executing Applicable ORAchk Validations with timeout of 600 seconds...
2024/05/01 16:24:16 UTC : Executing IPS Incident Package Collection(s)...
2024/05/01 16:24:25 UTC : No ADR Incidents for db23cdb1 covering period "2024-05-01 15:13:32" to "2024-05-01 16:13:32" were generated, IPS Pack will not be collected.
2024/05/01 16:24:25 UTC : Executing SQL Script db_feature_usage.sql on db23cdb1 with timeout of 600 seconds...
2024/05/01 16:24:25 UTC : Executing Collection for OS with timeout of 1800 seconds...
2024/05/01 16:24:39 UTC : Completed Collection of Additional Diagnostic Information...
2024/05/01 16:24:47 UTC : Completed Local Collection
2024/05/01 16:24:47 UTC : Not Redacting this Collection ...
2024/05/01 16:24:47 UTC : Remote Collection in Progress...
2024/05/01 16:24:48 UTC : Collection completed on host: machine2
2024/05/01 16:24:48 UTC : Collection completed on host: machine3
2024/05/01 16:24:48 UTC : Collection completed on host: machine4
2024/05/01 16:24:52 UTC : Executing Creation of insights zip with timeout of 900 seconds...
2024/05/01 16:28:49 UTC : Report is generated at : /u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine1_insights_2024_05_01_16_24_55.zip
2024/05/01 16:28:49 UTC : Finished creation of insights zip with status 0
2024/05/01 16:28:50 UTC : Collection completed on host: machine1
2024/05/01 16:28:49 UTC : Completed collection of zip files.
.-----------------------------------------.
|            Collection Summary           |
+---------------+-----------+------+------+
| Host          | Status    | Size | Time |
+---------------+-----------+------+------+
| machine2       | Completed | 13MB | 289s |
| machine3       | Completed | 12MB | 332s |
| machine4       | Completed | 13MB | 420s |
| machine1       | Completed | 17MB | 544s |
'---------------+-----------+------+------'
Logs are being collected to: /u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all
/u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine1.tfa_srdc_dbperf_Wed_May_01_16_15_26_UTC_2024.zip
/u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine2.tfa_srdc_dbperf_Wed_May_01_16_15_26_UTC_2024.zip
/u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine3.tfa_srdc_dbperf_Wed_May_01_16_15_26_UTC_2024.zip
/u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine4.tfa_srdc_dbperf_Wed_May_01_16_15_26_UTC_2024.zip
/u01/app/giusr/oracle.ahf/data/repository/srdc_dbperf_collection_Wed_May_01_16_15_27_UTC_2024_node_all/machine1_insights_2024_05_01_16_24_55.zip

完了すると、AHFはマシンごとにすべてをzipファイルにパッケージ化します。作業が進むにつれて、問題が発生したノードからのもののみが必要になります。

これで、ステップ2に進むことができます。Autonomous Health Frameworkインサイトを使用して、推奨事項を見つけます。

Autonomous Health Frameworkインサイトの使用

診断zipを、収集を開始したマシンからWebブラウザを備えたマシンに転送し、解凍します。

図7-39 AHFインサイト

ここには、Autonomous Health Frameworkインサイトを含む別のzipがあります。それを抽出して、index.htmlを開きます。

図7-40 AHFインサイト

構成とベスト・プラクティスの比較
Autonomous Health Frameworkインサイトでは、システム全体を俯瞰できます。これを使用すると、問題を特定し、根本原因を掘り下げ、解決方法を理解できます。

まず、関連する構成の問題を調べて、Oracleのベスト・プラクティスから逸脱しているかどうかを確認します。

「Best Practices issues」をクリックしてドリルダウンします。

図7-41 AHFインサイト

サマリーには、システムがベスト・プラクティスから逸脱している場所とその相対的な重大度の概要が示されます。

図7-42 AHFインサイト

下にスクロールすると、特定の構成の問題が表示されます。問題のリストを下へと調べて、関連するものがないか確認します。パフォーマンスに関連していると思われるものが見つかった場合は、それを展開して推奨事項を確認します。すべてのベスト・プラクティス・チェックでは、この構成の逸脱の影響およびリスクを修復ステップとともに説明しています。

図7-43 AHFインサイト
データベース異常およびリソースのボトルネックの検出と修正
次に、データベース異常アドバイザを確認します。

Autonomous Health Frameworkでは、AIを使用して異常なイベントを検出し、解決策を推奨します。

図7-44 AHFインサイト

このシナリオでは、Autonomous Health Frameworkは、データベースおよびホストのIOが遅いことを示すいくつかの異常なイベントを検出しています。

図7-45 AHFインサイト

ここからホーム画面に戻り、オペレーティング・システムのメトリックを調べることができます。

この例では、Autonomous Health Frameworkが、OracleプロセスがD状態(IOが戻るのを待機しているスタック状態)でブロックされていることを検出したことがわかります。また、一部のディスクの待機時間が長いこともわかります。

図7-46 AHFインサイト

これを展開すると、平均待機時間が20ミリ秒を超えるディスクおよび上位IO消費プロセスを示すグラフが表示されます。

図7-47 AHFインサイト

さらに下にスクロールすると、問題のあるスナップショットが表示されます。これは、どのディスクが低速であったかを示しています。

図7-48 AHFインサイト

高いCPU使用率の例のシナリオ

Autonomous Health Frameworkによって検出された異常を調べる別のシナリオを次に示します。このケースでは、データベース・グローバル・キャッシュ・メッセージのレイテンシが想定よりも高いことがわかります。Autonomous Health Frameworkは、原因および推奨される処置を示します。

これで、CPUがボトルネックであることがわかりました。

図7-49 AHF Insights

このシナリオのOS問題レポート・ページに移動すると、CPU使用率が高いという結果が示されます。この結果を展開すると、CPU使用率が高かった時期の詳細が表示されます。下にスクロールすると、CPU使用率が時間の経過とともにグラフ化されます。

図7-50 AHF Insights

さらに下に進むと、様々なプロセスのCPU使用率が表示されます。ここでは、データベースのバックグラウンド・プロセスとフォアグラウンド・プロセスが平均80%を超えるCPUを消費し、最大100%を超えるCPUを消費していることがわかります。

図7-51 AHF Insights
インサイト内でPerfHubレポートを使用して、パフォーマンスの低下したデータベース・ワークロードを特定してチューニングします
AHFは、最も有用なパフォーマンス・チューニング・レポートをAHFインサイト・レポートに直接埋め込みます。

「Performance Reports」セクションの内容は次のとおりです:
- PerfHubレポート
- AWRレポート
- AWR比較レポート
図7-52 「AHF Insights」ｰ「Home」

図7-53 「AHF Insights」ｰ「Performance Reports」

PerfHubレポートを開きます。

データベース・パフォーマンス・ハブ・レポートには、データベース・ワークロードの詳細が表示されます。

図7-54 パフォーマンス・ハブ

最初に理解する必要があるのは、アクティブ・セッションが実行していることです。アクティブ・セッションとは、クライアントにかわってアクティブに動作しているセッションです。

デフォルトでは、パフォーマンス・ハブ・レポートは「ASH Analytics」タブで開きます。

ASHはActive Session History (アクティブ・セッション履歴)の略で、アクティブなデータベース・セッションをサンプリングするデータベース機能です。

グラフを拡大して詳しく見てみましょう。

ここでは、最も高い待機クラスがCPUであることがわかり、データベースがCPUバインドされていることを示しています。

図7-55 パフォーマンス・ハブ

待機クラス別のSQLのグラフを見ると、チューニングの候補となるSQLを特定できます。

グラフを再度縮小し、「ADDM」タブを見てみましょう

ADDMはAutomatic Database Diagnostic Monitor (自動データベース診断モニター)の略です。

図7-56 パフォーマンス・ハブ

「ADDM」タブは、Automatic Workload Repository (AWR)のデータを分析し、パフォーマンス問題を解決するためのオプションを提供します。

結果のいずれかをクリックすると、推奨事項が表示されます。推奨事項では、何を変更すればよいかと、推定される利点が示されます。

図7-57 パフォーマンス・ハブ

この表を使用すると、長時間実行されている特定のSQL文を識別できます。

一度識別すれば、個々のパフォーマンスのチューニングに集中できます。

詳細は、『Oracle® Database SQLチューニング・ガイド』を参照してください。

Autonomous Health Frameworkを使用したノイジー・ネイバーの把握と保護

この3番目のステップは、他のデータベースが複数あるホストでデータベース・パフォーマンスの問題が繰り返され、ホストのCPU使用率が70%を超える期間が見られる場合にのみ適用されます。

このステップでは、ノイジー・ネイバーがないか確認します。一般的な用語では、ノイジー・ネイバーとは、あるサービスがシステム・リソースを想定よりも多く消費し、他のサービスのパフォーマンスに影響を与える可能性があることを指します。Autonomous Health Frameworkは、CPU使用率に基づいてノイジー・データベース・ネイバーを検出できます。

Autonomous Health Frameworkでは、Oracle Enterprise Managerリポジトリを履歴データのソースとして使用します。そのため、次を実行して、このリポジトリに接続するように構成します:

ahf configuration set --type impact --user-name <EM user> --connect-string <EM repository connection string>

リポジトリ・パスワードの入力を求められ、Autonomous Health Frameworkによって構成が設定されます。

たとえば:

ahf configuration set --type impact --user-name ahftest --connect-string "//<a href="http://mymachine.acme.com/" rel="nofollow">mymachine.acme.com</a>:1521/<a href="http://abcd.acme.com/" rel="nofollow">abcd.acme.com</a>"

Enter EM Repository password:

Re-enter EM Repository password:

Configuration files created in /opt/oracle.ahf/data/mymachine/balance/user_john

これで構成が完了したので、次を実行してクラスタ分析レポートを生成できます:

ahf analysis create --type impact --scope cluster --name cluster_name

たとえば:

ahf analysis create --type impact --scope cluster --name mycluster 

Starting analysis and collecting data for impact

Report is generated at : /opt/oracle.ahf/data/mymachine/diag/balance/user_john/cluster_160424_154432451_UTC.html

レポートの最初のセクションでは、現在のノイジー・ネイバーの露出および影響と、推奨CPU_COUNTを設定した場合とを対比してサマリーが示されます。

図7-58 AHF Insights

次のグラフは、過去1か月間の現在のノイジー・ネイバーのステータスと、推奨CPU_COUNTを使用した場合とを対比して示しています。黒い線がある場所は、データベースがノイジー・ネイバーによる影響を受けたことを示します。

図7-59 AHF Insights

グラフの上にカーソルを置くと、これらのコントロールが表示され、データを拡大したりパンしたりできるようになります。これを使用して、黒い線がパフォーマンスの問題が発生した時期と相関しているかどうかを把握します。

黒い線がデータベース・パフォーマンスが低下した期間と相関している場合は、レポートの残りの部分を使用して、データベースまたはマシンごとにさらにドリルダウンし、各種データベースにわたってCPU_COUNTに加える必要がある変更を把握します。

Autonomous Health Framework診断収集を使用した新しいSRの記録

それでもサポートが必要な場合は、最後のステップとして、Autonomous Health Framework診断収集を使用してSRを記録します。

My Oracle Supportにログインします。
「Service Requests」タブを選択します。
次に、「Create Technical SR」ボタンをクリックします。

図7-60 My Oracle Support
サービス・リクエストの必須フィールドをすべて入力します。
必ず製品を「Oracle Database - Enterprise Edition」として選択してください。
次に、「Problem Type」が表示されたら、「Create an Express SR」オプションを選択します。
これは、Autonomous Health Framework収集を使用した迅速なSR作成ルートです。

図7-61 My Oracle Support
収集のアップロードを含め、残りのステップに従います。
Oracleサポートが引き継ぎ、解決を支援します。