Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
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:SQLcreate 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:SQLcreate 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:SQLselect * 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:SQLselect * 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:SQLselect * 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:SQLinsert 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:SQLexec ins_regions@xe; Procedimento PL/SQL concluído com sucesso. == agora COMITO : SYSTEM:@O11GR2:SQLcommit; Commit concluído. = veja como ficaram os objetos locais : SYSTEM:@O11GR2:SQLselect * from tab_teste; C1 C2 -- 1 Linha 1 SYSTEM:@O11GR2:SQL = agora no banco-remoto : HR:@XE:SQLselect * 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
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
Chiappa, Isto que você citou sobre bancos com versões antigas é algo que nós como analistas/desenvolvedores questionamos muito a área de BD, mas nunca temos um posicionamento que nos dê garantia de que arrumaram a casa em um curto período de tempo. Quanto a sua explicação era justamente o que eu queria entender e ficou bem claro o funcionamento sim. Agora encontrar o problema e apontar a solução é como vocês estão falando, somente por alguém com acesso aos 2 sistemas e conhecimento do funcionamento de toda a estrutura de BD. De toda forma já repassei aos meus superiores tudo que consegui de explicação e direcionamento por parte de vocês sobre o que deverá ser feito para encontrarmos o real problema e implementarmos uma solução. Obrigado pela disposição, mesmo sabendo que eu não sou especialista em BD, tive um retorno EXCELENTE dos membros deste grupo. Abraços a todos! Marcos Em 12 de junho de 2014 12:30, Marcos Antônio de Araújo maac...@gmail.com escreveu: 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:SQLcreate 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:SQLcreate 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:SQLselect * 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:SQLselect * 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:SQLselect * 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:SQLinsert 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:SQLexec ins_regions@xe; Procedimento PL/SQL concluído com sucesso. == agora COMITO : SYSTEM:@O11GR2:SQLcommit; Commit concluído. = veja como ficaram os objetos locais : SYSTEM:@O11GR2:SQLselect * from tab_teste; C1 C2 -- 1 Linha 1 SYSTEM:@O11GR2:SQL = agora no
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
Bom dia André, Como a aplicação B é de outra equipe não tenho o conhecimento necessário de como está implementado todo o código da stored procedure, mas quanto ao tratamento de erros eu confirmei com a equipe se havia um exception when others justamente para retornar qualquer tipo de erro que pudesse estar ocorrendo e eles não estavam tratando. Mas mesmo assim não obtivemos sucesso. Em 10 de junho de 2014 18:17, Andre Santos andre.psantos...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos Depende muito de como foi elaborado o código PL/SQL... até mesmo um SELECT pode gerar erro... e como é feito o tratamento dos erros (exceptions)? [ ]'s André Em 10 de junho de 2014 17:14, angelo angelolis...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Vamos lá, bora tentar matar mais essa charada Pergunta em cima da pergunta... Na aplicação A, quando o procedimento que faz a leitura da tabela, ela vai sempre ao DBLINK para acessar também base B? Ou não necessariamente, podendo variar tipo, pode ir ou não? O fato de ter alterado, se nao mexeram no DBLINK, teoricamente nao deveria alterar em nada.. Quanto ao processo do gravação, acho que o Oracle não interfere não, até porque o controle ta dentro do codigo, na transação aberta tudo vai ser processado como se fosse uma coisa só.. e a conta fecha, quando vier o commit encerrando o processo. Bom, to dando pitaco sem testar.. O que se pode fazer é checar a conectividade, se o DBLINK está de pé (se bem que se nao tivesse daria erro na primeiro select bla, bla from tabela@B ) no momento da execução.. 2014-06-10 10:04 GMT-03:00 Marcos Antônio de Araújo maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Pessoal, Agradeço demais as explanações feitas por vocês afim de me direcionar para a solução do problema. Acabou que ontem a tarde detectamos o real motivo do problema e como vocês mesmo já haviam dito, me parece ter sido implementação de código. Porém, é a segunda vez que ocorre e gostaria de ver se você saberiam me explicar o que ocorre tecnicamente no Oracle. *CASO* Temos 2 aplicações que fazem interoperabilidade através de stored procedure, durante o processo de gravação de registros. A *aplicação A* abre uma transação e executa diversos INSERTs/UPDATEs na própria base de dados e em um determinado momento executa uma stored procedure através de um DBLINK que faz diversas validações na base de dados da *aplicação B*. Tudo funcionava perfeitamente até que um dia foi implementado neste procedimento uma leitura de uma tabela da *aplicação A *novamente e a partir deste dia começou a ocorrer o problema citado, onde a transação não retorna erro mas não grava nenhum dado na base da *aplicação A*. 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? Abraços, Marcos Em 9 de junho de 2014 09:19, Marcos Antônio de Araújo maac...@gmail.com escreveu: Chiappa, Valeu demais esta sua explicação. Vou sentar com as chefias aqui e repassar tudo isto afim de detectarmos o problema. Obrigado! Abraços, Marcos Em 9 de junho de 2014 00:06, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: No RDBMS Oracle, o trace de SQL pode ser aplicado a um SQL específico, a uma sessão, ou a todas as sessões que se conectarem ao banco de dados : não há, por parte do RDBMS, nenhuma opção de trace a nível de instância nem a nível de servidor. Não haverá, portanto, a necessidade de restart do servidor, nem nada do tipo. A nível de database, os únicos parâmetros exigidos são o TIMED_STATISTICS=TRUE, os parâmetrso de dump apontando para um filesystem/disco com bastante espaço livre e o max_dump_file_size setado para um valor o mais alto possível. Evidentemente : a) traces do tipo podem interferir SERIAMENTE com a performance, já que tipicamente um database Oracle de produção processa centenas de SQLs a cada curto período : assim sendo, JAMAIS vc ativará o trace num período de uso comum, mas sim num período/dia escolhido aonde haja o menor número de utilizadores, ou até mesmo (preferencialmente) só o usuário testador b) os arquivos gerados por esse trace tendem a crescer muito, então o servidor deve ser Preparado, liberando-se o máximo de espaço possível (ou mesmo adicionando-se espaço extra) c) deve ser levantado se o ambiente usa algum tipo de POOL DE CONEXÕES, aonde a aplicação não cria uma sessão para cada conexão, mas sim cada comando enviado ao database por cada conexão são atendidos por uma sessão pré-criada pelo pool : se isso for verdadeiro, o pessoal aí terá que instrumentar/identificar a sessão, com um dos mecanismo de end-to-end trace : veja http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html para um exemplo d) deve ser levantada a comunicação com o database, no sentido de checar se
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
André, Então pode ser isto. Eu tinha um entendimento errado referente a esta opção de when others então. Você tem algum material para me indicar sobre tratamento de exceptions? Aqui utilizamos muita coisa em PL/SQL, porém os exceptions tratados em grande maioria é no_data_found e when others. Abraços Em 11 de junho de 2014 11:25, Andre Santos andre.psantos...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos O ideal é que alguém que conhece Oracle PL/SQL pudesse verificar essa procedure. Apenas saber que existe um exception when others não diz muita coisa... Na realidade, um tratamento com when others pode até omitir erros (o que, infelizmente, é muito comum), ao invés de retorná-los. [ ]'s André Em 11 de junho de 2014 09:19, Marcos Antônio de Araújo maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Bom dia André, Como a aplicação B é de outra equipe não tenho o conhecimento necessário de como está implementado todo o código da stored procedure, mas quanto ao tratamento de erros eu confirmei com a equipe se havia um exception when others justamente para retornar qualquer tipo de erro que pudesse estar ocorrendo e eles não estavam tratando. Mas mesmo assim não obtivemos sucesso. Em 10 de junho de 2014 18:17, Andre Santos andre.psantos...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos Depende muito de como foi elaborado o código PL/SQL... até mesmo um SELECT pode gerar erro... e como é feito o tratamento dos erros (exceptions)? [ ]'s André Em 10 de junho de 2014 17:14, angelo angelolis...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Vamos lá, bora tentar matar mais essa charada Pergunta em cima da pergunta... Na aplicação A, quando o procedimento que faz a leitura da tabela, ela vai sempre ao DBLINK para acessar também base B? Ou não necessariamente, podendo variar tipo, pode ir ou não? O fato de ter alterado, se nao mexeram no DBLINK, teoricamente nao deveria alterar em nada.. Quanto ao processo do gravação, acho que o Oracle não interfere não, até porque o controle ta dentro do codigo, na transação aberta tudo vai ser processado como se fosse uma coisa só.. e a conta fecha, quando vier o commit encerrando o processo. Bom, to dando pitaco sem testar.. O que se pode fazer é checar a conectividade, se o DBLINK está de pé (se bem que se nao tivesse daria erro na primeiro select bla, bla from tabela@B ) no momento da execução.. 2014-06-10 10:04 GMT-03:00 Marcos Antônio de Araújo maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Pessoal, Agradeço demais as explanações feitas por vocês afim de me direcionar para a solução do problema. Acabou que ontem a tarde detectamos o real motivo do problema e como vocês mesmo já haviam dito, me parece ter sido implementação de código. Porém, é a segunda vez que ocorre e gostaria de ver se você saberiam me explicar o que ocorre tecnicamente no Oracle. *CASO* Temos 2 aplicações que fazem interoperabilidade através de stored procedure, durante o processo de gravação de registros. A *aplicação A* abre uma transação e executa diversos INSERTs/UPDATEs na própria base de dados e em um determinado momento executa uma stored procedure através de um DBLINK que faz diversas validações na base de dados da *aplicação B*. Tudo funcionava perfeitamente até que um dia foi implementado neste procedimento uma leitura de uma tabela da *aplicação A *novamente e a partir deste dia começou a ocorrer o problema citado, onde a transação não retorna erro mas não grava nenhum dado na base da *aplicação A*. 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? Abraços, Marcos Em 9 de junho de 2014 09:19, Marcos Antônio de Araújo maac...@gmail.com escreveu: Chiappa, Valeu demais esta sua explicação. Vou sentar com as chefias aqui e repassar tudo isto afim de detectarmos o problema. Obrigado! Abraços, Marcos Em 9 de junho de 2014 00:06, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: No RDBMS Oracle, o trace de SQL pode ser aplicado a um SQL específico, a uma sessão, ou a todas as sessões que se conectarem ao banco de dados : não há, por parte do RDBMS, nenhuma opção de trace a nível de instância nem a nível de servidor. Não haverá, portanto, a necessidade de restart do servidor, nem nada do tipo. A nível de database, os únicos parâmetros exigidos são o TIMED_STATISTICS=TRUE, os parâmetrso de dump apontando para um filesystem/disco com bastante espaço livre e o max_dump_file_size setado para um valor o mais alto possível. Evidentemente : a) traces do tipo podem interferir SERIAMENTE com a performance, já que tipicamente um database Oracle de produção processa centenas de SQLs a cada curto período : assim sendo, JAMAIS vc ativará o trace num período de
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
Pessoal, Agradeço demais as explanações feitas por vocês afim de me direcionar para a solução do problema. Acabou que ontem a tarde detectamos o real motivo do problema e como vocês mesmo já haviam dito, me parece ter sido implementação de código. Porém, é a segunda vez que ocorre e gostaria de ver se você saberiam me explicar o que ocorre tecnicamente no Oracle. *CASO* Temos 2 aplicações que fazem interoperabilidade através de stored procedure, durante o processo de gravação de registros. A *aplicação A* abre uma transação e executa diversos INSERTs/UPDATEs na própria base de dados e em um determinado momento executa uma stored procedure através de um DBLINK que faz diversas validações na base de dados da *aplicação B*. Tudo funcionava perfeitamente até que um dia foi implementado neste procedimento uma leitura de uma tabela da *aplicação A *novamente e a partir deste dia começou a ocorrer o problema citado, onde a transação não retorna erro mas não grava nenhum dado na base da *aplicação A*. 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? Abraços, Marcos Em 9 de junho de 2014 09:19, Marcos Antônio de Araújo maac...@gmail.com escreveu: Chiappa, Valeu demais esta sua explicação. Vou sentar com as chefias aqui e repassar tudo isto afim de detectarmos o problema. Obrigado! Abraços, Marcos Em 9 de junho de 2014 00:06, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: No RDBMS Oracle, o trace de SQL pode ser aplicado a um SQL específico, a uma sessão, ou a todas as sessões que se conectarem ao banco de dados : não há, por parte do RDBMS, nenhuma opção de trace a nível de instância nem a nível de servidor. Não haverá, portanto, a necessidade de restart do servidor, nem nada do tipo. A nível de database, os únicos parâmetros exigidos são o TIMED_STATISTICS=TRUE, os parâmetrso de dump apontando para um filesystem/disco com bastante espaço livre e o max_dump_file_size setado para um valor o mais alto possível. Evidentemente : a) traces do tipo podem interferir SERIAMENTE com a performance, já que tipicamente um database Oracle de produção processa centenas de SQLs a cada curto período : assim sendo, JAMAIS vc ativará o trace num período de uso comum, mas sim num período/dia escolhido aonde haja o menor número de utilizadores, ou até mesmo (preferencialmente) só o usuário testador b) os arquivos gerados por esse trace tendem a crescer muito, então o servidor deve ser Preparado, liberando-se o máximo de espaço possível (ou mesmo adicionando-se espaço extra) c) deve ser levantado se o ambiente usa algum tipo de POOL DE CONEXÕES, aonde a aplicação não cria uma sessão para cada conexão, mas sim cada comando enviado ao database por cada conexão são atendidos por uma sessão pré-criada pelo pool : se isso for verdadeiro, o pessoal aí terá que instrumentar/identificar a sessão, com um dos mecanismo de end-to-end trace : veja http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html para um exemplo d) deve ser levantada a comunicação com o database, no sentido de checar se cada tela do aplicativo abre uma conexão ou não, se é viável indicar uma sessão específica para os testes... Isso é no sentido de facilitar a sessão a tracejar, Evtando trace a nível de database que via de regra é por demais intrusivo []s Chiappa OBS : como referência, indico além da documentação Oracle (em especial o manual de Tuning), também os links http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php , http://www.databasejournal.com/features/oracle/article.php/3469891/Collecting-Oracle-Extended-Trace-10046-event.htm , http://www.dicka.eclipse.co.uk/oracle_trace_event_10046_notes.htm e The Oracle Instructor: Oracle TRACE EVENT 10046 http://shoaib-dba.blogspot.com.br/2012/06/oracle-trace-event-10046.html The Oracle Instructor: Oracle TRACE EVENT 10046 http://shoaib-dba.blogspot.com.br/2012/06/oracle-trace-event-10046.html Visualizar em shoaib-dba.blogspot.com.br http://shoaib-dba.blogspot.com.br/2012/06/oracle-trace-event-10046.html Visualização pelo Yahoo
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
Boa tarde Angelo, Na aplicação A quando esta executando a transação de gravação só executa o acesso a B em uma condição especifica. Logo quando se passava pela execução da stored procedure via DBLINK para a B o processo sempre era concluído com sucesso. O problema somente ocorre quando a stored procedure é executada. A minha dúvida é tecnicamente falando o Oracle consegue controlar sem problemas esta via de mão dupla, onde a aplicação A faz o acesso a B e na mesma transação a B faz acesso a A? Ao estabelecer esta comunicação entre as aplicações é somente um canal que é aberto? Ou cada comando trata de forma isolada a comunicação entre ambas aplicações? Abraços Em 10 de junho de 2014 17:14, angelo angelolis...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Vamos lá, bora tentar matar mais essa charada Pergunta em cima da pergunta... Na aplicação A, quando o procedimento que faz a leitura da tabela, ela vai sempre ao DBLINK para acessar também base B? Ou não necessariamente, podendo variar tipo, pode ir ou não? O fato de ter alterado, se nao mexeram no DBLINK, teoricamente nao deveria alterar em nada.. Quanto ao processo do gravação, acho que o Oracle não interfere não, até porque o controle ta dentro do codigo, na transação aberta tudo vai ser processado como se fosse uma coisa só.. e a conta fecha, quando vier o commit encerrando o processo. Bom, to dando pitaco sem testar.. O que se pode fazer é checar a conectividade, se o DBLINK está de pé (se bem que se nao tivesse daria erro na primeiro select bla, bla from tabela@B ) no momento da execução.. 2014-06-10 10:04 GMT-03:00 Marcos Antônio de Araújo maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Pessoal, Agradeço demais as explanações feitas por vocês afim de me direcionar para a solução do problema. Acabou que ontem a tarde detectamos o real motivo do problema e como vocês mesmo já haviam dito, me parece ter sido implementação de código. Porém, é a segunda vez que ocorre e gostaria de ver se você saberiam me explicar o que ocorre tecnicamente no Oracle. *CASO* Temos 2 aplicações que fazem interoperabilidade através de stored procedure, durante o processo de gravação de registros. A *aplicação A* abre uma transação e executa diversos INSERTs/UPDATEs na própria base de dados e em um determinado momento executa uma stored procedure através de um DBLINK que faz diversas validações na base de dados da *aplicação B*. Tudo funcionava perfeitamente até que um dia foi implementado neste procedimento uma leitura de uma tabela da *aplicação A *novamente e a partir deste dia começou a ocorrer o problema citado, onde a transação não retorna erro mas não grava nenhum dado na base da *aplicação A*. 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? Abraços, Marcos Em 9 de junho de 2014 09:19, Marcos Antônio de Araújo maac...@gmail.com escreveu: Chiappa, Valeu demais esta sua explicação. Vou sentar com as chefias aqui e repassar tudo isto afim de detectarmos o problema. Obrigado! Abraços, Marcos Em 9 de junho de 2014 00:06, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: No RDBMS Oracle, o trace de SQL pode ser aplicado a um SQL específico, a uma sessão, ou a todas as sessões que se conectarem ao banco de dados : não há, por parte do RDBMS, nenhuma opção de trace a nível de instância nem a nível de servidor. Não haverá, portanto, a necessidade de restart do servidor, nem nada do tipo. A nível de database, os únicos parâmetros exigidos são o TIMED_STATISTICS=TRUE, os parâmetrso de dump apontando para um filesystem/disco com bastante espaço livre e o max_dump_file_size setado para um valor o mais alto possível. Evidentemente : a) traces do tipo podem interferir SERIAMENTE com a performance, já que tipicamente um database Oracle de produção processa centenas de SQLs a cada curto período : assim sendo, JAMAIS vc ativará o trace num período de uso comum, mas sim num período/dia escolhido aonde haja o menor número de utilizadores, ou até mesmo (preferencialmente) só o usuário testador b) os arquivos gerados por esse trace tendem a crescer muito, então o servidor deve ser Preparado, liberando-se o máximo de espaço possível (ou mesmo adicionando-se espaço extra) c) deve ser levantado se o ambiente usa algum tipo de POOL DE CONEXÕES, aonde a aplicação não cria uma sessão para cada conexão, mas sim cada comando enviado ao database por cada conexão são atendidos por uma sessão pré-criada pelo pool : se isso for verdadeiro, o pessoal aí terá que instrumentar/identificar a sessão, com um dos mecanismo de end-to-end trace : veja http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html para um exemplo d) deve ser levantada a comunicação com o database, no sentido de checar se cada tela do aplicativo abre
Re: [oracle_br] Problema de Comunicação entre Aplicação e BD
Fábio, Obrigado pelo retorno. Farei isto agora e caso tenha alguma dúvida volto a pedir ajuda. Att, Marcos Antônio de Araújo Analista de Sistema - SOF/PBH PRODABEL (31) 3277-4177 / 4425 Em 8 de junho de 2014 16:13, Fabio Prado fbifa...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos, O modo mais fácil de identificar se algo está sendo executado (ou falhando, talvez por falta de privilégios... erro muito comum) é habilitar a auditoria padrão do Oracle. Leia o artigo http://www.fabioprado.net/2013/01/auditoria-x-performance-no-oracle.html que você vai entender o que é essa auditoria e encontrará o link de outro artigo onde vc aprenderá a habilitar e consultar os registros de auditoria. []s *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle Em 8 de junho de 2014 09:37, maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Pessoal, Eu sou analista/desenvolvedor e estamos atualmente passando por um problema extremamente sério em relação a comunicação entre aplicação e BD aqui na empresa. Este sistema possui diversas funcionalidades, algumas extremamente simples e outras muito complexas, no que diz respeito a inserção ou atualização de dados no BD. Dentre estas funcionalidades há uma que possui 53 comandos de atualização de dados (Insert e Update) que pela LOG gerada pela aplicação ocorre todos com sucesso e o BD não retorna nenhuma mensagem e nenhum código de erro desta transação. Porém, após concluído o processo quando fazemos select para verificar os registros cadastrados verificamos que nada foi gravado no BD. O mais preocupante é que repeti este mesmo teste 8 vezes seguidas e em 2 momentos os registros foram efetivados no BD. Eu como leigo no que diz respeito a gerenciamento de BD gostaria de saber de vocês algumas dicas do que poderia ser feito para conseguirmos detectar o que pode estar acontecendo de anormalidade, uma vez que esta aplicação já roda a 12 anos sem este tipo de problema e segundo os DBA's aqui da empresa não houve nenhum tipo de alteração no servidor e nem na instância Oracle deste sistema. A versão do oracle utilizada é:* Oracle Database 10g Release 10.2.0.1.0* Caso alguém tenha algumas dicas para que possamos tomar algumas ações para tentar entender e sanar o problema, peço o favor de me responder. Att, Marcos Antônio de Araújo Analista de Sistema - SOF/PBH PRODABEL (31) 3277-4177 / 4425
Re: [oracle_br] Problema de Comunicação entre Aplicação e BD
Boa noite Ângelo, Tenho o fonte sim e gerei uma LOG do que a aplicação envia ao BD, são 53 comandos e ao final é dado COMMIT, exceto quando a aplicação recebe a indicação do BD de que houve algum erro. Não foi feita nenhuma manutenção na aplicação e por este motivo acredito que a única forma de compreender é conseguir a LOG gerada no BD. Obrigado! Em 8 de junho de 2014 20:58, angelo angelolis...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos, Vc tem acesso aos fontes? Segue o artigo do Fabio e faz um teste de mesa no codigo SQL...pra ver se ele realmente está funcionando. Pois às vezes um detalhe minúsculo ou uma linha comentada muda toda a história.. A aplicação que acessa o BD sofreu alguma atualização recente ? Pelo que vc descreve, parece mais que está faltando commit, que é trivial e ao mesmo tempo estranho porque se ja funciona ha anos, o comportamento nao deveria mudar assim... 2014-06-08 16:13 GMT-03:00 Fabio Prado fbifa...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Marcos, O modo mais fácil de identificar se algo está sendo executado (ou falhando, talvez por falta de privilégios... erro muito comum) é habilitar a auditoria padrão do Oracle. Leia o artigo http://www.fabioprado.net/2013/01/auditoria-x-performance-no-oracle.html que você vai entender o que é essa auditoria e encontrará o link de outro artigo onde vc aprenderá a habilitar e consultar os registros de auditoria. []s *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle Em 8 de junho de 2014 09:37, maac...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Pessoal, Eu sou analista/desenvolvedor e estamos atualmente passando por um problema extremamente sério em relação a comunicação entre aplicação e BD aqui na empresa. Este sistema possui diversas funcionalidades, algumas extremamente simples e outras muito complexas, no que diz respeito a inserção ou atualização de dados no BD. Dentre estas funcionalidades há uma que possui 53 comandos de atualização de dados (Insert e Update) que pela LOG gerada pela aplicação ocorre todos com sucesso e o BD não retorna nenhuma mensagem e nenhum código de erro desta transação. Porém, após concluído o processo quando fazemos select para verificar os registros cadastrados verificamos que nada foi gravado no BD. O mais preocupante é que repeti este mesmo teste 8 vezes seguidas e em 2 momentos os registros foram efetivados no BD. Eu como leigo no que diz respeito a gerenciamento de BD gostaria de saber de vocês algumas dicas do que poderia ser feito para conseguirmos detectar o que pode estar acontecendo de anormalidade, uma vez que esta aplicação já roda a 12 anos sem este tipo de problema e segundo os DBA's aqui da empresa não houve nenhum tipo de alteração no servidor e nem na instância Oracle deste sistema. A versão do oracle utilizada é:* Oracle Database 10g Release 10.2.0.1.0* Caso alguém tenha algumas dicas para que possamos tomar algumas ações para tentar entender e sanar o problema, peço o favor de me responder. Att, Marcos Antônio de Araújo Analista de Sistema - SOF/PBH PRODABEL (31) 3277-4177 / 4425
Re: [oracle_br] Re: Problema de Comunicaç ão entre Aplicação e BD
Boa noite Chiappa, O que estamos tentando rastrear é algo como você descreveu mesmo, pois como utilizamos uma framework desenvolvida por terceiros e conhecemos o funcionamento conceitual dela, mas como você mesmo citou pode ser algo mal implementado e que não esteja tratando um retorno de erro gerado na transação. Através do DEBUG e TRACE na aplicação não foi possível detectar nenhuma anormalidade e por isto acho que valeria a pena ter uma LOG gerada do lado do BD. Vou conversar com o pessoal para que façamos o que você citou utilizando esta opção de TRACE+TKPROF. Desculpe se esta pergunta for óbvia, mas como citei não sou especialista em BD, o TRACE+TKPROF é por instância ou geral? Para ativar precisaremos reiniciar o servidor? Obrigado pelos esclarecimentos. Att, Marcos Antônio de Araújo Analista de Sistema - SOF/PBH PRODABEL (31) 3277-4177 / 4425 Em 8 de junho de 2014 21:19, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Marcos, mesmo sendo (como é, mesmo) tão antiga, bugada e problemática essa versão 10.2.0.1, eu reporto como *** MINÚSCULA ***, praticamente NULA, desprezível mesmo, a chance do banco de dados ter uma falha tão grosseira que faça ele apagar ou não registrar, DMLs que foram executados com sucesso e comitados, okdoc ?? Isso é básico demais pra acontecer Pra mim o que está havendo aí é : a) há algum erro acontecendo em algum ponto da transação (seja já na hora do INSERT ou do UPDATE, seja na hora de encerrar com commit) e o Aplicativo está MASCARANDO *** o erro, engolindo-o sem aviso : digamos, há um EXCEPTION WHEN OTHERS null; se a programação for em PL/SQL, ou simplesmente o próprio aplicativo (via programação na linguagem/tool que estiver usando) ignora o erro ... Por mais estranho que pareça, isso é LONGE de ser impossível, infelizmente já vi muito código porquinho do tipo, e nada impede que a situação de erro passou a acontecer há pouco (digamos, espaço em disco diminuiu o que antes não acontecia tanto), por isso a situação de engolir o erro não foi notada antes OU b) é um erro de lógica , seja um IF, uma trigger, ou algo programado do tipo, que em alguns casos faz o aplicativo , digamos, não passar pelo trecho que faz o COMMIT, ou então cair numa linha que faz o ROLLBACK : essa condição , por causa dos dados, não era verdadeira antes e só recentemente os dados que entraram fizeram a condição ser verdadeira e o bug aparecer... === SE vc tiver o código-fonte Atualizado e 100% confiável dessa aplicação, seria realmente um trabalho de DEBUG , provavelmente introduzindo-se ou ativando a Instrumentação que puder Caso não possa haver debug, aí Qualquer um dos dos dois casos, vc pega OU fazendo um TRACE+TKPROF (o ideal, já que assim vc não perde nada), OU se não for possível isso vc pode habilitar ao menos as opções completas de Auditoria, para que fique registrado os comandos que foram enviados []s Chiappa
