!
!
Info TAFORA
!
Méthodes Conseil
!
Mon credo Oracle
!
Nouveautés
!
Expertise technique
!
Fiches Techniques
!
Séminaires
Technique
FAQ
Domaines
DBA
Tuning
PL/SQL
Divers
Varia
Liens
Contact
TAFORA
Radu
Mail
ora-3113, ora-3114 (1/12/2003)
Parmi les applications ORACLE dont on dispose, quelques unes provoquent (sur certaines bases) un nombre très important de déconnexions ORA-3113 et ORA-3114.
Qui provoque ORA-3113 ?
ORA-3113 (end-of-file on communication channel) est une erreur plutôt générique qui indique que le process client a perdu le contact avec le process serveur. En règle générale il signifie que le process serveur est mort. Si un process background est mort également, ORA-3113 est accompagné de ORA-3114. L'analyse des logs (client et serveur) est d'une grande utilité dans ce cas (en fait, c'est utile dans tous les cas). Les paragraphes suivants montrent une liste non exhaustive des causes que j'ai rencontrés :

Permissions des utilisateurs des exécutables Oracle
Généralement, un chmod 7755 $ORACLE_HOME/bin/oracle suffit.

Valeur invalide processes dans init.ora, si la valeur est incompatible avec les parameters Os SEMMSL and SEMMNS
Reduire le nombre de processes ou modifier SEMMSL et SEMMNS. En regle generale, SEMMSL > 10 + max(process rencontrés)

Le shared_pool_size est trop petit.
Agrandissez legerement le shared pool (25%) et reesayez.

timed_statistics=true.
Si timed_statistics est à true, essayeze-le à FALSE.

Un fichier essaye de s'agrandir à plus de 2 gigaOctets.
Beurk !

Packages invalides
Recompilez et vérifiez que les packages sont bien compilés et valides.
Analyser la source du probleme
[Oracle9i Database Performance Guide and Reference]
Si le problème vient du réseau, tracez-le ! Il est important de dépister si les erreurs se trouvent dans les traces client, dans les traces serveur, ou dans les deux.
Erreurs uniquement dans les traces Client
Le problème provient du serveur.
Erreurs uniquement dans les traces serveur et/ou listener
Le problème provient du client.
Erreurs dans les traces client ET serveur
Le réseau est fautif.
MTS? (shared servers)
C'est plus complexe à dépister ;- :
SDU, MTU (comment les modifier ?)
Tnsnames.ora
. . . = 
  (DESCRIPTION = 
    (SDU=1450)(TDU=1500) 
    (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = . . . )(PORT = 1521)) 
    ) 
    (CONNECT_DATA = 
      (SERVICE_NAME = . . .) 
      (SID = . . .) 
    ) 
  )

listener.ora: 
. . .
    (SID_DESC = 
      (SDU=1450) 
      (TDU=1500) 
      (GLOBAL_DBNAME = . . .) 
      (ORACLE_HOME = . . . ) 
      (SID_NAME = . . . ) 
    )

La théorie dit que MTU (maximum transmission unit) = SDU (session data unit)=TDU et SDU devrait être un multiple du paquet transmis (1500 sur Ethernet) ce qui détermine un MTU de minimum 1500 MAIS:
Du fait de l'entête lui-meme (IP+TCP+SQL*Net c.a.d. 20+20+10 octets), la taille optimale du SDU est MTU-50.

Si Oracle > 7.3.3, MTU et SDU peuvent etre modifiés pour MTS (shared server).
D’où je sors le 1500 ? D'ici:
[oracle@jaguar oracle]$ netstat -i
Kernel Interface table
Iface     MTU Met   RX-OK RX-ERR RX-DRP RX-OVR   TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0     1500   0 2354550      0      0      1 1713348      0      0      0 BMRU
lo      16436   0   27269      0      0      0   27269      0      0      0 LRU
[oracle@jaguar oracle]$
tcp.nodelay
tcp.nodelay = true dans sqlnet.ora (client ET serveur) force TCP d'émettre le paquet sans attendre.
Copyright © 1998-2002 Radu Caulea, TAFORA MAJ 06/11/2006 !
Commentaires et suggestions radu[CHEZ]tafora.fr