fala Marcelo Procksch. blz? na verdade, esse problema nem é meu. só entrei no assunto do fábio gibon porque o chiappa falou que o redolog de 200mb por membro era muito pequeno e que deveria jogar para 2gb por membro no mínimo. e eu achei exagerado 2gb por membro. mas enfim, o fábio não citou o tmanho do banco dele, nem se ele considera que o banco dele tem muito volume de redolog gerado por hora, e nem quantos switch está fazendo atualmente. isso realmente é muito relativo.
por falar nisso, o fábio gibon falou que "o dbwr não passa de 6Mb/segundo de taxa de IO". também fiquei curioso para saber de onde ele tirou essa informação. tem no enterprise manager do 11g? ou no awr? --- Em oracle_br@yahoogrupos.com.br, Marcelo Procksch <marceloprocksch@...> escreveu > > Silva, boa tarde. > > A maioria de problemas de performance que pego com redo logs são por causa > do tamanho do redo, disco lento e muitos membros no mesmo disco. > > Como sei que tamanho meu redo log deve ter? > Por recomendação da Oracle um switch deve ocorrer em 20 minutos mais ou > menos, se vc tem 8 grupos de redos e mesmo assim espera por um redo log > livre, concerteza seu redo log está pequeno e 200 megas eu também acho > pequeno, nem minhas vms de teste tem redologs com esse tamanho. > > Redo log pequeno é menos performatico do que redo log grande, se seu redo > log for pequeno seu banco vai fazer mais switch e consequentemente terá que > sincronizar mais vezes deixando todo o processo mais lento. > > Para banco de dados o recomendável é usar raid 10, mais nem todo banco de > dados pode ter essa configuração devido o alto custo, vejo muita gente > configurar raid 5 para banco de dados, raid 5 é lento para banco de dados, > veja se não é seu caso. > > Outro problema que encontro por ai são grupos de redo log com muitos membros > apontando para o mesmo disco, o ideal é ter os membros do grupo de redo em > discos separados para distribuir o IO, veja se não é seu caso. > > > Verifique como está seu ambiente, e nos informe. > > Abraço > Att. > Marcelo Procksch > > > Em 3 de junho de 2011 22:32, jljlsilva <jljlsilva@...> escreveu: > > > > > > > chiappa, > > mas, vamos detalhar um pouco mais. o que é um "banco de dados nanico" prá > > vc? > > vc acha q um redolog muito grande não poderia causar problemas de > > performance no momento do arquivamento? afinal, não é toda empresa que tem > > storages de performance tão alta quanto gostaríamos. > > nunca precisei usar um membro de redolog de 2GB, até o momento. me parece > > q, como vc citou no final da sua explicação, vc usou como base "níveis / > > volumes não triviais", o que precisaria de muito mais análise para se chegar > > a tal conclusão. > > entende porque me surpreendeu? até porque vc enfatiza com letras grandes > > como se o básico/mínimo fosse aquilo, via de regra. > > > > > > --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@> > > escreveu > > > > > > Então, seguinte : é Claro que a maneira Correta e precisa de especificar > > o redo log size no 10g é usar o Assistente apropriado, e é claro também que > > o redo log guarda alterações vindas de DML basicamente, então o tamanho > > apropriado depende Totalmente de quantas alterações simultâneas vc tem E o > > quanto elas 'alteram' , E também óbvio que podem existir bancos nanicos > > aonde o mínimo do mínimo tá mais que bão, mas eu penso aqui em produção > > plena, ambiente com criticidade, numa Empresa com muitos usuários, muitas > > alterações e centenas e centenas de Gb de dados, NÂO-ESTÁTICOS .... Nesse > > cenário não tem como eu chamar centena de Mbs de outra coisa que não anão, > > mínimo do mínimo , verticalmente prejudicado se vc quiser ser politicamente > > correto... > > > Pra vc ter uma idéia , a nota oficial sobre isso (a "General Guideline > > For Sizing The Online Redo Log Files" (Doc ID 781999.1), acessível no > > metalink) diz : > > > > > > 'An excerpt from the Oracle Database Performance Tuning Guide provides > > the general guideline. > > > > > > "It may not always be possible to provide a specific size recommendation > > for redo log files, but redo log files in the range of a hundred megabytes > > to a few gigabytes are considered reasonable. Size your online redo log > > files according to the amount of redo your system generates. > > > > > > ' > > > > > > ==> OU SEJA, algumas centenas de Mb é o **** INÍCIO *** da faixa > > recomendada, o MÍNIMO : alguma surpresa que eu recomende sensivelmente mais > > que isso pra ambiente Produção, ainda mais : > > > > > > 1. nós, técnicos de TI, sabermos do e testemunharmos o volume sempre > > crescente de dados numa Empresa > > > > > > e > > > > > > 2. sabendo que PODE SIM haver implicação de performance num redo log size > > pequeno > > > > > > e > > > > > > 3. que se, por qquer improvável combinação, esse tamanho for muito grande > > é plenamente possível vc diminuir SEM downtime, via de regra ??? > > > > > > É isso, eu Absolutamente não vejo porque vc se surpreendeu ... > > > > > > E mais, vc se admira de 80 Gb, usa até o ! para expressar surpresa, mas > > pense assim : num Storage de produção vc via de regra vai ter pelo menos 4 > > discos usáveis (desconheço MESMO storage production-class , com RAID e tudo > > o mais necessário, que aceite trabalhar com menos que isso) , e hoje em dia > > discos profissionais, de alta-performance, vc DIFICILMENTE encontra algum > > menos do que 100 Gb, ou seja , coisa de pouco menos 500 Gb é quase um mínimo > > na prática quando se fala em Enterprise-class, eu sinceramente não vejo nada > > de mais em usar coisa de 15% ou 20% pro REDO, SE for realmente Exigido... > > Ainda mais que (cfrme sabemos) ** NÂO ** é uma coisa temporária, é parte > > Rotineira do banco de dados pra fornecer Intergidade de leitura, e , Repito, > > vc pode ter problemas de performance e/ou disponibilidade com redo pequeno > > ... > > > > > > OK ? É essa a minha razão - eu , repito, até Entendo que possam haver > > bancos menos exigentes que não precisem disso mas ao aconselhar aqui no > > Fórum eu sempre penso num ambiente Produção, pleno E nos níveis / volumes > > não triviais que eu encontro pelaí nos meus Clientes e/ou conversando com > > outros profissionais, então Recomendo de acordo ... > > > > > > []s > > > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br, "jljlsilva" <jljlsilva@> escreveu > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Att. > Marcelo E. Procksch > > > [As partes desta mensagem que não continham texto foram removidas] >
