Rafael e Chiappa,
Permitam-me dar minha opinião.
Uma query rodando em 40 minutos, prá mim é um tempo longo se ela não for um
relatório/report. Se está em uma tela de consulta e com o sistema aberto para o
usuário da ponta rodá-la, pode olhar que esta rotina é uma séria candidata a um
refactoring, nem que seja para uma mudança de estratégia.
Outro ponto: levar 8 horas para rodar? só se for um processo batch que atualiza
zilhões de linhas. Cuidado com a concorrência, neste caso somente um usuário
poderia disparar esta rotina.
Se é uma tela de consulta/relatório, a hora de verificar é durante a execução.
Pontos a considerar:
- tunning da query: vc conhece TUNNING_TASK (dbms_sqltune.create_tuning_task)?
Isto pode te ajudar bastante, a analizar sua query, sugerindo indices ou melhor
escolha do plano de execução criando um profile otimizado do sql.
- Verificar LOCK durante a execução (tem o script UTLLOCKT.sql na área de
rdbms/admin). Se está havendo lock entre sessões, uma delas ficará aguardando
com a execução parada ...
- Verificar V$SESSION_LONGOPS (monitorar query´s demoradas):
SELECT TO_CHAR(s.sid) sid,
TO_CHAR(s.serial#) serial,
s.username,
SUBSTR(DECODE(target_desc,NULL,DECODE(target,NULL,opname, concat(opname,
concat (' - ',target))),
DECODE(target,NULL,concat(opname, concat (' : ',target_desc)),
concat(opname, concat (' : ',concat(target_desc, concat (' -
',target)))))),1,25) "Processo" ,
TO_CHAR(start_time,'dd/mm/yyyy hh24:mi:ss') "Inicio",
TO_CHAR(elapsed_seconds,'9999999') "Tempo(s)" ,
DECODE(sofar, 0, 0, ROUND(elapsed_seconds*(totalwork-sofar)/sofar)) "Blocos
Processados"
FROM v$session_longops l,
v$session s
WHERE sofar < totalWork
AND s.sid =l.sid;
Espero ter ajudado, sei que esta situação é complicadíssima pois já senti na
pele.
Forte abraço.
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
--- Em oracle_br@yahoogrupos.com.br, Rafael Vieira <vieira.rafael44@...>
escreveu
>
> Chiappa, gostaria de mais uma ajuda sua...
> Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em 8
> horas, o pessoal veio argumentar que a aplicação não mudou absolutamente
> nada, e que queria uma explicação por conta desse tempo, está todo mundo
> colocando a culpa no database, mas eu não mudei absolutamente nada, não foi
> feita nenhuma alteração e nenhum ajuste foi feito no database, o argumento do
> pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi colocado
> novamente em execução e acabou em 8 horas. O meu argumento está sendo que o
> problema é a query que detectei mal escrita que está dando o problema e que
> eh executada dezenas de vezes, mas eles voltam a argumentar o tempo que foi
> rodado antes em 40 minutos, teria algo a acrescentar em defesa do database?
> Preciso de uma justificativa à dar sobre isso, eu sei que é difícil pra uma
> pessoa que está de fora e não tem nem noção da infra-estrutura, nem idéia do
> modelo e de como é o processo,
> mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai pra
> diretoria e preciso de algo para me justificar. O grande problema é que não
> tenho à quem recorrer além do Blog e dos amigos.
>
>
> ________________________________
> De: Rafael Vieira <vieira.rafael44@...>
> Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
> Enviadas: Quinta-feira, 10 de Maio de 2012 9:35
> Assunto: Re: [oracle_br] Re: Eventos em espera
>
>
>
> Chiappa, muito obrigado pela ajuda.
>
> Realmente, achei muito interessante essa criação da view materializada,
> realmente essae query busca milhões de linhas todas as vezes que é
> consultada, e como falei anteriormente ela é rodada centenas de vezes( que
> segundo o pessoal realmente é necessário). Irei fazer sim esse teste junto
> com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc
> escreveu no prórpio grupo sobre MV's é uma excelente alternativa.
>
> Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em
> índices onde a maioria está setada para 8 que é o total de processadores que
> nós temos, como esse banco é expecífico para esse BATCH, quando o processo
> inicia ninguém mais se conecta no banco por questão de concorrência etc...
>
> No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? Eu
> sou muito novo na área e estou aprendendo aos poucos, eu me encontro em uma
> situação dificil pois não tem outro DBA para me auxiliar.
> Então alguns termos as vezes não fica claro para mim.
>
> As estatísticas, todas estão sim atualizadas.
>
> ________________________________
> De: J. Laurindo Chiappa <jlchiappa@...>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quarta-feira, 9 de Maio de 2012 18:10
> Assunto: [oracle_br] Re: Eventos em espera
>
>
>
> Colega, lamento ser o desmancha-prazeres, mas é um Fato que :
>
> - não existe um "parâmetro", um setting que vc aplique e faça qquer tarefa no
> banco de dados ficar "rápida"
>
> - como qquer software, se vc mandar o banco de dados fazer uma asneira
> (exemplo, ler a mesma informação vezes e vezes sem conta, repetidas vezes, ou
> não usar o melhor construto SQL para uma solicitação, ou acessar um modelo
> falho, etc ), ele VAI burramente fazer, não tem por onde
>
> ==> Então, a partir do momento que vc identificou um processamento que de
> cara não parece ser bem-feito E ainda por cima é repetido N vezes, pouco vc
> tem fazer no banco de dados em si - com certeza, algum tipo de Tuning no
> processo vai ser inescapável.... E que fique Claro, esse Tuning tanto pode
> envolver alterações no SQL envolvido (o que é comum), quanto também pode
> envolver no modelo (por exemplo, de-normalizando alguns pontos,
> criando/removendo índices, utilizando GTT sendo inseridas em APPEND-MODE para
> "separar" os dados, etc), quanto pode também envolver uso dos recursos do
> banco de dados para diminuir o I/O sendo feito (exemplo, particionamento da
> informação, uso de View materializadas que já trazem o resultado desejado
> para Evitar ter que ler e ler e ler a informação, etc, etc) ....
>
> Respondendo porém a sua pergunta sobre os eventos : os eventos com PX como
> prefixo são relacionados à SQL executando em parallel mode , e cfrme
> http://www.confio.com/blog/oracle-wait-event-explained-direct-path-read-temp
> , o evento de direct path read indica que ou o SQL está ordenando dados, ou
> está criando um área temporária em disco (para hash, talvez), ou simplesmente
> está fazendo paralelismo... TODAS essas operações dificilmente podem ser
> feitas em RAM, no caso de Parallel SQL é por definição : o modelo de
> paralelismo de SQL no RDBMS Oracle é dividir um segmento por intervalos e ter
> N slaves lendo o mesmo segmento, cada um lendo uma porção diferente de
> extents e cada slave enviando o que leu para a sessão MASTER, que é aquela de
> onde o Parallel SQL se originou, e se lê extents logicamente NÃO pode confiar
> no cache, que contém BLOCOS isolados....
>
> O que eu diria pra vc fazer de momento então é :
>
> 1. CONFIRMAR que vc está solicitando um grau de paralelismo razoável nas suas
> tabelas e índices, compatível com a quantidade de processadores que vc tem,
> com o grau de acesso simultãneo que o seu sub-sistema de I/O permite (é
> lógico que se já existem outros jobs consumindo I/O, ou se o seu sub-sistema
> de I/O é fraco e não consegue atender grande qtdade de acessos simultâneos,
> quanto mais parallel slaves ativos, pior é), e também compatível com os
> recursos de hardware (como RAM) ** livres ** : de nada adianta vc ter
> trocentos GB de RAM, por exemplo, se desse volume a maior parte já está
> alocado, não é porque vc tem dezenas de processadores que vc pode jogar o seu
> grau de paralelismo lá em cima se eles estão sendo consumidos....
>
> 2. Aumentar substancialmente a memória para SORTs e HASHes, se a qtdade de
> direct I/O path diminuir, vc sabe que ao menos parte deles era por SORTs ou
> HASHes...
>
> 3. CONFIRMAR que as estatísticas de Todas as tabelas e Índices envolvidos no
> SQL estão coletadas Recentemente, E que são representativas (ie, aonde vc ou
> o dono dos dados sabe que há mais valores distintos especificou-se na coleta
> HISTOGRAMAS, por exemplo)
>
> ==> SE mesmo com estas alterações o tempo de duração ficar o mesmo (o que
> pelo que vc descreve é bem provável), Não Vejo outro jeito que não se fazer o
> Tuning do processo...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "vieira.rafael44" <vieira.rafael44@>
> escreveu
> >
> > Pessoal, boa tarde.
> >
> > Estou tendo um problema, existe uma query que é rodada na aplicação
> > centenas de vezes é um processo recursivo e conversei com várias pessoas se
> > realmente é necessária rodar essa query tantas vezes e todos me disseram
> > que era necessário por conta da regra de negócio.
> >
> > Vi que a query tem sérios problemas de performance, como GROUP BY com 16
> > colunas, ORDER BY com 16 colunas, usa 8 tabelas com apenas 2 filtros, fica
> > complicado a minha situação, pois a query não poderá ser mudada agora na
> > aplicação e o BATCH precisa terminar e está muito lento por conta desta
> > query.
> >
> > Verifiquei os eventos em espera que está causando no banco e os eventos
> > encontrados foram esses:
> >
> > SELECT s.sid,
> > s.serial#,
> > s.username,
> > sw.event,
> > sw.p1text||'='||sw.p1 p1,
> > sw.p2text||'='||sw.p2 p2,
> > sw.p3text||'='||sw.p3 p3
> > FROM v$session_wait sw,
> > v$session s
> > WHERE sw.sid in (SELECT sid
> > FROM v$session
> > WHERE status ='ACTIVE'
> > AND USERNAME IS NOT NULL)
> > AND sw.sid = s.sid
> > ORDER BY sw.event
> >
> >
> > 27 2771 XUXA direct path read file number=16
> > first dba=1677954 block cnt=126
> >
> > 6 6009 XUXA direct path write temp file number=201
> > first dba=1343232 block cnt=31
> >
> > 1152 2429 XUXA PX Deq Credit: need buffer sleeptime/senderid=268501052
> > passes=27 qref=4801078576
> >
> > 1423 69 XUXA PX Deq Credit: send blkd sleeptime/senderid=268501000
> > passes=26 qref=4800963656
> >
> > 1449 1515 SYSTEM PX Deq Credit: send blkd sleeptime/senderid=268501032
> > passes=18 qref=4813095152
> >
> >
> > 1154 5791 XUXA PX Deq: Table Q Normal sleeptime/senderid=200
> > passes=18 =0
> >
> >
> > Alguns desses eventos aparecem dezenas de vezes, pelo pouco que entendo,
> > essa query que é rodada pela aplicação centenas de vezes está buscando os
> > dados em disco, se eu estiver correto, o que nao consigo entender que se
> > essa query é muito acessada, deveria estar buscando da memória, o banco
> > está sendo usado exclusivamente para esse BATCH.
> >
> > Alguém poderia me orientar o que posso fazer nessa situação?
> >
> > dados:
> > sga_max_target = 4GB
> > sga_target = 3GB
> > pga_aggregate_target = 2G
> > OEL 6
> > Oracle 11gR2
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
