Вероятно няма да получите данните, които търсите, без да направите повече конфигурация (като активиране на одит) или да направите някои компромиси. Какъв е бизнес проблемът, който се опитвате да разрешите? В зависимост от проблема, може да сме в състояние да ви помогнем да идентифицирате най-лесния подход за конфигуриране на базата данни, за да можете да записвате информацията, която търсите.
Oracle не се опитва да съхранява никъде колко пъти конкретен потребител (и особено не колко пъти конкретен потребител на операционна система) е изпълнил определена заявка. SQL_ID в V$SESSION показва само SQL_ID че сесията се изпълнява в момента. Ако, както предполагам, това е клиент-сървър приложение, много вероятно е това да е NULL през 99% от времето, защото по-голямата част от времето сесията не изпълнява никакъв SQL, тя чака потребителя да направя нещо. PREV_SQL_ID в V$SESSION е предишният SQL израз, който е бил изпълнен-- това поне обикновено няма да бъде NULL . Но той ще има само една стойност, няма да има история на SQL изразите, изпълнени от тази сесия.
V$SQL изгледът е представяне на това, което е в споделения SQL пул. Когато даден SQL оператор остарее от споделения пул, той вече няма да бъде в V$SQL изглед. Колко бързо ще се случи това зависи от множество фактори-- колко често някой изпълнява оператора, колко често се анализират новите оператори (което обикновено зависи силно от това дали вашите приложения използват правилно свързващите променливи), колко голям е вашият споделен пул и т.н. . Обикновено това ще отнеме някъде между няколко минути и докато базата данни се изключи.
Ако имате лиценз да използвате AWR таблиците и се интересувате от приближения, а не от съвършено верни отговори, може да успеете да получите информацията, която търсите, като разгледате някои от AWR таблиците. Например V$ACTIVE_SESSION_HISTORY ще улови SQL израза, че всяка сесия се е изпълнявала активно всяка секунда. Тъй като обаче това е приложение клиент-сървър, това означава, че по-голямата част от времето сесията ще бъде неактивна, така че нищо няма да бъде уловено. SQL изразите, които се случват да бъдат заснети за сесия, обаче, ще ви дадат известна представа за относителната честота на различните SQL изрази. Разбира се, има по-голяма вероятност да бъдат уловени и по-продължителните SQL изрази, тъй като е по-вероятно те да бъдат активни в даден момент. Ако и двете заявки A и B се изпълняват за точно еднакво време и е заснета сесия, изпълняваща A 5 пъти и B 10 пъти през последния час, можете да заключите, че B се изпълнява приблизително два пъти по-често от A. И ако знаете средното време за изпълнение на заявка, средната вероятност заявката да бъде уловена ще бъде броят секунди, които заявката изпълнява (заявка, която се изпълнява за 0,5 секунди, има 50% шанс да бъде уловена, тази, която се изпълнява за 0,25 секунди има 25% шанс да бъде уловен), така че можете да прецените колко често конкретна сесия е изпълнявала конкретна заявка. Това далеч не е точното число, особено за по-кратки времеви рамки и за заявки, чието действително време за изпълнение е по-променливо.
Данните в V$ACTIVE_SESSION_HISTORY изгледът обикновено е достъпен за няколко часа. След това се взема извадка в DBA_HIST_ACTIVE_SESS_HISTORY таблица, която намалява количеството налични данни с порядък, което прави всички оценки много по-малко точни. Но тези данни се съхраняват за какъвто и да е вашият интервал на задържане на AWR (по подразбиране това е една седмица, въпреки че много сайтове го увеличават до 30 или 60 дни).
