日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Oracleデータベースのパフォーマンス最適化とベンチマーク手順

03/13/2024 共同作成者

PDF

データベースストレージのパフォーマンスを正確にテストすることは、非常に複雑な課題です。次の問題について理解しておく必要があります。

IOPSとスループット
フォアグラウンドI/O処理とバックグラウンドI/O処理の違い
データベースへのレイテンシの影響
ストレージのパフォーマンスにも影響する多数のOSとネットワーク設定

また、ストレージデータベース以外のタスクについても考慮する必要があります。ストレージパフォーマンスがパフォーマンスの制限要因ではなくなったため、ストレージパフォーマンスを最適化しても有益なメリットは得られなくなります。

現在、データベースユーザの大半がオールフラッシュアレイを選択していることから、新たな考慮事項がいくつか生まれています。たとえば、2ノードのAFF A900システムでパフォーマンスをテストする場合を考えてみましょう。

読み取り/書き込み比率が80対20のA900ノードでは、レイテンシが150 µ sマークを超える前に、100万を超えるランダムデータベースIOPSを達成できます。これは、ほとんどのデータベースで現在必要とされているパフォーマンスをはるかに超えているため、予想される改善を予測することは困難です。ストレージがボトルネックになることはほとんどありません。
ネットワーク帯域幅は、パフォーマンス上の制約の原因としてますます一般的になっています。たとえば、回転式ディスクソリューションはI/Oレイテンシが非常に高いため、データベースパフォーマンスのボトルネックになることがよくあります。オールフラッシュアレイでレイテンシの制限が取り除かれると、多くの場合、その障壁はネットワークに移ります。これは、真のネットワーク接続を可視化することが困難な仮想環境やブレードシステムで特に顕著です。帯域幅の制限のためにストレージシステム自体をフルに活用できない場合、パフォーマンステストが複雑になる可能性があります。
オールフラッシュアレイのレイテンシが劇的に改善されるため、オールフラッシュアレイと回転式ディスクを搭載したアレイのパフォーマンスを比較することは一般的に不可能です。通常、テスト結果は意味がありません。
オールフラッシュアレイでピーク時のIOPSパフォーマンスを比較することは、データベースがストレージI/Oの制約を受けないため、あまり有益なテストではありません。たとえば、あるアレイが50万IOPSを維持でき、別のアレイが30万IOPSを維持できるとします。データベースの処理時間の99%がCPU処理に費やされている場合、この違いは現実の世界では無関係です。ワークロードがストレージアレイのすべての機能を利用することはありません。一方、ストレージアレイの能力を最大限に引き出すことが期待される統合プラットフォームでは、ピーク時のIOPS性能が重要になる場合があります。
どのストレージテストでも、レイテンシとIOPSを常に考慮してください。市場に出回っているストレージアレイの多くは、非常に高いIOPSを謳っていますが、このレベルのIOPSはレイテンシによって役に立たなくなります。オールフラッシュアレイの一般的なターゲットは1ミリ秒です。テストの優れた方法は、可能な最大IOPSを測定することではなく、平均レイテンシが1ミリ秒を超える前にストレージアレイが維持できるIOPSを特定することです。

Oracle自動ワークロードリポジトリとベンチマーク

Oracleのパフォーマンス比較のゴールドスタンダードは、Oracle Automatic Workload Repository（AWR）レポートです。

AWRレポートには複数のタイプがあります。ストレージの観点から見ると、 awrrpt.sql コマンドは、特定のデータベースインスタンスを対象としており、レイテンシに基づいてストレージI/Oイベントを内訳表示する詳細なヒストグラムが含まれているため、最も包括的で価値があります。

2つのパフォーマンスアレイを比較するには、各アレイで同じワークロードを実行し、ワークロードを正確に対象とするAWRレポートを作成するのが理想的です。非常に長時間のワークロードの場合は、開始時間と停止時間を含む経過時間を含む単一のAWRレポートを使用できますが、AWRデータを複数のレポートとして分割することを推奨します。たとえば、バッチジョブが午前0時から午前6時まで実行された場合は、午前0時から午前1時、午前1時から午前2時などの1時間のAWRレポートを作成します。

それ以外の場合は、非常に短いクエリを最適化する必要があります。最適なオプションは、クエリの開始時に作成されたAWRスナップショットと、クエリの終了時に作成された2番目のAWRスナップショットに基づくAWRレポートです。データベースサーバは、分析中のクエリのアクティビティを隠すバックグラウンドアクティビティを最小限に抑えるために、それ以外の場合は静かにしておく必要があります。

AWRレポートを使用できない場合は、代わりにOracle Statspackレポートを使用することを推奨します。AWRレポートとほとんど同じI/O統計情報が含まれています。

Oracle AWRとトラブルシューティング

AWRレポートは、パフォーマンスの問題を分析するための最も重要なツールでもあります。

ベンチマークと同様に、パフォーマンスのトラブルシューティングでは、特定のワークロードを正確に測定する必要があります。可能な場合は、パフォーマンスの問題をNetAppサポートセンターに報告するとき、または新しい解決策についてNetAppまたはパートナーアカウントチームと協力するときにAWRデータを提供してください。

AWRデータを提供する場合は、次の要件を考慮してください。

を実行します awrrpt.sql レポートを生成するコマンド。出力はテキストまたはHTMLのいずれかになります。
Oracle Real Application Clusters（RAC）を使用する場合は、クラスタ内の各インスタンスについてAWRレポートを生成します。
問題が発生した特定の時間をターゲットにします。AWRレポートの最大許容経過時間は、通常1時間です。問題が複数時間続く場合、またはバッチジョブなどの複数時間の操作を伴う場合は、分析対象の期間全体をカバーする複数の1時間のAWRレポートを提供します。
可能であれば、AWRスナップショット間隔を15分に調整します。この設定では、より詳細な分析を実行できます。これには、次の追加の実行も必要です。 awrrpt.sql 15分間隔ごとにレポートを作成します。
実行中のクエリが非常に短い場合は、操作の開始時に作成されたAWRスナップショットと、操作の終了時に作成された2つ目のAWRスナップショットに基づいてAWRレポートを提供します。それ以外の場合は、分析中の操作のアクティビティを隠すバックグラウンドアクティビティを最小限に抑えるために、データベースサーバは静かにしておく必要があります。
パフォーマンスの問題が特定の時間に報告され、他の時間には報告されない場合は、比較のために優れたパフォーマンスを示す追加のAWRデータを提供します。

キャリブレーション_IO

。 calibrate_io コマンドは、ストレージシステムのテスト、比較、ベンチマークには使用しないでください。Oracleのドキュメントに記載されているように、この手順はストレージのI/O機能を調整します。

キャリブレーションはベンチマークと同じではありません。このコマンドの目的は、問題I/Oを使用して、データベース処理を調整し、ホストに対して実行されるI/Oのレベルを最適化することで効率を向上させることです。これは、によって実行されるI/Oのタイプが calibrate_io 処理が実際のデータベースユーザI/Oを表しているわけではありません。結果は予測不可能であり、再現さえできないこともよくあります。

SLOB2

Silly Little Oracle BenchmarkであるSLOB2は、データベースのパフォーマンス評価に好まれるツールになりました。Kevin Clossonによって開発され、次のサイトで入手できます。 "https://kevinclosson.net/slob/"。インストールと設定には数分かかり、実際のOracleデータベースを使用してユーザ定義の表領域にI/Oパターンを生成します。オールフラッシュアレイをI/Oで飽和状態にすることができる数少ないテストオプションの1つです。生成されるI/Oのレベルをはるかに低くして、IOPSは低くてもレイテンシの影響を受けやすいストレージワークロードをシミュレートする場合にも役立ちます。

スイングベンチ

Swingbenchはデータベースのパフォーマンスをテストするのに役立ちますが、ストレージに負荷がかかるような方法でSwingbenchを使用することは非常に困難です。NetAppでは、Swingbenchによるテストで、AFFアレイに多大な負荷をかけるのに十分なI/Oが生成されたことはありません。一部のケースでは、Order Entry Test（OET）を使用してレイテンシの観点からストレージを評価できます。これは、データベースに特定のクエリに対する既知のレイテンシの依存関係がある場合に役立ちます。オールフラッシュアレイの潜在的なレイテンシを実現できるように、ホストとネットワークを適切に設定する必要があります。

HammerDB

HammerDBは、TPC-CやTPC-Hのベンチマークなどをシミュレートするデータベーステストツールです。テストを適切に実行するために十分な大きさのデータセットを構築するには、多くの時間がかかることがありますが、OLTPアプリケーションやデータウェアハウスアプリケーションのパフォーマンスを評価するための効果的なツールになる可能性があります。

オリオン

Oracle OrionツールはOracle 9で一般的に使用されていましたが、さまざまなホストオペレーティングシステムの変更に対応するためにメンテナンスが行われていません。OSやストレージ構成との互換性がないため、Oracle 10やOracle 11で使用されることはほとんどありません。

Oracleはこのツールを書き直し、Oracle 12cにデフォルトでインストールされます。この製品は改良され、実際のOracleデータベースと同じ呼び出しの多くを使用しますが、コードパスやI/O動作はOracleで使用されているものとまったく同じではありません。たとえば、ほとんどのOracle I/Oは同期的に実行されます。つまり、I/O処理はフォアグラウンドで完了するため、I/Oが完了するまでデータベースは停止します。ストレージシステムをランダムI/Oでフラッディングするだけでは、実際のOracle I/Oが再現されるわけではなく、ストレージアレイを比較したり、構成変更の影響を測定したりする直接的な方法もありません。

とはいえ、特定のホスト/ネットワーク/ストレージ構成の最大パフォーマンスの一般的な測定や、ストレージシステムの健全性の測定など、Orionのユースケースもあります。綿密なテストを実施すれば、Orionの使用可能なテストを考案して、ストレージアレイを比較したり、構成変更の影響を評価したりすることができます。ただし、パラメータにIOPS、スループット、レイテンシを考慮し、現実的なワークロードを忠実にレプリケートしようとする必要があります。