おそらく、追加の構成（監査の有効化など）を実行したり、妥協したりしない限り、探しているデータを取得することはできません。あなたが解決しようとしているビジネス上の問題は何ですか？問題によっては、必要な情報を記録できるようにデータベースを構成するための最も簡単なアプローチを特定できる場合があります。
Oracleは、特定のユーザーが特定のクエリを実行した回数（特に、特定のオペレーティングシステムユーザーが実行した回数）をどこにも保存しようとはしません。 SQL_ID V$SESSIONで SQL_IDのみを示します セッションが現在実行中であること。私が推測しているように、これがクライアントサーバーアプリケーションである場合、99％の確率でこれがNULLである可能性が非常に高くなります。これは、ほとんどの場合、セッションがSQLを実行しておらず、ユーザーを待機しているためです。何かをするために。 PREV_SQL_ID V$SESSIONで 実行された前のSQLステートメントです。少なくとも通常はNULLにはなりません。 。ただし、値は1つだけであり、そのセッションによって実行されたSQLステートメントの履歴はありません。
V$SQL ビューは、SQL共有プールにあるものを表したものです。 SQLステートメントが共有プールから古くなると、V$SQLには存在しなくなります。 見る。それがどのくらいの速さで発生するかは、誰かがステートメントを実行する頻度、新しいステートメントが解析される頻度（通常、アプリケーションがバインド変数を正しく使用しているかどうかに大きく依存します）、共有プールの大きさなど、さまざまな要因によって異なります。 。一般的に、それは数分からデータベースがシャットダウンするまでのどこかになります。
AWRテーブルの使用が許可されていて、完全に正しい答えではなく概算に関心がある場合は、いくつかのAWRテーブルを調べることで目的の情報を取得できる可能性があります。たとえば、V$ACTIVE_SESSION_HISTORY 各セッションが毎秒アクティブに実行されていたSQLステートメントをキャプチャします。ただし、これはクライアントサーバーアプリケーションであるため、ほとんどの場合、セッションは非アクティブになり、何もキャプチャされません。ただし、セッションでキャプチャされるSQLステートメントは、さまざまなSQLステートメントの相対頻度についてのアイデアを提供します。もちろん、実行時間の長いSQLステートメントは、特定の瞬間にアクティブになる可能性が高いため、キャプチャされる可能性も高くなります。クエリAとBの両方がまったく同じ時間で実行され、セッションがキャプチャされて、過去1時間にAが5回、Bが10回実行された場合、BはAの約2倍の頻度で実行されたと結論付けることができます。クエリの平均実行時間、クエリがキャプチャされた平均確率は、クエリが実行される秒数になります（0.5秒で実行されるクエリは、キャプチャされる可能性が50％で、0.25で実行されます。秒はキャプチャされる可能性が25％あるため、特定のセッションが特定のクエリを実行した頻度を見積もることができます。これは、特に短い時間枠で、実際の実行時間がより変動しやすいクエリの場合、正確な数とはほど遠いものです。
V$ACTIVE_SESSION_HISTORYのデータ ビューは通常、数時間利用できます。次に、DBA_HIST_ACTIVE_SESS_HISTORYにサンプリングされます。 利用可能なデータの量を桁違いに削減し、見積もりの精度を大幅に低下させるテーブル。ただし、そのデータはAWRの保持間隔に関係なく保持されます（多くのサイトでは30日または60日に延長されますが、デフォルトでは1週間です）。