1

アイデアは、ユーザーがクエリを実行し、コストが特定のしきい値を超えている悪いデカルトを持っている場合です。次に、オラクルはそれを私とユーザーに電子メールで送信します。私はいくつかのことを試しましたが、実行時に機能しません。toad と sql の開発者が実行計画を確認できる場合。それから私はそこに情報があると信じています。または、別のロジックを採用する必要があるかもしれません。

4

1 に答える 1

1

一般に、これはおそらく不可能です。

SELECT理論的には、本当に決心していれば、システム内のすべてのテーブルに対して、 、INSERT、UPDATE、およびごとに発火し、 fromDELETEを取得し、 に結合し、必要なロジックを実装するファイングレイン監査 (FGA) トリガーを生成できます。技術的には可能ですが、かなりの量のコードが必要になり、システム内のすべてのクエリにかなりの量のオーバーヘッドが追加される可能性があります。これはおそらく実用的ではありません。SQL_IDV$SESSIONV$SQL_PLAN

トリガーを使用しようとするのではなく、DBMS_JOBまたはDBMS_SCHEDULERパッケージを介して数分ごとに実行するようにスケジュールされたプロシージャを記述しV$SESSIONて、すべてのアクティブなセッションをクエリし、に参加しV$SQL_PLAN、必要なロジックを実装することができます。これにより、ユーザーがステートメントを実行するたびにトリガーを実行しようとするオーバーヘッドがなくなります。しかし、それでもかなりの量のコードが必要です。

解決しようとしているビジネス上の問題によっては、コードを記述するよりも、ユーザーのプロファイルにリソース制限を作成して、単一の SQL ステートメントが消費できるリソースの量に制限を適用できるようにする方が簡単な場合があります。たとえば、ユーザーのCPU_PER_CALL、LOGICAL_READS_PER_CALL、またはCOMPOSITE_LIMITを設定して、CPU の量、論理 I/O の量、または Oracle が強制終了する前に単一のステートメントで実行できる CPU と論理 I/O の複合制限を制限できます。

さらに制御が必要な場合は、Oracle Resource Managerを使用できます。これにより、実行時間が長すぎると推定された場合にOracleが特定のユーザーからのクエリを実行できないようにしたり、それらのリソースに競合がある場合にユーザーのグループが消費できるリソースを調整したりすることができます. オラクルは、長時間実行されるクエリを特定のユーザーから優先度の低いグループに自動的に移動したり、長時間実行されたクエリを自動的に強制終了したり、最初から実行されないようにすることができます。

于 2011-09-06T14:22:46.373 に答える