Menu de navegação

[airoospParticipant]

Boa tarde,

É possível criar uma consulta para ver as querys que estão em execução e ter um percentual de quanto já foi executado?
Banco 11g R2 Std One em Windows.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

Blz ? Sim, a parte da monitoração é completamente possível, sim : se vc estivesse na mais sofisticada Enterprise Edition aí vc teria N outras possibilidades muito mais Sofisticadas (como na inestimável package DBMS_SQLTUNE, vide https://oracle-base.com/articles/11g/real-time-sql-monitoring-11gr1 , ou algum tracing leve com DBMS_MONITOR, ou talvez até mesmo marcar / “colorir” esses SQLs tipo cfrme https://dioncho.wordpress.com/tag/colored-sql/ mostra, que aí eles iam ser especificamente trackeados pelo AWR/ASH) , mas já que vc tá no SE1 não há outra possibilidade que não seja fazer manualmente… A query básica seria algo do tipo :

select a.sid,a.serial#,a.username,b.sql_text
from v$session a,v$sqltext b
where a.username is not null
and a.status = ‘ACTIVE’
and a.sql_address = b.address
order by 1,2,b.piece;

==> Óbvio, ela pode (E DEVE!!) ser Muuuuito Mais Sofisticada e ajustada ao SEU ambiente (por exemplo, usando as GV$ se vc tá em RAC, e/ou então incluindo as colunas de WAIT e de STATUS/classificação na V$SESSION cfrme necessário, entre outras coisas) mas o basicão é isto aí de cima…
Evidentemente, o RDBMS Oracle é ** MULTI-USUÀRIO **, então pra maior Disponibilidade não é absolutamente impossível ele atender por alguns segundos uma sessão, depois marcar essa sessão temporariamente como INATIVA e ir atender outra, depois volta e marca novamente como ATIVA a outra sessão e a atende mais um pouco… Assim, queries de monitoramento devem ser executadas MUITAS VEZES, repetidamente, em intervalos curtos, pra vc ter mais chances de ‘pegar’ os SQLs que mais vezes ficam marcados como Ativo….

Já sobre avaliar o quanto de trabalho um SQL já fez, há algumas Possibilidades :

1. se for um SQL de Longa Duração (ie, um SQL que contenha alguma operação longa, que CADA EXECUÇÃO dela demore mais de 6 segundos, como por exemplo um FULL TABLE SCAN), essa operação fica registrada na V$SESSION_LONGOPS, vide https://dwbi.org/database/oracle/35-how-to-find-out-expected-time-of-completion-for-an-oracle-query pra um pequeno exemplo… Que fique CLARO, é a EXECUÇÃO DA OPERAÇÃO que tem que demorar mais que 6 segundos : assim por exemplo se vc tiver uma demora total no SQL por causa de um index access sendo repetido um bilhão de vezes, isso NÃO VAI ficar registrado na V$SESSION_LONGOPS porque CADA INDEX SCAN demora apenas uns milisegundos, muito menos do que os 6 segs pra entrar na V$SESSIONS_LONGOPS…. Igualmente, se o Plano de Execução do seu SQL é composto por umaoperação longa (um FTS, digamos), e por outras curtas, APENAS A OPERAÇÂO LONGA vai ser registrada lá…

2. se teu banco estiver configurado pra tal (principalmente parâmetro TIMED_STATISTICS ativo) a cada poucos segundos o RDBMS registra na V$SQL (coluna rows_processed) quantas linhas o SQL já processou

3. depois de fazer cada operação necessária pra cada SQL da sessão (ie, consumir um pouco de CPU fazendo contas, obter linhas via full table scan ou via index access, fazer um HASH de resultsets, etc, etc) o RDBMS registra isso em views internas da sessão como V$SESSTAT

==> Notar que 2. e 3. são CUMULATIVOS : assim se uma sessão anteriormente consumiu 100 ms de CPu e acabou de consumir mais 10, vai estar registrado na linha correspondente 110 ms… Igualmente, se um SQL anteriormente processo 1000 linhas (numa execução anterior, digamos) e o mesmo SQL foi re-executado e nessa re-execução processou 20 linhas, vai estar marcado 1020 na ROWS_PROCESSED….

Muito bem : depois de ter uma noção de quanto o SQL já fez, o Total de trabalho esperado de um SQL não é automaticamente registrado pelo RDBMS (até porque isso poderia causar overhead), então só há ESTIMATIVAS : se vc quiser saber NA REAL quanto de trabalhos (ie, quantas linhas processa, quanta CPU gasta, quantos I/Os faz, etc) um SQL deveria fazer, só mesmo tracejando execuções prévias desse SQL e registrando pra comparar com o que vc tem hoje…
Há porém há algumas opções pra vc estimar isso :

a. vc pode obter o Plano de Execução do SQL (via DBMS_XPLAN.DISPLAY_CURSOR por exemplo, cfrme https://blogs.oracle.com/optimizer/how-do-i-display-and-read-the-execution-plans-for-a-sql-statement) , e ANTES de executar o SQL vc anotou na V$SQL o valor da ROWS_PROCESSED, para ‘descontar’ execuções anteriores : a soma da coluna ROWS do plano maaaaais ou menos ao ser comparada com o valor da ROWS_PROCESSED a cada execução do SQL de monitoramento vai te dar um Idéia pálida e geral antes de executar o SQL… Se quiser um pouco mais de precisão, talvez vc possa Ativar (no SQL mesmo via HINT, ou na sessão via ALTER SESSION antes de executar o SQL) a opção de monitoramento do plano de execução cfrme https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate

ou

b. vc pode ter registrado (em execuções anteriores) o quanto de recursos um SQL gastou e ir compararando frequentemente o quanto já foi registrado na execução corrente via V$SESSTAT…

EM grandes pinceladas é mais ou menos isso que temos em termos de MOnitoração no SE/SE1/SE2 okdoc ??

[]s

Chiappa

OBS :

só um comentário : veja que eu falei bastante em ‘registrar dados de execuções anteriores’ pra poder os comparar com os dados extraídos no momento via V$SQL, V$SESSTATS e cia bela…. Não à toa, é mais ou menos isso o que o AWR/ASH faz : como no SE/SE1/SE2 vc não tem essa facilidade, vc PROVAVELMENTE vai ter que criar um registro do tipo manualmente, por conta própria – http://pioro.github.io/orasash/ é um exemplo possível….

[José Laurindo ChiappaModerator]

Ah, detalhe/opção adicional : se vc ENCAPSULOU teus SQLs dentro de stored PL/SQLs (sejam procs, funcs ou packages) vc AINDA tem a opção de na V$SQL e relacionadas saber o Número da Linha do programa sendo executado, cfrme https://connor-mcdonald.com/2016/01/20/problematic-sql-plsql-is-your-friend/ nos mostra….. de repente é útil pra vc , é uma opção a mais de monitoração/controle….

[]s

Chiappa

[Author]

Posts