IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PL/SQL Oracle Discussion :

PL/SQL Partager une table PL/SQL... possible ?


Sujet :

PL/SQL Oracle

  1. #1
    Membre émérite Avatar de Yorglaa
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    845
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2004
    Messages : 845
    Par défaut PL/SQL Partager une table PL/SQL... possible ?
    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.

  2. #2
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    Décembre 2002
    Messages
    3 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 461
    Par défaut
    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.

  3. #3
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    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 ;

  4. #4
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    Décembre 2002
    Messages
    3 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 461
    Par défaut
    Citation Envoyé par SheikYerbouti
    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...

  5. #5
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    Tu as raison Pomalaix. Dans un moment d'égarement j'ai confondu session et instance.

  6. #6
    Membre émérite Avatar de Yorglaa
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    845
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2004
    Messages : 845
    Par défaut
    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...

  7. #7
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut
    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

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 50
    Par défaut
    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?

  9. #9
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut
    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...

  10. #10
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    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.

  11. #11
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut
    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 ?

  12. #12
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    Non, parce que, rappelons-le une ultime fois, les variables de packages ne sont pas visibles entre plusieurs sessions

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    50
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 50
    Par défaut
    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 )!

  14. #14
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut
    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)

    ???

  15. #15
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    Lisibles ?

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

    Sont-elles répercutées ?

  16. #16
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut Re: PL/SQL Partager une table PL/SQL... possible ?
    Citation Envoyé par 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...
    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 ? )

  17. #17
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    Effectivement, il semblerait que le demandeur initial nous ai quitté depuis longtemps !....

  18. #18
    Membre émérite Avatar de Yorglaa
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    845
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2004
    Messages : 845
    Par défaut
    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

  19. #19
    Expert confirmé
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Par défaut
    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.

  20. #20
    Membre émérite Avatar de Yorglaa
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    845
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2004
    Messages : 845
    Par défaut
    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...

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Afficher le code SQL d'une table access | Possible ? |
    Par beegees dans le forum Requêtes et SQL.
    Réponses: 9
    Dernier message: 18/01/2019, 16h30
  2. Changer le nom d'une table sur SQL server avec une requete
    Par Oluha dans le forum MS SQL Server
    Réponses: 6
    Dernier message: 01/02/2014, 23h35
  3. Afficher le code SQL d'une table MYSQL : Possible ?
    Par beegees dans le forum Débuter
    Réponses: 2
    Dernier message: 24/11/2008, 14h29
  4. MAJ d'une table sous SQL Server par insertion
    Par keish dans le forum Langage SQL
    Réponses: 6
    Dernier message: 11/06/2003, 16h23
  5. [SQL] Remplacer une table
    Par rstephane dans le forum Langage SQL
    Réponses: 5
    Dernier message: 06/05/2003, 17h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo