Menu de navegação

[PetersonParticipante]

Mpvargas,

Desculpe se minha pergunta parece óbvia, mas não há multiplexação dos arquivos de logs dentro de uma mesma área de disco não né?
Outra coisa, seus datafiles são de gerência local ou por dicionário de dados?

[hudsonaParticipante]

Existe o Processo citado por você, o (ARCH), que sua função é arquivar os redo log files… Neste caso, bastaria melhorar a performance da flash_recovery_area, se fosse este mesmo o problema.

Eu estava querendo dizer é a espera do LGWR na escrita de novos redos no caso em que o DBWR(escrita em Datafile), não ter efetuado a escrita dos dados em datafile do redo passado.

A escrita do LGWR é muito mais rápida do que a do DBWR pela arquitetura do Oracle, sendo assim o tipo de espera mais comum relativos a redo.

Amigão

Sim, óbvio que existe o (ARCH) eu já citei ela na resposta acima (up) .
Ele pra “simplesmente” arquivar os redo log files, faz um trabalho de reads and writes nos redo log files e enquanto esse trabalho não termina LGWR não pode regravar os Redo Log Files , ou seja se você tiver uma grande geração de redo e uma quantidade de arquivos insuficientes ou pequenos demais, a espera vai ser … ….
Não estou falando de armazenamento dos archives, então por ora a flash_recovery_area não entra em questão ….

A Escrita do LGWR não é muito mais rápida que a do DBWR, ela é constante, rsrs , esse “i/o” não para, a gravação do conteudo do buffer de redo log para os Redo Log files é constante.

Sim realmente poderia ocorrer de LGWR estar esperando DBWn gravar os blocos nos datafiles, mas neste caso isso só poderia ocorrer se os redo logs fossem muito pequenos ,ou se o número de Redo logs fosse pequeno, Ai sim LGWR não ia poder regravar os redo log files, enquantos os datafiles estivessem sincronizados com o último Redo.
Ai sim poderiamos ter uma espera de LGWR por DBWR .

E se isso acontecesse, no alert.log teriamos o famoso:
Thread 1 cannot allocate new log, sequence 18
Checkpoint not complete

Como o Mpvargas falou que no alert dele não existe esse erro, e pelo número de redo log files, e o tamanho dos mesmos, exclui essa possibilidade e falei da possibilidade de ocorrer a espera pela gravação dos archives ….

[jspaulonciParticipante]

Oi mpvargas, vamos resolver esse problema.
Não esqueça de postar o resultado.

Bom…sugiro começarmos pelo começo, fazendo o básico.
Check a distribuição dos redo logs online, estão em discos separados ?
O I/O desse discos está legal ?
Sua máquina trabalha tranquila ? ou Trabalha estrangulada o dia todo ?
Qual é o tamanho do parametro log_buffer da sua base ?
Qual é a versão da base que você está utilizando ?
Qual é a versão do SO ?
Verifique o tempo entre um switch log file e outro, a Oracle recomenda como boa prática guardar pelo 20 minutos a cada switch, e no mínimo 3.5 minutos a cada switch.

Monitore as esperas pela query que o Vitor Leandro postou .
Não saia tomando nenhuma atitude, vamos diagnosticar o caso, e aí a gente estuda uma ação sensata.

Problemas do seu tipo é o que mais tem.

Abraços
Spaulonci

[hudsonaParticipante]

[quote=”mpvargas”:1d73a1n3]Fala Hudson,
Li o artigo (muito bom)
Mas estou em dúvida qto a solução…
Não tenho para onde mover os redo logs…
Seria interessante aumentar a qtde ou tamanho dos arquivos?[/quote]

Mpvargas ,

Hoje os redo logs estão no mesmo filesystem, e no mesmo disco ?

[jspaulonciParticipante]

Antes de aumentar o tamanho dos redos, verifique o tempo de intervalo entre cada Switch.

Spaulonci

[mpvargasParticipante]

Peterson,

Desculpe se minha pergunta parece óbvia, mas não há multiplexação dos arquivos de logs dentro de uma mesma área de disco não né?
R: Não são multiplexados, só uso um arquivo por grupo porque meus discos são espelhados.

Outra coisa, seus datafiles são de gerência local ou por dicionário de dados?
R: São gerenciados localmente

[mpvargasParticipante]

Fala jspaulonci
Vamos as respostas

Check a distribuição dos redo logs online, estão em discos separados ?
R: Tenho 8 grupos de 500MB, cada um com 1 arquivo… estão em dois discos em RAID 10

O I/O desse discos está legal ?
R: Está sim

Sua máquina trabalha tranquila ? ou Trabalha estrangulada o dia todo ?
R: Trabalhava tranquila com essa configuração, mas nessa semana está com muitos processos… temos 3 tabelas críticas e normalmente ocorre esse problema qdo as 3 são acessadas ao mesmo tempo

Qual é o tamanho do parametro log_buffer da sua base ?
R: 14MB
Obs.: Esse parâmetro gera muita controvérsia, alguns dizem que não adianta ser maior que 1MB outros dizem que o ideal é colocar pelo menos uns 50MB… O meu é default

Qual é a versão da base que você está utilizando ?
R: Enterprise 10G – 10.2.0.1.0

Qual é a versão do SO ?
R: Linux 64Bits – CentOS

Verifique o tempo entre um switch log file e outro, a Oracle recomenda como boa prática guardar pelo 20 minutos a cada switch, e no mínimo 3.5 minutos a cada switch.
R: Isso é que eu acho estranho… ele está gerando poucos logs, então teoricamente não deveria estar sinalizando o LGWR… ontem gerou 6 logs o dia inteiro, variando entre 2 e 4horas de intervalo… hoje gerou um log às 00:27 e outro às 10:03h

[mpvargasParticipante]

Fala Hudson,

Hoje os redo logs estão no mesmo filesystem, e no mesmo disco ?
R: SIM… tenho um servidor com 8 discos e fiz a distribuição da seguinte forma:

FileSystem Descrição
/ Instalação, tablespaces de sistema e controlfile1
/dados Dados e controlfile2
/indices Indices e controlfile3
/logs Redo Logs e flash_recovery_area

2 discos por filesystem em RAID 10
Sempre funcionou bem com essa configuração

No ADDM recebo algumas msg sugerindo o aumento da SGA para 7GB… o servidor tem 14GB de RAM mas só consigo alocar 6GB na SGA

[mpvargasParticipante]

Fala João Paulo,

Antes de aumentar o tamanho dos redos, verifique o tempo de intervalo entre cada Switch.

R: O tempo de intervalo está bem alto… por isso estou achando estranho esse problema.

[mpvargasParticipante]

ACHO QUE CONSEGUI RESPONDER A TODOS

OBRIGADO PELA AJUDA

A LUTA CONTINUA

[jspaulonciParticipante]

Vargas, pelo que temos de informaçãoe parace que as coisas estão como devem estar, quanto ao ADDM sugerir aumento da SGA , eu recomendo que vc não considere, pois se você aumentar a SGA daqui algum tempo concerteza ele irá pedir para você aumentar novamente, aumentar a SGA eu acho que não é o caminho.
Seu tempo de switch está bom seu problema não está no tamanho dos seus redos.
Quanto ao log buffer, recomendo deixar 15 mb mesmo, bom…vc tem Metalink ? Se sim, eu abriria um chamado no Metalink e colocaria isso para eles, de repente pode ter até algum bug relacionado.
Quanto a essas três tabelas, sugiro você pegar as querys mais pesadas e passar para os analistar ou sugerir tuning.

Poste pra nós a sua decisão.

Abraços
Spaulonci

[hudsonaParticipante]

jspaulonci

O mpvargas não pode abrir chamado no metalink, o SO dele é o CENTOS e o CENTOS não é homologado pela Oracle, eu acredito que o problema deve estar concentrado nas tabelas particionadas e nas consultas em cima das mesmas.

Mpvargas,

Como foi feito o particionamento dessas tabelas ?
E essas consultas que rodam em cima dessas tabelas ? elas estão otimizadas ?
Você disse que esse problema começou ha algumas semanas , quais foram as modificações que o banco sofreu? o servidor sofreu alguma modificação ?

Abraços !!

[jspaulonciParticipante]

Mpvargas, faça o que o hudsona pediu, nos passe como foi realizado o particionamento, verifique se tem indices em UNUSABLE, o Oracle poderá fazer um FULL SCAN nas tabelas caso tiver indices em USUBLE, pois no 10g tem o parametro skip_unusable_indexes o default é TRUE, quando está TRUE o Oracle não emite erros para instruções em tabelas com indices em USUBLE, aí o Oracle monta o planto de execução sem o indice mesmo, ai a casa cai pois ele poderá fazer full scan nessas tabelas que são as maiores.

Isso é importante.
Spaulonci

[mpvargasParticipante]

Hudson e João Paulo

Quanto a abrir o chamado, não tem problema, eu consigo abrir chamados tranquilamente… eu uso o CentOS mas ele lê como Red-Hat

Com relação aos questionamentos:

Como foi feito o particionamento dessas tabelas ?
R: O particionamento é por data

E essas consultas que rodam em cima dessas tabelas ? elas estão otimizadas ?
R: Recebo muitas msg para otimizar as consultas, mas como é um ERP comprado (Microsiga) agente tem que se virar pra fazer isso funcionar

Você disse que esse problema começou ha algumas semanas , quais foram as modificações que o banco sofreu? o servidor sofreu alguma modificação ?
R: Na verdade não houve mudança…. o que está havendo é uma grande qtde de processos simultaneos, tipo: Fechamento da Contabilidade, DIRF, etc

[jspaulonciParticipante]

Mpvargas, faça o que o hudsona pediu, nos passe como foi realizado o particionamento, verifique se tem indices em UNUSABLE, o Oracle poderá fazer um FULL SCAN nas tabelas caso tiver indices em USUBLE, pois no 10g tem o parametro skip_unusable_indexes o default é TRUE, quando está TRUE o Oracle não emite erros para instruções em tabelas com indices em USUBLE, aí o Oracle monta o planto de execução sem o indice mesmo, ai a casa cai pois ele poderá fazer full scan nessas tabelas que são as maiores.

Isso é importante.
Spaulonci

[Autor]

Posts