Menu de navegação

[acg1574Participante]

Pessoal achei esse script na internet, e gostaria de uma coisa. pq ele fala q a hora inicial da operacao foi as 04:08 do dia 16/12/2016, sendo que foi as 10:38 do dia 15/12/2016 ?? e o calculo do processo fica correto ou fica errado ? ou estou comendo bola em algo, pq na tabela v$sql, da a data e a hora certinhas “2016-12-15/10:38:43”
mas na tabela v$session_longops, esta com data de hoje as 4 da madruga. alguem pode me explicar como funciona esse script ? obrigado.

select
to_char(sid) || ‘,’ || ltrim(to_char(serial#)) sid,
decode(opname,
‘Hash Join’, ‘Hash Join’,
‘Index Fast Full Scan’, ‘Index Scan’,
‘Sort Output’, ‘Sort Output’,
‘Sort/Merge’, ‘Sort Merge’,
‘Table Scan’, ‘Table Scan’,
‘-‘) operacao,
target objeto,
sofar executado,
totalwork total,
trunc((sofar/totalwork)*100,2) pct,
to_char(start_time, ‘DD/MM HH24:MI’) inicio,
trunc(elapsed_seconds/86400)|| ‘:’
|| to_char(to_date(mod(elapsed_seconds,86400), ‘SSSSS’), ‘HH24:MI:SS’) decorrido,
trunc(time_remaining/86400)|| ‘:’
|| to_char(to_date(mod(time_remaining,86400), ‘SSSSS’), ‘HH24:MI:SS’) restante,
decode(units,’Blocks’,’Blk’,’-‘) unidade,USERNAME,MESSAGE,elapsed_seconds,time_remaining
from v$session_longops
where time_remaining > 0
and sid like nvl(‘&sesid’,’%’);

[José Laurindo ChiappaModerador]

Nem vou olhar o script, mas tecnicamente falando, o que ocorre com a V$SESSION_LONGPS é que ela registra Cada Uma das ** sub-operações ** que um SQL faz, desde que cada suboperação leve mais do que o tempo que o RDBMS considera ser longo (3 segundos, normalmente)…
Então o seguinte : suponha que em 15 de Dezembro de 2016 às 22h:38m:43s vc começou a executar um SELECT que precisa ler via full-table-scan (que normalmente demora mais que os 3 segs) uma tabela A , uma tabela B e uma tabela C, e para cada fts vc precisa buscar dados complementares na tabela X, via índice – a V$SESSION_LONGOPS registraria algo do tipo :

=> “2016-12-15/22h:38m:43s” : começou o table scan na tabela A, digamos que ele vai levar três horas , isso é o que vai estar marcado nas colunas de start (a START_TIME), ELAPSED é marcado como zero, a previsão de término é calculada, etc

=> o full-table-scan vai acontecendo, vai indo e indo, a coluna ELAPSED e TIME_REMAINING vai sendo atualizada, até que 3 horas depois do ínicio da operação , em “2016-12-16/01h:38m:43s” ela acabou (aí o TIME_REMAINING é colocado como zero, o ELAPSED congela, etc) e uma nova sub-operação , ainda atendendo esse mesmo SQL começa…
Digamos que essa sub-operação é uma busca por índice na tabela X, e que isso seja tão rápido que não conte como long op, pois levou menos que 3 segundos : ** NADA ** vai ficar registrado pra isso na V$SESSION_LONGOPS

=> AINDA trabalhando para esse mesmo SQL, digamos que agora (em “2016-12-16/01h:38m:45s) o RDBMS precisa fazer um outro full table scan, agora na tabela B, que vai levar 5 horas : assim que esse FTS começa, START_TIME passa para “2016-12-16/01h:38m:45s”, ELAPSED é zerado e vai sendo incrementada cfrme a sub-operação (fts no caso) vai progredindo, TIME_REMAINING vai diminuindo a partir da estimativa….

E assim por diante, as operações necessárias para o SQL vão acontecendo e SE forem longas vão sendo registradas na V$SESSION_LONGOPS…. Sacou ???

Sendo assim, pra mim tá CLARO que o que está acontecendo aí é exatamente isso : o SQL começou às 22h:38m do dia 15/12/2016, mas ele demandou diversas sub-operações (full table scan, SORTs, MERGES, index scan, etc etc), que estão rolando ainda…..

O ponto é : essa START_TIME registra o começo DAS SUB-OPERAÇÕES INTERNAS LONGAs que o RDBMS teve/está tendo que fazer por causa de algum SQL – não tem NADA A VER com a data em que o SQL começou…. Tá claro ???

[]s

Chiappa

[José Laurindo ChiappaModerador]

Aliás, uma crítica pra esse script : ele mostra as sub-operações longas que estão ainda acontecendo, ok mas essas sub-operações estão sendo feitas por causa de QUAL SQL ???? No seu caso, como vc não tem essa info na tela, será que essa operação longa que vc viu que começou hoje ás 4 da madruga *** está relacionada *** com esse SQL que vc disparou às 10:38 do dia 15/12/2016 ????? Ou será que essa sub-operação aí decorreu de algum ** OUTRO SQL ** ???
Justamente pra não ter Dúvidas desse tipo, cada SQL no RDBMS Oracle ao começar a ser executado ganha um ID (um número identificador único, uma “chave” sequencial, se vc preferir) , que fica registrado na coluna SQL_ID da V$SQL, e a V$SESSION_LONGOPS justamente repete essa coluna SQL_ID, para sabermos ** qual ** o SQL que forçou o banco a fazer aquela operação longa….

Sabendo disso (e dos demais conceitos que expliquei) vc tem várias possibilidades :

a) se vc quer ter o histórico das operações longas de um SQL (além da operação longa que esse SQL esteja atualmente forçando o banco a fazer) a consulta teria um filtro pela SQL_ID e ela apareceria nas colunas do SELECT

b) se vc quer saber QUAIS SQLs estão neste momento forçando o banco a fazer operação longa, vc inclui o SQL_ID nas colunas do SELECT

e assim por diante…

Vale ** muito ** a pena dar uma estudada nos manuais Oracle que descrevem/explicam as V$ e alterar o script (ou mesmo criar o seu) em cima do que vc quer/precisa…

[]s

Chiappa

[Autor]

Posts