Bonjour,
 
Dans l'entreprise dans laquelle je fais actuellement mon stage il y a un probleme assez bizard ..
De temps en temps, sur les serveurs de production (aie!) il y a des sessions qui se "lock", c'est à dire que les sessions se mettent à attendre l'une sur l'autre... En gros toutes les sessions attendent qu'une autre ait fini d'executer la sienne avant de continuer .. Et donc plus personne ne passe ...
 
Le code source de l'application (ecrite en Java) à bien entendu été passé au peigne fin mais rien n'a été sorti ...  
Le problème est que ce genre de problème arrive quand beaucoup de personnes balancent le meme genre de requete (qui est pourtant tres simple ... ) en meme temps, et étant donné qu'on est seulement 20 dans la boite on n'est pas assez pour faire locker nos serveurs de dev et donc arriver a voir exactement où ça plante.
 
On a demandé a un DBA oracle de venir voir, mais il n'a pas trop su comment réparer ça .. Il avait presque l'air de dire que c'est oracle qui n'arrive pas a gerer autant de requetes concourantes ( a vu de nez entre 30 et 50 ).
 
Est-ce que vous connaissez des cas similaires qui ont été resolu, ou est-ce que vous voyez ce que ça pourrait etre (on sait jamais).
 
Je n'ai pas collé ici une des requetes "suspectes" parcequ'il n'y a vraiment rien de sorcier... Une de celles qui semble locker le plus souvent est un insert d'une 40 ène de champs , monotable ... Rien de bien sorcier quoi ..
 
Merci d'avance

Ca m'étonne qu'un DBA Oracle n'ait pas pu vous en dire plus.
 
Quelle version ? Support Oracle dispo ?

Salut,
Comme comme je l'ai dit dans le titre, c'est des 9.x (plusieurs version si je me trompe pas). Qu'entends tu par support oracle dispo?

Beh, entre 9.x et la version précise, y'a une marge.
 
Plusieurs versions --> ???
 
Le but de ma question était de savoir si le dernier patch dispo avait été appliqué.
 
Support Oracle : beh, le support de chez Oracle. Tu payes très cher et tu peux les appeler, anytime.

Il y a plusieurs version differentes parceque plusieurs serveurs ... Tout les serveurs n'ont pas la meme version d'oracle (ni de jre ... j'te dis pas le bordel pour developper .. mais bon les clients veulent rien savoir ...).  
 
Je vais me renseigner pour le support de chez oracle

Update : Non pas de support

Y a personne qui s'amuse à lancer un UPDATE sur la table en question, sans COMMIT ? ou qqch dans le genre (qui expliquerait le lock).

ça m'etonnerais qu'ils soient passés a coté de ça ... Mais demain je vais aller en reparler avec l'admin pour savoir vous en dire un peu plus. Merci beaucoup en tous cas

Beegee> Coup classique, spécialement si des utilisateurs sont connectés à la DB. Mais j'en doute ici s'il s'agit d'une DB de prod. Il s'agirait plutôt d'une erreur dans le code.
 
Mais esox nous dit qu'ils l'ont passé au peigne fin.
 
C'est quoi comme accès à la DB ? Entity-beans, JDBC, Spring ? Application server, connection pooling ?
 
Si vous arrivez à 30-50 requêtes concurrentes sur un système prod et que vous n'avez pas de contrat de support, il y a sans doute un sérieux problème de management.
 
En plus avec des versions hétéroclites... Faut pas chercher les ennuis et ensuite venir pleurer.
 
J'approfondirait sur la requête qui bloque le plus souvent à défaut de mieux pour l'instant.
 
Si tu es d'attaque, tu peux te risquer avec Toad et le DBA module pour voir ça de plus près.

C'est du JDBC . Pour le contrat support j'ai demandé a un des mecs du support de chez nous et il m'a dit non, demain l'admin est la et je lui demande le tout ...
 
Pour toad, je vais lui proposer ça, le truc c'est que mon cahier de charges est assez rempli et que je suis pas sur qu'ils soient motivés a "perdre" un dev Java experimenté au profit d'un DBA incapable
 
Deplus, pour les version différentes, c'est une des raisons pour lesquelles on gueule 3x par semaine ... le probleme est que certaines client ne veulent pas se mettre a jour parcequ'ils ont d'autres appli qui se nourissent de la meme base, et qu'ils veulent pas risquer d'avoir des emmerdes

C'est pourtant ce qu'ils ont fait avec moi.

Je ne prendrais pas la perche que tu me tends...  Considère le une marque de mon respet pour toi

Juste comme ça... Quand vous avez passé au peigne fin l'appli, vous avez vérifié quoi ?
 
Si vous n'avez vérifier que des trucs bête genre que toute connection / commande ouverte était bien fermée après utilisation, c'est un coup d'épée dans l'eau.
En effet, que ce soit Java ou JDBC, les deux s'en occupent très bien (connectionTimeOut / commandTimeOut / garbage collector)
Au pire, vous auriez un ralentissement de l'appli.
 
Donc c'est pas ça qu'il faut recherche.
 
Je ne maîtrise pas Java du tout, et pas plus JDBC, par contre, une chose qui est sûre, c'est qu'ils permettent de faire la même chose qu'en VB/C++ avec une connection OLE/ODBC.
 
DONC. Par exepérience, ce qui peut faire des deadlock :
-> Vérifier que vous n'avez des transaction qu'aux endroits absolument nécessaires, ET que tout le lot est éxécuté d'un coup. Il ne faut pas commencer une transaction sur un écran et la finir sur un autre écran : si la personne part boire un café, l'ensemble des lignes touchées par la transaction sont lockées jusqu'à ce qu'elle revienne.
-> Si JDBC ne fonctionne pas en AUTO COMMIT, alors forcez-le immédiatement : avec OLEDB, si on le désactive, le COMMIT est fait uniquement lorsqu'on ferme la connection (c'est très con mais c'est comme ça). Vu que ça génère une transaction, vous imaginez les problèmes sous-jascents.
-> N'utilisez PAS de curseur dynamique, c'est à dire des curseurs qui permettent des modifications et des mises à jour "en live" depuis un objet DataGrid par exemple. En effet, ça génère, en plus de transactions, carrément des LOCK.
 
Maintenant, imagine :
 
J'ai un DataGrid qui fait un lock sur la table "facture".
Lorsque je met à jours les lignes de "facture", alors je met à jour aussi la table "client" (un compteur ou autre) par trigger.
Pendant que je suis en train de bosser sur ma facture, une autre personne lit sa fiche client, et change le status de l'utilisateur. Cependant, il n'est pas sûr, donc avant de valider, il veut vérifier les factures et... tente d'ouvrir celle que le premier utilisateur modifie.
 
Là, proutch, les deux sont bloqués.
=> L'utilisateur 1 ne peux pas valider car le trigger est blocké par le lock sur le client
=> L'utilisateur 2 ne peux pas accéder à la facture car elle est en cours de modif et la ligne est donc lockée.
 
Si le code ne gère pas proprement le code, permettant d'annuler la dernière action dans la base et en forçant l'un d'eux d'annuler ses modif, t'as un dead lock et c'est fini.
 
Bref, aucun lock explicit, aucun truc bizarre dans l'appli, et pourtant ça merde.