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/), TRACEJAR no linux o que está sendo feito (em 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
Oi, Nelson : eu não tinha ainda trabalhado com 8i em linux, mas já usei async em 8i nos mais diversos unixes (aix, hp, Solaris) e nunca tive probs, imaginava que no linux fosse o mesmo, talvez só precisasse de algum patch... Putz, não é à toa que neguinho reclamava tanto do 8i no linux nos fóruns gringos :o Mais uma limitação aí na sua situação - aliás, sugiro que vc documente isso com a sua gerência , é mais um argumento pra upgrade a toque de caixa (tipo, numa máquina de teste vc ter o 8i e o 9i instalados, e usar o procedimento citado no link pra demonstrar que o 9i com async rende mais)... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
Chiappa, Apenas uma dúvida, existe algum contra com relação a isso, ou seja, ligar o async? []'s Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 13:04 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Oi, Nelson : eu não tinha ainda trabalhado com 8i em linux, mas já usei async em 8i nos mais diversos unixes (aix, hp, Solaris) e nunca tive probs, imaginava que no linux fosse o mesmo, talvez só precisasse de algum patch... Putz, não é à toa que neguinho reclamava tanto do 8i no linux nos fóruns gringos :o Mais uma limitação aí na sua situação - aliás, sugiro que vc documente isso com a sua gerência , é mais um argumento pra upgrade a toque de caixa (tipo, numa máquina de teste vc ter o 8i e o 9i instalados, e usar o procedimento citado no link pra demonstrar que o 9i com async rende mais)... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu 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/), 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 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
Na verdade a nota é bem clara, NÂO funciona, não é suportado em 8i rodando sob linux - fatalmente, quando a Oracle diz isso, é uma loteria, é algo que PODE ou não funcionar, e ainda que funcionar pode levar à corrupção e outras coisitas más, já que 8i não é mais suportado, não recomendo ir contra a posição oficial de modo algum, se der pau vc estará sozinho na chuva... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu Chiappa, Apenas uma dúvida, existe algum contra com relação a isso, ou seja, ligar o async? []'s Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 13:04 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Oi, Nelson : eu não tinha ainda trabalhado com 8i em linux, mas já usei async em 8i nos mais diversos unixes (aix, hp, Solaris) e nunca tive probs, imaginava que no linux fosse o mesmo, talvez só precisasse de algum patch... Putz, não é à toa que neguinho reclamava tanto do 8i no linux nos fóruns gringos :o Mais uma limitação aí na sua situação - aliás, sugiro que vc documente isso com a sua gerência , é mais um argumento pra upgrade a toque de caixa (tipo, numa máquina de teste vc ter o 8i e o 9i instalados, e usar o procedimento citado no link pra demonstrar que o 9i com async rende mais)... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu 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/), 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 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
Desculpe, não me expressei bem. Essa pergunta foi relacionado ao oracle 9i. Queria saber se especificamente este parametro tem alguma contra-indicação ahaha. To falando sendo tudo suportado, ou seja oracle 9.2 com RH AS 2.1 Abraços, Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 14:26 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Na verdade a nota é bem clara, NÂO funciona, não é suportado em 8i rodando sob linux - fatalmente, quando a Oracle diz isso, é uma loteria, é algo que PODE ou não funcionar, e ainda que funcionar pode levar à corrupção e outras coisitas más, já que 8i não é mais suportado, não recomendo ir contra a posição oficial de modo algum, se der pau vc estará sozinho na chuva... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu Chiappa, Apenas uma dúvida, existe algum contra com relação a isso, ou seja, ligar o async? []'s Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 13:04 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Oi, Nelson : eu não tinha ainda trabalhado com 8i em linux, mas já usei async em 8i nos mais diversos unixes (aix, hp, Solaris) e nunca tive probs, imaginava que no linux fosse o mesmo, talvez só precisasse de algum patch... Putz, não é à toa que neguinho reclamava tanto do 8i no linux nos fóruns gringos :o Mais uma limitação aí na sua situação - aliás, sugiro que vc documente isso com a sua gerência , é mais um argumento pra upgrade a toque de caixa (tipo, numa máquina de teste vc ter o 8i e o 9i instalados, e usar o procedimento citado no link pra demonstrar que o 9i com async rende mais)... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu 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/), http://www.iozone.org/), http://www.iozone.org/), http://www.iozone.org/), http://www.iozone.org/), 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 http://www.mgogala.com/directio.pdf http://www.mgogala.com/directio.pdf http://www.mgogala.com/directio.pdf http://www.mgogala.com/directio.pdf 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
Não, se o hardware aceita E a versão de SO também E o filesystem está montado com as opções necessárias, não há contra-indicação nenhuma (afora bugs eventuais que vc checa no metalink), lembrando que no 9i vc tanto tem o disk_async_io quanto o filesystemio_options, que habilita i/o direto no filesystem. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu Desculpe, não me expressei bem. Essa pergunta foi relacionado ao oracle 9i. Queria saber se especificamente este parametro tem alguma contra- indicação ahaha. To falando sendo tudo suportado, ou seja oracle 9.2 com RH AS 2.1 Abraços, Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 14:26 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Na verdade a nota é bem clara, NÂO funciona, não é suportado em 8i rodando sob linux - fatalmente, quando a Oracle diz isso, é uma loteria, é algo que PODE ou não funcionar, e ainda que funcionar pode levar à corrupção e outras coisitas más, já que 8i não é mais suportado, não recomendo ir contra a posição oficial de modo algum, se der pau vc estará sozinho na chuva... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu Chiappa, Apenas uma dúvida, existe algum contra com relação a isso, ou seja, ligar o async? []'s Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: terça-feira, 14 de fevereiro de 2006 13:04 Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: RES: RES: [oracle_br] Re: Problema Urgente Oi, Nelson : eu não tinha ainda trabalhado com 8i em linux, mas já usei async em 8i nos mais diversos unixes (aix, hp, Solaris) e nunca tive probs, imaginava que no linux fosse o mesmo, talvez só precisasse de algum patch... Putz, não é à toa que neguinho reclamava tanto do 8i no linux nos fóruns gringos :o Mais uma limitação aí na sua situação - aliás, sugiro que vc documente isso com a sua gerência , é mais um argumento pra upgrade a toque de caixa (tipo, numa máquina de teste vc ter o 8i e o 9i instalados, e usar o procedimento citado no link pra demonstrar que o 9i com async rende mais)... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo [EMAIL PROTECTED] escreveu 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/), http://www.iozone.org/), http://www.iozone.org/), http://www.iozone.org/), http://www.iozone.org/), http
RES: RES: RES: [oracle_br] Re: Problema Urgente
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 tpsblks/s 06:00:34 PMdev2-0 0.00 0.00 06:00:34 PMdev3-0 0.00 0.00 06:00:34 PMdev8-0 0.00 0.00 06:00:34 PMdev8-1 0.00 0.00 06:00:34 PMdev8-2 83.00 1040.00 Average: DEV tpsblks/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 i38602/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 c0b0t0d0s137 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 verifique se seus processos utilizam bind-variables o que pouparia o I/O e seu database buffer cache. Como o Chiappa falou isso pode ser decorrente de n variáveis, tente se sercar de
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 tpsblks/s 06:00:34 PMdev2-0 0.00 0.00 06:00:34 PMdev3-0 0.00 0.00 06:00:34 PMdev8-0 0.00 0.00 06:00:34 PMdev8-1 0.00 0.00 06:00:34 PMdev8-2 83.00 1040.00 Average: DEV tpsblks/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 i38602/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 c0b0t0d0s137 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
RES: RES: RES: RES: [oracle_br] Re: Problema Urgente
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 tpsblks/s 06:00:34 PMdev2-0 0.00 0.00 06:00:34 PMdev3-0 0.00 0.00 06:00:34 PMdev8-0 0.00 0.00 06:00:34 PMdev8-1 0.00 0.00 06:00:34 PMdev8-2 83.00 1040.00 Average: DEV tpsblks/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 i38602/10/06 17:27:02 device MB %busy avque r+w/s blks
