Discussion :

[Yorglaa]

Bonjour,
j'utilise une procédure qui pour le moment s'exécute pour chaque user à la connection et qui remplit un tableau PL/SQL de données de base utile ensuite un peu partout dans l'application...

je voudrais savoir si il est possible de partager une table PL/SQL entre différent user... en quelque sorte pour faire comme une "GLOBAL TEMPORARY TABLE" mais au niveau de l'instance et pas au niveau du user...
le but serait de faire exécuter la procédure qui remplit ce tableau au démarrage de l'instance et ensuite que chaque user puisse aller "taper" dans ce tableau sans avoir à le charger dans leur propre mémoire...

mais est-ce que c'est possible ?

merci d'avance pour vos informations.

[Pomalaix]

Bonjour

De prime abord, je ne vois pas d'autre solution qu'une table régulière.

Les tables temporaires sont finalement des tables privées (chaque utilisateur ne voit que les données qu'il y a lui-même mises), même si on rend la table accessible à plusieurs utilisateurs.
Le mot clé GLOBAL, qui est de toute façon obligatoire avec TEMPORARY, ne rend pas les données partageables.

Je ne connais pas de moyen de créer une variable globale partagée par toutes les sessions.

[SheikYerbouti]

Oui si vous définissez vos variables en global dans un package.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE OR REPLACE PACKAGE MON_PKG IS
 
-- Variables globales
.....
.....
 
END MON_PKG ;

[Pomalaix]

Oui si vous définissez vos variables en global dans un package.

D'après mes connaissances, (pas retesté) une variable globale est globale au sein d'une session !
Chaque utilisateur en a sa propre copie dans sa PGA, on ne peut pas dire qu'elle soit partagée entre les utilisateurs.

Donc ça ne peut malheureusement pas marcher...

[SheikYerbouti]

Tu as raison Pomalaix. Dans un moment d'égarement j'ai confondu session et instance.

[Yorglaa]

Salut à tous,
Merci pour vos infos...

je vais donc essayer de faire une table standard et d'y charger mes données...

je verrais ensuite ce que ça donne au niveau performances... je suppose que je vais gagner de l'espace mémoire puisque chaque user n'aura pas à charger sa propre table PL mais je risque de perdre un peu en accès disque...

je vais essayer ça et je vous tiens au courant...

[Marc Musette]

hello

à ce sujet, Tom Kyte préconise dans l'ordre

1) garder les variables en tête de package (package de valeurs magiques comme dirait feuerstein) disponible pour chaque session
2) utiliser un trigger on-login qui remplit la cache de chaque session
3) utiliser une table

http://asktom.oracle.com/pls/ask/f?p...:653024150407, pour plus d'info

bonne lecture

[Patmane]

Je me demande si en réfléchissant bien autour d'un bon vieux PIPE (DBMS_PIPE) on pourrait pas faire quelque chose. Recréer une sorte de bus applicatif gérer par une session lançée lors du démarrage du serveur!
Veux tu investiguer sur cette piste?

[Marc Musette]

si il s'agit de charger un tableau de valeur pour chaque session, non un dbms_pipe n'est pas une bonne solution ;

ce package permet déchanger des infos entre deux ou plusieurs sessions et est utilisé pour l'interface avec un service 3GL, des transactions indépendantes, des "alerters", du debugging ,... (voir la doc Oracle sur ce package pour une explication complète des utilisations de DBMS_PIPE)

pour charger des données communes à plusieurs sessions, on utilise les méthodes proposées (et expliquées) dans l'article de Tom Kyte dont je vous ai fourni le lien

restons humble ... il propose trois solutions, je ne crois pas que l'on va en trouver une quatrième plus efficace...

[SheikYerbouti]

Malheureusement les variables globales aux packages ne sont pas visibles entre 2 sessions, et la mise en oeuvre des PIPES est fastidieuse compte tenu de la problématique.

La table partagée semble la solution la plus simple, d'autant plus que si elle ne contient que peu de lignes, elle peut être chargée et conservée dans le cache.

[Marc Musette]

tout dépend de ce que veux notre ami

si il s'agit de constantes, alors pas de problèmes pour la solution "package" , non ?

[SheikYerbouti]

Non, parce que, rappelons-le une ultime fois, les variables de packages ne sont pas visibles entre plusieurs sessions

[Patmane]

OUPS
moi je donnais mon avis sur une solution de "remplacement" et qui entre parenthèse fonctionne très bien (pour l'avoir implémentée). En fait le but est de recréer le fonctionnement d'un bus applicatif (GRACE AUX PIPES)
Ceci dit il est clair qu'une solution plus "oracle" conviendra surement mieux (je n'en disconviens point )!

[Marc Musette]

là, j'ai un problème ...

je crée sous le user TEST, le package suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
CREATE OR REPLACE PACKAGE pck_global AS
   ok         VARCHAR2 (2)  := 'OK';
   not_ok     VARCHAR2 (3)  := 'NOK';
   fct_dec    VARCHAR2 (7)  := 'FCT_DEC';
   fct_ctrt   VARCHAR2 (8)  := 'FCT_CTRT';
   nc_dec     VARCHAR2 (6)  := 'NC_DEC';
   nc_ctrt    VARCHAR2 (7)  := 'NC_CTRT';
   ctrt       VARCHAR2 (4)  := 'CTRT';
   dc         VARCHAR2 (2)  := 'DC';
   dg         VARCHAR2 (2)  := 'DG';
   ds         VARCHAR2 (2)  := 'DS';
   dgrc       VARCHAR2 (4)  := 'DGRC';
   cont       VARCHAR2 (4)  := 'CONT';
   pca        VARCHAR2 (3)  := 'PCA';
   cdc        VARCHAR2 (3)  := 'CDC';
   tva        NUMBER (4, 2) := 0.06;
   debstat    DATE          := TO_DATE ('01-01-1998', 'dd-mm-yyyy');
   finstat    DATE          := TO_DATE ('31-12-2005', 'dd-mm-yyyy');
END pck_global;
/

qui reprend un ensemble de constante, que plusieurs de mes procédures vont utiliser ... la session n'a rien à voir ici ; ces valeurs sont lisibles dans n'importe quelle session connectée au schéma de mon package (et autre via GRANT)

???

[SheikYerbouti]

Lisibles ?

modifiez les valeur par le schéma X et affichez-les ensuite par le schéma Y.

Sont-elles répercutées ?

[Marc Musette]

Bonjour,
j'utilise une procédure qui pour le moment s'exécute pour chaque user à la connection et qui remplit un tableau PL/SQL de données de base utile ensuite un peu partout dans l'application...

ce que j'avais compris de la question était d'avoir une structure read-only, ou des constantes qu'aucun ne modifierait

effectivement, le seul moyen de changer ces variables de package serait de recompiler

mais dans le cas de constante, cela marche non? et mettre à disposition des développeurs une table de valeurs globales qu'ils peuvent modifier individuellement (lock, persistence des données) me semble également dangereux

reste à voir ce que Yorglaa veut réellement mettre à disposition de ses développeurs (mais le saura-t'on ? )

[SheikYerbouti]

Effectivement, il semblerait que le demandeur initial nous ai quitté depuis longtemps !....

[Yorglaa]

coucou me revoilà...

tout d'abord je ne vous ai pas abandonné, mais la vie d'un DBA étant ce qu'elle est j'ai eu quelques "point chaud" à manager sur notre base de Prod... dont une mise en Production Express d'une nouvelle version de notre application...

alors sorry de vous avoir laissés si longuement deviser sans moi !

dans le cas qui nous occupe ma table PL est constituée d'environ 4100 lignes sur 6 solonnes, composées par 3 col de type NUMBER et 3 de type varchar2(150)...

donc le nombre de ligne n'est pas excessivement important et je suppose que ce ne serait pas trop lourd que de charger cette table dans le cache...

donc la solution de la table "en dur" me semble bonne, mais pour les raisons que je vous ai expliqué plus haut je n'ai pas encore pu tester...

dans la solution actuellement en vigueur, le tableau PL généré pour chaque user est bel et bien placé dans un package de variables que l'utilisateur ne charge qu'au login... 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...

enfin bref je vais faire le test de la table "en dur" et vous donne des nouvelles...
Promis je ne vous oublie pas !!!

à bientôt

[SheikYerbouti]

Pour couper la poire en deux, vous pourriez valoriser les variables de votre package par lecture de la table. Cela évitera de recompiler le package à chaque modification.

[Yorglaa]

En l'état c'est déjà ce qu'il se passe...

le tableau PL est populé à partir d'un Select sur différentes tables sources au login de l'utilisateur...

donc comme ces données constituent en fait des données de paramètrage de l'application, je peux intervenir sur les données originales des tables et le user les aura effectivement en vigueur lors de son prochain login... pas de recompilation de package...