Menu de navegação

[Manoel872Participante]

Boa tarde,

Pessoal existe uma forma que eu defina o comando de update ou a tabela, que não faça lock de registro, exemplo se duas seções concorrentes fazem um update sem um commit não gere um lock ficando o ultimo commit?

Att,

Manoel Jr.

[IshiiParticipante]

Olá,

Manuel, desculpe-me a curiosidade, mas o por que?

Com isso a transação deixaria de ser íntegra ou não?

[]s Ishii

[Manoel872Participante]

Cenário:

Tenho trigger em diversas tabelas do meu sistemas onde essas trigger fazem um insert em uma tabela de interface, sempre deixando o registro mais atualizado na interface, portando quando tenho um registro na interface da tabela x registro y e faço uma outra alteração no registro y ele envia novamente para interface e inativa o antigo.
Tenho uma rotina que lê a tabela de interface de 100 em 100 registro e cria um arquivo txt para o outro sistema, porém como ao processar eu altero o registro para status processado enquanto ele não terminar o cursor não faço commit, gerando um lock, podendo possivelmente locar registros enquanto o cursor nao finalizar.

Att,

Manoel Jr.

[IshiiParticipante]

Olá,

“Trigger às vezes nos faz dar um tiro no pé” já dizia um DBA amigo meu….

Mas vamos lá…

Se você “autocomittar” a transação de atualização da Interface ANTES do cursor terminar, você não corre o risco do Cursor estar com um valor errado? E com isso a interface ficaria com um valor diferente da tabela de Interface ou seja um valor antigo?

Não conheço exatamente a sua interface mas ela me parece bastante correta ao ‘esperar’ o cursor finalizar. O lock ocorre na atualização do valor novo e desativação do antigo na tabela de Interface? Se sim, sugiro apenas reduzir o número de registros para o arquivo txt, com isso o tempo pode ser reduzido e evitando o lock…

Agora se o número de acessos na tabela original for alto e com isso o nível de alteração na tabela de interface também for alto, sugiro rever a estratégia de integração…(por exemplo passar de trigger para Scheduler com procedure, ou ainda criar uma tabela temporária…)

[]s Ishii

[Manoel872Participante]

Opa,

Aplicação roda 24 x 7 portando tenho muitos usuário e as trigger estão em algumas tabelas principais do sistema, mesmo se diminuir existe a possibilidade. Estava com problema de snapshoot para solucioná-lo eu alterei para usar uma tabela virtual de session como cursor e processo de 100 em 100 dando commit no final do 100 para lipar a tabela. No caso a rotina ja está schedullada para processar de madrugada.

Att,

Manoel jr.

[Rodrigo AlmeidaParticipante]

Você quer desabilitar uma das principais funções do Oracle que é justamente conseguir manter os dados íntegros! Isso pode lhe trazer alguns probleminhas.

Uma saída para esse seu problema é seguir a sugestão do Ishii ou usar o SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ou READ COMMITED!

Uma outra saída também é usa a opção OF UPDATE NOWAIT na construção do cursor.

Abraços,

Rodrigo Almeida

[IshiiParticipante]

Olá,

Voltando ao problema…

Não entendi direito… você tem uma tabela temporária virtual session que é alimentada pelas triggers e a usa como cursor para um processe que roda de 100 em 100 registros comittando para limpar a tabela. O que exatamente faz essa rotina schedulada de madrugada?

[]s Ishii

[Manoel872Participante]

Opa,

A rotina e para criação de um arquivo txt para exportação de dados, pensei melhor e criei uma forma de não gerar lock no banco. Faço o update no final do processo commitando em seguida. Estou dando manutenção nesse código e está complicado. HeHe!

Muito obrigado pela ajuda de todos.

Att,

Manoel jr

[Rodrigo AlmeidaParticipante]

Era o caso apenas de pensar no processo ao todo.

Pegar código de terceiros é realmente díficil dar manutenção.

Boa Manuel.

Abraços,

Rodrigo Almeida

[Autor]

Posts