Discussion :

[awalter1]

Bonjour,
Auparavant, mon application gérait un projet par database. Chaque user unix avait un user oracle associé.
Il est décidé de mettre plusieurs projets par database, chaque projet restant indépendant des autres. Je pense à utiliser le concept de tablespace avec 1 projet=1 tablespace.
Un utilisateur unix doit pouvoir accèder à chaque projet (tablespace), pas en même temps cependant. Comment faire le lien entre un user et un tablespace ?
Je vois que lors de la création d'un user, on peut associer un tablespace. Faut t'il alors considérer que chaque user unix aura plusieurs users oracle en fonction du tablespace à atteindre ? Y a t'il d'autre moyens ?
Merci de votre éclairage

[Pomalaix]

Dédier un tablespace (ou un jeu de tablespaces) à chaque application, c'est une bonne chose, car ainsi vous aurez la possibilité de faire des opérations de maintenance qui toucheront uniquement l'application ciblée : mise OFFLINE, READ ONLY, sauvegarde, etc.

Par contre, la notion de tablespace n'intervient pas pour ce qui concerne les privilèges. On donne par exemple le droit SELECT à SCOTT sur la table COMPTA.HISTO_TVA, peu importe le tablespace dans lequel cette table se trouve.

Donc le fait de mutualiser votre base entre plusieurs applications ne change rien à votre gestion : il faut donner aux utilisateurs juste les droits dont ils ont besoin, et rien de plus.

Dans une base mutualisée, pour garantir l'étanchéité entre les différentes applications, il faut en particulier contrôler les points suivants
* aucun privilège sur des objets applicatifs ne devrait être donné à PUBLIC
* personne ne devrait avoir de privilèges de type ANY (par exemple SELECT ANY TABLE), car sinon ces personnes pourront accéder à tous les objets de la base, toutes applications confondues
* pas d'usage des liens de base de données publics
* pas d'usage des synonymes publics

[awalter1]

Pourtant, il est possible de préciser un tablespace lors de la création d'une table, ceci ne restreint t'il pas l'accès à la table ?
merci

[awalter1]

Si j'ai compris ce que j'ai lu par ailleurs :
pour le projet1 :
je crée le user PROJET1,
je créé mes tables du projet1 sous le user PROJET1,
puis je donne les droits aux autres users sur ces tables.
Je fais de même pour les autres projets, et j'aurais une séparation claires entre mes projets.
Je garde la notion de tablespace pour faciliter les opérations de maintenance.
Merci

[Pomalaix]

C'est bien ça !

Car il n'y a pas de lien entre tablespace et droit d'accès. On ne peut pas donner des droits d'accès à quelqu'un sur un tablespace.

[awalter1]

Juste pour terminer, pourquoi lors de la création d'un user faut t'il préciser un tablespace ?
Merci

[Rams7s]

Pour savoir ou il va enregistrer ses objets.

Si je ne m'abuse, un tablespace, c'est simplement le lieu ou les donnees vont etre enregistrees physiquement. En sachant qu'apres un tablespace est constitue de datafiles, qui sont eux les fichiers present sur le serveur.

[awalter1]

Si j'ai compris, c'est lors de la création d'une table que l'on précise le tablespace ou vont être stockées les données de la table.
Lors de la création du user, on peut préciser les tablespace qu'il va pouvoir utiliser et par conséquent les tables associées. Il s'agit donc d'un privilège d'accès.

[skuatamad]

pourquoi lors de la création d'un user faut t'il préciser un tablespace ?

Ca n'est pas obligatoire, tout comme lors de la création d'une table.
Par défaut c'est le tablespace USERS qui est utilisé.

[Pomalaix]

Lors de la création du user, on peut préciser les tablespace qu'il va pouvoir utiliser et par conséquent les tables associées. Il s'agit donc d'un privilège d'accès.

Nan ! Emplacement et privilège, ça n'a rien à voir. La notion de "les tablespaces qu'il va pouvoir utiliser" n'existe pas.

Quand on crée une table, on peut préciser dans quel tablespace elle sera stockée.

Code :

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

create table t1(a int) tablespace demo;

Si on ne le précise pas, elle sera stockée dans le tablespace par défaut associé à l'utilisateur.
Un utilisateur a un et un seul tablespace par défaut.

Ici, on indique que COMPTA sera le tablespace par défaut de X.

Code :

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

1
2
3
create user x
identified by y
default tablespace compta;

[Pomalaix]

... Par défaut c'est le tablespace USERS qui est utilisé.

Le tablespace USERS étant facultatif, ça ne peut pas être vrai.

De tout temps, le tablespace par défaut a été SYSTEM.
Depuis Oracle 10g, il existe la possibilité de définir, lors de la création de la base, un tablespace par défaut qui s'appliquera aux utilisateurs qui ont été créés sans préciser la clause DEFAULT TABLESPACE.

Autrement dit, si aucun tablespace par défaut n'a été défini au niveau de la base, ni au niveau de l'utilisateur, alors implicitement ça sera encore SYSTEM.

[awalter1]

Nan ! Emplacement et privilège, ça n'a rien à voir. La notion de "les tablespaces qu'il va pouvoir utiliser" n'existe pas.[/code]

J'avais trouvé le terme utiliser dans la rubrique suivante extraite de http://oracle.developpez.com/guide/a...ion/adminuser/:

Code :

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

1
2
3
4
5
6
7
1.4. Choisir les TABLESPACEs que l'utilisateur pourra utiliser

Il va maintenant falloir choisir le domaine d'action du nouvel utilisateur. 

En effet, pour des raisons de sécurités évidentes, nous allons restreindre le champ d'action de l'utilisateur en choisissant les tablespaces que celui-ci sera en mesure d'utiliser. 

Il va donc falloir identifier tous les tablespaces nécessaire à l'utilisateur, que ce soit des tablespaces de données, d'index, ou temporaire. Il n'y a pas de syntaxe particulière pour cette étape.

Pour une fois que je pensais avoir compris

[Pomalaix]

Je comprends mieux où ça coince ...

Le paragraphe que vous citez est affreusement ambigu, car ce qui se cache derrière est la notion de quota, alors que tout laisse à penser qu'on parle de droits d'accès (du genre SCOTT aurait le droit de lire dans tel ou tel tablespace).

Disons que vous avez une appli COMPTA, dont les tables appartiennent à l'utilisateur Oracle COMPTA. Les utilisateurs de l'application ont besoin de privilèges de type SELECT, INSERT, UPDATE, DELETE et EXECUTE sur ces objets (tables, procédures...).
J'insiste sur le fait que de tels privilèges ne peuvent pas porter sur un tablespace.

Par contre, le propriétaire de la table a besoin d'avoir un quota sur le tablespace dans lequel il veut créer la table. C'est le droit de consommer une certaine quantité d'espace dans ce tablespace, le fameux "utiliser" de votre paragraphe. Les quotas sont à 0 par défaut.

Code :

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

1
2
alter user compta
quota 100M on TBS_COMPTA;

Même si les insertions dans la table sont faites par d'autres utilisateurs, c'est le propriétaire de la table et lui seul qui a besoin d'un quota sur le tablespace concerné.

En espérant que ça clarifie le sujet !

[skuatamad]

Merci Pomalaix pour les précisions.

[awalter1]

je comprends, en conséquence, lorsque on définit un user avec un tablespace particulier (ou plusieurs) c'est uniquement pour signifier la taille max que pourra occuper les tables qu'il va créer sous son nom et qu'il va associer à un tablespace pour organiser le stockage physique des données.
Merci

[Pomalaix]

...c'est uniquement pour signifier la taille max que pourra occuper les tables qu'il va créer sous son nom et qu'il va associer à un tablespace pour organiser le stockage physique des données.

Oui, sur cette partie nous sommes d'accord.

Le début de votre phrase, par contre, c'est vraiment trop flou : "lorsque on définit un user avec un tablespace particulier (ou plusieurs)".
Que signifie "définir un utilisateur AVEC des tablespaces" ?

[awalter1]

J'ai repris la syntaxe de l'ordre CREATE USERS qui permet de définir, outre le tablespace par défaut et/ou temporaire, plusieurs directives de quota sur tablespace.

Code :

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

1
2
3
...
QUOTA 5M ON TBS_USERS QUOTA UNLIMITED ON TMP_USERS...
...

[Pomalaix]

Votre exemple amène un dernier commentaire : on ne peut pas définir de quota sur les tablespaces d'annulation ou les tablespaces temporaires. Pour eux, le quota est automatiquement illimité pour tout le monde.

[awalter1]

merci pour toutes ces informations