ricardo proni, correto seu raciocínio. mas, novamente está falando de algo fora do trivial. quando se está trabalhando fora do trivial, a análise não é trivial também. segundo entendi, a nota lá fala que 1 switch a cada 20 minutos é uma regra geral, para ambiente transacional (OLTP), em horário de pico.
On Jun 07, 2011, at 12:13 , ricardo.pr...@gmail.com wrote: > Eu respeitosamente discordo da métrica, pois ela nao eh absoluta. Em uma > carga de OLAP, atualmente gero 500 GB de dados em 30 minutos. De acordo com a > metrica, teria que ter Redo Logs de cerca de 300 GB cada. > > O problema nao e um (ou 20) switch, mas o ultimo switch sem que haja um Redo > Log disponivel para continuar a gravacao. Isto tb invalida a metrica. > > Um cliente nao liga para switch, ele nao reclama disso. Ele quer que o SQL > execute em menos tempo, e para isto você deve analisar o tempo que o banco > gastou esperando por Redo Log livre (evento log file switch completion). Esta > analise eh simples com o AWR. > > Enviado pelo meu aparelho BlackBerry da Claro > > -----Original Message----- > From: JLSilva <jljlsi...@yahoo.com.br> > Sender: oracle_br@yahoogrupos.com.br > Date: Tue, 7 Jun 2011 10:01:18 > To: <oracle_br@yahoogrupos.com.br> > Reply-To: oracle_br@yahoogrupos.com.br > Subject: Re: RES: [oracle_br] Re: DBWR lento > > fala Welvis. blz? > aquela nota que o chiappa citou fala sobre isso: 781999.1 > vc tem acesso ao metalink? se sim, dê uma olhada nessa nota. > mas em resumo, a sugestão da nota é dimensionar os redologs para 20 minutos > entre cada switch. > > On Jun 07, 2011, at 9:44 , wel...@stcruz.com.br wrote: > >> Olá pessoal... >> >> Gostaria de saber se há alguma nota no metalink que diz se quanto em >> quanto tempo é um switch para um banco OLTP.. Eu costumo >> deixar/recomendar que os switchs sejam de pelo menos uns 10 minutos., >> claro dependendo do horário este número pode variar um pouco tanto para >> mais quanto para menos. >> >> Mas com toda esta discussão fiquei curioso sobre isso... >> >> Att, >> >> Welvis Douglas >> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em >> nome de Fábio Gibon - Comex System >> Enviada em: segunda-feira, 6 de junho de 2011 22:08 >> Para: oracle_br@yahoogrupos.com.br >> Assunto: Re: [oracle_br] Re: DBWR lento >> >> >> Na real eu não queria saber realmente se o redolog deveria ser 50mb, >> 200mb, 2gb, ... foi levantado a hipótese aqui de que o problema de >> desempenho do banco era por problema de performance de IO nos discos onde >> estavam os redologs, então tentei levantar alguns dados para ver se não >> estava pecando em alguma configuração (antes de sair culpando o disk group >> que estão os redos) >> >> sds >> Fábio Gibon >> ----- Original Message ----- >> From: jljlsilva >> To: oracle_br@yahoogrupos.com.br >> Sent: Monday, June 06, 2011 4:40 PM >> Subject: [oracle_br] Re: DBWR lento >> >> portilho, legal suas observações. penso que o caminho é esse mesmo. >> eu imagino que as pessoas que colocam perguntas desse tipo que o fábio >> gibon colocou aqui nesse tópico, não tem informações suficientes sobre o >> assunto e precisam justamente desse tipo de comentário, sem exageros, mas >> direcionando, neste caso, sobre como calcular o que ele precisa. >> legal... valeu... >> >> --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni >> <ricardo.proni@...> escreveu >>> >>> Oi. >>> >>> - Não importa o tamanho do banco, e sim o tamanho das gravações. Um >>> banco de 1TB que só sofre SELECT não terá impacto em ter os pequenos >>> Redo Logs padrão do Oracle (3 x 50MB); >>> - Você deve ter Redo Logs suficientes (em tamanho e quantidade) para >>> contar sua maior gravação concorrente. Veja neste exemplo, eu executo >>> uma gravação de 250MB sem ter 250MB de Redo Log, e o tempo é prejudicado >>> em mais de 100%. Após adicionar um único Redo Log de 1GB, tenho meu >>> problema solucionado: >>> http://profissionaloracle.com.br/blogs/portilho/2009/01/14/imp-lento-no-oracle/ >>> - Você deve ter Redo Logs suficientes (em tamanho em quantidade) de >>> forma que o Wait Event "log file switch" não ocupe um tempo relevante no >>> período analisado. Se ele ocupa apenas 5% do seu tempo de banco, e você >>> não precisa destes 5% de tempo, não precisa altera-los; >>> - Redo Logs grandes não impactam o sistema por conta da geração de >>> Archives grandes: se você está efetuando uma gravação de 100GB, o Oracle >>> irá gerar 100GB (+ ou -) de Archives de qualquer forma, seja em pedaços >>> de 100MB ou de 1GB; >>> - Em um RAC de 8 Nós, teriam sido gastos alguns milhões de dólares só >>> de licenças do Oracle. Neste cenário, 160GB de disco é irrelevante, este >>> ambiente deve ter até mais de 160GB de RAM. >>> >>> Espero ter ajudado. >>> >>> >>> Em Sáb, 2011-06-04 às 01:32 +0000, 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] >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> [As partes desta mensagem que não continham texto foram removidas] >>> >> >> [As partes desta mensagem que não continham texto foram removidas] >> >> >> >> >> ------------------------------------ >> >> -------------------------------------------------------------------------------------------------------------------------- >>> Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >>> responsabilidade de seus remetentes. >> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ >> -------------------------------------------------------------------------------------------------------------------------- >>> Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure >>> » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >>> http://www.oraclebr.com.br/ >> ------------------------------------------------------------------------------------------------------------------------ >> Links do Yahoo! Grupos >> >> > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > ------------------------------------ > > -------------------------------------------------------------------------------------------------------------------------- >> Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >> responsabilidade de seus remetentes. > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > -------------------------------------------------------------------------------------------------------------------------- >> Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >> Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >> http://www.oraclebr.com.br/ > ------------------------------------------------------------------------------------------------------------------------ > Links do Yahoo! Grupos > >
