Probablemente no obtendrá los datos que está buscando sin hacer más configuraciones (como habilitar la auditoría) o hacer algunos compromisos. ¿Cuál es el problema comercial que está tratando de resolver? Dependiendo del problema, es posible que podamos ayudarlo a identificar el enfoque más fácil para configurar la base de datos para poder registrar la información que busca.
Oracle no intenta almacenar en ningún lugar cuántas veces un usuario en particular (y particularmente cuántas veces un usuario de un sistema operativo en particular) ejecutó una consulta en particular. El SQL_ID en V$SESSION solo indica el SQL_ID que la sesión se está ejecutando actualmente. Si, como supongo, esta es una aplicación cliente-servidor, es muy probable que sea NULL el 99% de las veces porque la gran mayoría de las veces, la sesión no ejecuta ningún SQL, está esperando al usuario. hacer algo. El PREV_SQL_ID en V$SESSION es la instrucción SQL anterior que se ejecutó, que al menos generalmente no será NULL . Pero solo tendrá un valor, no tendrá un historial de las sentencias SQL ejecutadas por esa sesión.
El V$SQL view es una representación de lo que hay en el grupo compartido de SQL. Cuando una declaración de SQL vence del grupo compartido, ya no estará en el V$SQL vista. La rapidez con que eso suceda depende de una multitud de factores:la frecuencia con la que alguien ejecuta la declaración, la frecuencia con la que se analizan las nuevas declaraciones (lo que generalmente depende en gran medida de si sus aplicaciones usan las variables de vinculación correctamente), qué tan grande es su grupo compartido, etc. Por lo general, eso será en algún momento entre unos minutos y hasta que la base de datos se apague.
Si tiene licencia para usar las tablas AWR y está interesado en aproximaciones en lugar de respuestas perfectamente correctas, es posible que pueda obtener la información que busca mirando algunas de las tablas AWR. Por ejemplo, V$ACTIVE_SESSION_HISTORY capturará la declaración SQL que cada sesión estaba ejecutando activamente cada segundo. Sin embargo, dado que se trata de una aplicación cliente-servidor, eso significa que la gran mayoría de las veces, la sesión estará inactiva, por lo que no se capturará nada. Sin embargo, las declaraciones de SQL que se capturan para una sesión le darán una idea de la frecuencia relativa de las diferentes declaraciones de SQL. Por supuesto, es más probable que también se capturen las sentencias SQL de ejecución más prolongada, ya que es más probable que estén activas en un instante determinado. Si la consulta A y B se ejecutan exactamente en la misma cantidad de tiempo y se capturó una sesión ejecutando A 5 veces y B 10 veces en la última hora, puede concluir que B se ejecuta aproximadamente el doble de veces que A. Y si sabe el tiempo promedio de ejecución de una consulta, la probabilidad promedio de que la consulta haya sido capturada será la cantidad de segundos que la consulta se ejecute (una consulta que se ejecuta en 0,5 segundos tiene un 50 % de posibilidades de ser capturada, una que se ejecuta en 0,25 segundos tiene un 25% de posibilidades de ser capturado) para que pueda estimar con qué frecuencia una sesión en particular ejecutó una consulta en particular. Eso está lejos de ser un número exacto, particularmente en períodos de tiempo más cortos y para consultas cuyos tiempos de ejecución reales son más variables.
Los datos en V$ACTIVE_SESSION_HISTORY La vista generalmente está disponible durante unas horas. Luego se muestrea en el DBA_HIST_ACTIVE_SESS_HISTORY tabla que reduce la cantidad de datos disponibles en un orden de magnitud, lo que hace que las estimaciones sean mucho menos precisas. Pero esos datos se guardan durante el intervalo de retención de AWR (de manera predeterminada, es una semana, aunque muchos sitios lo aumentan a 30 o 60 días).
