Discussion :

[Marc Musette]

j'ai du mal à comprendre

si ces valeurs sont en read-only pour les utilisateurs, pourquoi ne pas continuer avec la solution package ? chaque session a accès à ce package quand même ?!?!

... donc c'est exact que les valeurs de variables d'un tel package ne peuvent pas être partagées en l'état par de multiples sessions...

désolé mais je comprends pas la nuance de "partagées en l'état" ...

de même, il me semble que ces paramètres ne doivent pas changer souvent ... il me semble également dangereux de charger de tels paramètres via une table car les valeurs chargées dans chaque session risquent d'être différentes selon le moment du login ?!?

je reste persuadé que si il s'agit de données sur lesquelles l'utilisateur n'a qu'un droit de lecture, et bien les variables packages (à recompiler) constituent la solution la plus homogène et la plus rapide

merci de me convaincre

[SheikYerbouti]

Je ne partage pas l'avis de la recompilation du package.

Les valeurs sont stockées par utilisateur, et chargée dans le package dès le premier appel dans l'instance. pourquoi recompiler ?

[Yorglaa]

je suis assez d'accord qu'il n'est pas utile de recompiler, un user "lambda" n'a , dans notre environement, aucun moyen d'aller modifier les valeurs ni des tables sources ni des valeurs attribuées dans la variable...

je rappelle juste le but de ma question initiale :

• actuellement chaque user possède sa propre table PL en mémoire, avec LES MEMES DONNEES pour tout le monde
• la question était : y-a-t'il une possibilité d'économiser de la mémoire et des accès disques(pour le chargement) en partageant cette table PL de manière à ce qu'elle soit chargée UNE SEULE fois en mémoire pour tout le monde, vu que tout le monde utilise les même données...

en fait il semble que non, donc je vais soit laisser en l'état ou bien stocker ces valeurs en dur à chaque démarrage de la base (actuellement nous faisons des backups à froid et la base démarre tous les matins) dans une table physique (à charger dans le cache) qui remplacerait la table PL de chaque user...

par contre cette dernière solution demande un peu de travail pour tester parce que je doit adapter toutes les PL qui vont ensuite se référer à ces données...

[Marc Musette]

bon ... j'ai quand même quelques interrogations auquelles j'aimerais que vous apportiez une explication

1- lors du premier appel du package de variables "globales", le package COMPILE est mis dans la SGA et partagé par toutes les sessions de l'instance ? nous sommes bien d'accord ?

2- néanmoins, chaque session se voit assigner sa propre zone PL/SQL qui contient une copie des données du package ? toujours d'accord ?

3- si ces données de packages se voient affectées une valeur par un SELECT dans une table, ces valeurs risquent d'être différentes par session --> exemple :

session user1 : select var1 from PL qui renvoie la valeur 5
session DBA-Yorglaa : update PL set var1 = 6; commit;
session user2 : select var1 from PL ... renverra bien la valeur 6 et non 5

? est-ce que ce que je dis est vrai ?

par contre il me semble que si la modification des variables globales (uniquement réalisée par le dba-Yorglaa) se fait par une recompilation, les valeurs renvoyées seront toujours celles de la forme compilée chargées initialement dans la SGA ?

je me trompe ???

[Pomalaix]

Pas de problème, tout ça est bien exact !
Mais Yorglaa a précisé que ses utilisateurs n'ont pas accès à la table de paramètres sous-jacente.

[Yorglaa]

En effet Marc, ces 3 points sont exact !

il se trouve toutefois que seul moi-même et quelques autres "élus" avons accès à la(les) table(s) sources de ces données si sensibles... Et que nous ne nous permettons pas de les modifier "à la volée" sans, au préalables, s'assurer que plus aucun utilisateur n'est connecté à la base...

ces données étant susceptibles de contenir des matrices de règles de gestions (pour simplifier disons un lien entre un no d'article et son tarif, même si n'est pas notre domaine d'activité), il est clair que nous devons être extrèmement conséquents avec notre manière de modifier ces paramètres...

ceci dit en cas "d'urgence" nous avons la possibilté d'y inclure des données qui ne seraient pas encore utilisées par les utilisateurs si ces nouveaux éléments ne sont pas encore appelés par les PL correspondantes... mais ça ne concerne que des nouveaux éléments, surtout pas d'update lorsque des users sont connectés, sinon le risque est en effet d'avoir des users avec des données de paramètre différentes !!

[Marc Musette]

bon je suis rassuré alors

mais si j'avais dû implémenter cela personnelement, je ne serais pas passé par une table ... mais bon je suppose qu'il doit bel et bien avoir une raison à cette façon de faire

bonne chance alors et merci pour cet échanges d'infos

[Yorglaa]

à vrai dire je n'ai pas développé ça non plus... mais maintenant que le développeur original n'est plus là, ben il faut faire avec... d'où ma (mes) question(s)... pour savoir si on peut optimiser à cet endroit ou pas, sans forcément réécrire de grosses parties de code...

[Marc Musette]

par contre il me semble que si la modification des variables globales (uniquement réalisée par le dba-Yorglaa) se fait par une recompilation, les valeurs renvoyées seront toujours celles de la forme compilée chargées initialement dans la SGA ?

je me trompe ???

j'ai testé ; je me trompais !!!!!!!!!

la recompilation entraîne le rechargement des nouvelles valeurs dans la SGA et provoque même l'erreur ORA-04068

[Yorglaa]

Test effectués... aucun gain de performance visible en utilisant une table "en dur"...

et comme je n'ai pas monté cette solution en PROD je ne peux rien dire au niveau des contentions (lock, etc) qu'aurait pu causer cette solution avec 200 users...

toujours est-il que je vais rester pour le moment avec mon tableau PL pour chaque user...

merci à tous d'avoir pris le temps de réfléchir à des solutions... j'espère pouvoir vous être utile une fois aussi...

à bientôt

[Pomalaix]

Test effectués... aucun gain de performance visible en utilisant une table "en dur"...

??? Là je ne comprends pas cette remarque pour le coup !
Comment pouviez-vous espérer un gain de performances en utilisant une table physique plutôt qu'un tableau en mémoire ?

Au fait, vous avez un réel problème avec le système actuel (une consommation mémoire assez forte je suppose), ou bien vous aviez juste une interrogation préventive ?

[Marc Musette]

cela semblait évident ; j'ai aiguillé directement vers un article de Tom Kyte qui présentait trois solutions au problème de notre ami et la solution table physique était la dernière retenue ... mais tester par soi-même a du bon et la discussion était relevée et conviviale !

[Yorglaa]

il se trouve que n'ayant pas 10 ans de métier dans le domaine, je me posait la question si une charge supplémentaire induite par une table en dur pouvait être compensée par une charge plus légère en mémoire...

A mon avis bien m'en a pris puisque j'ai beaucoup appris à travers toute notre discussion, la doc suggérée par Marc et les tests induits par tout ceci...

donc à mon avis le but est atteint dans le sens qu'un forum est un échange d'idée, d'expériences (même les moindres) et qu'en plus c'est quand même souvent en testant de "mauvaises options" qu'on se dirige ensuite vers les bonnes...

par contre je suis tout à fait d'accord pour admettre que certaines de mes idées peuvent paraître un peu naïves pour quelqu'un qui maîtrise nettement mieux que moi les rouages complexes des systèmes Oracle actuels... mais comme on dit " que celui qui n'a jamais été Junior me jette le premier Deadlock !"

[Yorglaa]

Oups j'ai oublié de répondre à la 2ème question de Pomalaix... sorry

je ne suis pas face à un réel problème de mémoire pour le moment... c'était en effet "préventif".

comme je l'ai dis précédemment nous avons "hérité" ce code d'un développeur qui n'est plus là et je voulais voir si il y avait d'autres façons peut-être plus efficaces de gérer son héritage ... si possible sans devoir réécrire toute l'application !

voilà

[Pomalaix]

il se trouve que n'ayant pas 10 ans de métier dans le domaine, je me posait la question si une charge supplémentaire induite par une table en dur pouvait être compensée par une charge plus légère en mémoire...

A mon avis bien m'en a pris puisque j'ai beaucoup appris à travers toute notre discussion, la doc suggérée par Marc et les tests induits par tout ceci...

donc à mon avis le but est atteint dans le sens qu'un forum est un échange d'idée, d'expériences (même les moindres) et qu'en plus c'est quand même souvent en testant de "mauvaises options" qu'on se dirige ensuite vers les bonnes...

par contre je suis tout à fait d'accord pour admettre que certaines de mes idées peuvent paraître un peu naïves pour quelqu'un qui maîtrise nettement mieux que moi les rouages complexes des systèmes Oracle actuels... mais comme on dit " que celui qui n'a jamais été Junior me jette le premier Deadlock !"

Loin de moi l'idée de vous regarder de haut ni comme un débutant hein !
Je me disais juste que comme vous aviez fait preuve dans tous ces échanges d'un niveau technique que je juge plutôt relevé, votre idée finale était un peu saugrenue.
Mais effectivement, un bon test pour confirmer l'intuition ou la théorie est toujours un bon réflexe !

Et celle-là je la note : "que celui qui n'a jamais été Junior me jette le premier Deadlock"

[Yorglaa]

pour conclure je suppose que ce Post a maintenant atteint ses limites... alors je le mets en "résolu"...

merci à tous ceux qui y ont participés !!