Opa, blz ? Bom, se realmente Tudo que foi dito, tanto por mim quanto pelos
outros colegas, foi lido e levado em consideração OK, tamos tranquilos... Sendo
assim, eu Imagino que além da questão de tuning do SQL, Foram consideradas as
possibilidades do próprio database estar influindo, como por exemplo na geração
de planos diferentes para o mesmo SQL, atividades internas do database estarem
causando concorrência, etc, e isso Vai ser levado em conta por vc, que vai
fazer análise de waits pelas v$ citadas e/ou se possível ativar um trace de SQL
e/ou ter snapshots AWR gerais ativos em intervalos curtos durante as próximas
execuções, vai executar o script que passei para identificar quantos e quais
parallel slaves estão sendo ativados, vai consultar V$SQL e V$SQL_PLAN, etc ...
O fato é, vc TEM que eliminar a possibilidade de elementos externos à query
estarem interferindo, senão o tuning deles pode correr o risco de não resolver
o problema....
De resto, não deixe de perguntar sempre, estamos aqui para isso, só quis
relembrar vc que nós, por questão de tempo/esforço/oportunidade só podemos dar
um guia geral E mesmo esse é restrito, todos nós aqui respondemos em intervalos
do trabalho... Assim, a possibilidade de contratar um auxílio local temporário
certamente aceleraria em muito a Solução, mas se não há nem da forma mais
remota essa possibilidade, vc certamente chega lá mas vai demorar muito mais...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Rafael Vieira <vieira.rafael44@...>
escreveu
>
> Obrigado pela atenção de todos vocês.
> Tudo que foi dito, foi dada a atenção devida.
> Ao rodar o BATCH novamente, me atentei primeiramente ao Hardware. Abri um
> terminal e fiz as seguinte consultas:
>
> vmstat : Me deparei com um swap muito alto, uma quantidade de swap out que
> chegou a 9000.
>
> iostat - o %iostat chegou a 80%, é um disco SATA 2.
>
> Outra coisa que me atentei, foi realmente verificar as sessões ativas, e o
> que essas sessões ativas estavam sendo executadas...
> Como mais uma vez falei, a Query problemática volta a ocasionar todo esse
> problema...
>
> Então fiz um documento com uns prints mostrando os problemas que estavam
> acontecendo com o batch, e algumas sugestões de melhoria, como aumentar a
> memória física da máquina, mudar para um disco mais rápido e fazer o tunning
> da query.
>
> Eu sei que a intenção do fórum não é achar o problema para você, e sim dá
> sugestões. Me desculpem se "pedi" de mais. Mas infelizmente aqui é um dos
> poucos lugares aonde posso recorrer por ajuda, e sempre sou ajudado por todos
> vocês, agradeço a compreensão de todos e a ajuda de todos, todos os dias aqui
> no fórum é um grande aprendizado, creio eu, que para todos que acompanham o
> fórum é uma grande ferramenta de consulta e uma maneira de disseminar o
> conhecimento.
>
>
>
> ________________________________
> De: J. Laurindo Chiappa <jlchiappa@...>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Sexta-feira, 11 de Maio de 2012 20:29
> Assunto: [oracle_br] Re: Eventos em espera
>
>
>
> Na verdade, o tempo de 40 minutos para alguma coisa que é descrita como
> "batch" não me preocupa muito, MAS o fato de haver Flutuações, e flutuações
> grandes (de 40 minutos para 8h) sim... Claro que há diversas possibilidades
> de NÂO se executar o SQL simplesmente (tendo os dados coletados via view
> materializada, por exemplo), mas em se falando de descoberta da causa desse
> comportamento do SQL, eu digo :
>
> 1. tem que se confirmar (consultando a V$SQL, consultando os desenvolvedores,
> olhando o código-fonte, olhando as views de histórico como dba_hist_sqltext
> se vc tem Licença para elas, etc) que REALMENTE é Absolutamente o mesmo SQL
> que é executado a cada vez : absolutamente não é impossível que seja gerado
> dinamicamente um texto levemente diferente a cada execução
>
> 2. se REALMENTE o texto do SQL é sempre o mesmo mas há flutuações imensas
> como essas reportadas, aí há POUCAS possibilidades que podem causar esse tipo
> de comportamento :
>
> a. há Planos de Execução diferentes nas execuções "boas" e "ruins" - entre
> outras coisas, planos diferentes podem ser gerados por BIND VALUEs
> diferentes, mudanças no ambiente via ALTER SESSION, tamanhos amplamente
> diferentes de bind values, valores não-cobertos por histogramas sendo
> "adivinhados" erradamente pelo CBO, estatísticas alteradas (até as
> estatísticas "automáticas" coletadas quando o objeto não tem estatísticas
> reais ...
> Pra obter o Plano de Execução real, pode-se consultar a V$SQL_PLAN e
> derivadas no omento de cada execução, e/ou pode-se pedir um trace de SQL
> (evento 10046), se vc tiver o espaço necessário livre em disco
>
> b. uma das tabelas envolvidas é aleatoriamente preenchida com valores, aí
> quando vêm "poucos" valores/linhas na tabela o SQL vai bem, o plano escolhido
> é razoável, quando há "muitos" não... No plano de execução e na V$SQL há
> infos de qtdades/cardinalidades...
>
> c. há espera por LOCKs, latches ou recursos compartilhados do tipo : uma
> maneira simples de se saber são as colunas de WAIT da V$SESSION, outra
> poderia ser um trace de sql
>
> d. concorrência : apesar dos desenvolvedores dizerem que não há mais ninguém
> acessando o banco quando o SQL roda, é de bom tom se confirmar isso, na
> V$SESSION e/ou nas views históricas .... E lembremos que pode haver
> concorrência fora do database (ie, outros programas ou mesmo o SO consumindo
> recursos)...
> É durante a execução da rotina se usar as tools do SO (ou mesmo uma tool de
> monitoração de recursos permanentemente executando, como o Cacti, por
> exemplo), e consultar a V$SESSION e V$SESS_STATS para ver o que as sessões
> estão fazendo....
> Há a possibilidade de se consultar waits/recursos/eventos a nível de
> database, com o AWR, também : não é garantido que vc veja o que causa demora
> numa sessão olhando pro database como um todo, mas pode valer a tentativa, de
> repente se pega uma Evidência a mais ...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "ederson2001br" <ederson2001br@> escreveu
> >
> > 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]
> > >
> >
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
