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.rafae...@yahoo.com.br> 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 <jlchia...@yahoo.com.br> 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]
