{Oracle} Tablespace
ablette07
Messages postés
5
Date d'inscription
Statut
Membre
Dernière intervention
-
fiu -
fiu -
Bonjour,
Je dois créer une BDD sous Oracle. Il y aura environ 6 utilisateurs qui bosseront dessus (create, insert, update, select....)
Je me demande combien de tablespace je dois créer ???? 1 seul pour tout les base de données ou plusieurs ??? Bref je débute et je ne sais pas comment m'y prendre.
Quels sont les choses à faire à tout prix (essentielles) à la création d'une nouvelles instance.
Merci par avance de votre aide
Je dois créer une BDD sous Oracle. Il y aura environ 6 utilisateurs qui bosseront dessus (create, insert, update, select....)
Je me demande combien de tablespace je dois créer ???? 1 seul pour tout les base de données ou plusieurs ??? Bref je débute et je ne sais pas comment m'y prendre.
Quels sont les choses à faire à tout prix (essentielles) à la création d'une nouvelles instance.
Merci par avance de votre aide
A voir également:
- {Oracle} Tablespace
- Oracle liste des tables - Forum Oracle
- Oracle jre usage ✓ - Forum Virus
- Oracle 11g download windows 64-bit ✓ - Forum Oracle
- Telecharger oracle virtualbox - Télécharger - Émulation & Virtualisation
- Find oracle sid ✓ - Forum Bases de données
5 réponses
Salut
Euh... tout dépend de comment tu veux gérer l'espace que tu mets à disposition de tes utilisateurs.
Tu mettras un tablespace commun si tu acceptes de mutualiser l'espace de tes utilisateurs
Tu mettras un tablespace par utilisateur si tu veux éviter qu'un utilisateur bouffe tout l'espace de tout le monde
Et, sous réserves de droits d'accès, les utilisateurs auront accès aux tables des autres utilisateurs quel que soit le nombre de tablespaces que tu choisis.
De toutes façons, l'accroissement de l'espace d'un tablespace n'est pas problématique : tu peux faire croître les fichiers sous-jacents et/ou en ajouter de nouveaux.
Euh... tout dépend de comment tu veux gérer l'espace que tu mets à disposition de tes utilisateurs.
Tu mettras un tablespace commun si tu acceptes de mutualiser l'espace de tes utilisateurs
Tu mettras un tablespace par utilisateur si tu veux éviter qu'un utilisateur bouffe tout l'espace de tout le monde
Et, sous réserves de droits d'accès, les utilisateurs auront accès aux tables des autres utilisateurs quel que soit le nombre de tablespaces que tu choisis.
De toutes façons, l'accroissement de l'espace d'un tablespace n'est pas problématique : tu peux faire croître les fichiers sous-jacents et/ou en ajouter de nouveaux.
En ait j'ai du mal à comprendre le fonctionnement des tablespaces ! Si tous les utilisateurs doivent avoir accès à toutes les tables d'une même BDD et que je fais 6 tablespaces (1 par user), je devrais avoir chaque table de la BDD à l'intérieur de chaque tablespace ? Ca ne multiplie pas tout ? Quel est l'interêt ?
Désolé mais je débute et je suis un peu perdu
Merci
Désolé mais je débute et je suis un peu perdu
Merci
re
en fait, il faut plutôt voir un tablespace comme un volume, un espace de stockage contigu, doté d'attributs et qui contiendra tables et indexes. Pour clarifier ta vision de la chose : le disque supporte les fichiers qui supportent les tablespaces qui supportent les tables et indexes. Et de la même manière qu'on ne peut répartir un fichier sur plusieurs volumes, un objet Oracle ne peut être réparti sur plusieurs tablespaces. Les attributs des tablespaces guident le comportement par défaut pour l'allocation d'espace de stockage.
Quand un utilisateur crée un objet (une table ou un index), cet objet est obligatoirement stocké dans un tablespace :
* si le tablespace est spécifié lors de la création, c'est celui-ci qui contiendra l'objet ;
* sinon l'objet sera stocké dans le tablespace par défaut de l'utilisateur
C'est ce tablespace par défaut que tu es censé définir à la création de l'utilisateur.
Si un utilisateur ne veut pas que ses tables soient accessibles à d'autres personnes, il lui suffit de ne pas leur donner de droits d'accès (et que le DBA n'en donne pas non plus)
Si tu as une BDD que les utilisateurs doivent faire vivre tout en ayèant le droit de créer leurs propres tables, crées alors un tablespace destiné à recevoir la BDD et crées un tablespace pour tes utilisateurs (ou réutilise USERS) : tu auras ainsi la certitude que les tables créées par les utilisateurs ne viendront pas grignoter l'espace nécessaire à la BDD
en fait, il faut plutôt voir un tablespace comme un volume, un espace de stockage contigu, doté d'attributs et qui contiendra tables et indexes. Pour clarifier ta vision de la chose : le disque supporte les fichiers qui supportent les tablespaces qui supportent les tables et indexes. Et de la même manière qu'on ne peut répartir un fichier sur plusieurs volumes, un objet Oracle ne peut être réparti sur plusieurs tablespaces. Les attributs des tablespaces guident le comportement par défaut pour l'allocation d'espace de stockage.
Quand un utilisateur crée un objet (une table ou un index), cet objet est obligatoirement stocké dans un tablespace :
* si le tablespace est spécifié lors de la création, c'est celui-ci qui contiendra l'objet ;
* sinon l'objet sera stocké dans le tablespace par défaut de l'utilisateur
C'est ce tablespace par défaut que tu es censé définir à la création de l'utilisateur.
Si un utilisateur ne veut pas que ses tables soient accessibles à d'autres personnes, il lui suffit de ne pas leur donner de droits d'accès (et que le DBA n'en donne pas non plus)
Si tu as une BDD que les utilisateurs doivent faire vivre tout en ayèant le droit de créer leurs propres tables, crées alors un tablespace destiné à recevoir la BDD et crées un tablespace pour tes utilisateurs (ou réutilise USERS) : tu auras ainsi la certitude que les tables créées par les utilisateurs ne viendront pas grignoter l'espace nécessaire à la BDD
Bonjour
Merci pour tes explications. Je comprends un peu mieux certaines choses maintenant. Cependant si je veux qu'un utilisateur ait accès à plusieurs tablespaces, je ne trouve pas l'endroit pour le faire. Il a bien son tablespace par défaut où je trouve les tables auxquelles je peux lui donner des accès, mais je ne parviens pas à lui en affecter un autre....
De plus j'ai une autre grosse interrogation : les sauvegardes
Quoi sauvegarder, comment ?????
Encore merci pour votre aide
Merci pour tes explications. Je comprends un peu mieux certaines choses maintenant. Cependant si je veux qu'un utilisateur ait accès à plusieurs tablespaces, je ne trouve pas l'endroit pour le faire. Il a bien son tablespace par défaut où je trouve les tables auxquelles je peux lui donner des accès, mais je ne parviens pas à lui en affecter un autre....
De plus j'ai une autre grosse interrogation : les sauvegardes
Quoi sauvegarder, comment ?????
Encore merci pour votre aide
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Salut,
un utilisateur n'a qu'un tablespace par défaut, mais il peut décider de créer sa table ou son index sur un autre tablespace.
dans la mesure ou un utilisateur A autorise l'utilisation de ses tables et indexes à un utilisateur B, ce dernier pourra les utiliser quels que soient les tablespaces où sont stockés ces objets.
nb: il y a des notions de quota sur les tablespaces que je ne connais pas qui pourraient limiter ces deux assertions
concernant la sauvegarde, tu as le choix
1. Tu peux arrêter ta base (manuellement ou selon planification) : tu envoies un shutdown immediate (arrêt de l'instance en déconnectant les utilisateurs mais sans pouvoir déconnecter les DBA), tu sauvegardes les fichiers composant le tablespace et tu redémarres la base avec startup
2. Tu ne veux pas arrêter ta base et tu sais qu'il y a de grosses périodes d'inactivité (ie entre 18h et 8h) : tu planifies à 22h un export de ta base avec l'utilitaire EXP qui va enregistrer dans un fichier les déclarations de tes objets et les données de tes tables
3. Tu ne peux pas arrêter ta base : comme les tablespaces peuvent devenir très gros et qu'Oracle s'en sert comme il le veut, la seule méthode pour avoir la garantie que le tablespace (ou plutôt les fichiers le composant) n'évolue pas pendant la sauvegarde est de demander ALTER TABLESPACE nom_tablespace BEGIN BACKUP; Cette commande indique à Oracle de ne plus enregistrer aucune activité dans le tablespace le temps de le sauvegarder ; l'activité consignée dans les redologs est alors archivée (dans des archivelogs) pour pouvoir ensuite être jouée et impacter les modifications lors du ALTER TABLESPACE nom_tablespace END BACKUP;
un utilisateur n'a qu'un tablespace par défaut, mais il peut décider de créer sa table ou son index sur un autre tablespace.
dans la mesure ou un utilisateur A autorise l'utilisation de ses tables et indexes à un utilisateur B, ce dernier pourra les utiliser quels que soient les tablespaces où sont stockés ces objets.
nb: il y a des notions de quota sur les tablespaces que je ne connais pas qui pourraient limiter ces deux assertions
concernant la sauvegarde, tu as le choix
1. Tu peux arrêter ta base (manuellement ou selon planification) : tu envoies un shutdown immediate (arrêt de l'instance en déconnectant les utilisateurs mais sans pouvoir déconnecter les DBA), tu sauvegardes les fichiers composant le tablespace et tu redémarres la base avec startup
2. Tu ne veux pas arrêter ta base et tu sais qu'il y a de grosses périodes d'inactivité (ie entre 18h et 8h) : tu planifies à 22h un export de ta base avec l'utilitaire EXP qui va enregistrer dans un fichier les déclarations de tes objets et les données de tes tables
3. Tu ne peux pas arrêter ta base : comme les tablespaces peuvent devenir très gros et qu'Oracle s'en sert comme il le veut, la seule méthode pour avoir la garantie que le tablespace (ou plutôt les fichiers le composant) n'évolue pas pendant la sauvegarde est de demander ALTER TABLESPACE nom_tablespace BEGIN BACKUP; Cette commande indique à Oracle de ne plus enregistrer aucune activité dans le tablespace le temps de le sauvegarder ; l'activité consignée dans les redologs est alors archivée (dans des archivelogs) pour pouvoir ensuite être jouée et impacter les modifications lors du ALTER TABLESPACE nom_tablespace END BACKUP;
