Comment définir le schéma par défaut d'un utilisateur Oracle?


12

J'ai créé quelques nouveaux utilisateurs dans Oracle. Cependant, lors de l'exécution de sqlplus, ils doivent tous qualifier complètement les noms de table dans la requête. Quelle est la meilleure façon de définir un schéma par défaut pour ces nouveaux utilisateurs?

Réponses:


19

Il n'y a rien de tel que PostgreSQL set search_pathdans Oracle.

La chose la plus proche à laquelle je peux penser serait un déclencheur de connexion pour l'utilisateur qui exécute un ALTER SESSION SET CURRENT_SCHEMA ...

CREATE OR REPLACE TRIGGER LOGON_TRG 
  AFTER LOGON ON SCHEMA
BEGIN
     EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = foobar';
EXCEPTION 
  when others 
    then null; -- prevent a login failure due to an exception
END;
/  

Si la liste des utilisateurs n'est pas trop longue, vous pouvez créer un déclencheur de connexion à la base de données afin de ne pas avoir à créer ce déclencheur pour chaque utilisateur:

CREATE OR REPLACE TRIGGER LOGON_TRG 
  AFTER LOGON ON DATABASE
BEGIN
    if (user in ('TOM', 'DICK', 'HARRY')) then
      EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = foobar';
    end if;
exception 
  when others 
    then null; -- prevent a login failure due to an exception
END logon_trg;
/  

Bien sûr, la liste des utilisateurs dont vous souhaitez modifier le schéma par défaut peut également être extraite d'une table. Dans ce cas, il vous suffit d'insérer ou de supprimer des lignes à partir de là pour "activer" cette fonctionnalité (plutôt que de recréer le déclencheur à chaque fois).

Une autre option serait de créer des synonymes chaque fois que vous créez un utilisateur qui pointe vers les vraies tables. Vous pouvez automatiser cela à l'aide d'une procédure stockée qui parcourt toutes les tables dans un schéma et crée les synonymes pour elles dans l'autre schéma.

À moins que tous vos utilisateurs Oracle ne travaillent sur les mêmes tables, je déconseille fortement d'utiliser des synonymes publics que vous ne devrez créer qu'une seule fois - ils peuvent causer beaucoup de problèmes si différents utilisateurs d'application existent dans votre installation.

Modifier :

Suivant la suggestion d'Alex, voici un déclencheur de connexion qui vérifie le rôle plutôt qu'un nom d'utilisateur:

CREATE OR REPLACE TRIGGER LOGON_TRG
  AFTER LOGON ON DATABASE
declare
  has_role boolean;
BEGIN

    has_role := dbms_session.is_role_enabled('FOOBAR_ROLE');

    if (has_role) then
      EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA = foobar';
    end if;
exception 
   when others 
      then null; -- prevent a login failure due to an exception    
END logon_trg;
/

Excellente idée mais comme il when others then null;s'agit d'un fourre-tout, cela compliquera le dépannage car il rend toute erreur invisible. Peut-être supprimer complètement la gestion des exceptions ou enregistrer l'erreur sur le serveur dans une transaction AUTONOME, puis la relancer ?
George3

@ George3: mais si l'exception est réellement levée, l'utilisateur ne peut pas se connecter - je voulais juste empêcher quelqu'un de ne pas pouvoir se connecter simplement à cause d'une erreur stupide dans le déclencheur. Mais chacun est libre d'adapter cela à ce qu'il veut.
a_horse_with_no_name

0

Je ne pense pas qu'il existe un moyen d'en définir un. L'utilisateur est le schéma. AFAIK, vous ne pouvez définir que l'espace disque logique par défaut.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.