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 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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > >
