Du kommer förmodligen inte att få den data du letar efter utan att göra mer konfiguration (som att aktivera revision) eller göra några kompromisser. Vilket är affärsproblemet du försöker lösa? Beroende på problemet kan vi kanske hjälpa dig att identifiera det enklaste sättet att konfigurera databasen för att kunna registrera den information du är ute efter.
Oracle försöker inte lagra någonstans hur många gånger en viss användare (och särskilt inte hur många gånger en viss operativsystemanvändare) utförde en viss fråga. SQL_ID i V$SESSION indikerar bara SQL_ID att sessionen körs för närvarande. Om, som jag gissar, det här är en klient-serverapplikation, är det ganska troligt att detta är NULL 99% av tiden eftersom sessionen inte kör någon SQL, den väntar på användaren. att göra någonting. PREV_SQL_ID i V$SESSION är den tidigare SQL-satsen som kördes - som åtminstone inte vanligtvis är NULL . Men det kommer bara att ha ett värde, det kommer inte att ha en historik över de SQL-satser som exekveras av den sessionen.
V$SQL vyn är en representation av vad som finns i den delade SQL-poolen. När en SQL-sats åldras ur den delade poolen kommer den inte längre att finnas i V$SQL se. Hur snabbt det händer beror på en mängd faktorer - hur ofta någon kör satsen, hur ofta nya satser analyseras (vilket i allmänhet beror mycket på om dina applikationer använder bindningsvariabler korrekt), hur stor din delade pool är, etc. . Generellt sett tar det någonstans mellan några minuter och tills databasen stängs av.
Om du har licens att använda AWR-tabellerna och du är intresserad av uppskattningar snarare än helt korrekta svar, kanske du kan få den information du är ute efter genom att titta på några av AWR-tabellerna. Till exempel V$ACTIVE_SESSION_HISTORY kommer att fånga SQL-satsen som varje session aktivt körde varje sekund. Eftersom detta är en klient-serverapplikation betyder det dock att sessionen för det mesta kommer att vara inaktiv, så ingenting kommer att fångas. De SQL-satser som råkar fångas för en session kommer dock att ge dig en uppfattning om den relativa frekvensen av olika SQL-satser. Naturligtvis är det mer sannolikt att SQL-satser som löper längre tid också fångas eftersom de är mer benägna att vara aktiva på ett givet ögonblick. Om fråga A och B båda körs på exakt samma tid och en session fångades som kör A 5 gånger och B 10 gånger under den senaste timmen, kan du dra slutsatsen att B exekveras ungefär dubbelt så ofta som A. Och om du vet den genomsnittliga exekveringstiden för en fråga, den genomsnittliga sannolikheten att frågan fångades kommer att vara antalet sekunder som frågan körs (en fråga som körs på 0,5 sekunder har 50 % chans att fångas, en som körs på 0,25 sekunder har 25 % chans att fångas) så att du kan uppskatta hur ofta en viss session körde en viss fråga. Det är långt ifrån ett exakt antal, särskilt över kortare tidsramar och för frågor vars faktiska körtider är mer varierande.
Data i V$ACTIVE_SESSION_HISTORY visningen är vanligtvis tillgänglig under några timmar. Den samplas sedan ner i DBA_HIST_ACTIVE_SESS_HISTORY tabell som minskar mängden tillgänglig data i en storleksordning vilket gör alla uppskattningar mycket mindre exakta. Men denna data bevaras oavsett ditt AWR-lagringsintervall (som standard är det en vecka även om många webbplatser ökar det till 30 eller 60 dagar).