Obrigado Chiappa, vou estudar os docs que me passou. Abs
On 3/21/08, jlchiappa <[EMAIL PROTECTED]> wrote: > > Colega, o documento que vc quer é a nota 280939.1, Subject:Checklist > for Performance Problems with Parallel Execution , lá vc verá que até > há algumas coisinhas que vc pode verificar, mas ela mesma (e as notas > para as quais há link dentro dela), outras notas relacionadas como a > 203238.1 Subject:Using Parallel Execution, a documentação mesmo > (manuais oficiais Oracle do banco, nos itens inicados pela nota > 184417.1 Subject: Where to find Information about Parallel Execution > in the Oracle Documentation, todas dizem o mesmo basicamente : > > 1. cada um dos parallel Slaves fazem um pedaço da leitura que o SQL > da sessão master lhe pediu, então ** SE ** a o SQL em si na sessão > master está ruim, está acessando muitas coisas que não precisa, está > usando um método de join ineficiente, etc, os slaves vão fazer > TONELADAS de trabalho inútil, o primeiro passo sempre, SEMPRE, ** > SEMPRE **, é tunning do SQL, para que ele faça o menor número possível > de LIOs, ok ? > > 2. já que os parallel slaves fazem I/O numa parcela do total, opções > que segreguem parte do todo (como PARTICIONAMENTO) são absolutamente > críticas para a performance deles. Da mesma forma o é o ajuste do I/O > (tanto dentro do banco, com params de multiblock_read e de > filesystem_options) quanto FORA do banco, no servior, setando onde > possível I/O asíncrono, I/O direto, params de I/O (** vitais no > unix/linux)..... > > ==> então a minha recomendação é : se não o fez ainda, *** PRIMEIRO > *** vá pro tunning do SQL, melhorias das estruturas de dados (com > paralelismo, índices seletivos, global temporary tables, modo > nologging aonde/se possível, etc), e pra verificação de I/O no banco > e no servidor, apenas ** SE ** não obter nada significativo aí sim vá > pro micro-tunning como é o caso de params de parallel... Isso porque, > tal como as notas metlink citadas falam, esses ajuste são CUSTOSOS, > baseados muito em tentativa e erro, e ao final talvez não tragam nada > de significativo.... > > []s > > Chiappa > > =========================================================== > Participe do ENPO - Encontro de Profissionais Oracle 2008 ! > Informações e inscrições em http://www.enpo-br.org > José Laurindo Chiappa, Palestrante ENPO-2008 > =========================================================== > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > "Rodrigo Telles" > <[EMAIL PROTECTED]> escreveu > > > > Pessoal, > > estou com uma query que , em seus eventos de espera, tenho o evento > *PX Deq: > > Execute Reply* como o maior. > > > > Evento > > Total_Waits > > Total_TimeOuts > > Time_Waited > > > > > > > > > > SQL*Net more data from client > > 1 > > 0 > > 0 > > PX Deq: Join ACK > > 4 > > 0 > > 0 > > PX Deq: Parse Reply > > 4 > > 0 > > 2 > > SQL*Net message to client > > 15 > > 0 > > 0 > > SQL*Net message from client > > 15 > > 0 > > 31 > > latch free > > 17 > > 14 > > 8 > > PX Deq Credit: send blkd > > 1738 > > 0 > > 175 > > PX Deq: Execute Reply > > 1954 > > 1597 > > 316325 > > PX Deq Credit: need buffer > > 9029 > > 0 > > 338 > > db file scattered read > > 14892 > > 0 > > 18049 > > db file sequential read > > 19486 > > 0 > > 15048 > > > > Em doc da Oracle esse evento é visto como idle event. Porém se o > tempo dele > > for muito grande com relação aos outros devemos investigar os processos > > paralelos escravos. Olhando cada um, que são 4, verifiquei que o maior > > evento em espera são:*PX Deq Credit: send blkd e PX Deq: Table Q Normal* > > Aqui temos um ambiente de DW e o Oracle é o 9.2.0.5 > > > > Alguém ja passou por essa situação e conseguiu diminuir esses eventos de > > espera? Além disso, a Oracle fala muito em investigar os processos > paralelos > > escravos? Existe algum lugar que mostre como investigar isso a fundo > > verificando se eles estão ou não trabalhando com boa performance? > > > > Sds > > > > Rodrigo > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas]
