Probabilmente non otterrai i dati che stai cercando senza fare più configurazione (come abilitare l'auditing) o fare qualche compromesso. Qual è il problema aziendale che stai cercando di risolvere? A seconda del problema, potremmo essere in grado di aiutarti a identificare l'approccio più semplice alla configurazione del database per poter registrare le informazioni che stai cercando.
Oracle non tenta di memorizzare da nessuna parte quante volte un particolare utente (e in particolare non quante volte un particolare utente del sistema operativo) ha eseguito una determinata query. Il SQL_ID in V$SESSION indica solo il SQL_ID che la sessione è attualmente in esecuzione. Se, come immagino, questa è un'applicazione client-server, è molto probabile che sia NULL il 99% delle volte perché la stragrande maggioranza delle volte la sessione non esegue alcun SQL, sta aspettando l'utente fare qualcosa. Il PREV_SQL_ID in V$SESSION è l'istruzione SQL precedente che è stata eseguita, che almeno non sarà generalmente NULL . Ma avrà solo un valore, non avrà una cronologia delle istruzioni SQL eseguite da quella sessione.
Il V$SQL view è una rappresentazione di ciò che è nel pool condiviso SQL. Quando un'istruzione SQL esce dal pool condiviso, non sarà più nel V$SQL Visualizza. La rapidità con cui ciò accade dipende da una moltitudine di fattori:la frequenza con cui qualcuno esegue l'istruzione, la frequenza con cui vengono analizzate le nuove istruzioni (che generalmente dipende fortemente dal fatto che le tue applicazioni utilizzino correttamente le variabili di collegamento), quanto è grande il tuo pool condiviso, ecc. In genere, ciò durerà da qualche minuto fino alla chiusura del database.
Se sei autorizzato a utilizzare le tabelle AWR e sei interessato ad approssimazioni piuttosto che a risposte perfettamente corrette, potresti essere in grado di ottenere le informazioni che cerchi guardando alcune delle tabelle AWR. Ad esempio, V$ACTIVE_SESSION_HISTORY catturerà l'istruzione SQL che ogni sessione stava eseguendo attivamente ogni secondo. Poiché si tratta di un'applicazione client-server, tuttavia, ciò significa che la maggior parte delle volte la sessione sarà inattiva, quindi non verrà acquisito nulla. Le istruzioni SQL che vengono acquisite per una sessione, tuttavia, ti daranno un'idea sulla frequenza relativa delle diverse istruzioni SQL. Naturalmente, è più probabile che vengano acquisite anche istruzioni SQL di esecuzione più lunga poiché è più probabile che siano attive in un determinato istante. Se la query A e B vengono eseguite entrambe esattamente nella stessa quantità di tempo e una sessione è stata acquisita eseguendo A 5 volte e B 10 volte nell'ultima ora, puoi concludere che B viene eseguito all'incirca il doppio di A. E se lo sai il tempo medio di esecuzione di una query, la probabilità media che la query sia stata acquisita sarà il numero di secondi di esecuzione della query (una query che viene eseguita in 0,5 secondi ha una probabilità del 50% di essere acquisita, una che viene eseguita in 0,25 secondi ha una probabilità del 25% di essere catturati) in modo da poter stimare la frequenza con cui una determinata sessione ha eseguito una determinata query. Questo è tutt'altro che un numero esatto, in particolare su intervalli di tempo più brevi e per query i cui tempi di esecuzione effettivi sono più variabili.
I dati in V$ACTIVE_SESSION_HISTORY la visualizzazione è generalmente disponibile per alcune ore. Viene quindi campionato nel DBA_HIST_ACTIVE_SESS_HISTORY tabella che riduce la quantità di dati disponibili di un ordine di grandezza rendendo le stime molto meno accurate. Ma quei dati vengono conservati per qualunque sia l'intervallo di conservazione dell'AWR (per impostazione predefinita, è una settimana, anche se molti siti lo aumentano a 30 o 60 giorni).
