Grande Venturine, tudo bom ?? Rapaz...a questão não é o tamanho do redo e consequentemente, o tamanho dos acrh que serão gerados...
O meu grande problema é a rep0licação dos dados com o uso do dataguard...não posso ter arch muito grandes pq tenho que realizar replicação com o dataguard que fica em outro estado...pq, se o tamanho do arc ficar grande demais...vou engargalar tudo qusndo for realizar a transferencia para o standy database. Se nao fosse por isso, eu colocava uns grupos com 30 a 50 mb e ja estava resolvido o problema ;-) --- Em oracle_br@yahoogrupos.com.br, Gustavo Venturini de Lima <gventur...@...> escreveu > > Camarada, 15Mb nem de longe é um tamanho considerado grande para um banco de > produção... Ainda mais vc relatando que tem muitas transações... > Trabalhamos com alguns bancos aqui que o redo é de 2GB... > Com relação ao DG, o link vai depender do volume de redo que seu banco vai > gerar... não importa se será um de 500M ou 10 de 50M... > > 2009/2/10 amorrimm <ammo...@...> > > > Bem, como teste, reduzi a quantidade de grupos de Redo Log para 6 e > > aumentei o tamanho deles...neste momento eles se encontram com 15M..e > > tinham somente 3 mb... > > > > Por se tratar de um banco que tem muitas operações de DML, acredito > > que 3Mb para redo estava realmente muito baixo o valor... > > > > Acho que com tamanhos maiores de redo, vou ter problemas para > > trabalhar com o dataguard que pretendo implementar...pois os archives > > irá para um outro estado..logo...precisarei de um baita link para > > trafegar pacotes de 15 em 15 mb...n[e nao ? > > > > --- Em oracle_br@yahoogrupos.com.br <oracle_br% 40yahoogrupos.com.br>, > > RTS-Rio, André Monteiro > > <trainee@> escreveu > > > > > > Bom Dia Amorrimm ! > > > > > > > > > > > > Vc está no Rio ? Aqui na RESULT temos um diagnóstico de ambiente > > Oracle que > > > é show. E o melhor: é oferecido aos futuros parceiros "free". > > > > > > > > > > > > Meia hora de coleta e em 5 dias a companhia entrega o laudo > > técnico. Sem > > > custos. > > > > > > > > > > > > Abcs > > > > > > > > > > > > André Monteiro > > > > > > http://www.resultnet.com.br > > > > > > > > > > > > De: oracle_br@yahoogrupos.com.br <oracle_br% 40yahoogrupos.com.br> > > [mailto:oracle_br@yahoogrupos.com.br <oracle_br% 40yahoogrupos.com.br>] Em > > > nome de amorrimm > > > Enviada em: terça-feira, 10 de fevereiro de 2009 12:16 > > > Para: oracle_br@yahoogrupos.com.br <oracle_br% 40yahoogrupos.com.br> > > > Assunto: [oracle_br] Re: Tamanho de Redo Logs !! > > > > > > > > > > > > Opa...tudo bom ? > > > > > > Sei não...por exemplo, comecei a trabalhar com este banco > > > recentemente...ele tem 12 grupos de redo e cada membro tem 3 > > > mb...comecei a alterar aos poucos, auemntando o tamnho dos redos e > > > percebi que os wait aumentaram consideravelmente, com relaçãoao > > > evento commit... > > > > > > Este banco ainda naoe sta operando em archivelog...antes de passa- > > lo > > > para archive log, gostaria de reduzir estes tempos de commit pois > > > tenho o receio de que, na momento o arch for gravado em disco, eu > > > possa ter mais lentidão de uma maneira geral..pq ja estou com > > commit > > > altos e tambem terei gravações altas... > > > > > > --- Em oracle_br@yahoogrupos.com.br <oracle_br% 40yahoogrupos.com.br><mailto: > > oracle_br% <oracle_br%25> > > 40yahoogrupos.com.br> > > > , Gustavo Venturini de Lima > > > <gventurini@> escreveu > > > > > > > > Bom dia ammorim... > > > > Não sei qual a sua arquitetura de disco e distribuição dos > > arquivos > > > sobre > > > > eles... Mas é normal que em sistemas de grande atividade tenha-se > > > uma carga > > > > mais elevada sobre os redos... > > > > O ideal seria ter os redos em discos bem velozes e separados dos > > > demais... > > > > Além disso, creio que um aumento no tamanho dos redos pode lhe > > > trazer alguns > > > > benefícios sim... Vc não informa, mas imagino que tenha este > > banco > > > em modo > > > > ARCHIVE correto? Se sim, o processo de swicth dos logs forçará a > > > criação de > > > > um archivelog, o que gera ainda mais um "esforço" do SO em > > disco... > > > > Com os redos maiores, vc aumenta [tempo] o intervalo da geração > > dos > > > > archives, e consequentemente a gravação em dos archives em > > disco... > > > > Acompanhe o comportamento do banco durante estes "gargalos" na > > hora > > > de > > > > comitar... Veja se o problema está mesmo nos redos ou se todo seu > > > subsystem > > > > de IO está com uma performance prejudicada... > > > > Ainda com relação ao tamanho dos redos e grupos, acompanhe na > > v$log > > > (select > > > > * from v$log order by 3;) o campo STATUS... veja se aparecem > > alguns > > > como > > > > INACTIVE... Se houver, não acho que será necessário adicionar > > mais > > > grupos ou > > > > aumentar o tamanho dos redos, e sim verificar seu IO no geral... > > > > Esta é uma percepção, de certo o Chiappa ou os outros Gurus aqui > > do > > > forum tb > > > > terão mais ifnormações pra adicionar... > > > > Abraços. > > > > > > > > > > > > 2009/2/10 amorrimm <ammorim@> > > > > > > > > > Bom dia pessoal, > > > > > > > > > > Uma pequena dúvida sobre o tamanho dos redologs... > > > > > > > > > > Em ambientes OLTP, para aplicações que fazem bantantes DML, > > qual > > > seria > > > > > o ideal ? Aumentar o tamanho dos redos e o numero de grupos, > > > > > facilitando assim o evento 'COMMIT' ? > > > > > > > > > > Estou tendo alguns gargalos para commitar...eles tendo ficado > > com > > > um > > > > > WAIT bem alto...aumentei o grupo de redologs, adicionando mais > > um > > > grupo > > > > > mas fico na dúvida se aumento o tamanho do mesmo ou não pois, > > > > > dependendo do tamnanho, posso ter problema na hora da gravação > > dos > > > > > mesmos e disco.... > > > > > > > > > > O que vcs acham ? > > > > > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
