Buenas, então vou citar alguns outros dados, não o fiz antes porque achei
irrelevante em relação a questão de performance de IO do DBWR/LGWR.
Quanto a taxa de IO/segundo tem no EM do 11g. E quanto ao banco, é um banco de
testes (um pré-produção), e será utilizado por algumas ferramentas de BI/ETL.
Nos testes de carga os 8 grupos de redolog eram preenchidos e o banco ficava
aguardando a liberação, ou seja, 8 x 200mb em alguns poucos minutos.
sds
Fábio Gibon
----- Original Message -----
From: jljlsilva
To: oracle_br@yahoogrupos.com.br
Sent: Monday, June 06, 2011 4:30 PM
Subject: [oracle_br] Re: DBWR lento
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]
>
[As partes desta mensagem que não continham texto foram removidas]
