Architettura dell'RDBMS Oracle
Gestione dei dati nel database
Dimensionamento degli oggetti Oracle
Tipi di dati Oracle
Creazione del database
Attivazione e arresto del database
Salvataggio e ripristino del database
Salvataggio logico dei dati
Salvataggio fisico offline
Salvataggio parziale del database
Salvataggio a database attivo
Gestione di Utenti, Profili, Ruoli
Grant
Revoke
Principali programmi di amministrazione
Un database ORACLE e’ composto delle seguenti strutture fisiche:
· Database Files Contengono le strutture logiche e i dati del database
· Redo Log Files Registrano le modifiche effettuate sul database
· Control Files Registra la struttura fisica del database
· Parameter File Contiene i parametri di inizializzazione del database
Un' istanza ORACLE e’ composta dalla System Global Area (un insieme di buffer di shared memory) e dai Processi di background (processi di sistema che gestiscono il database in maniera asincrona).
La Program Global Area e’ un' area di memoria che contiene i dati di un singolo processo utente ed e’ allocata da ORACLE quando un utente si collega al database e una sessione viene creata.
Un' applicazione che lavora su una macchina client crea un processo utente, che genera a sua volta un processo server sulla macchina dove risiede il database: questo processo comunica con la SGA.
La System Global Area e’ composta di diversi buffer:
· Database Buffer Cache
· Shared SQL Area
· Redo Log Buffer
La Database Buffer Cache contiene una copia dei dati letti dal disco ed e’ composta di:
· buffer liberi (Free Buffers)
· buffer occupati dai dati letti (Pinned Buffers)
· buffer i cui dati sono stati modificati (Dirty Buffers)
La Shared SQL Area e’ l' area di memoria dove vengono eseguiti gli statements SQL.Due processi che eseguono lo stesso statement condividono la stessa area di memoria.
La Shared SQL Area contiene:
· il testo dello statement SQL
· la forma parsificata ("compilata")
· l' Execution plan
· informazioni del Dizionario Dati
Il processo di background DBWR (Database Writer) gestisce la Database Buffer Cache in modo che i processi utente trovino sempre buffer liberi dove leggere i dati.
Il processo DBWR scrive su disco, nei Data Files, il contenuto dei Dirty Buffers cosicche’ essi ritornano nello stato di Free Buffers. Se necessita ulteriore spazio utilizza i blocchi della lista LRU (least recently used).
I blocchi di una transazione possono non essere scritti sul database al momento della commit: l' integrita’ del database e’ garantita dalla scrittura dei blocchi committati nei Redo Log Files.
La scrittura sul database avviene quando la Database Buffer Cache e’ piena o quando si verifica un checkpoint.
Il checkpoint viene eseguito dopo che uno specifico numero di blocchi Redo Log sono stati scritti oppure quando il Redo Log File corrente e’ pieno e si verifica lo switch su un altro Redo Log File.
Il checkpoint viene eseguito normalmente dal processo LGWR ma in casi particolari si puo’ attivare l' apposito processo di background CKPT per alleggerire il processo LGWR di questo compito.
ORACLE registra tutti i cambiamenti fatti sul database nel Redo Log Buffer.
Il processo di background LGWR (Redo Log Writer) e’ incaricato di scrivere queste informazioni sul disco, nei Redo Log Files, al commit di una transazione oppure quando il buffer e’ pieno (in questo caso i blocchi diventeranno permanenti solo se la transazione verra’ conclusa normalmente).
Se i Redo Log Files sono mirrorati la stessa informazione viene scritta su piu’ Redo Log Files.
Il processo di background ARCH (Archiver) gestisce l'archiviazione automatica dei Redo Log Files on line sull' apposito device di archiviazione (disco o nastro) quando questi sono pieni; essi servono per ripristinare i dati del database in caso di necessita’. ARCH e’ un processo opzionale ed e’ attivato quando i Redo Log Files sono usati in modo ARCHIVELOG ed e’ abilitata l' archiviazione automatica (questi parametri sono specificati nel Parameter file che viene letto allo startup dell' istanza).
Il processo di background Dnnn (Dispatcher) permette che tutti i processi utente condividano un certo numero di processi server. Senza il Dispatcher ogni processo utente necessita un processo server dedicato, invece in un server multi-threaded un numero limitato di processi server possono gestire tutti i processi utente. Il server multi-threaded necessita di SQL*Net Version 2 e ogni processo che si collega al Dispatcher deve farlo tramite SQL*Net, anche se i due processi sono sulla stessa macchina.
Il processo di background PMON (Process Monitor) esegue il recovery quando un processo utente fallisce:
· toglie il process ID dalla lista dei processi attivi
· fa rollback delle transazioni
· rilascia i lock
· libera le risorse della SGA e pulisce la cache
Il processo di background SMON (System Monitor) gestisce lo startup e lo shutdown del database e in caso di fallimento dell' istanza esegue l' opportuno recovery.
Ripulisce il database eseguendo gli opportuni rolling-back e rolling-forward.
Ripulisce gli eventuali temporary segment che da tempo non vengono utilizzati.
Compatta i segmenti liberi contigui per creare segmenti piu’ larghi disponibili sul Data file per la creazione di nuovi oggetti o per la crescita di quelli esistenti.
Il processo di background RECO (Recoverer) gestisce le transazioni distribuite e il meccanismo di Two-phase Commit.
Il Control File e’ un piccolo file binario che contiene il nome del database e il riferimento ai file fisici del database ed e’ necessario per aprire il database poiche’ contiene tutte le informazioni necessarie alla localizzazione delle varie risorse. Per tale motivo vengono generalmente poste piu’ copie di tale file su dischi differenti.
Un database ORACLE e’ composto delle seguenti strutture logiche:
· Tablespaces
· Segments
· Extents
· Blocks
Il Tablespace e’ il partizionamento logico fondamentale del database. E' costituito di segmenti e di spazio libero. Si appoggia su uno o piu’ file del sistema operativo (database files). In un database deve esistere almeno il tablespace SYSTEM, ma solitamente esistono i seguenti tablespace (che vengono creati dalla procedura di installazione di default):
E' consigliabile dividere il tablespace USERS in due tablespace (eg. USER_TAB con le tabelle e USER_IND con gli indici) residenti su dischi diversi per accedere in parallelo a una tabella e al suo indice, migliorando le performance.
Puo’ essere utile dividere ancora il tablespace USER_TAB in due tablespace separando le tabelle con differenti esigenze di backup.
E’ inoltre notevolmente vantaggioso sfruttare l’eventuale striping sui dischi che il sistema operativo offre.
Il Segmento e’ un set di uno o piu’ Extent contenente i dati di un particolare oggetto del database:
· Data
segment contiene i dati di una tabella o di un cluster
· Index segment contiene
i dati di un indice
· Rollback segment contiene
un' immagine dei dati prima della modifica
· Temporary segment contiene
temporaneamente i dati su cui vengono fatti ordinamenti
o totalizzazioni
· Bootstrap segment contiene
le definizioni del dizionario necessarie quando il database viene aperto
Esistono alcuni parametri di allocazione dello spazio nel Segmento:
· INITIAL dimensione
del primo extent del segmento
(default 5 blocchi, cioe’ 10K bytes)
· NEXT dimensione
del successivo extent del segmento(default 5
blocchi, cioe’ 10K bytes)
· MAXEXTENTS numero
massimo di extent (default 121)
· MINEXTENTS numero
minimo di extent (default 1, per i rollback segment 2)
· PCTINCREASE percentuale
di incremento di un extent rispetto al precedente
(default 50 percent)
Se non vengono specificati nella creazione dello specifico oggetto, vengono presi quelli di default del Tablespace a cui l' oggetto appartiene.
L' Extent e’ un insieme di Blocchi logici contigui.
Il Blocco logico (o blocco ORACLE) e’ la piu’ piccola unita’ di Input/Output usata dal database.
Corrisponde a uno o piu’ blocchi fisici sul disco.
La dimensione del blocco logico dipende dal parametro DB_BLOCK_SIZE del file parameter file (INIT.ORA) e non puo’ essere cambiata dopo la creazione del database.
La dimensione del blocco ORACLE e’ tipicamente 2K o 4K bytes.
La dimensione del blocco fisico dipende dal sistema operativo: su UNIX ha valori che dipendono dal sistema operativo e dal tipo di file system.
Il Blocco logico e’ suddiviso in diverse porzioni:
· Header contiene
l' indirizzo del blocco e il tipo di segmento
· Row directory contiene
informazioni sulle righe attualmente nel blocco
· Free space e’
lo spazio disponibile per successivi update o insert
· Row data sono
i dati dell' oggetto (tabella, indice, ecc)
Esistono due parametri di utilizzazione dello spazio nel Blocco logico:
· PCTFREE indica
la percentuale di spazio del blocco da riservare per le successive
update delle righe inserite nel blocco (quando lo spazio libero
raggiunge questo valore il blocco viene tolto dalla insert block
list)
· PCTUSED indica
la percentuale di spazio usato sotto la quale il blocco viene utilizzato
per l'inserimento di nuove righe (viene rimesso nella insert block
list)
Un basso PCTFREE:
· Permette
di riempire di piu’ il blocco e di risparmiare blocchi
· Diminuisce le
performance perche’ Oracle deve riorganizzare piu’ frequentemente i blocchi
Un alto PCTFREE:
· Riserva
piu’ spazio per le future update e utilizza piu’
blocchi
· Aumenta le performance
perche’ Oracle deve riorganizzare piu’ raramente i blocchi
Un basso PCTUSED:
· Aumenta
le performance perche’ rientrano raramente nella insert block list
· Aumenta lo spazio
inutilizzato
Un alto PCTUSED:
· Diminuisce
le performance perche’ rientrano frequentemente nella insert block list
· Migliora l' utilizzo
dello spazio.
Per ottenere le migliori prestazioni dal database Oracle e’ necessario dimensionare correttamente gli oggetti in esso contenuti e definirne un corretta allocazione fisica. Nel seguito vengono riportati alcuni elementi relativi ai principali oggetti di Oracle
Il dimensionamento di ogni singola tabella dipende dalla dimensione di ciascuna riga, dal numero delle righe e dagli overhead presenti a livello di riga, di blocco e di tabella. La dimensione di ciascuna riga dipende ovviamente dai dati in essa presenti, il prossimo capitolo riporta i tipi di dati presenti in Oracle.
Oracle memorizza solo i dati necessari di una tabella, pertanto il tracciato record non e’ fisso ma variabile.
Il dimensionamento di un indice dipende dalla dimensione della chiave, dal numero di righe e dagli overhead presenti a livello di chiave, di blocco e di indice. Oracle utilizza gli alberi bilanciati come struttura dati per gli indici.
Il numero e la dimensione dei segmenti di rollback dipende dalla tipologia di transazioni presenti sul sistema. In genere un sistema OLTP richiede molti segmenti di rollback con dimensioni ridotte mentre un sistema con programmi batch pesanti necessita di pochi (anche un solo) rollback ma di grandi dimensioni.
Per ogni utente Oracle viene definita una tablespace temporanea. Su tale tablespace vengono allocati gli spazi temporanei necessari per alcune operazioni su grandi moli di dati (eg. Una creazione di un indice o una selezione con clausola di GROUP BY).
L’RDBMS Oracle supporta i seguenti tipi di dati:
|
Tipo di dato |
Descrizione |
|
CHAR(n) |
(fino alla vers. 6.x): Stringa costituita al massimo da n caratteri. (vers. 7 e succ.): stringa costituita esattamente da n caratteri; se la lunghezza effettiva della stringa e’ m < n, Oracle aggiunge in coda al record (n - m)caratteri blank in modo da rendere la lunghezza comunque di n caratteri. |
|
VARCHAR2(n) |
Stringa costituita al massimo da n caratteri. Non puo’ comunque eccedere la lunghezza di 2000 caratteri. |
|
VARCHAR(n) |
Nella versione 7 e’ analogo al VARCHAR2; si prevede che, nelle future versioni di Oracle, diventi un tipo di dato a se stante. |
|
LONG |
Puo’ contenere stringhe lunghe fino a 2GB. E’ utile ma ha diverse limitazioni( una tabella puo’ contenere solo un campo LONG, non si possono fare ricerche su sottostringhe al suo interno, ecc...) |
|
NUMBER |
Dati di tipo numerico. Accetta numeri interi o decimali purche’ il numero complessivo di cifre sia al massimo 38 |
|
NUMBER(p) |
Accetta solo numeri interi con un numero massimo di p cifre |
|
NUMBER(p,s) |
p = precision, num. max.cifre s = scale, num. max di cifre decimali. Se s e’ negativo, il dato viene arrotondato a s cifre a sinistra del punto decimale: ad es. valore = 1234567.89 NUMBER(7,-2) ==> 1234600 |
|
DECIMAL(p,s) |
E’ sinonimo di NUMBER(p,s) |
|
INTEGER |
Sinonimo di NUMBER(38). |
|
SMALLINT |
Sinonimo di NUMBER(38). |
|
DATE |
Usato per contenere informazioni su data e tempo, piu’ precisamente su: · secolo E’ possibile selezionare un campo DATE con numerosissimi formati. |
|
ROWID |
Tipo di dato particolare che e’ restituito dalla pseudo-colonna ROWID che rappresenta l' indirizzo fisico del record. E' normalmente visualizzato in esadecimale. |
|
RAW(n) |
Stringa binaria della lunghezza specificata (max 2000 bytes). puo’ essere utilizzato per memorizzare su tabelle programmi applicativi in altri linguaggi immagini grafiche. |
|
LONG RAW |
Stringa binaria come RAW, con caratteristiche simili al tipo LONG. |
La creazione di un database ORACLE e’ composta dai seguenti passi:
· Scegliere
il nome dell' istanza (da 1 a 8 lettere)
· Copiare e modificare
il parameter file
· Settare le appropriate
varabili d' ambiente del sistema operativo
· Entrare in SQLDBA,
collegarsi come INTERNAL e attivare l' istanza
· Creare il database
Se il nome dell' istanza e’ A, il suo parameter file si chiamera’ initA.ora e risiedera’ nella directory $ORACLE_HOME/dbs.
Il parameter file viene letto dall' RDBMS solo alla creazione e all'attivazione del database, quindi per rendere effettivo un nuovo parametro aggiunto all' init.ora bisogna fermare e riattivare il database.
I compiti del parameter file sono:
· Dimensionare
i diversi buffer della System Global Area
· Settare i valori
di default del database
· Settare i limiti
del database
· Settare gli attributi
fisici del database (solo alla creazione)
· Specificare i
control file
· Ottimizzare le
performance modificando i settaggi di memoria
· Definire vari
parametri operativi
Esempi:
DB_NAME nome dell' istanza
CONTROL_FILES path dei control file
DB_BLOCK_SIZE dimensione in byte del blocco logico
DB_BLOCK_BUFFER dimensione in blocchi della SGA
IFILE nome di un altro parameter file da inglobare in questo
OPEN_CURSORS massimo numero di cursori che un utente puo’ aprire
SQL_TRACE Abilita o disabilita la trace sulle sessioni
OPTIMIZER_MODE specifica a Oracle il tipo di ottimizzatore da usare
Per vedere come sono stati settati i parametri in un database funzionante: entrare in SQLDBA, collegarsi come INTERNAL ed eseguire il comando SHOW PARAMETER.
Esempio di settaggio delle variabili di ambiente in UNIX (esempio in bourne shell):
$ ORACLE_SID=a
$ ORACLE_HOME=/home2/oracle
$ ORACLE_TERM=vt100
$ export ORACLE_SID ORACLE_HOME ORACLE_TERM
Per attivare il database: entrare in SQLDBA, collegarsi come INTERNAL ed eseguire il comando STARTUP.
Con questo comando viene creata la Sistem Global Area e vengono attivati almeno quattro processi di background (DBWR, LGWR, PMON, SMON).
Per creare il database usare il comando CREATE DATABASE, il quale:
· Crea il control file, il database file e i log file
· Crea il dizionario dati
· Crea gli utenti SYS/change_on_install e SYSTEM/manager
· Crea il rollback segment SYSTEM
Dopo la creazione del database eseguire in SQLDBA il comando: @$ORACLE_HOME/rdbms/admin/catalog che crea le viste sul dizionario dati comunemente usate.
Il dizionario dati e’ la fonte centrale di informazioni sull' RDBMS stesso e sugli utenti del database.
Il dizionario dati consiste in tabelle e viste dalle quali possiamo estrarre informazioni con il comando SELECT. Le informazioni del dizionario dati vengono modificate dal sistema quando eseguiamo un comando DDL, ma non possiamo modificarle con i comandi DML.
Le tabelle e le viste del dizionario dati si dividono in tre categorie:
· prefisso
DBA_ accessibili solo dai DBA, contengono
informazioni su ogni oggetto del database
· prefisso USER_ accessibili
da ogni utente, contengono informazioni sugli
oggetti di proprieta’ dell' utente
· prefisso ALL_ accessibili
da ogni utente, contengono informazioni sugli
oggetti accessibili all' utente
Attivazione e arresto del database
L' attivazione di un database ORACLE e’ composta dai seguenti passi:
· Entrare
in SQLDBA
· Collegarsi come
INTERNAL
· Eseguire il comando
STARTUP
Le fasi dello Startup sono tre:
· NOMOUNT start
dell' istanza
· MOUNT start
dell' istanza + apertura del control file
· OPEN start
dell' istanza + apertura del control file, dei data file e dei
log file
Si puo’ passare da una fase all' altra nel seguente modo:
· ALTER
DATABASE MOUNT (da NOMOUNT a MOUNT)
· ALTER DATABASE
OPEN (da MOUNT a OPEN)
· ALTER DATABASE
CLOSE (da OPEN a MOUNT)
· ALTER DATABASE
DISMOUNT (da MOUNT a NOMOUNT)
L' arresto di un database ORACLE e’ composta dai seguenti passi:
· Entrare
in SQLDBA
· Collegarsi come
INTERNAL
· Eseguire il comando
SHUTDOWN
Lo Shutdown puo’ avvenire in tre modi:
· NORMAL aspetta
che gli utenti connessi terminino le loro sessioni normalmente
· IMMEDIATE esegue
il rollback delle transazioni e chiude le sessioni aperte
· ABORT chiude
immediatamente il database, quindi bisogna farlo seguire da uno
Startup e da uno Shutdown normal che esegua il rollback delle
transazioni
Il bootstrap e lo shutdown di un database sono spesso effettuati in modo automatico direttamente dagli script di bootstrap e shutdown del sistema. In tal caso il DBA deve approntare gli opportuni script da lanciare (eg. dbstart e dbshut).
Server Manager
Le differenti versioni di Oracle offrono differenti programmi di amministrazione. A partire dalla versione 7.0 e' presente il programma Server Manager (generalmente attivato con svrmgr). Dalla versione 7.3 il programma sqldba non e' piu' supportato.
Benche’ il ripristino dei dati su un RDBMS sia uno dei peggiori incubi che un DBA possa avere e’ necessario esservi sempre preparati.
E’ fondamentale definire in maniera precisa quali siano le strategie di backup da effettuasi che debbono sempre avere ampi margini di sicurezza e ridondanza. E’ necessario seguire strettamente le procedure definite. E’ necessario definire un piano di disaster recovery. E’ opportuno effettuare prove di recovery dei dati in modo da essere preparati in caso di problemi e, soprattutto essere certi che tutto quanto funzioni correttamente.
Le scelte che si presentano all’amministratore Oracle sono parecchie. E’ possibile effettuare salvataggi logici o fisici dei dati. E’ possibile salvare completamente la base dati o solo parte di essa. La frequenza di salvataggio puo’ essere la piu’ svariata cosi’ come la ciclicita’ dei nastri di salvataggio. E’ possibile effettuare salvataggi mentre il database e’ attivo oppure a database disattivo. E’ possibile effettuare salvataggi periodici oppure che arrivano sino all’ultima transazione effettuata. E’ possibile gestire manualmente il salvataggio dei log oppure farlo effettuare in maniera automatica. …
Non esiste una strategia "perfetta" ma ogni situazione va esaminata nelle sue caratteristiche. E’ comunque piu’ che opportuno adottare una politica conservativa che tenga dovuto conto della legge di Murphy sui backup.
Naturalmente ad ogni strategia di backup ed ad ogni tipologia di errore corrispondono una serie di modalita’ di ripristino dei dati. I casi possibili sono pertanto molto ampi ed, in genere, richiedono l’intervento del DBA.
Per effettuare il salvataggio logico dei dati viene utilizzata l’utility export. Con tale utility e’ possibile effettuare il salvataggio dell’intero database, di un utente, un insieme di tabelle su file.
Per il ripristino dei dati viene utilizzata la funzione di utilita’ import che effettua l’operazione inversa. Con l’utility di import e’ possibile recuperare l’intero contenuto del file salvato o parte di esso.
Principali caratteristiche:
· Poiche’ si tratta di un salvataggio logico dei dati e’ possibile recuperare anche una sola tabella salvata. Con le altre modalita’ di backup e’ possibile recuperare un intero datafile che puo’ contenere centinaia di tabelle.
· Vengono salvati i soli dati presenti.
· Oltre che per effettuare salvataggi le utility vengono anche utilizzate per "deframmentare" la base dati o per spostare dati verso utenti/database differenti.
· Il database deve essere attivo.
· Per basi dati di grandi dimensioni il salvataggio, e soprattutto il ripristino, possono richiedere parecchio tempo.
Per effettuare un salvataggio fisico della base dati deve essere effettuato lo shutdown del database e quindi debbono essere salvati tutti i file del database: data file, log file, control file. E’ inoltre opportuno che venga salvato anche il file di parametri del database (initX.ora). Il salvataggio viene effettuato con una utility del sistema operativo ospite. Su Unix generalmente sono utilizzate dd (sicuramente la piu’ utilizzata e valida nella maggior parte dei sistemi), tar, cpio, cp.
Terminato il salvataggio si effettua un normale bootstrap del database.
In caso di necessita’ di ripristino vengono recuperati tutti i file e si effettua un normale bootstrap del database.
Principali caratteristiche:
· In
caso di recupero si effettua una ricopertura totale dei dati.
· Vengono salvati
tutti i file presenti.
· Il database deve
essere disattivo.
· Le operazioni
sono piuttosto veloci (dipendono dalla velocita’ dei dischi e/o dei nastri
utilizzati).
Nei file di log vengono salvate tutte le transazioni effettuate. I file di log vengono utilizzati circolarmente. Se e’ attiva la modalita’ di ARCHIVELOG il processo opzionale ARC si occupa di salvare i file di log correntemente non utilizzati. Il salvataggio puo’ avvenire in maniera manuale o automatica. Anche in questo ultimo caso e’ comunque necessario l’intervento dell’operatore/DBA per la pulizia/sostituzione dei supporti fisici su cui viene effettuato il salvataggio.
Il salvataggio dei file di log permette la ricostruzione, da parte dell’RDBMS stesso, della situazione finale del database partendo da un salvataggio fisico e riapplicando tutte le transazioni occorse. Le istruzioni da utilizzare sono quelle di RECOVER DATABASE, la casistica possibile e’ molto ampia (eg. ripartenza da backup totale e riapplicazione di tutti i log, ripartenza da situazione attuale+backup di un tablespace e riapplicazione dei log solo a tale tablespace
Principali caratteristiche:
· E’
possibile risalire sino al momento immediatamente precedente all’ultima transazione
effettuata.
· Il database subisce
una penalizzazione prestazionale (molto limitata se ben configurato).
· L’operativa e’
piu’ complessa.
Quando e’ attivo il salvataggio dei log e’ possibile effettuare il salvataggio di un tablespace singolo. Il tablespace puo’ essere attivo o disattivo. Poiche’ il salvataggio avviene in modalita’ non sincronizzata e’ necessario utilizzare i comandi di ALTER TABLESPACE tablespacename {BEGIN BACKUP | END BACKUP} per notificare all’RDBMS l’inizio e la fine delle attivita’ di backup.
Il salvataggio di un tablespace attivo ha un notevole impatto prestazionale.
Le modalita’ di ripristino sono analoghe a quelle del paragrafo precedente.
Su alcune installazioni e’ necessario fornire un servizio 7x24. In tali casi e’ necessario effettuare un backup a database attivo. Tale salvataggio puo’ essere effettuato solo se e’ attiva la modalita’ ARCHIVELOG. Debbono essere singolarmente salvate tutte le tablespace presenti con la modalita’ descritta in precedenza.
La gestione della sicurezza del database avviene tramite la creazione degli utenti e degli schema a loro associati.
Quando si crea un utente viene automaticamente creato uno schema con lo stesso nome a lui associato: l' utente e’ owner di tutti gli oggetti del suo schema.
La creazione e la gestione degli utenti sono compiti del Database Administrator.
Al momento della creazione dell' utente vengono definiti alcuni limiti alla sua attivita’ sul database:
Il profilo DEFAULT (assegnato di default all' utente) permette un uso illimitato delle risorse di sistema.
Assegnandogli invece un profilo personalizzato possiamo limitare, tra l' altro:
· La
quota di CPU per sessione e per chiamata
· Il numero di
letture logiche per sessione e per chiamata
· Il numero di
sessioni per utente
· La quota privata
di SGA
La vista di sistema DBA_USERS contiene le informazioni sugli utenti del database.
Esempio:
SELECT * FROM dba_users;
USERNAME USER_ID PASSWORD DEFAULT_TAB TEMPORARY_TAB CREATED PROFILE
-------- ------- ---------------- ----------- ------------- --------- -------
SYS 0 1F525B7270F5D52D SYSTEM TEMP 15-OCT-95 DEFAULT
SYSTEM 5 78D8CE4865E38E8D SYSTEM TEMP 15-OCT-95 DEFAULT
USR1 8 599A3AAEA47C5F48 USERS TEMP 15-OCT-95 DEFAULT
DEMO 11 4646116A123897CF USERS USERS 21-APR-95 DEFAULT
La vista di sistema DBA_TS_QUOTAS contiene le informazioni sui limiti di utilizzo dei tablespace da parte degli utenti (il valore -1 significa quota illimitata).
Esempio:
SELECT * FROM dba_ts_quotas;
TABLESPACE_NAME USERNAME BYTES MAX_BYTES BLOCKS MAX_BL
--------------- ---------- ---------- ---------- ---------- ------
USERS DEMO 3762176 5242880 1837 2560
USERS USR1 405186560 -1 197845 -1
TEMP USR1 0 512000 0 250
IDX USR1 128901120 -1 62940 -1
Il Database Administrator puo’, in caso di necessita’, interrompere la sessione di un utente.
Questa azione:
· esegue
il rollback della transazione dell' utente
· rilascia tutti
i lock sulle tabelle modificate dalla utente
· libera le risorse
di memoria occupate dalla utente
Il Database Administrator permette a ogni singolo utente di fare una gamma piu’ o meno ampia di operazioni sul database e sui suoi oggetti concedendogli e revocandogli certi privilegi.
Puo’ concedere certi privilegi a tutti gli utenti (a PUBLIC) e la possibilita’ di compiere operazioni delicate a un singolo utente.
Puo’ restringere l' accesso ai dati e la loro modifica.
Puo’ limitare la possibilita’ di cambiare le strutture del database.
I privilegi sono i diritti di compiere determinate azioni.
Esistono due tipi di privilegi:
I privilegi sono molto numerosi, gli utenti possono essere molti e con mansioni molto differenziate:
per semplificare la gestione della sicurezza il Database Administrator puo’ usare i Ruoli.
Il Ruolo e’ un insieme di privilegi correlati fra loro, ha un nome e viene assegnato agli utenti o ad altri ruoli.
Alla creazione del database esistono dei ruoli di default con diversi gradi di azione:
E' possibile ovviamente creare dei ruoli personalizzati adatti alle diverse figure professionali che accedono al database.
Dopo aver definito un ruolo il Database Administrator lo assegna a tutta una classe di utenti (Impiegati, Cassieri, Responsabile, ecc).
Assegnando ad un utente un insieme di ruoli l’utente ereditera’ tutti i privilegi dei ruoli assegnati.
I privilegi sugli oggetti dipendono dal tipo di oggetto a cui si riferiscono:
|
Object privilege |
Table |
View |
Sequence |
Procedure |
Snapshot |
|
ALTER |
X |
X |
|||
|
DELETE |
X |
X |
|||
|
EXECUTE |
X |
||||
|
INDEX |
X |
||||
|
INSERT |
X |
X |
|||
|
REFERENCES |
X |
||||
|
SELECT |
X |
X |
X |
X |
|
|
UPDATE |
X |
X |
Assegna ruoli o privilegi (di sistema o sugli oggetti) a utenti o ruoli.
Un utente puo’ usare questo comando se e’ in possesso della clausola WITH ADMIN OPTION.
Sintassi:
1.GRANT {system_priv|role}
TO {user|role|PUBLIC} [WITH ADMIN OPTION]
2.GRANT {object_priv|ALL} [ (column1,...) ] ON object
TO {user|role|PUBLIC} [WITH GRANT OPTION]
Parametri:
system_priv: il privilegio di sistema da assegnare. Tra i piu’ importanti privilegi si ricorda CREATE ANY oggetto, DROP ANY oggetto, SELECT
object_priv: il privilegio sull' oggetto da assegnare.
object: l' oggetto sul quale vengono assegnati i privilegi.
role: il ruolo da assegnare; un ruolo e’ un insieme di privilegi. Quelli gia’ definiti dal sistema sono CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE, IMP_FULL_DATABASE.
user: l’utente a cui e’ assegnato il privilegio
role: il ruolo a cui e’ assegnato il privilegio
PUBLIC: se indicato, significa che tutti gli utenti riceveranno il privilegio indicato.
WITH ADMIN OPTION: permette all’utente specificato di poter assegnare a sua volta i privilegi di sistema e i ruoli che ha ricevuto ad altri utenti.
WITH GRANT OPTION: permette all’utente specificato di poter assegnare a sua volta i privilegi sull’ oggetto che ha ricevuto ad altri utenti.
Esempi:
1.GRANT connect TO demo;
2.GRANT select,insert,update,delete ON anag_operatori TO gestore;
Toglie privilegi a utenti e ruoli.
Un utente puo’ usare questo comando se e’ in possesso della clausola WITH ADMIN OPTION.
Sintassi:
1.REVOKE {system_priv|role} FROM {user|role|PUBLIC}
2.REVOKE {object_priv|ALL} ON object
FROM {user|role|PUBLIC} [CASCADE CONSTRAINTS]
Parametri:
system_priv: il privilegio di sistema da togliere.
object_priv: il privilegio di sistema da togliere.
role: il ruolo da togliere.
user: l’utente a cui togliere il privilegio.
role: il ruolo a cui togliere il privilegio.
PUBLIC: se indicato, significa che tutti gli utenti perderanno il privilegio.
CASCADE CONSTRAINTS: cancella i constraints referenziali che l' utente aveva creato usando il privilegio REFERENCES che ora gli togliamo.
Esempio:
1.REVOKE execute any procedure FROM operatore;
2.REVOKE ALL ON anag_operatori from PUBLIC;
La vista di sistema DBA_SYS_PRIVS contiene le informazioni sui privilegi di sistema.
Esempio:
SELECT * FROM dba_sys_privs;
GRANTEE PRIVILEGE ADMIN_OPTION
---------- ------------------------- ------------
CASSIERE CREATE SESSION NO
CASSIERE EXECUTE ANY PROCEDURE NO
CASSIERE INSERT ANY TABLE NO
CASSIERE UPDATE ANY TABLE NO
CONNECT ALTER SESSION NO
CONNECT CREATE CLUSTER NO
CONNECT CREATE DATABASE LINK NO
CONNECT CREATE SEQUENCE NO
CONNECT CREATE SESSION NO
CONNECT CREATE SYNONYM NO
CONNECT CREATE TABLE NO
CONNECT CREATE VIEW NO
La vista di sistema DBA_TAB_PRIVS contiene le informazioni sui privilegi sugli oggetti.
Esempio:
SELECT * FROM dba_tab_privs;
GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANT
---------- ---------- --------------- ---------- ---------- ------
GESTORE USR1 ANAG_OPERATORI USR1 DELETE NO
GESTORE USR1 ANAG_OPERATORI USR1 INSERT NO
GESTORE USR1 ANAG_OPERATORI USR1 SELECT NO
GESTORE USR1 ANAG_OPERATORI USR1 UPDATE NO
I privilegi sugli oggetti possono essere limitati ad alcune colonne dell' oggetto e in tal caso le informazioni sono contenute dalla vista di sistema DBA_COL_PRIVS.
Per la gestione dell’RDBMS Oracle possono essere utilizzati diversi programmi di amministrazione. Si e’ ritenuto interessante fornirne una breve panoramica.
· SQL*DBA:
con tale programma si effettuano le principali operazioni di gestione della
base dati quali il bootstrap e shutdown
· Server Manager:
programma grafico per il DBA. Contiene un numero maggiore di opzioni rispetto
al programma sqldba e ne sara’ il naturale sostituto
· Import/Export:
con tali funzioni di utilita’ vengono effettuati i salvataggi logici ed
i ripristini dei dati
· Tkprof:
con tale utility e’ possibile analizzare i trace dell’RDBMS
· SQL*Loader:
con tale utility e’ possibile importare dati da un formato definito
· Script SQL:
un insieme di script SQL fanno sempre parte del bagaglio di un buon DBA. Alcuni
script interessanti possono essere trovati in $ORACLE_HOME/rdbms/admin
· Tool
di terze parti: sul mercato sono presenti diversi tool di terze parti
per il monitoraggio, la gestione, il supporto alla programmazione, …
Testo: Corso amministrazione
Oracle
Data: 30 Dicembre 1997
Versione: 1.3
Autore: mail@meo.bogliolo.name