chiappa, muito me surpreende você dizer que 200M para um redolog é um redolog "anão". tá certo que tem pendrive muito grande hoje em dia, mas, essas coisas não são equivalentes, penso eu. 2GB de redolog é um tamanho inicial mínimo? desse jeito, em um ambiente Oracle RAC com 8 nodes tenho que ter um storage para os redologs e outro para o resto do banco, né? 8 nodes x 5 grupos x 2GB = 80GB de redologs! e se for multiplexado: 8 nodes x 5 grupos x 2 membros x 2GB = 160GB de redologs... bom, acho que, além de mim, mais gente também gostaria que você explicasse um pouco mais sobre essa questão de redologs com absurdos 2GB cada... abraço.
--- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@...> escreveu > > Vamos por partes : PRIMEIRO DE TUDO, sorry, mas 200mb é *** RIDICULAMENTE > PEQUENO ***, é MINÚSCULO - se esse banco tem a MENOR PRETENSÂO de ser um > teste sério, um Homologação de alguma coisa, vc deve estar com MONTES de > waits por causa de log switch, com os redos enchendo a toda hora ... Não faz > o MENOR SENTIDO se ter redo logs ANÔES assim, pra gente começar a conversar > bota cada redo pra 2 Gb, Mínimo (isso é menos que meu pendrive, é um Início, > mesmo) ... Outra coisa é o LOG BUFFER, ele não pode ser nem muito grande que > fique inutilizado na maior porção nem muito pequeno que force gravação de > redo a toda hora pela regra de 1/3 de redo log buffer cheio ou qquer outra... > Minha sugestão (SE o seu database está com menos hoje) é começar com 1 Mb , e > ir testando a partir daí... > > DEPOIS disso feito, aí sim vamos pensar no I/O : pra início de conversa, se > vc está preocupado com performance de escrita de redo logs, vc deveria estar > pensando muito mais é no LGWR (LOG WRITER, o nome já diz) do que no DBWR (que > tem a ver por causa dos COMMITs, que forçam materialização & flush de redo, > mas se vc estiver comitabndo em excesso a otimização óbvia é comitar menos, > comitar só no fim da transação)... > Anyway : pra atingir a melhor performance de gravação, via de regra o que > vc precisa é de Direct I/O (I/O não-bufferizado) ** E ** de I/O Asynch (ie, > aonde o I/O propiamente dito é feito EM BACKGROUND, permitindo ao requester > processar outras coisas enquanto isso) : a não ser em RARÍSSIMOS CASOS de > tempestades de gravação, com montes de processos querendo gravar montes de > coisa , um DBWR (com DIo e AIO, of course) é plenamente capaz de dar conta, > múltiplos DBWR são ** quebra-galhos ** para quando por qquer motivo vc não > pode ter a coisa real, ie, Direct I/O ** E ** Async I/O ... Veja em > http://kevinclosson.wordpress.com/2007/08/10/learn-how-to-obliterate-processor-caches-configure-lots-and-lots-of-dbwr-processes/ > , > http://kevinclosson.wordpress.com/2007/08/17/over-configuring-dbwr-processes-part-ii/ > e > http://kevinclosson.wordpress.com/2007/08/17/over-configuring-dbwr-processes-part-iii/ > , que lá o autor discorre longamente sobre os quês e porquês... Sobre como > obter DIO e AIO no seu ambiente, aí depende TOTALMENTE do que vc tem , se > está usando filesystems, raw devices, ASM, qual o SO, qual o hardware, se há > camada de software extra (por exemplo, gerenciadores) entre o SO e o storage, > vareia ... > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, Fábio Gibon - Comex System <gibon@> > escreveu > > > > Olá Pessoal, > > tive contato com um banco 11g, redhat, onde existem 8 grupos de > > redolog (200mb cada) e com frequencia todos os grupos estão com status de > > active (sendo um deles o current), então o sistema fica lento e gera > > alertas de free_buffer_waits, log_file_switch, ... e o dbwr não passa de > > 6Mb/segundo de taxa de IO. Hoje roda só com um processo DBWR, deveria > > adicionar outros? (o server tem 4 cpu's, mas é uma vmware). > > > > abraços > > > > Fábio Henrique Gibon > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
