Você provavelmente não obterá os dados que procura sem fazer mais configurações (como habilitar a auditoria) ou fazer algumas concessões. Qual é o problema de negócios que você está tentando resolver? Dependendo do problema, podemos ajudá-lo a identificar a abordagem mais fácil para configurar o banco de dados para poder registrar as informações que você procura.

A Oracle não tenta armazenar em nenhum lugar quantas vezes um determinado usuário (e particularmente não quantas vezes um determinado usuário do sistema operacional) executou uma determinada consulta. O SQL_ID em V$SESSION indica apenas o SQL_ID que a sessão está em execução no momento. Se, como estou supondo, esta é uma aplicação cliente-servidor, é bem provável que seja NULL 99% do tempo porque na grande maioria das vezes, a sessão não está executando nenhum SQL, está esperando o usuário fazer alguma coisa. O PREV_SQL_ID em V$SESSION é a instrução SQL anterior que foi executada -- que pelo menos geralmente não será NULL . Mas terá apenas um valor, não terá um histórico das instruções SQL executadas por essa sessão.

O V$SQL view é uma representação do que está no pool compartilhado do SQL. Quando uma instrução SQL sair do pool compartilhado, ela não estará mais no V$SQL Visão. A rapidez com que isso acontece depende de vários fatores - com que frequência alguém está executando a instrução, com que frequência novas instruções são analisadas (o que geralmente depende muito se seus aplicativos estão usando variáveis ​​de ligação corretamente), quão grande é seu pool compartilhado etc. Geralmente, isso vai demorar entre alguns minutos e até que o banco de dados seja desligado.

Se você estiver licenciado para usar as tabelas AWR e estiver interessado em aproximações em vez de respostas perfeitamente corretas, poderá obter as informações que procura examinando algumas das tabelas AWR. Por exemplo, V$ACTIVE_SESSION_HISTORY irá capturar a instrução SQL que cada sessão estava executando ativamente a cada segundo. Como este é um aplicativo cliente-servidor, no entanto, isso significa que, na grande maioria das vezes, a sessão ficará inativa, portanto, nada será capturado. As instruções SQL que são capturadas para uma sessão, no entanto, darão uma ideia sobre a frequência relativa de diferentes instruções SQL. É claro que instruções SQL de execução mais longa também são mais propensas a serem capturadas, pois são mais propensas a estarem ativas em um determinado instante. Se as consultas A e B forem executadas exatamente na mesma quantidade de tempo e uma sessão foi capturada executando A 5 vezes e B 10 vezes na última hora, você pode concluir que B é executado aproximadamente duas vezes mais que A. E se você souber o tempo médio de execução de uma consulta, a probabilidade média de que a consulta foi capturada será o número de segundos que a consulta executa (uma consulta executada em 0,5 segundo tem 50% de chance de ser capturada, uma que executa em 0,25 segundos tem 25% de chance de ser capturado) para que você possa estimar com que frequência uma determinada sessão executou uma determinada consulta. Isso está longe de ser um número exato, especialmente em prazos mais curtos e para consultas cujos tempos de execução reais são mais variáveis.

Os dados em V$ACTIVE_SESSION_HISTORY geralmente fica disponível por algumas horas. Em seguida, ele é amostrado no DBA_HIST_ACTIVE_SESS_HISTORY tabela que reduz a quantidade de dados disponíveis por uma ordem de grandeza, tornando quaisquer estimativas muito menos precisas. Mas esses dados são mantidos por qualquer que seja o intervalo de retenção do AWR (por padrão, é uma semana, embora muitos sites o aumentem para 30 ou 60 dias).