Menu de navegação

[vieriParticipante]

Caros,

costantemente aqui na empresa
sofremos com este erro aqui na empresa.

ORA-01591: lock held by in-doubt distributed transaction 7.29.1547289

Criei um procedimento que é o seguinte.

Set pagesize0
Spool gera_kill_lock.sql
select ‘ rollback force ”’||LOCAL_TRAN_ID||””||’;’ from dba_2pc_pending where RETRY_TIME > sysdate – 1 ;
select ‘ exec dbms_transaction.purge_lost_db_entry ”’||LOCAL_TRAN_ID||””||’;’|| chr(10) ||’ commit ; ‘
from dba_2pc_pending where RETRY_TIME > sysdate – 1;
@gera_kill_lock.sql

Este refinado ao longo de algumas semanas para atender por completo o problema.

alêm disso ainda tem está consulta que pega a transação que está provocando o lock-held.

select e.sql_text, d.osuser,d.username from v$transaction c, v$session d, v$sqlarea e
where d.taddr = c.addr and e.address = d.prev_sql_addr and
c.xidusn = <1st Part of Transaction -ID> and
c.xidslot =<2nd Part of Transaction -ID> and
c.xidsqn = <3rd Part of Transaction -ID>;

Do papel do DBA existe algo que ainda posso está esquecendo?

Mas a minha grande dúvida é a seguinte…

Qdo começou a dar este problema eu sempre fazia apenas o rollback
das transações com o rollback force, não fazia o purge,
e mesmo assim eliminava o lock.

Este tipo de atuação será que pode ter feito com que o Oracle(RECO)tente resgatar o processo global novamente, e como a conexão distribuida já morreu ele fique entrando em loop de tantos em tantos dias,
poque mesmo apos o rollback no dia 05, no dia 7 parecia que o mesmo processo tentava novamente, sendo isto claro
nos campos FAIL_TIME,FORCE_TIME,RETRY_TIME
na view dba_2pc_pending.

Agora com a solução completa rollback force + purge acredito que não irá mais ocorrer por causa deste loop, mas concordamos que é um comportamento extrano??!?!?!

Alêm disso temos o parametro commit_point_strength,
que define qual banco será o coordenador da transação global,
ou seja na maioria dos casos o banco com maior importância e maior disponibilidade, mas isso é muito pouco implementado, pelo menos por onde eu passei.
Alguem já implementou ou viu nescessidade parecida?

Queria explanar este assunto neste post, porque este erro ocorre bastante e nem sempre sua teoria e prática são bem explicados.

Se alguem tiver algo a acrescentar ou críticar sou todo ouvidos!
ou melhor monitor! risos..

obs? As vezes o Oracle me intriga, após força o rollback o background RECO 1 dia depois tentar executar a transação, porque ele faria isso…

abços!!

[Rodrigo AlmeidaParticipante]

Bom,

Faz algum tempo que escrevi algo sobre o Commit Two-Phase no me blog (https://profissionaloracle.com.br/blogs/rodrigoalmeida/2008/08/11/transacoes-pendentes-em-ambiente-distribuido/), mas sobre os Lock held in-doubt é realmente quando ele está duvidoso sobre sua transação e o processo RECO não consegue realizar o seu COMMIT ou ROLLBACK.

Eu diria que isso não é totalmente culpa do RECO, pois esse processo tem apenas a finalidade de terminar a sessão, que quem deveria realizar isso melhor seria o PMON, que deveria apontar o problema e o RECO acabar com a transação LOCAL.

Mas, isso era muito comum em bases 8i e até mesmo 9i, onde se deveria realizar o ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY para conseguir eliminar a transação por completa.

No 10g já fica mais complicado isso acontecer, até mesmo porque se usa UNDO, desde os próprios segmentos de ROLLBACK (são a mesma coisa, mas quem controla isso no 10g é o oracle, se tiver com a opção UNDO_MANAGEMENT = AUTO), por isso a facilidade.

Sobre os parâmetros da instância, geralmente utilizo o commit_point_strength e distributed_transactions para “TENTAR” realizar esse controle das transações que estão sobre o Commit Two_Phase, para as versões 8i e 9i.

Mas mesmo assim, aqui no ambiente também acontece muito Lock held principalmente quando algum link da unidade está fora, por ocorrer a perda de dados, a transação vai ficar duvidosa e ter esses problemas. No nosso caso, temos 17 unidades, os problemas de lock são diretamente aplicadas a infra-estrutura dos links, já que os processos de replicação possuem COMMIT e ROLLBACK em toda fase da transação.

Abraços,
Rodrigo Almeida

[vieriParticipante]

Exatamente Rodrigo,

o pessoal de rede detectou perda de pacotes, entre os servidores
os bancos ficam em hosting’s diferente…e também possuem commit e rollback, e um cenârio identico ao seu.

Tenho 99% que o problema está ai,
como não é da minha ossada esse tipo de problema aqui na empresa,
fiz um procedimento para mandar e-mail quando houver
transação dúvidosa.

Acho que por passar por este problema, que vc escreveu esse material.

Pois eles são “raros”, trabalhei em uma empresa que durante 2 anos,
só vi esse erro uma vez, e aqui ocorre com muita frequencia.

como não vi solução de minha parte, e o processo é muito crítico e acaba gerando indisponibilidade, criei um processo(job) para me enviar e-mail e um script dinâmico para matar o problema.

Resumidamente é isso aqui:

create or replace procedure pr_monit_2pc
is
L_CONT varchar2(1000);
l_body long := chr(10) ||’ ‘|| lpad(‘LOCAL_TRAN_ID’,18, ‘ ‘) || ‘ ‘
|| rpad(‘STATE’, 12, ‘ ‘) || ”
|| rpad(‘FAIL_TIME’, 20, ‘ ‘) || ‘ ‘
|| rpad(‘RETRY_TIME’, 20, ‘ ‘) || chr(10);

begin

select count(*)
into L_CONT from dba_2pc_pending;

IF ( L_CONT > 0) THEN

for x in ( select LOCAL_TRAN_ID,STATE,FAIL_TIME,RETRY_TIME from dba_2pc_pending )
loop
l_body := l_body || lpad(x.LOCAL_TRAN_ID, 18, ‘ ‘) || ‘ ‘ ||
rpad(x.STATE, 12, ‘ ‘) ||” || rpad(x.FAIL_TIME,20,’ ‘) ||’ ‘|| rpad(x.retry_time,20,’ ‘) || chr(10) ;
end loop;

mail.send
( p_sender_email => ‘mail’,
p_from => ‘mail’,
p_to => mail.array(‘mail’),
p_subject => ‘Estamos com Lock Held … Verificar com urg¿ncia!!!’,
p_body => l_body );

END IF;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(SQLERRM);

END;

dinâmico:

Set pagesize0
Spool gera_kill_lock.sql
select ‘ rollback force ”’||LOCAL_TRAN_ID||””||’;’ from dba_2pc_pending
union all
select ‘ exec dbms_transaction.purge_lost_db_entry’||'(‘||””||LOCAL_TRAN_ID||””||’)’||’;’|| chr(10) ||’ commit ; ‘
from dba_2pc_pending ;
@gera_kill_lock.sql

Se quiser lhe envio todo o processo, package,package_body,procedure,jobs.. etc..etc tudo por e-mail,
como sempre me ajuda lhe dou essa mordomia..
hehehe

Mas derropente ai na sua empresa não existe essa nescessidade,
aqui foi ata de reunião… : /

[]s

[Rodrigo AlmeidaParticipante]

Vieri,

Pode passar sim por e-mail, é sempre bom e até mesmo implementar esses recursos criados por nós. ajuda em muito.

Uma dúvida, os links que sua empresa está trabalhando hoje não é da Telefônica não né?

Aqui na empresa, temos muitos problemas com outros estados por moivos de perda de pacotes entre eles, e consequentemente, Lock-in-held doubt!!!

Hoje, para ter um controle sobre eles, criamos Batchs para analisar todas as transações na base, muitos aqui ainda são 8i, e por isso, o cuidado com os locks-in-held!!!

Abraços,
Rodrigo Almeida | dbarodrigo@gmail.com

[vieriParticipante]

Cara acho que são da embratel.

Não entendi qual a ajuda da bath que controla as
transações? oque ela faz?

acabei de enviar o e-mail, dps me responde se implementou ou não, acho que funciona no 8i tranquilamente,
fiz questão de usar a utl_smtp.
Se conseguir fazer alguma melhora no processo,
eu apanhei para formatar o e-mail não é mto minha praça…

[]s

[Autor]

Posts