U krijgt waarschijnlijk niet de gegevens waarnaar u op zoek bent zonder meer configuratie (zoals het inschakelen van auditing) of het sluiten van enkele compromissen. Wat is het zakelijke probleem dat u probeert op te lossen? Afhankelijk van het probleem kunnen we u misschien helpen bij het identificeren van de eenvoudigste manier om de database te configureren om de gewenste informatie te kunnen vastleggen.
Oracle probeert nergens op te slaan hoe vaak een bepaalde gebruiker (en vooral niet hoe vaak een bepaalde gebruiker van het besturingssysteem) een bepaalde query heeft uitgevoerd. De SQL_ID in V$SESSION geeft alleen de SQL_ID . aan dat de sessie momenteel wordt uitgevoerd. Als, zoals ik vermoed, dit een client-servertoepassing is, is het vrij waarschijnlijk dat dit 99% van de tijd NULL is, omdat de sessie in de overgrote meerderheid van de tijd geen SQL uitvoert, maar op de gebruiker wacht iets doen. De PREV_SQL_ID in V$SESSION is de eerdere SQL-instructie die is uitgevoerd -- die in het algemeen niet NULL zal zijn . Maar het heeft maar één waarde, het heeft geen geschiedenis van de SQL-instructies die door die sessie zijn uitgevoerd.
De V$SQL view is een weergave van wat zich in de gedeelde SQL-pool bevindt. Wanneer een SQL-instructie uit de gedeelde pool veroudert, staat deze niet langer in de V$SQL visie. Hoe snel dat gebeurt, hangt af van een groot aantal factoren:hoe vaak iemand de instructie uitvoert, hoe vaak nieuwe instructies worden geparseerd (wat over het algemeen sterk afhangt van of uw toepassingen de bindvariabelen correct gebruiken), hoe groot uw gedeelde pool is, enz. Over het algemeen is dat ergens tussen een paar minuten en totdat de database wordt afgesloten.
Als u een licentie heeft om de AWR-tabellen te gebruiken en u bent geïnteresseerd in benaderingen in plaats van perfect correcte antwoorden, kunt u wellicht de informatie krijgen die u zoekt door enkele van de AWR-tabellen te bekijken. Bijvoorbeeld V$ACTIVE_SESSION_HISTORY zal de SQL-instructie vastleggen die elke sessie elke seconde actief aan het uitvoeren was. Aangezien dit een client-servertoepassing is, betekent dit echter dat de sessie in het overgrote deel van de tijd inactief zal zijn, zodat er niets wordt vastgelegd. De SQL-instructies die toevallig voor een sessie worden vastgelegd, geven u echter een idee van de relatieve frequentie van verschillende SQL-instructies. Natuurlijk is de kans groter dat ook langer lopende SQL-instructies worden vastgelegd, omdat ze waarschijnlijker op een bepaald moment actief zijn. Als query A en B beide in exact dezelfde tijd worden uitgevoerd en een sessie is vastgelegd tijdens het uitvoeren van A 5 keer en B 10 keer in het afgelopen uur, kun je concluderen dat B ongeveer twee keer zo vaak wordt uitgevoerd als A. En als je weet de gemiddelde uitvoeringstijd van een query, de gemiddelde kans dat de query is vastgelegd, is het aantal seconden dat de query wordt uitgevoerd (een query die in 0,5 seconden wordt uitgevoerd, heeft 50% kans om te worden vastgelegd, een kans die wordt uitgevoerd in 0,25 seconden heeft een kans van 25% om te worden vastgelegd), zodat u kunt inschatten hoe vaak een bepaalde sessie een bepaalde query heeft uitgevoerd. Dat is verre van een exact aantal, vooral over kortere tijdsperioden en voor zoekopdrachten waarvan de werkelijke uitvoeringstijden meer variabel zijn.
De gegevens in V$ACTIVE_SESSION_HISTORY weergave is over het algemeen beschikbaar voor een paar uur. Het wordt vervolgens gesampled in de DBA_HIST_ACTIVE_SESS_HISTORY tabel die de hoeveelheid beschikbare gegevens met een orde van grootte vermindert, waardoor schattingen veel minder nauwkeurig zijn. Maar die gegevens worden bewaard voor wat uw AWR-retentie-interval ook is (standaard is dat een week, hoewel veel sites dit verlengen tot 30 of 60 dagen).