Vous n'obtiendrez probablement pas les données que vous recherchez sans faire plus de configuration (comme activer l'audit) ou faire quelques compromis. Quel est le problème commercial que vous essayez de résoudre ? Selon le problème, nous pourrons peut-être vous aider à identifier l'approche la plus simple pour configurer la base de données afin de pouvoir enregistrer les informations que vous recherchez.
Oracle n'essaie de stocker nulle part le nombre de fois qu'un utilisateur particulier (et en particulier pas le nombre de fois qu'un utilisateur particulier du système d'exploitation) a exécuté une requête particulière. Le SQL_ID dans V$SESSION indique uniquement le SQL_ID que la session est en cours d'exécution. Si, comme je le suppose, il s'agit d'une application client-serveur, il est fort probable que ce soit NULL 99% du temps car la grande majorité du temps, la session n'exécute aucun SQL, elle attend l'utilisateur faire quelque chose. Le PREV_SQL_ID dans V$SESSION est l'instruction SQL précédente qui a été exécutée - qui au moins ne sera généralement pas NULL . Mais il n'aura qu'une seule valeur, il n'aura pas d'historique des instructions SQL exécutées par cette session.
Le V$SQL view est une représentation de ce qui se trouve dans le pool partagé SQL. Lorsqu'une instruction SQL vieillit hors du pool partagé, elle ne sera plus dans le V$SQL voir. La rapidité avec laquelle cela se produit dépend d'une multitude de facteurs - la fréquence à laquelle quelqu'un exécute l'instruction, la fréquence à laquelle les nouvelles instructions sont analysées (ce qui dépend généralement fortement de l'utilisation correcte des variables de liaison par vos applications), de la taille de votre pool partagé, etc. . Généralement, cela va prendre entre quelques minutes et jusqu'à ce que la base de données s'arrête.
Si vous êtes autorisé à utiliser les tables AWR et que vous êtes intéressé par des approximations plutôt que par des réponses parfaitement correctes, vous pourrez peut-être obtenir les informations que vous recherchez en consultant certaines des tables AWR. Par exemple, V$ACTIVE_SESSION_HISTORY capturera l'instruction SQL que chaque session exécutait activement chaque seconde. Comme il s'agit d'une application client-serveur, cela signifie que la grande majorité du temps, la session sera inactive, donc rien ne sera capturé. Cependant, les instructions SQL capturées pour une session vous donneront une idée de la fréquence relative des différentes instructions SQL. Bien sûr, les instructions SQL à exécution plus longue sont plus susceptibles d'être également capturées, car elles sont plus susceptibles d'être actives à un instant donné. Si les requêtes A et B s'exécutent toutes les deux exactement dans le même laps de temps et qu'une session a été capturée en exécutant A 5 fois et B 10 fois au cours de la dernière heure, vous pouvez conclure que B est exécuté environ deux fois plus souvent que A. Et si vous savez le temps d'exécution moyen d'une requête, la probabilité moyenne que la requête ait été capturée va être le nombre de secondes que la requête s'exécute (une requête qui s'exécute en 0,5 seconde a 50 % de chances d'être capturée, une qui s'exécute en 0,25 secondes a 25 % de chances d'être capturées) afin que vous puissiez estimer la fréquence à laquelle une session particulière a exécuté une requête particulière. C'est loin d'être un nombre exact, en particulier sur des périodes plus courtes et pour les requêtes dont les temps d'exécution réels sont plus variables.
Les données dans V$ACTIVE_SESSION_HISTORY La vue est généralement disponible pendant quelques heures. Il est ensuite échantillonné dans le DBA_HIST_ACTIVE_SESS_HISTORY tableau qui réduit la quantité de données disponibles d'un ordre de grandeur, ce qui rend toute estimation beaucoup moins précise. Mais ces données sont conservées quel que soit votre intervalle de conservation AWR (par défaut, c'est une semaine bien que de nombreux sites l'augmentent à 30 ou 60 jours).
