Chiappa, Obrigado pelas dicas, vou ler este documento que enviou o link e vou pesquiser melhor sobre o software. Com relação ao paremetro disk_asynch_io, não será possível colocá-lo como true, pois o mesmo só é suportado para versões 9.2 de oracle como está dizendo a nota 225751.1 no metalink. Acho que a única saída seria mesmo colocar multiplos dbwrs, pelo menos até migrarmos para a versão 9.2 no qual será feito até meio do ano. Abraços,
Nelson Cartaxo DBA ORACLE -----Mensagem original----- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 09:48 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Nelson, PMFJI, mas deixe-me só adicionar mais alguns tópicos que podem te ajudar : a) primeiro, em vc tendo TUDO no mesmo volume, nos mesmos filesystems, controlados pela mesma única controladora, necessariamente ** vai ** haver contenção, já que (logicamente) uma controladora, por mais super-rápida que seja, NÂO consegue atender as N solicitações de I/O simultâneas que um banco Oracle faz, PONTO. da mesma forma, é fácil se comprovar pesquisando na net que por design o RAID-5 ** impõe ** uma demora extra pra cálculo de paridade, PONTO. Assim, o seu trabalho será ALIVIAR essas duas condições no possível, REALMENTE descobrir exatamente QUAL hardware de I/O vc tem, como está configurado exatamente, E em cima disso tentar otimizá-lo ao máximo, mas de saída vc já está com uma grande desvantagem aí, que é o fato de tudo depender de um único caminho de acesso. Assim, tranquilamente PODE ocorrer de essas melhorias que vc fizer na config de I/O simplesmente NÂo compensem essa desvantagem de hardware. O que vc irá fazer é ao final do trabalho montar um RELATÓRIO mostrando situação atual, situação depois das alterações, ganho obtido , MAS se o ganho ainda não for suficiente pra melhoria sensível, é mesmo ir pra up do hardware, não tem milagre aqui... Pra vc obter essas infos, é mesmo usar o iostat/vmstat (e/ou alguma tool específica como http://www.iozone.org/), <http://www.iozone.org/),> TRACEJAR no linux o que está sendo feito (em http://www.mgogala.com/directio.pdf <http://www.mgogala.com/directio.pdf> vc tem um exemplo com strace) , e fazer um TRACE 10046 level 12 dos principais processos dos usuários que estão causando demora nesse banco, aí com esse material vc tem argumentos pra mostrar pra tua gerência "ó, fiz isso aqui, como mostrado por esses traces obtive essa pequena melhoria aqui, este é o limite desse hardware". Enquanto vc não fizer isso, apresentando argumentos os mais sólidos possíveis, como vc disse "a culpa sempre é do banco" ... Caso vc não tenha experiência nesses itens citados, sugiro uma contratação temporário de um técnico que as tenha, ou algum estudo em cima das fontes que citei e das demias (como newsgroups, sites especializados em linux, etc). b) quando for mudar configs no banco, como eu tinha dito na msg anterior, o ideal é vc ter disk_asynch_io como TRUE, que aí vc tem I/O asíncrono , ao menos vc está otimizando o acesso à sua única controladora - múltiplos DBWRs são um QUEBRA-GALHO pra vc simular I/O asíncrono caso vc não possa ter a coisa real, mas NÂO comece por aí, tente a coisa real primeiro, ok ?? . CASO o teu pessoal de admin de SO e hardware não saiba se o hardware permite ou não, a sugestão seria vc criar uma pequena instânciazinha abrindo um pequeno database de teste nessa máquina, botar o parâmetro como TRUE e fazer uns testes de estabilidade e tracejar... c) lógico, já que o hardware não ajuda, torna-se AINDA mais premente vc desperdiçar o mínimo de recursos, então tablespaces LMT (preferencialmente uniform-size), operações direct-mode, geração de mínimo redo e undo possível, são simplesmente uma necessidade.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo <[EMAIL PROTECTED]> escreveu > > Oi Ricardo, > > O SO é Red Hat 2.1 e o banco é 8.1.7.4. Vou checar com o pessoal as > configurações do storage certinho, quantos discos, se tem discos internos em > raid, etc. > > > Atenciosamente, > Nelson Cartaxo > DBA ORACLE > GABD - Ger. Adm. de Banco de Dados > DATASUS/RJ (MS) > Tel: 3985-7090 > > -----Mensagem original----- > De: Ricardo Marques "Silvirio [mailto:[EMAIL PROTECTED] > Enviada em: segunda-feira, 13 de fevereiro de 2006 09:52 > Para: oracle_br@yahoogrupos.com.br > Assunto: Re: RES: RES: RES: [oracle_br] Re: Problema Urgente > > > Nelson, > > Verifique com o pessoal do SO, inclusive para > descobrir qual processo está consumindo mais recursos. > Se o LGWR, DBWR, etc... > A propósito: qual versão de seu SO e do Banco ? > Você está usando discos internos para RAID 5 ? São > Quantos ? > > Silvério. > > > --- Nelson Cartaxo <[EMAIL PROTECTED]> > wrote: > > > Jonathan, > > > > Agora está em média de 15 em 15 minutos os switchs. > > > > > > Ricardo, > > > > Quanto ao Raid, não tenho ideia, pois normalmente > > quem trata disso é o > > pessoal de SO. Tenho que concordar com o Jonathan > > que se eu diminuir o > > tamanho dos redos, certamente a performance irá > > piorar. Na verdade estou > > pensando em colocar mais processos de DBWR para ver > > se a contençao irá > > diminuir. > > > > Bem vou tentar algo por aqui, mas to achando dificil > > conseguir através do > > oracle. > > > > De qualquer maneira obrigado pela força aos dois. > > > > > > Atenciosamente, > > Nelson Cartaxo > > -----Mensagem original----- > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Enviada em: sábado, 11 de fevereiro de 2006 10:34 > > Para: oracle_br@yahoogrupos.com.br > > Assunto: Re: RES: RES: [oracle_br] Re: Problema > > Urgente > > > > > > > > > > Oi Ricardo, > > Pelo contrário, quanto menor os grupos > > de redo mais agressivo > > será a escrita em disco pois a cada alternância de > > log ocorre chekpoint e > > ocorrendo isto o lgwr escreve o conteúdo do buffer > > de redo para os redos, o > > dbwr escreve os buffers sujos do buffer cache para > > os datafiles, o processo > > checkpoint atualiza os cabeçalhos dos datafiles e > > controlfiles com os redo. > > Então o caso ficaria pior ainda. A Oracle aconselha > > dimensionar os grupos de > > > > redo para que ocorra uma alternância de log entre > > 15 a 20 min em média. > > Isto > > também para que o lgwr não tenha que esperar para > > escrever em um grupo de > > redo que ainda tenha transações ativas que não foram > > escritas nos datafiles. > > É bom também nesse caso aumentar os grupos de redo > > principalmente quando a > > carga de DML é intensa no banco. > > > > Abs > > > > Jonathan Barbosa > > > > ----- Original Message ----- > > From: "Ricardo Marques Silvério" > > <[EMAIL PROTECTED]> > > To: <oracle_br@yahoogrupos.com.br> > > Sent: Saturday, February 11, 2006 10:10 AM > > Subject: Re: RES: RES: [oracle_br] Re: Problema > > Urgente > > > > > > > Nelson, > > > > > > Você disse que está usando RAID5. Quantos discos > > você > > > tem ligados a este RAID5. Sua controladora possui > > > cache ? Este RAID5 foi criado com qual tamanho de > > > blocos ? > > > Em controladoras e alguns modelos de storage o > > RAID5 > > > deixa o sistema Oracle muito lento. Existem até > > alguns > > > docs no metalink que não recomendam a utilização > > de > > > RAID5, dando preferência a RAID 0, 0+1, 1 ou 10. > > Para > > > leitura o RAID5 geralmente é rápido, o problema é > > na > > > escrita. > > > Inicialmente, eu reduziria o tamanho dos redo > > logs. > > > Teoricamente, isso poderia amenizar o switch log > > pois > > > reduziria a sobrecarga de write nos discos. Seria > > um > > > paliativo: não iríamos resolver o problema > > totalmente. > > > Porém, é essencial você avaliar o que pode estar > > > ocorrendo com seu sistema de discos. > > > Em storages novos, este problema é compensado, > > sendo > > > em alguns casos o RAID5 até mais eficiente do que > > um > > > RAID 10 como no caso de um EVA da HP. > > > > > > Silvério. > > > > > > > > > --- Nelson Cartaxo <[EMAIL PROTECTED]> > > > wrote: > > > > > >> Luis, > > >> > > >> Até tem o SAR, mas o output é diferente > > >> > > >> Segue o resultado. > > >> > > >> Linux 2.4.9-e.3smp (papaterra.datasus.gov) > > >> 02/10/2006 > > >> > > >> 06:00:33 PM DEV tps blks/s > > >> 06:00:34 PM dev2-0 0.00 0.00 > > >> 06:00:34 PM dev3-0 0.00 0.00 > > >> 06:00:34 PM dev8-0 0.00 0.00 > > >> 06:00:34 PM dev8-1 0.00 0.00 > > >> 06:00:34 PM dev8-2 83.00 1040.00 > > >> > > >> Average: DEV tps blks/s > > >> Average: dev2-0 0.00 0.00 > > >> Average: dev3-0 0.00 0.00 > > >> Average: dev8-0 0.00 0.00 > > >> Average: dev8-1 0.00 0.00 > > >> Average: dev8-2 83.00 1040.00 > > >> > > >> Obrigado. > > >> > > >> > > >> Atenciosamente, > > >> Nelson Cartaxo > > >> DBA ORACLE > > >> -----Mensagem original----- > > >> De: Luis Claudio Arruda Figueiredo > > >> [mailto:[EMAIL PROTECTED] > > >> Enviada em: sexta-feira, 10 de fevereiro de 2006 > > >> 17:35 > > >> Para: oracle_br@yahoogrupos.com.br > > >> Assunto: Re: RES: [oracle_br] Re: Problema > > Urgente > > >> > > >> > > >> > > >> Boa tarde Nelson. > > >> > > >> Tente utilizar o comando sar. > > >> > > >> ex...: sar -d 1 1 > > >> > > >> Ele irá mostrar o i/o no disco como abaixo: > > >> > > >> UnixWare uw7homolog 5 7.1.3 i386 02/10/06 > > >> > > >> 17:27:02 device MB %busy avque > > >> r+w/s > > >> blks/s avwait avserv > > >> 17:27:03 c0b0t0d0s1 5500 2 1.0 > > > > >> 3 > > >> 72 0.0 6.7 > > >> 17:27:03 c0b0t0d0s13 70000 54 1.1 > > > > >> 104 > > >> 2160 0.3 5.2 > > >> 17:27:03 c0b0t0d0 277835 54 1.1 > > > > >> 107 > > >> 2232 0.5 5.0 > > >> 17:27:03 c0b0t2d0s1 69458 47 1.0 > > > > >> 61 > > >> 976 0.0 7.7 > > >> 17:27:03 c0b0t2d0 69459 47 1.0 > > > > >> 61 > > >> 976 0.0 7.7 > > >> > > >> Verifique os parâmetros como %busy para verificar > > o > > >> % > > >> de ocupação para write and read. > > >> Verifique no hardware do servidor se você possui > > uma > > >> controladora off-board com cache ou é só a > > on-board, > > >> se os discos são de 10,15 ou 20 rpm etc com base > > >> nestas informações você consegue diagnosticar se > > o > > >> gargalo é no disco ou não. > > >> Obs...:Eu sei que todos vêm mas vale lembrar > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com <http://mail.yahoo.com> < http://mail.yahoo.com <http://mail.yahoo.com> > > > > -------------------------------------------------------------------- -------- > ---------------------------------------------- > Atenção! As mensagens deste grupo são de acesso público e de inteira > responsabilidade de seus remetentes. > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> > < http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> > > -------------------------------------------------------------------- -------- > ---------------------------------------------- ______________________________ > ____________________________________ > Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine > > __________________________________________________________________ > > > > Yahoo! Grupos, um serviço oferecido por: > > PUBLICIDADE > > > > > _____ > > Links do Yahoo! Grupos > > > * Para visitar o site do seu grupo na web, acesse: > http://br.groups.yahoo.com/group/oracle_br/ <http://br.groups.yahoo.com/group/oracle_br/> > < http://br.groups.yahoo.com/group/oracle_br/ <http://br.groups.yahoo.com/group/oracle_br/> > > > > * Para sair deste grupo, envie um e-mail para: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] subject=Unsubscribe> > > > * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do > Serviço do Yahoo! < http://br.yahoo.com/info/utos.html <http://br.yahoo.com/info/utos.html> > . > > > > > [As partes desta mensagem que não continham texto foram removidas] > ---------------------------------------------------------------------------- ---------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> ---------------------------------------------------------------------------- ----------------------------------------------______________________________ ____________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Yahoo! Grupos, um serviço oferecido por: PUBLICIDADE _____ Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <http://br.groups.yahoo.com/group/oracle_br/> * Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo! <http://br.yahoo.com/info/utos.html> . [As partes desta mensagem que não continham texto foram removidas] -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
