Colega, antes de responder uma obs : se há criticidade suficiente, e se é exigida um tempo de resposta curto para este Incidente, eu recomendo Fortemente que vc avalie a possibilidade de contratação temporária de um DBA Sênior aí, que possa te ajudar localmente .... Isso porque nós aqui só podemos dar dicas gerais, não há possibilidade nenhuma de aprofundamento, nem é esse o objetivo do Fórum...
Isto posto , minhas obs : 1. a MV é uma possibilidade interessante, mas Não Deixe de consultar detalhadamente a Documentação (e os bons livros, como os do Tom Kyte), aonde se deatlham os mecanismos de funcionamento e exigências : nem todo SQL pode ser satisfeito com MVs 2. é óbvio que usuário e desenvolvedor vai dizer que não tem como deixar de executar a query trocentas vezes : não adianta que não passa na cabeça deles coisas como se ter os dados numa tabela de trabalho populada à noite (por exemplo) , e aí durante o dia para se buscar os dados é só um SELECT * dessa tabela.... O problema com técnicas do tipo, como nós sabemos, é que vc não teria os dados atualizados até o último minuto/segundo, mas como vc diz que é uma rotina tipo batch, nem sempre o fato de vc não ter a informação do dia de hoje influenciaa, até porque as vendas de hoje, os proddutos de hoje, enfim, os dados de hoje AINDA não estão fechados, faz sentido eles não entrarem num report gerencial... 3. quando vc diz que "não existe paralelismo em tabelas", vc Realmente tem certeza disso ??? Por exemplo, não há HINT de PARALLEL em ação nos seus SQLs ? Não há DDL dinâmico alterando degrees ?? Vc REALMENTE deveria, para se assegurar disso, rodar diversas vezes durante diversos dias a query que eu te passe logo no início da thread e que mostra os Parallel Master e SLAVEs, ** E ** consultar a V$SQL procurando por HINTs, e coisas assim.... 4. É bem difícil de aceitar quando vc diz que não há ninguém mais conectado ao database durante a execução do tal processo batch - database mono-usuário é algo Bem difícil de se ver .... Vc tem provas disso, por exemplo consultando a V$SESSION repetidas vezes durante o processamento ? Ou ainda, se vc tiver Licença para isso, vc consultou as views/tabelas de histórico do database para um intervalo em que o processamento estava executando ? Ainda mais, vc SABE que o próprio RDBMS Oracle possui Diversos processos internos que podem estar executando em qquer momento, e que assim ** pode ** haver concorrência sim, no caso entre o seu batch e os processos internos ? E ainda, vc CONFIRMOU consultando as tools do sistema operacional (como TOP, iostat, vmstat, netstat) que durante o processamento do tal batch realmente não tinha nada mesmo usando os recursos do hardware ?? 5. finalmente, sim : quando eu falei de sort area/hash area, ambos (sendo conexão dedicada) são sim componentes da PGA : a sugestão foi no sentido de, ao invpes de deixar o Oracle por tentativa e erro fazer o sizing, vc mesmo (via ALTER SESSION, talvez) setaria manualmente a área de sort e a de hash : dê uma verificada no manual de Tuning que ele fala um pouco a respeito. 6. estatísticas : absolutamente ** NÂO BASTA ** vc dizer que estão atualizadas... Repito/pergunto de novo, além de coletadas elas estão coletadas ADequadamente, com Histogramas nas colunas que vc saiba que tem desvio de valores, usando COMPUTE onde adequado, e sempre com DBMS_STATS, e nunca com ANALIZE ?? Quando as tabelas mudam/são inseridas/deletadas, as Estatísticas São recoletadas ?? []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rafael Vieira <vieira.rafael44@...> escreveu > > 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] >
