Les Framework d'ORM modernes sont sans conteste un grand progrès dans le monde du développement logiciel : laisser le système gérer correctement les interactions avec la base de données au lieu les coder soi-même (mal) à coup de copier coller rébarbatifs. Avant l'arrivée de solutions comme Hibernate, soit on faisait le mapping manuellement classe par classe, champ par champ, soit on passait par un Framework maison. Un bienfaiteur anonyme nous envoie le mail que tous les développeurs de sa société ont reçu.
Pour en apprécier toute la saveur, il faut savoir que leur système s'appuie pour sa "couche de persistance", sur une flopée de fonctions et procédures en PL/SQL inmaintenables : environ 2500 fichiers de procédures et fonctions PL/SQL pour un schéma de 384 tables. Il ne se passe pas une journée sans que les développeurs soupirent en pensant à des choses avant-gardistes comme, je ne sais pas moi avez-vous déjà entendu parler de ce truc, comment ça s'appelle déjà, OR...M ?
Bonjour à tous,
à partir de 15h aujourd’hui le nombre de curseurs ouverts par session en prod excédait parfois 4000 qui est notre limite.
Conséquence, pour environ une requête sur 200 ou 500, le client recevait le message d’erreur suivant : « maximum open cursors exceeded ».
Nous avons modifié il y a 40 minutes le paramétrage de prod pour porter cette limite à 5000, mais cela semble très élevé (pour 20 sessions, cela représente une limite de 100 000 curseurs ouverts en prod).
J’avais une link en rédaction depuis avril (V5-2815) où le problème avait fait surface et où nous avions constaté que certains curseurs n’étaient jamais fermés (la nuit il y a entre 3 et 10 000 curseurs encore ouverts ...)
Il serait bon de s’y pencher cet été
Modifier le hardware pour qu'il supporte les vices du sotfware, clbuttic ! Comme dit notre rapporteur, c'est pas encore cet hiver que l'on poura Hibern(at)er.
