Newsgroup: it.comp.software.database
Titolo: Tablespace in Oracle

Qual'è la differenza di inserire un utente in fase di creazione in un 
tablespace come User,System,Temp.... ? 

 
System dovrebbe essere solo per gli oggetti di sistema, quindi non 
metterci niente che non sia di sys.
Temp ti serve per oggetti temporanei e operazioni di sort quindi, se e' 
stata creata come temporary (che e' il default dalla 8i in avanti), non 
puo' essere la tablespace dove vai a mettere oggetti permanenti di 
nessun utente.
Undo (visto che sei in 9i) serve per la gestione automatica dei vecchi 
rollback. Anche li' niente oggetti di utenti.
User la crea il dbca come base per gli utenti. Se stai solo giocando 
puo' andare bene.
In genere, per ragioni amministrative e non di performance, e' bene 
avere una tablespace per utente, piu' indici.
Puoi anche avere tablespace per alcune funzioni particolari: aree di 
stage, oggetti partizionati, LOB, oggetti di grandi dimensioni, gestioni 
particolari dello storage, etc...
L'importante, se non vuoi essere fulminato dai dba futuri che vedranno 
il tuo lavoro, e' di non mischiare tutto e di non lavorare nella sys.
Ciao
-- 
Fabrizio Magni
fabrizi...@mycontinent.com
replace mycontinent with europe

 tablespace per utente, piu' indici.
Io attribuisco a piu' utenti (una decina) lo stesso tablespace, la ragione
e' che accedono al DB molto di rado e lo modificano con la stessa frequenza.
  Raffaello


Anch'io faccio condivedere a piu' utente alcune tablespace, anche se, il 
mio criterio di divisione, e' basato piu' sulla mole dati che sulla 
modalita' di accesso.
Se ho venti schema, da pochi mega ciascuno, non ho molta voglia di 
gestire molte tablespace. Preferisco averne una sola.
La mole esigua mi permette anche operazioni veloci di spostamento 
oggetti (se dovesse presentarsene la necessita') e politiche di backup 
"snelle".
Comunque ritengo che la "best practice" sia dettata piu' dal buon senso 
che da regole predefinite.
Ciao
PS: Rimane da definire quanto buon senso un amministratore abbia...


 ha scritto nel messaggio 
news:4263...@x-privat.org...


 
Non capisco la tua domanda sull'eredita'.
In ogni caso, all'utente non ammministrativo, che deve solo operare sui 
dati (chiamiamolo "operatore"), concedi: "create session".
Dall'utente admin granta select, insert, update, delete sulle "target" 
all'utente "operatore".
Per la tablespace concedi pure la stessa dell'utente admin tanto non 
devi creare segmenti con "operatore" (significa anche che non devi 
preoccuparti di impostare clausule di quota).
Nota che "operatore" puo' vedere le tabelle di admin solo con nomi 
"fully qualified" cioe' come admin.nome_tabella
Se vuoi vederle come nome_tabella (senza il nome del proprietario 
davanti) hai bisogno di creare sinonimi).


 hai bisogno di creare sinonimi).
Premetto che uso Oracle 9i ed è tutto grafico e niente sql, quindi ho 
necessità di saperlo fare Enterprise Manager Console 

 
Tutto quello che ti ho descritto funziona anche con OEM.
In ogni caso... apri OEM e crea un utente GUEST a cui assegni una 
tablespace di default, la password e il privilegio di create session 
(togli quello di connect).
Poi crea due ruoli uno chiamato, per esmpio, admin_data_read e uno 
admin_data_modify.
In italiano dovresti trovare un tab "oggetto". Da li' concedi i 
privilegi sugli oggetti.
Quindi al ruolo admin_data_read concedi solo le select su tabelle e 
viste di admin mentre a admin_data_modify quelli di update, delete, insert.
Prossimo passo: torna su guest a cui concederai i ruoli appena creati.
Ora GUEST potra' leggere e modificare i dati delle tabelle di AMDIN.
ATTENZIONE:
Se crei un nuovo oggetti dovrai aggiungere al ruolo i privilegi su cio' 
che hai appena creato, altrimenti l'utente GUEST non potra' lavorci.
Ti cosiglio i ruoli in questo modo se dovessi creare GUST2 che deve 
avere i privilegi di sola lettura su admin le operazioni di grant 
saranno molto piu' snelle.
Buona mattinata


 ha scritto nel messaggio 
news:4264A670...@mycontinent.com...


 necessità di saperlo fare Enterprise Manager Console
Perche` sei tu che vuoi usare esclusivamente Enterprise Manager.
Personalmente, gestisco un mio db di sviluppo direttamente via SQL*Plus,
Enterprise Manager, TOAD, SQLTools, Squirrel...
Henryx