Oracle のオプティマイザ インデックス コスト調整パラメータを設定する正しい方法は何ですか。開発者として、このパラメータを下げるとパフォーマンスが大幅に向上することを確認しました。一般的なクエリは 2 秒から 200 ミリ秒に短縮されます。この値を下げるとデータベースに深刻な問題が発生するという警告がネット上にたくさんありますが、何が問題になるのかは詳しく示されていません。
現時点では、アプリケーションのパフォーマンスが大幅に向上し、欠点は見当たらないという良い面しか見られません。これらのパラメータを調整することで生じる可能性のある悪影響について、さらに理解を深める必要があります。
答え1
このパラメータを変更することが推奨されない理由は、オプティマイザにデータベース全体にわたる影響を与えるためです。したがって、特定のクエリを調整するためにパラメータを変更すると、他の多くのクエリにも影響が及ぶ可能性があります。したがって、アプリ全体を慎重にテストせずに本番環境でパラメータを変更するのは危険です。
しかし：
- 開発/テスト環境で設定し、本番環境で同じ値を維持することは許容される可能性があります (OLTP システムでは一般的な方法でした)。ただし、アプリが専用の DB で実行され、デフォルトのパラメータ セットを使用して別の DB に統合されないことを確信できますか?
- パラメータは、OracleがI/OとCPUの相対コストに関するヒューリスティックを使用しているため役立ちますが、あなたのケースではヒューリスティックが十分ではないため、Oracleは最適ではない実行プランを選択します。ヒューリスティックを修正するための推奨方法は、Oracleに収集させることです。システム統計DB マシンの場合 - CPU の速度はどのくらいか、通常のシステム負荷時に I/O システムから単一ブロックまたは複数ブロックを取得するのにどのくらい時間がかかるかなど。Oracleドキュメントを参照。
システム統計とオプティマイザーパラメータの両方を使用したい場合は、Google で検索してください。Jonathan Lewis がそれについて書いています (申し訳ありませんが、サイトでは複数のリンクを投稿できません)
参考になれば幸いです
答え2
このパラメータは、実稼働環境では変更しないでください。主な用途は、異なる実行プランでパフォーマンスを確認するためだけに、プラン変更を強制することです。基本的に、データベース内のすべてのインデックスは他のアクセス パスよりも安価であるとオプティマイザに提案していることになります。これは、一部の SQL では当てはまるかもしれませんが、他の SQL では当てはまらない可能性があります。
適切なパフォーマンス プランを作成したら、オプティマイザーがそれを使用しない理由を理解し、修正を試みる必要があります (つまり、最新で正確な統計が利用できない -> 最新のより正確な統計を収集します)。
これが役に立つことを願います、ステファノ
答え3
これら 2 つのパラメータのデフォルトは、最も一般的なタイプのデータベースである OLTP システムには不向きです。これにより、完全なテーブル スキャンが増え、クエリが不適切になります。通常、これらのパラメータは、稼働前に設定する必要があります。テスト フェーズで設定します。
稼働後にこれらを変更すると、不適切な設定に調整された他のクエリが変更されるリスクがあります。クエリ プランではなく応答時間について言及しているため、データベースの調整についてあまり知らないようです。これらのパラメータには触れないでください。
ほとんどの DBA は、修正と設計の概念の違いを理解していません。稼働後は修正を行うため、そのときにこれらのパラメータを変更する際には注意が必要です。稼働する前は、設計と開発の段階です。そのときに、このようにパラメータを調整します。
ちなみに、これらのパラメータから始めるのが良いでしょう (本番環境に移行する前に、何をしているのかわかっている場合にのみ注意してください)。
optimizer_index_cost_adj=10 オプティマイザ キャッシュ=90
これは OLTP 用です。バッチ処理の場合、最初に使用する設定は大きく異なります。私はこれらの設定を少しいじっていますが、これらの設定により、OLTP では 99% の確率で全体的に最良の結果が得られます。ただし、実稼働に移行した後は、これらの設定には触れません。設定が適切でない場合は、そのままにして、クエリを調整します。