L'autre jour chez un de mes clients, on nous avait dit qu'on avait quelques problèmes avec des sessions gelées au moment de déposer un fichier BLOB sur la base de données en passant par une connexion sécurisée.
Base de données : 11.2.0.4
Système d'exploitation de la Bd : Solaris 10
Client Oracle : 11g (11.2.0.4) sur Windows Server 64 bits
Toutes les autres activités en TCPS se faisaient sans problème, mais c'était juste au moment d'essayer de déposer un fichier sur la base de données qu'on avait le problème.
En activant le trace sur le client 11g au niveau du "sqlnet.ora" (Voir les paramètres ci-dessous)
TRACE_UNIQUE_CLIENT=ON
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=C:\Temp
TRACE_FILE_CLIENT=TRC_CLT
TRACE_FILELEN_CLIENT=40960
TRACE_FILENO_CLIENT=2
TRACE_TIMESTAMP_CLIENT=ON
ADR_BASE=OFF
DIAG_ADR_ENABLED=OFF
J'ai demandé au responsable de lancer un autre test afin d'obtenir le fichier de trace.
Une fois obtenu, en feuillant dans le fichier de trace je me suis aperçu que la lecture du wallet se faisait sans problème et que l'établissement de la connexion sécurisée entre le serveur et client se faisait aussi, cependant j'ai remarqué aussi les lignes ci-dessous, en particulier de la ligne en surbrillance, qui montre un message d'erreur :
...
[000001 16-OCT. -2018 11:40:15:736] ntt2err: exit[000001 16-OCT. -2018 11:40:15:736] nttrd: socket 712 had bytes read=0
[000001 16-OCT. -2018 11:40:15:736] nttrd: exit
[000001 16-OCT. -2018 11:40:15:736] [Raw read] length = 0
[000001 16-OCT. -2018 11:40:15:736] <read error -6993>
[000001 16-OCT. -2018 11:40:15:736] read 0 bytes. cicerr = -2130640891
[000001 16-OCT. -2018 11:40:15:736] read 0 bytes. error = 28861
[000001 16-OCT. -2018 11:40:15:736] nzos_Read: exit
[000001 16-OCT. -2018 11:40:15:736] ntznzosread: encountered "wouldblock" error
[000001 16-OCT. -2018 11:40:15:736] ntctst: size of NTTEST list is 1 - not calling poll
[000001 16-OCT. -2018 11:40:15:736] sntseltst: Testing for DATA on socket 712
[000001 16-OCT. -2018 11:40:16:018] sntseltst: FOUND: read request on socket 712
[000001 16-OCT. -2018 11:40:16:018] nzos_Read: entry
[000001 16-OCT. -2018 11:40:16:018] reading 8208 bytes
[000001 16-OCT. -2018 11:40:16:018] nttrd: entry
[000001 16-OCT. -2018 11:40:16:018] nttrd: socket 712 had bytes read=5
[000001 16-OCT. -2018 11:40:16:018] nttrd: exit
[000001 16-OCT. -2018 11:40:16:018] [Raw read] length = 5
...
Le détail sur le code d'erreur relié selon le lien ci-dessous dit :
https://docs.oracle.com/cd/E16764_01/core.1111/e10113/chapter_ssl_messages.htm
SSL-28861: SSL connection would block
Cause: This error is informational. It should never be communicated to the user.
Action: Enable tracing and retry the connection to determine the exact cause of the error. Contact Oracle customer support if needed.Level: 00001
Type: ERROR
Impact: Other
Type: ERROR
Impact: Other
Dans ce cas, et avec l'information obtenue, je vais soir sur le site de support Oracle j'ai trouvé une note qui parle d'un problème similaire mais avec le client 10g, lequel supposément est corrigé avec le client 11g (Note : 1298611.1)
Pour essayer de voir si c'est le même cas, et afin de tester la recommandation d'Oracle malgré que ma version est 11g, je suis allé modifier le tnsnames du client en ajoutant le paramètre SEND_BUF_SIZE, afin d'avoir quelque chose comme ça:
MYBD.WORLD=(DESCRIPTION =(SEND_BUF_SIZE=2557500)(ADDRESS = (PROTOCOL = TCPS)(HOST = myserver.domain )(PORT = 1822))(ADDRESS = (PROTOCOL = TCP)(HOST = myserver.domain)(PORT = 1821))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = mybd.domain)(SECURITY= (SSL_SERVER_CERT_DN="CN=XXXXXX,OU=YYYYYY,O=ZZZ,L=ZZZZ,ST=ZZZ,C=CA"))))
Sur le serveur de base de données j'ai ajouté aussi une modification additionnelle sur le listener sécurisé qui dessert ladite base de données, dans ce cas-là, j'ai ajouté le paramètre RECV_BUF_SIZE
L_MYBD_SSL =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL=IPC)(KEY=EXTPROC1822))
(ADDRESS = (PROTOCOL=TCPS)(HOST=myserver.domain)(PORT=1822))
(RECV_BUF_SIZE=2557500))
)
)
C'est important de repartir le listener, pas juste un RELOAD, mais vraiment un STOP/START.
En faisant une autre fois les test, le problème semble corrigé. Le dépôt des BLOB's semble se faire sans problème cette fois à travers d'une connexion sécurisée.
Il faut remarquer que les valeurs utilisées dépendront bien sûr de vos configurations et comme vous savez, Oracle même ne donne pas une recommandation sur les valeurs. Donc, il faudrait calculer la bonne valeur afin de ne pas impacter le trafic sur le réseau non plus.
