Bem, deixem-me dar uns pitacos a mais : a) será que não valeria a pena tentar primeiro tentar a coisa real (ie, o ASYNCH I/O) antes de partir pra múltiplos DBWRs cfrme discutido em http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:11531181159946 e http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1257800375707 ? Cfrme o caso, pode-se testar asynch com e sem direct i/o também.... Lógico, em RAID 0+1 se possível, e isso TANTO para os redo log files quanto para os db files, se possível e se máxima performance é paradigma...
b) otimização de gravações do lgwr: além de a) sim, ter múltiplos grupos no mesmo volume imho é indefensável, vc tem o overhead natural E não está se protegendo de nada, sim... SE desejado 2 elementos por grupo, que existam 2 volumes (QUE sejam capazes de I/O simultâneo, ambos atendidos pelo mesmíssimo canal de I/O é overhead na certa) e se crie o elemento 1 no volume 1 e o elemento 2 no 2... E os params todos, como o log_buffer, e os params de checkpoint, como é que estão ??? os params de cache, estão adequados pela sua análise ? c) otimização gravação dbwr : além de a) acima isso envolve (entre n outras coisas) evitar delayed block cleanout sendo disparado pra um montão de blocos duma vez, o objetivo sempre é ter o dbwr trabalhando continuamente MAS um pouco por vez - pode acontecer que as tais N alterações que os seus processos fazem estejam sendo acumuladas aí quando o dbwr é disparado não tem como ele ser instantâneo, o montão de blocos a limpar leva tempo, necessariamente.... Dá uma lida no livro de arquitetura do Tom Kyte que ele dá uma explicação bem legal sobre isso. Outra coisa é vc ter CERTEZA que apenas o mínimo dos mínimos de blocos são tocados durante a operação, ie : ter CERTEZA que os params de storage dos blocos estão bem, que os Planos de execução realmente tão o melhor possível, que os eventuais UPDATEs estão cabendo dentro dos blocos (ie, não há migração) d) e o principal, tuning do Processo em si : vc DISCUTIU com o time de app as opções de gerar menos redo, como GTTs e operações nologging, ter algum/alguns índice(s) desabilitados durante a operação e depois reconstruir em nolog/parallel ? Isso tudo imho PODE entrar em tese em pauta, pois uma alteração grande é uma operação BATCH imho, vc SCHEDULAR ela pra uma janela fixa e ter um backup depois e um breve período de blackout pra rebuild/atualização de índices é normal, penso... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni <ricardo.pr...@...> escreveu > > Realmente são gravações absurdas ! > As mensagens no Alert não deixam dúvidas: > - Você deve aumentar os REDOs sim, em tamanho e se possível em quantidade; > - Deve utilizar múltiplos DBWR para que ele não fique muito atrás do LGWR; > - Não utilize os dois membros no mesmo disco. Com dois membros no mesmo > disco e até mesmo diretório, acho que nem de erros "dedais" você está se > protegendo, então se não tiver outro disco, use só um membro por grupo. > > Abraço ! > > > Ricardo Portilho Proni > http://nervinformatica.com.br > > Oracle ACE > Oracle Database 10g Administrator Certified Professional > Oracle Database 10g: RAC Administrator Certified Expert > Oracle Database 10g: Managing Oracle on Linux Certified Expert > Microsoft Certified Database Administrator > Microsoft Certified Technology Specialist: SQL Server 2005 > Certified MySQL Database Administrator > IBM Certified Database Administrator > > > > > > Em 18 de fevereiro de 2010 08:52, candiurudba > <candiuru...@...>escreveu: > > > > > > > Grande Portilho / Colegas... > > > > Tue Feb 2 08:39:57 2010 > > Thread 1 cannot allocate new log, sequence 1073 > > > > Private strand flush not complete > > Current log# 4 seq# 1072 mem# 0: /s03/oracle/xpi/redo/redo04.log > > Current log# 4 seq# 1072 mem# 1: /s03/oracle/xpi/redo/redo04a.log > > Tue Feb 2 08:40:09 2010 > > Thread 1 advanced to log sequence 1073 (LGWR switch) > > Current log# 1 seq# 1073 mem# 0: /s03/oracle/xpi/redo/redo01.log > > Current log# 1 seq# 1073 mem# 1: /s03/oracle/xpi/redo/redo01a.log > > Tue Feb 2 08:40:48 2010 > > Thread 1 cannot allocate new log, sequence 1074 > > > > Private strand flush not complete > > Current log# 1 seq# 1073 mem# 0: /s03/oracle/xpi/redo/redo01.log > > Current log# 1 seq# 1073 mem# 1: /s03/oracle/xpi/redo/redo01a.log > > Tue Feb 2 08:40:50 2010 > > Thread 1 advanced to log sequence 1074 (LGWR switch) > > Current log# 2 seq# 1074 mem# 0: /s03/oracle/xpi/redo/redo02.log > > Current log# 2 seq# 1074 mem# 1: /s03/oracle/xpi/redo/redo02a.log > > Tue Feb 2 08:41:00 2010 > > Thread 1 cannot allocate new log, sequence 1075 > > > > Private strand flush not complete > > Current log# 2 seq# 1074 mem# 0: /s03/oracle/xpi/redo/redo02.log > > Current log# 2 seq# 1074 mem# 1: /s03/oracle/xpi/redo/redo02a.log > > > > Tenho gravações absurdas sim Portilho...vc pode perceber ai em cima no log > > que o giro esta sendo feito bem rapido... que o que ocorre é que em > > determinados momentos do dia, tenho alguns sistemas e alguns robos > > desenvolvidos que fazem milhares de alterações (basicamente comandos DML) no > > banco, ou seja, nestes determinados horarios tinhamos lentidão quando estas > > aplicações iriam fazer as alterações e o problema foi minimizado quando > > aumentei o tamanho dos Redos para 11264M (Nunca trabalhei com um tamanho > > destes para membros de REDO). > > > > Apesar dos problemas de lentidão terem sido solucionados, tenho sim estes > > alertas indicando algum problema na gravação / alocação de redos. > > > > Os meus grupos estão gravando em um mesmo HD...mas foi pensando na melhora > > de I/O que separei um array só para os REDOs pq antigamente eles estavam > > alocados por todos os discos do servidor (/u01, /u02, /u03), ou seja, > > concorriam com as tools do proprio banco localizados la na instalação, > > concorriam com a gravação de dados que estavam localizadas no /u02 e etc. > > Aloquei todos os REDOS em uma unica unidade mas seus membros continuam sendo > > gravados ao mesmo tempo... > > > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > > Ricardo Portilho Proni <ricardo.proni@> escreveu > > > > > > > > Dificilmente você deve aumentar a quantidade / tamanho de REDOs, a não > > ser > > > que você tenha uma gravação absurda. Qual o tempo médio de giro entre os > > > REDOs? > > > > > > O seu problema agora deve ser o I/O mesmo. > > > Os seus grupos de REDO possuem dois membros cada, e estão gravando no > > mesmo > > > HD? Se sim, este pode ser seu problema. > > > > > > DBWR adicionais devem te ajudar. > > > *In some cases, this message can be resolved by increasing > > db_writer_process > > > value. > > > * > > > A nota 372557.1 tem uma explicação detalhada sobre esta mensagem. > > > > > > Ricardo Portilho Proni > > > http://nervinformatica.com.br > > > > > > Oracle ACE > > > Oracle Database 10g Administrator Certified Professional > > > Oracle Database 10g: RAC Administrator Certified Expert > > > Oracle Database 10g: Managing Oracle on Linux Certified Expert > > > Microsoft Certified Database Administrator > > > Microsoft Certified Technology Specialist: SQL Server 2005 > > > Certified MySQL Database Administrator > > > IBM Certified Database Administrator > > > > > > > > > Em 17 de fevereiro de 2010 11:52, candiurudba > > > <candiurudba@>escreveu: > > > > > > > > > > > > > > > > > Bom dia Colegas, > > > > > > > > Tenho uma situação um tanto quanto nova ocorrendo em um banco de dados > > que > > > > tenho em produção. > > > > > > > > O Oracle nele instalado é 10.2.0.4 em um Linux Red Hat 5.2.. > > > > > > > > Tenho algumas aplicações que fazem milhares de atualizações (comandos > > DML) > > > > nesta base de dados e por este motivo, fui aumentando meus Redos Logs > > de > > > > forma que os mesmos pudessem suportar estes massiços DML ( normalmente > > > > UPDATE). > > > > > > > > Comecei trabalhando com 500 MB, tendo um total de 12 grupos...hoje em > > dia, > > > > estou trabalhando com 7 grupos de 11GB e mesmo assim, ainda tenho > > alertas de > > > > Private strand flush not complete. > > > > > > > > Fico na dúvida se continuo aumentando o tamanho dos Redos...digo > > tamanho pq > > > > a quantidade vejo que esta boa, com varios grupos inativos no momento > > que > > > > estou com alto volume de alterações sendo realizadas no banco... > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >