André/Ângelo,
Repassei a gerência isto que vocês falaram sobre o rastreio ser feito nestas condições de acesso e conhecimento. Agora é aguardar a posição deles. Valeu pelas dicas e orientações. Abraços, Marcos Em 11 de junho de 2014 19:33, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Bem, antes de responder primeiro tenho que dizer que normalmente só é > compreensível se usar uma versão antiga e sem suporte de database se for um > sistema LEGADO, APOSENTADO, que nunca vai ser Homologado nas versões mais > recentes porque está CONGELADO no tempo.... No seu caso, porém, o fato do > sistema estar recebendo alterações NEGA a possibilidade de ser um sistema > LEGADO, então isso é um ponto de Estranheza total... > Um segundo ponto é : como vc mesmo diz que não é especialista, Imagino > que vc deva ter uma posição mais gerencial, correto ?? Sendo isso mesmo, vc > ** TEM ** que contratar um Especialista Oracle (um DBA Sênior, se for o > caso) em que vc confie e que assuma a posuição de TECH LEADER, sim ??? > > Respondendo : os conceitos que precisam ser entendidos aqui são : > > - NÃO é a "Aplicação que abre uma TRANSAÇÃO" : no RDBMS Oracle, as > Transações são abertas automaticamente pelo próprio RDBMS, no instante em > que uma sessão envia o primeiro DML, e ficam abertas até a sessão > desconectar ou enviar um COMMIT ou ROLLBACK... > > - se uma sessão desconectar/cair em timeout ainda com uma Transação > aberta, normalmente é o ambiente/tool que impõe o que acontece : no > sqlplus, por exemplo, o default é COMMITar a transação eventualmente > pendente depois de uma desconexão graceful (ie, SEM nenhum abort envolvido) > > - um database link pode ser entendido como uma nova "thread" da conexão > que o acionou, compartilhando a mesma sessão E portanto partilhando da > mesma Transação aberta pelo banco-origem > > Demonstração : > > => crio uma tabela no banco "A", no banco-origem, e que Inclusive vai ser > a mesma consultada remotamente na procedure chamada em B : > > SYSTEM:@O11GR2:SQL>create table TAB_TESTE(c1 number, c2 varchar2(40)); > > Tabela criada. > > => crio a procedure no banco XE , que vai ser acessada remotamente, SEM > nenhuma transação aberta : > > HR:@XE:SQL>create or replace procedure ins_regions is > 2 x number; > 3 BEGIN > 4 select count(*) into x from TAB_TESTE@o11gr2; > 5 insert into regions values(99, 'c=' || to_char(x) ); > 6 END; > 7 / > > Procedimento criado. > > => eis o status da tabela : > > HR:@XE:SQL>select * from hr.regions; > > REGION_ID REGION_NAME > ---------- ------------------------- > 1 Europe > 2 Americas > 3 Asia > 4 Middle East and Africa > > HR:@XE:SQL> > > => veja o dblink : > > HR:@XE:SQL>select * from user_db_links; > > DB_LINK USERNAME PASSWORD > HOST CREATED > ----------------------- ---------------- ------------------------------ > ------------ -------- > O11GR2 SYSTEM > o11gr2 10/06/14 > > => veja que no banco-origem o dblink aponta realmente pro banco-destino > nesse mesmo usuário SYSTEM em que estou conectado : > > SYSTEM:@O11GR2:SQL>select * from user_db_links; > > DB_LINK USERNAME PASSWORD > HOST CREATED > ----------------------- ---------------- ------------------------------ > ------------ -------- > XE HR > XE 10/06/14 > > > ==> agora , inicio uma transação local no banco-origem "A" - no meu banco > o11gr2 - via DML : > > SYSTEM:@O11GR2:SQL>insert into TAB_TESTE values (1, 'Linha 1'); > > 1 linha criada. > > => e executo a procedure remota, que vai fazer DML ** mas ** vai também > consultar tabela no banco-origem : > > SYSTEM:@O11GR2:SQL>exec ins_regions@xe; > > Procedimento PL/SQL concluído com sucesso. > > ==> agora COMITO : > > SYSTEM:@O11GR2:SQL>commit; > > Commit concluído. > > => veja como ficaram os objetos locais : > > SYSTEM:@O11GR2:SQL>select * from tab_teste; > > C1 C2 > ---------- ---------------------------------------- > 1 Linha 1 > > SYSTEM:@O11GR2:SQL> > > => agora no banco-remoto : > > HR:@XE:SQL>select * from hr.regions; > > REGION_ID REGION_NAME > ---------- ------------------------- > 1 Europe > 2 Americas > 3 Asia > 4 Middle East and Africa > 99 c=1 > > HR:@XE:SQL> > > => legal ???? Veja que a sessão "remota" *** enxergou *** o INSERT > não-comitado no banco-origem, E a transação encerrou suavemente, *** > GRAVANDO SIM SENHOR *** os DMLs feitos no banco remoto ** E ** no > banco-origem, cfrme acima, yes ??? SEM problema algum , ***** APESAR **** > da rotina remota ter feito um acesso ao banco origem, então a sua SUPOSIÇÂO > de que "o Oracle não permite que durante um processo de gravação seja > estabelecido a comunicação de A -> B e de B -> A em uma mesma transação" > simplesmente CAI POR TERRA, ok ???? > Repito, com certeza das duas uma : OU não deve ser só uma "validação" > simples que a procedure faz (talvez tenha select for update, talvez faça > DMLs no banco-origem), OU (como já dito E muito provável) por erro de > exception ou na aplicação tá dando um ** ERRO ** qualquer, que está sendo > mascarado e está fazendo algum INSERT ou UPDATE não ter sucesso.... É caso > de DEBUG, puro e SIMPLES.... > > []s > > Chiappa > >
