Oracle 10gには、さまざまなリソースを制限できるプロファイルがあります。わかりやすくするための参考資料を次に示します-orafaq.com、OracleDocumentation。私は特に、、を制限することに興味がCPU_PER_CALLあり、形式の悪いステートメントが他のすべてのセッションのパフォーマンスを破壊するのを防ぐことを目的LOGICAL_READS_PER_CALLとしています。COMPOSITE_LIMIT
私の問題は、これらのパラメーターに使用する値がわからないことです。これにより、通常の長時間実行されるリソースを大量に消費する操作を可能にすると同時に、本当に悪い操作を防ぐことができます。値は、ハードウェア、許容レベル、および関連するクエリによって異なることを認識しています。そのため、どの値が最適かを判断するために従う方法に興味があります。
状況に応じて、さまざまなアプローチがあります。機能する可能性がある最も簡単な方法は、最も長く実行されている現実的な操作が実行される時間を尋ね (これは明らかにシステムに依存し、これが構築中のシステムであるか既存のものであるかによって異なります)、元に戻ることです。その時間制限と並列度に基づく CPU_PER_CALL。シングルスレッド操作を想定して、クエリが 30 分以内に返されなかった場合にそれを強制終了したいと合理的に言える場合は、CPU_PER_CALL を設定して 30 分分の CPU を割り当てることができます (明らかに、ほとんどのクエリは 100 を使用しません)。 30 分間の制限により、ある程度の余裕が得られるように、% を一定に保つ必要があります)。
これが既存のシステムである場合、あなた (またはあなたの DBA) は妥当な日数の間、AWR/statspack レポートを確認できます (一部のシステムでは、追加の処理が発生する可能性がある月/四半期/年末のレポートを確認する必要があります)。 CPU と I/O を最も多く使用する実際のステートメントを見つけます。その後、プロファイルの制限を適切に設定できます (つまり、過去 1 か月間にステートメントに対して記録された最大 CPU + 余裕の 30%)。
もちろん、選択した制限については、誰かがシステムを監視して、制限が遅れていないことを確認する必要があります。たとえば、データ量の増加によりクエリのコストが時間の経過とともにますます高くなる場合、その最大 + 30% の制限では 6 か月では不十分である可能性があります。毎晩の処理が中止されたときにそれを見つけたくない場合は、誰かがそれを維持する必要があります。
エンタープライズ エディションを使用している場合は、プロファイルよりもリソース マネージャーを見たほうがよい場合があります。プロファイルを使用するとランナウェイ セッションを強制終了できますが、Resource Manager を使用すると、さまざまな要因に基づいてセッションの優先度を変更できます。30 分以上 CPU を使用したクエリを強制終了するよりも、優先度を低くして、長時間実行されている場合に備えて、強制終了せずに他のセッションに干渉しないようにすることをお勧めします。