Du vil sandsynligvis ikke få de data, du leder efter, uden at foretage mere konfiguration (såsom at aktivere revision) eller indgå nogle kompromiser. Hvad er det forretningsproblem, du forsøger at løse? Afhængigt af problemet kan vi muligvis hjælpe dig med at identificere den nemmeste tilgang til at konfigurere databasen til at kunne registrere de oplysninger, du leder efter.
Oracle forsøger ikke at gemme hvor mange gange en bestemt bruger (og især ikke hvor mange gange en bestemt operativsystembruger) udførte en bestemt forespørgsel. SQL_ID i V$SESSION angiver kun SQL_ID at sessionen kører i øjeblikket. Hvis, som jeg gætter på, dette er en klient-server-applikation, er det ret sandsynligt, at dette er NULL 99% af tiden, fordi det store flertal af tiden ikke udfører nogen SQL, den venter på brugeren at gøre noget. PREV_SQL_ID i V$SESSION er den tidligere SQL-sætning, der blev udført - som i det mindste generelt ikke vil være NULL . Men det vil kun have én værdi, det vil ikke have en historik over SQL-sætningerne udført af den session.
V$SQL view er en repræsentation af, hvad der er i den delte SQL-pulje. Når en SQL-sætning ældes ud af den delte pulje, vil den ikke længere være i V$SQL udsigt. Hvor hurtigt det sker afhænger af en lang række faktorer - hvor ofte nogen udfører sætningen, hvor ofte nye sætninger parses (hvilket generelt afhænger meget af, om dine applikationer bruger bindevariabler korrekt), hvor stor din delte pulje er osv. Generelt vil det være et sted mellem et par minutter og indtil databasen lukker ned.
Hvis du har licens til at bruge AWR-tabellerne, og du er interesseret i tilnærmelser frem for helt korrekte svar, kan du muligvis få den information, du leder efter, ved at se på nogle af AWR-tabellerne. For eksempel V$ACTIVE_SESSION_HISTORY vil fange den SQL-sætning, som hver session aktivt udførte hvert sekund. Da dette er en klient-server-applikation, betyder det dog, at det meste af tiden, sessionen vil være inaktiv, så intet vil blive fanget. De SQL-sætninger, der tilfældigvis bliver fanget til en session, vil dog give dig en idé om den relative hyppighed af forskellige SQL-sætninger. Selvfølgelig er længerevarende SQL-sætninger også mere tilbøjelige til at blive fanget, da de er mere tilbøjelige til at være aktive på et givet øjeblik. Hvis forespørgsel A og B begge udføres på nøjagtig samme tid, og en session blev fanget, der udfører A 5 gange og B 10 gange i den sidste time, kan du konkludere, at B udføres omtrent dobbelt så ofte som A. Og hvis du ved den gennemsnitlige udførelsestid for en forespørgsel, den gennemsnitlige sandsynlighed for, at forespørgslen blev fanget, vil være antallet af sekunder, som forespørgslen udføres (en forespørgsel, der udføres på 0,5 sekunder har en 50 % chance for at blive fanget, en forespørgsel, der udføres om 0,25 sekunder har en 25 % chance for at blive fanget), så du kan estimere, hvor ofte en bestemt session udførte en bestemt forespørgsel. Det er langt fra et nøjagtigt tal, især over kortere tidsrammer og for forespørgsler, hvis faktiske eksekveringstider er mere variable.
Dataene i V$ACTIVE_SESSION_HISTORY visning er generelt tilgængelig i et par timer. Det bliver derefter samplet ned i DBA_HIST_ACTIVE_SESS_HISTORY tabel, som skærer mængden af tilgængelige data i en størrelsesorden, hvilket gør eventuelle estimater meget mindre nøjagtige. Men disse data opbevares uanset dit AWR-retentionsinterval (som standard er det en uge, selvom mange websteder øger det til 30 eller 60 dage).