Res: [oracle_br] Re: Problemas de Performance - Oracle 9.2.0.4
Como vejo as tabelas mais acessadas do banco de dados.??? att, Welvis - Mensagem original De: Rodrigo Almeida <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 20 de Outubro de 2006 11:03:14 Assunto: Re: [oracle_br] Re: Problemas de Performance - Oracle 9.2.0.4 Olá Juliano, Problemas com a LMT não pode ser, pelo contrario, a DMT é mais lenta que uma LMT. Faça o Seguinte: 1 - ) Veja se nas tablespaces existem TABELAS e ÌNDICES juntos. Se achar crie outra tablespace só para índices e deixe uma somente para tabelas. 2 - ) Veja as tabelas mais acessadas, e verifique se está na mesma tablespace, caso tenha muitas tabelas que são acessadas constantemente, separe elas de tablespace, para distribuir o I/O entre os datafiles. 3 - ) Colete as estatísticas das tabelas. Se preciso periodicamente, Diário ou Semanal. 4 - ) Veja a quantidade de serviços de DB_WRITE_PROCESSES no init, caso seja 1, aumente para 2 ou 3. 5 - ) Passe analise nos índices também, no mesmo periodo que as tabelas. 6 - ) Como existe muitos comandos DML nas tabelas, alguns índices das principais tabelas podem estar "danificadas", como está com bastante eventos de db file scattered read (leitura de múltiplos blocos de disco para buffer), faça um REBUILD nas PKs e índices das tabelas. 7 - ) Se estiver utilizando versão 9i, faça um relatorio de STATSPACK, caso seja 10g AWR, para pode pegar mais informações sobre performance no banco de dados e SO. 8 - ) Quando os principais processos de carga entrarem, faça um trace na sessão, para coletar mais informações, sempre com a opção EXPLAIN do TKPROF habilitada no usuário. Acho que isso pode ajudar a melhorar um pouco o ambiente. Abraços, Rodrigo Almeida On 10/20/06, Juliano <[EMAIL PROTECTED]> wrote: > > Gustavo, > > Sou iniciante nessas tarefas de DBA, a parte de tunning não conheço > quase nada. Fiz uma consulta na sys.v_$system_event durante a > execução desses processos que tiveram a performance muito afetada. > Abaixo as informações obtidas > > Existe alguma dica que ta caindo de madura?? > Pude notar que o parametro wakeup time manager obteve uma média de > espera muito alta, comparada com os outros. Pode ser aí o problema?? > > Agradeço a atenção e ajuda de todos > > System-wide Wait Analysis > for current wait events > > > Average > Event Total Seconds > Total Wait > Name Waits Waiting Timeouts > (in secs) > -- --- > -- > db file scattered read7,668,3215,928 > 0 .000 > db file sequential read 3,412,3904,620 > 0 .000 > SQL*Net more data from client 363,3097,599 > 0 .020 > control file parallel write 253,169 360 > 0 .000 > control file sequential read102,2043 > 0 .000 > log file parallel write 91,2231 > 91,219 .000 > direct path read 50,9531 > 0 .000 > latch free 48,2661,309 > 26,252 .030 > direct path write25,9860 > 0 .000 > wakeup time manager 24,484 731,815 24,484 > 29.890 > log file sync19,154 129 > 3 .010 > db file parallel write 14,9430 > 0 .000 > db file parallel read 5,311 134 > 0 .030 > buffer busy waits 1,4636 > 0 .000 > LGWR wait for redo copy 5300 > 8 .000 > enqueue 3631,044 > 340 2.880 > rdbms ipc reply 800 > 0 .010 > log file sequential read 360 > 0 .010 > db file single write 270 > 0 .000 > log file single write260 > 0 .000 > process startup 100 > 0 .020 > log file switch completion51 > 0 .170 > async disk IO 30 > 0 .000 > recovery read 20 > 0 .000 > library cache load lock 20 > 0 .020 > reliable message 10 > 0 .010 > refresh controlfile command 10 > 0 .030 > control file heartbeat14 > 1 3.990 > library cache pin 13 > 1 2.990 > checkpoint completed 10 > 0 .450 > > --- Em or
Re: [oracle_br] Re: Problemas de Performance - Oracle 9.2.0.4
Olá Juliano, Problemas com a LMT não pode ser, pelo contrario, a DMT é mais lenta que uma LMT. Faça o Seguinte: 1 - ) Veja se nas tablespaces existem TABELAS e ÌNDICES juntos. Se achar crie outra tablespace só para índices e deixe uma somente para tabelas. 2 - ) Veja as tabelas mais acessadas, e verifique se está na mesma tablespace, caso tenha muitas tabelas que são acessadas constantemente, separe elas de tablespace, para distribuir o I/O entre os datafiles. 3 - ) Colete as estatísticas das tabelas. Se preciso periodicamente, Diário ou Semanal. 4 - ) Veja a quantidade de serviços de DB_WRITE_PROCESSES no init, caso seja 1, aumente para 2 ou 3. 5 - ) Passe analise nos índices também, no mesmo periodo que as tabelas. 6 - ) Como existe muitos comandos DML nas tabelas, alguns índices das principais tabelas podem estar "danificadas", como está com bastante eventos de db file scattered read (leitura de múltiplos blocos de disco para buffer), faça um REBUILD nas PKs e índices das tabelas. 7 - ) Se estiver utilizando versão 9i, faça um relatorio de STATSPACK, caso seja 10g AWR, para pode pegar mais informações sobre performance no banco de dados e SO. 8 - ) Quando os principais processos de carga entrarem, faça um trace na sessão, para coletar mais informações, sempre com a opção EXPLAIN do TKPROF habilitada no usuário. Acho que isso pode ajudar a melhorar um pouco o ambiente. Abraços, Rodrigo Almeida On 10/20/06, Juliano <[EMAIL PROTECTED]> wrote: > > Gustavo, > > Sou iniciante nessas tarefas de DBA, a parte de tunning não conheço > quase nada. Fiz uma consulta na sys.v_$system_event durante a > execução desses processos que tiveram a performance muito afetada. > Abaixo as informações obtidas > > Existe alguma dica que ta caindo de madura?? > Pude notar que o parametro wakeup time manager obteve uma média de > espera muito alta, comparada com os outros. Pode ser aí o problema?? > > Agradeço a atenção e ajuda de todos > > System-wide Wait Analysis > for current wait events > > > Average > Event Total Seconds > Total Wait > Name Waits Waiting Timeouts > (in secs) > -- --- > -- > db file scattered read7,668,3215,928 > 0 .000 > db file sequential read 3,412,3904,620 > 0 .000 > SQL*Net more data from client 363,3097,599 > 0 .020 > control file parallel write 253,169 360 > 0 .000 > control file sequential read102,2043 > 0 .000 > log file parallel write 91,2231 > 91,219 .000 > direct path read 50,9531 > 0 .000 > latch free 48,2661,309 > 26,252 .030 > direct path write25,9860 > 0 .000 > wakeup time manager 24,484 731,815 24,484 > 29.890 > log file sync19,154 129 > 3 .010 > db file parallel write 14,9430 > 0 .000 > db file parallel read 5,311 134 > 0 .030 > buffer busy waits 1,4636 > 0 .000 > LGWR wait for redo copy 5300 > 8 .000 > enqueue 3631,044 > 340 2.880 > rdbms ipc reply 800 > 0 .010 > log file sequential read 360 > 0 .010 > db file single write 270 > 0 .000 > log file single write260 > 0 .000 > process startup 100 > 0 .020 > log file switch completion51 > 0 .170 > async disk IO 30 > 0 .000 > recovery read 20 > 0 .000 > library cache load lock 20 > 0 .020 > reliable message 10 > 0 .010 > refresh controlfile command 10 > 0 .030 > control file heartbeat14 > 1 3.990 > library cache pin 13 > 1 2.990 > checkpoint completed 10 > 0 .450 > > --- Em oracle_br@yahoogrupos.com.br, "Gustavo Venturini de Lima" > <[EMAIL PROTECTED]> escreveu > > > > Valide se as estastísticas destas tabelas estão sendo calculadas > > corretamente, o plano de execução em cima delas e quais os wait > events... > > A utilização de LMT é muito recomendada... Com certeza o problema > não está > > aí... > > > > > > Em 19/10/06, Juliano <[EMAIL PROTECTED]> escreveu: > > > > > > Bom Dia Lista > > > > > > Há 2 meses realizei uma instalação do Oracle 9i (9.2.0.4) em um > > > Servidor Linux Red Hat 9. O motivo dessa instalação foi devido > uma > > > quebra do HD exis
[oracle_br] Re: Problemas de Performance - Oracle 9.2.0.4
Gustavo, Sou iniciante nessas tarefas de DBA, a parte de tunning não conheço quase nada. Fiz uma consulta na sys.v_$system_event durante a execução desses processos que tiveram a performance muito afetada. Abaixo as informações obtidas Existe alguma dica que ta caindo de madura?? Pude notar que o parametro wakeup time manager obteve uma média de espera muito alta, comparada com os outros. Pode ser aí o problema?? Agradeço a atenção e ajuda de todos System-wide Wait Analysis for current wait events Average Event Total Seconds Total Wait Name Waits Waiting Timeouts (in secs) -- --- -- db file scattered read7,668,3215,928 0 .000 db file sequential read 3,412,3904,620 0 .000 SQL*Net more data from client 363,3097,599 0 .020 control file parallel write 253,169 360 0 .000 control file sequential read102,2043 0 .000 log file parallel write 91,2231 91,219 .000 direct path read 50,9531 0 .000 latch free 48,2661,309 26,252 .030 direct path write25,9860 0 .000 wakeup time manager 24,484 731,815 24,484 29.890 log file sync19,154 129 3 .010 db file parallel write 14,9430 0 .000 db file parallel read 5,311 134 0 .030 buffer busy waits 1,4636 0 .000 LGWR wait for redo copy 5300 8 .000 enqueue 3631,044 340 2.880 rdbms ipc reply 800 0 .010 log file sequential read 360 0 .010 db file single write 270 0 .000 log file single write260 0 .000 process startup 100 0 .020 log file switch completion51 0 .170 async disk IO 30 0 .000 recovery read 20 0 .000 library cache load lock 20 0 .020 reliable message 10 0 .010 refresh controlfile command 10 0 .030 control file heartbeat14 1 3.990 library cache pin 13 1 2.990 checkpoint completed 10 0 .450 --- Em oracle_br@yahoogrupos.com.br, "Gustavo Venturini de Lima" <[EMAIL PROTECTED]> escreveu > > Valide se as estastísticas destas tabelas estão sendo calculadas > corretamente, o plano de execução em cima delas e quais os wait events... > A utilização de LMT é muito recomendada... Com certeza o problema não está > aí... > > > Em 19/10/06, Juliano <[EMAIL PROTECTED]> escreveu: > > > > Bom Dia Lista > > > > Há 2 meses realizei uma instalação do Oracle 9i (9.2.0.4) em um > > Servidor Linux Red Hat 9. O motivo dessa instalação foi devido uma > > quebra do HD existente nesse servidor. > > Criei a base de dados mantendo os mesmos parâmetros de configuração > > existentes nesse Servidor anteriormente (Servidor IBM XSeries > > Pentium III bi-processado) > > A única diferença que teve foi que anteriormente esse servidor > > possuía tablespaces DMT e agora eu criei as mesmas como LMT > > Autoallocate. > > O Sistema utilizado para acessar os dados do banco não sofreu > > nenhuma alteração, a versão é a mesma da instalação antiga. O > > Hardware também é o mesmo, com as mesmas configurações. > > > > Acontece que somente em "dois" processos (segundo os responsáveis > > pelo desenvolvimento do sistema, os dois realizam muito > > select/insert/update e delete nas maiores tabelas do sistema) os > > usuários reclamam que
