Menu de navegação

[Ricardo Portilho ProniParticipante]

UNDO_RETENTION de 1500 significa que ele irá reter até 1500 segundos de UNDO, ou seja, 25 minutos.
Se você tiver uma transação maior que este tempo, e tiver um SELECT sobre os dados que esta transação está alterando, terá este erro.
Aumente a tablespace de UNDO, aumente o RETENTION.

Para ver os SQLs mais pesados de um período, você pode tirar um statspack ou awr report.

[mpvargasParticipante]

Ricardo,
Na verdade só ocorre esse erro com essa query:
ORA-01555 caused by SQL statement below (SQL ID: bj6nf951c195s, Query Duration=26680 sec, SCN: 0x0000.039b0bf8):
Wed Feb 11 17:56:50 2009
SELECT CTK_FILIAL, CTK_SEQUEN, CTK_DC, CTK_DEBITO, CTK_CREDIT,CTK_VLR01,CTK_VLR02,CTK_VLR03, …

Essa tabela tem 10 milhões de registros… mas vamos mexer nela, como ela é uma tabela de contra-prova da contabilidade, vou renomeá-la, fazer um backup e criar uma nova.
Com relação ao parâmetro, devo voltar para 900 ou posso deixar 1500?

O que continua acontecendo, com maior frequencia, é a demora do checkpoint causando bloqueio das sessões.
Será que mexer no redo log ajuda?
Obrigado

[vieriParticipante]

O tamanho do LOG_BUFFER ajuda sim a melhorar performance
oque ocorre é que em versões antigas 8i,
o valor default é 1MB e uma vez, aumentando esse valor
juntamente com o aumentos dos redos tive melhoria,
e as msgs do alert sumiram.

Oque ocorre é que a Oracle verificando isso nas versões
mas recentes o valor default agora (10g) gira em torno
de 14Mb, realmente se isto já está setado e o s redos estão
com valor alto, não à muito oque fazer na config do oracle,
o disco que é lento.

Verique com os desenvolvedeores se no processo do cara que está esgotando a undo
se ele faz commit de tantos em tantos registros atualizados,
para consumir menos undo e ter + performance.

[]s

[]s

[mpvargasParticipante]

OK Vieri
Obrigado pela ajuda.

Posso aumentar esse parâmetro em tempo de execução?
E com relação aos logs, devo aumentar a qtde de grupos ou o tamanho do arquivo?

Os processos fazem vários commit, eu acho que meu problema está relacionado aos discos e processamento.

O comando para fazer a alteração é esse:
ALTER SYSTEM SET log_buffer = 20971520 SCOPE=BOTH

E esse parâmetro tem alguma influência no tamanho da SGA?

[vieriParticipante]

Esta citação no metalink explica bem oque citei acima e corrige alguns pontos.

QUESTION

How does Oracle calculate the LOG_BUFFER size ?

A big difference can be seen between 10.2.0.3 and 10.2.0.4 when using the same system configuration (in terms of the application and its db objects and datafiles, ram size, number of CPUs etc). In 10.2.0.3 it was set by Oracle to 14M and now in 10.2.0.4 to 1.5M.

Solution
ANSWER

=========

The LOG_BUFFER size will be set by default, by Oracle internal algorithm.

In 10G R2, Oracle combines fixed SGA area and redo buffer [log buffer] together.
If there is a free space after Oracle puts the combined buffers into a granule, that space is added to the redo buffer. Thus you see redo buffer has more space than expected. This is an expected behavior.

Bug 4930608 documents this :
“In 10.2 the log buffer is rounded up to use the rest of the granule…
The granule size can be found from the hidden parameter “_ksmg_granule_size” ”

In 10G the log_buffer could fall between the log_buffer specified in spfile and the granule size.

A minimum value can be specified, but Oracle can initialize it with a bigger value, as decided by its internal algorithm.

Eu aumentario os redos para no máximo 300Mb.
Se após isso não haver melhoria.

Qto a undo ,pede para eles diminuir o intervalos entre os commit’s
se fazem de 1000000 em 1000000 diminui para 10000 em 10000
coisa do tipo ou como dito acima aumente a undo_retention.

o alter system está correto.

mas não lembro se o parâmetro é dinâmico, se tomar erro
troque por scope=spfile.

[]s

[mpvargasParticipante]

OK Vieri
Muito Obrigado.
Vou fazer os testes.

[Autor]

Posts