Re: [oracle_br] Re: ORA-03113

2014-09-09 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Tá, mas e o resto das infos : por exemplo, há quanto tempo a sessão já estava 
conectada quando cai ? É sempre mais ou menos no mesmo ponto da 
aplicação/consulta (provavelmente no mesmo SQL) ? É reproduzível, ou só 
acontece de vez em quando ? Nas mesmas máquinas, ou não ? Essas coisas podem 
ajudar a realmente direcionar a pesquisa para fatores externos ao database ou 
não 
 Outra dica certeira : instala e deixe executando por um período razoavelmente 
longo o utilitário da Oracle chamado OSWatcher... Ele fica em background 
constantemente executando comandos do SO como iostat e netstat, aí qualquer 
perda de pacotes, diferença de performance no envio, etc, vc acaba pegando... 
Inclusive, pode ser Extremamente Útil pro teu pessoal de rede vc comparar o 
output do oswatcher numa lâmina/servidor/whatever OK com esse aí que está 
Problemático.
 E Óbvio, imagino que o teu sysadmin já pegou os erros via ifconfig, já olhou 
os logs do sistema, o teu pessoal de Rede já usou as tools deles para teste do 
hardware de rede (desde um simples ftp monitorado até tools tipo cacti, o que 
for)...
 
  []s
  
Chiappa

Re: [oracle_br] Re: ORA-03113

2014-09-09 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
Obrigado Chiappa.
Dentre as inúmeras recomendações que você citou, tinha levantado o firewall e 
os PROFILES, mas nada de anormal nem de configuração foi encontrado.

* a conexao eh dedicada
* OLTP
* O oracle client é 11gr2 32 bits
...
...

Enfim, no final desta tarde percebemos um problema de perda de pacotes com a 
lâmina blade onde se encontra o servidor do banco. Tal lâmina foi migrada em 
30/08, e possivelmente está com alguma incosistência de configuração.



Em seg, 8/9/14, jlchia...@yahoo.com.br [oracle_br] 
 escreveu:

 Assunto: [oracle_br] Re: ORA-03113
 Para: oracle_br@yahoogrupos.com.br
 Data: Segunda-feira, 8 de Setembro de 2014, 18:36
 
 
  
 
 
 
   
 
 
 
   
   
   Bom, pra quem eventualmente esteja na mesma
 situação poder te ajudar, Please nos dê os detalhes : vc
 usa conexões dedicadas ou mts/shared ? Tem pool de conexão
 na parada ? Há middleware (tipo ODBC, JDBC) envolvido ?
 Quando os teus usuários recebem a desconexão, eles estão
 usando qual programa cliente ? É uma sessão tipo oltp,
 onde muitos usuários executam sqls curtos, ou é um
 processamento batch ? Há quanto tempo a sessão que cai
 estava inativa, e há quanto tempo estava logada ? Conseguiu
 identificar qual SQL/qual ponto da Aplicação que causa a
 desconexão ?
  O que a gente pode dizer de
 imediato é que estas mensagens : 
  
  TNS-12535: TNS:operation timed out
  
  e
  
  TNS-00505: Operation timed out
  
  bem Claramente indicam que
 a conexão está sendo derrubada pela camada de rede (fosse
 crash do processo shadow normalmente a msg seria outra),
 então eu também Recomendo Fortemente que sejam
 investigadas as possibilidades de PROFILE especificando
 tempo de conexão, firewall/antivirus/antimalware/filtro de
 pacotes  (tanto nas máquinas-clientes quanto nos
 servidores envolvidos)  E vale Também fazer um check
 profundo no SO destas máquinas : não é impossível, por
 exemplo, Windows desligando a placa de rede para poupar
 energia
  
  []s
  
    Chiappa
    
    OBS : nessa
 investigação, provavelmente vão ser muito úteis as notas
 metalink : "Troubleshooting ORA-03113: end-of-file on
 communication channel Errors in Campus Solutions
 Application" (Doc ID 1192684.1), "Master Note:
 Troubleshooting ORA-03113" (Doc ID 1506805.1) e
 "DIAGNOSING ORA-3113 ERRORS" (Doc ID 1020463.6)
 
 
 
  
 
 
 
 
 
 
 #yiv8130855565 #yiv8130855565 --
   #yiv8130855565ygrp-mkp {
 border:1px solid #d8d8d8;font-family:Arial;margin:10px
 0;padding:0 10px;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp hr {
 border:1px solid #d8d8d8;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp #yiv8130855565hd {
 color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
 0;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp #yiv8130855565ads {
 margin-bottom:10px;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp .yiv8130855565ad {
 padding:0 0;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp .yiv8130855565ad p {
 margin:0;}
 
 #yiv8130855565 #yiv8130855565ygrp-mkp .yiv8130855565ad a {
 color:#ff;text-decoration:none;}
 #yiv8130855565 #yiv8130855565ygrp-sponsor
 #yiv8130855565ygrp-lc {
 font-family:Arial;}
 
 #yiv8130855565 #yiv8130855565ygrp-sponsor
 #yiv8130855565ygrp-lc #yiv8130855565hd {
 margin:10px
 0px;font-weight:700;font-size:78%;line-height:122%;}
 
 #yiv8130855565 #yiv8130855565ygrp-sponsor
 #yiv8130855565ygrp-lc .yiv8130855565ad {
 margin-bottom:10px;padding:0 0;}
 
 #yiv8130855565 #yiv8130855565actions {
 font-family:Verdana;font-size:11px;padding:10px 0;}
 
 #yiv8130855565 #yiv8130855565activity {
 
background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}
 
 #yiv8130855565 #yiv8130855565activity span {
 font-weight:700;}
 
 #yiv8130855565 #yiv8130855565activity span:first-child {
 text-transform:uppercase;}
 
 #yiv8130855565 #yiv8130855565activity span a {
 color:#5085b6;text-decoration:none;}
 
 #yiv8130855565 #yiv8130855565activity span span {
 color:#ff7900;}
 
 #yiv8130855565 #yiv8130855565activity span
 .yiv8130855565underline {
 text-decoration:underline;}
 
 #yiv8130855565 .yiv8130855565attach {
 clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
 0;width:400px;}
 
 #yiv8130855565 .yiv8130855565attach div a {
 text-decoration:none;}
 
 #yiv8130855565 .yiv8130855565attach img {
 border:none;padding-right:5px;}
 
 #yiv8130855565 .yiv8130855565attach label {
 display:block;margin-bottom:5px;}
 
 #yiv8130855565 .yiv8130855565attach label a {
 text-decoration:none;}
 
 #yiv8130855565 blockquote {
 margin:0 0 0 4px;}
 
 #yiv8130855565 .yiv8130855565bold {
 font-family:Arial;font-size:13px;font-weight:700;}
 
 #yiv8130855565 .yiv8130855565bold a {
 text-decoration:none;}
 
 #yiv8130855565 dd.yiv8130855565last p a {
 font-family:Verdana;font-weight:700;}
 
 #yiv8130855565 dd.yiv8130855565last p span {
 margin-right:10px;font-family:Verdana;font-weight:700;}
 
 #yiv8130855565 dd.yiv8130855565last p
 span.yiv8130855565yshor

Re: [oracle_br] Re: ORA-03113: fim de arquivo no canal de comunicação

2007-01-10 Por tôpico ednagobbi

Bom dia!

Coloque no init o parametro:
alter session set events '10181 trace name context forever, level 1'



Espero que ajude.

Edna


-- Mensagem original --

>Então é Metalink na certa.
>Depois, caso ache alguma solução, poste aqui para enriquecer o grupo.
>Abraço.
>
>Em 15/12/06, Ryan <[EMAIL PROTECTED]> escreveu:
>>
>>   Gustavo,
>>
>> O cursor_sharing da base já estava EXACT.
>> De qualquer forma, obrigado!
>> Um abraço,
>>
>> Ryan
>>
>> --- Em oracle_br@yahoogrupos.com.br ,
>> "Gustavo Venturini de Lima"
>> <[EMAIL PROTECTED]> escreveu
>> >
>> > Ryan, qual sua configuração de cursor_sharing nesta base de dados?
>> > Se for similar ou force, experimente colocar para EXACT.
>> > Tive este problema na 10.2, que inclusive foi corrigida no patch
>> 5162241.
>> >
>> > []'s
>> >
>> > Em 15/12/06, Ryan <[EMAIL PROTECTED]> escreveu:
>>
>> > >
>> > > Senhores,
>> > >
>> > > Ao executar uma consulta boba num servidor Oracle 9.2.0.4 com RH
>> 4,
>> > > recebemos o seguinte erro:
>> > >
>> > > SELECT t.coluna1, t.coluna2, t.coluna3, t.coluna4, t.coluna5
>> > > FROM tabela t
>> > > WHERE (t.coluna1 = 901511) OR (t.coluna1 = 300750);
>> > > *
>> > > ERRO na linha 1:
>> > > ORA-03113: fim de arquivo no canal de comunicação
>> > >
>> > > Usando o IN, acontece o mesmo. Com UNION a consulta roda
>> normalmente.
>> > >
>> > > No alert.log encontramos o seguinte trecho:
>> > >
>> > > Errors in
>> > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_8155.trc:
>> > >
>> > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
>> > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
>> > >
>> > > Fri Dec 15 13:38:34 2006
>> > >
>> > > Errors in
>> > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_6260.trc:
>> > >
>> > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
>> > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
>> > >
>> > > Fizemos um teste deletando as estatísticas da tabela e
>> estranhamente
>> > > a consulta passou a funcionar.
>> > >
>> > > Porém, precisamos das estatísticas. Alguém pode dar uma luz?
>> > >
>> > > Abraços,
>> > >
>> > > Ryan
>> > >
>> > >
>> > >
>> >
>> >
>> > [As partes desta mensagem que não continham texto foram removidas]
>> >
>>
>>  
>>
>
>
>[As partes desta mensagem que não continham texto foram removidas]
>
>


Edna Gobbi




Re: [oracle_br] Re: ORA-03113: fim de arquivo no canal de comunicação

2006-12-20 Por tôpico Duilio Bruniera Junior
Altere o parametro "_complex_view_merging" para false e tente executar a
query !

SQL> alter system set "_complex_view_merging" = false scope = spfile;
SQL> shutdown
SQL> startup



2006/12/15, Gustavo Venturini de Lima <[EMAIL PROTECTED]>:
>
>   Então é Metalink na certa.
> Depois, caso ache alguma solução, poste aqui para enriquecer o grupo.
> Abraço.
>
> Em 15/12/06, Ryan <[EMAIL PROTECTED] >
> escreveu:
> >
> > Gustavo,
> >
> > O cursor_sharing da base já estava EXACT.
> > De qualquer forma, obrigado!
> > Um abraço,
> >
> > Ryan
> >
> > --- Em oracle_br@yahoogrupos.com.br 
> >  rupos.com.br>,
>
> > "Gustavo Venturini de Lima"
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Ryan, qual sua configuração de cursor_sharing nesta base de dados?
> > > Se for similar ou force, experimente colocar para EXACT.
> > > Tive este problema na 10.2, que inclusive foi corrigida no patch
> > 5162241.
> > >
> > > []'s
> > >
> > > Em 15/12/06, Ryan <[EMAIL PROTECTED]> escreveu:
> >
> > > >
> > > > Senhores,
> > > >
> > > > Ao executar uma consulta boba num servidor Oracle 9.2.0.4 com RH
> > 4,
> > > > recebemos o seguinte erro:
> > > >
> > > > SELECT t.coluna1, t.coluna2, t.coluna3, t.coluna4, t.coluna5
> > > > FROM tabela t
> > > > WHERE (t.coluna1 = 901511) OR (t.coluna1 = 300750);
> > > > *
> > > > ERRO na linha 1:
> > > > ORA-03113: fim de arquivo no canal de comunicação
> > > >
> > > > Usando o IN, acontece o mesmo. Com UNION a consulta roda
> > normalmente.
> > > >
> > > > No alert.log encontramos o seguinte trecho:
> > > >
> > > > Errors in
> > > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_8155.trc:
> > > >
> > > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
> > > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
> > > >
> > > > Fri Dec 15 13:38:34 2006
> > > >
> > > > Errors in
> > > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_6260.trc:
> > > >
> > > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
> > > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
> > > >
> > > > Fizemos um teste deletando as estatísticas da tabela e
> > estranhamente
> > > > a consulta passou a funcionar.
> > > >
> > > > Porém, precisamos das estatísticas. Alguém pode dar uma luz?
> > > >
> > > > Abraços,
> > > >
> > > > Ryan
> > > >
> > > >
> > > >
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



Re: [oracle_br] Re: ORA-03113: fim de arquivo no canal de comunicação

2006-12-16 Por tôpico Gustavo Venturini de Lima
Então é Metalink na certa.
Depois, caso ache alguma solução, poste aqui para enriquecer o grupo.
Abraço.

Em 15/12/06, Ryan <[EMAIL PROTECTED]> escreveu:
>
>   Gustavo,
>
> O cursor_sharing da base já estava EXACT.
> De qualquer forma, obrigado!
> Um abraço,
>
> Ryan
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Gustavo Venturini de Lima"
> <[EMAIL PROTECTED]> escreveu
> >
> > Ryan, qual sua configuração de cursor_sharing nesta base de dados?
> > Se for similar ou force, experimente colocar para EXACT.
> > Tive este problema na 10.2, que inclusive foi corrigida no patch
> 5162241.
> >
> > []'s
> >
> > Em 15/12/06, Ryan <[EMAIL PROTECTED]> escreveu:
>
> > >
> > > Senhores,
> > >
> > > Ao executar uma consulta boba num servidor Oracle 9.2.0.4 com RH
> 4,
> > > recebemos o seguinte erro:
> > >
> > > SELECT t.coluna1, t.coluna2, t.coluna3, t.coluna4, t.coluna5
> > > FROM tabela t
> > > WHERE (t.coluna1 = 901511) OR (t.coluna1 = 300750);
> > > *
> > > ERRO na linha 1:
> > > ORA-03113: fim de arquivo no canal de comunicação
> > >
> > > Usando o IN, acontece o mesmo. Com UNION a consulta roda
> normalmente.
> > >
> > > No alert.log encontramos o seguinte trecho:
> > >
> > > Errors in
> > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_8155.trc:
> > >
> > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
> > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
> > >
> > > Fri Dec 15 13:38:34 2006
> > >
> > > Errors in
> > > file /oracle/product/9.2.0/admin/ALPHA/udump/alpha_ora_6260.trc:
> > >
> > > ORA-07445: exception encountered: core dump [evaopn2()+2421]
> > > [SIGSEGV] [Address not mapped to object] [0x0] [] []
> > >
> > > Fizemos um teste deletando as estatísticas da tabela e
> estranhamente
> > > a consulta passou a funcionar.
> > >
> > > Porém, precisamos das estatísticas. Alguém pode dar uma luz?
> > >
> > > Abraços,
> > >
> > > Ryan
> > >
> > >
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]