Oracle 10gには、さまざまなリソースを制限するためのプロファイルがあります。わかりやすくするための参考資料 - orafaq.com、Oracle Documentationです。私は特に、他のすべてのセッションでパフォーマンスが低下するのを防ぐために、CPU_PER_CALL、LOGICAL_READS_PER_CALL、およびCOMPOSITE_LIMITを制限することに関心があります。Oracle User Profilesはどのように実用化されていますか？
私の問題は、本当に悪いものを防ぎながら、典型的な長期実行リソース集約型操作を可能にするこれらのパラメータにどのような値を使用するのか分かりません。ハードウェア、許容レベル、およびクエリに基づいて値が異なることに気付きます。そのため、どの値が最良かを判断する方法にもっと興味があります。
状況によっては、さまざまなアプローチがあります。可能な最も簡単なアプローチは、最長実行の現実的な操作がどれだけ長く実行されるかを尋ねることです（これは明らかにシステムに依存し、構築しているシステムか既存のシステムかによって異なります）。その時間制限および並列度に基づくCPU_PER_CALLを含む。シングルスレッドの操作を前提とすると、クエリが30分以内に戻ってこない場合、CPU_PER_CALLを設定してCPUの30分分を割り当てることができます（ほとんどのクエリで100を使用しないことが明らかです30分制限はあなたに呼吸の部屋のいくつかの量を与えるように、絶えず、％）。
これが既存のシステムであれば、あなた（またはあなたのDBA）はAWR/statspackレポートを妥当な日数で処理できます（システムによっては、月/四半期/年末のレポートを確認する必要があります）追加の処理が実行される可能性があります）、最もCPUとI/Oを使用する実際のステートメントを見つけます。プロファイルの上限を適切に設定することができます（つまり、過去1ヶ月の明細で記録された最大CPU +呼吸室の30％）。
もちろん、あなたが選んだ任意の限界に対して、誰かがシステムを監視して限界がペースを維持していることを確認する必要があります。例えば、データ量の増加のためにクエリがますます高価になる場合、最大30％の制限は6ヶ月では不十分かもしれません。あなたは、夜間の処理が中止されたときにそれを見つけ出すことは望ましくありません。誰かがそれを維持しなければなりません。
エンタープライズ版を使用している場合は、プロファイルではなくリソースマネージャーを見ているほうが良いでしょう。プロファイルでは暴走したセッションを殺すことができますが、Resource Managerではさまざまな要因に基づいてセッションの優先順位を変更できます。 30分以上のCPUを使用したクエリを強制終了するのではなく、優先度を低くして、実行中の他のセッションと干渉しないようにしてください。
リソース・マネージャのドキュメントには、「データベース・リソース・マネージャの主な目的は、Oracle Databaseサーバーにリソース管理の意思決定をより詳細に制御させることで、非効率なオペレーティング・システム管理に起因する問題を回避することです。これは私の目標には当てはまらないと思った。私は再びそれを見ます。先端に感謝します。 –
しかし、Oracleの観点からすれば、問題を解決しようとしている可能性があります。オペレーティングシステムのスケジューラは、ビジネスをオンラインに保ち、セッションが長時間のレポートを実行する重要なOLTP操作を行うセッションに等しい重みを与えるため、明日の会合では面白いかもしれない。 Resource Managerを使用すると、特定のセッションが他のセッションよりも重要であること、およびOLTPセッションの応答時間を維持するためにそのレポート・セッションを遅くする必要があることをOracleに伝えることができます。 –