Corso Amministrazione Oracle Sommario 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 Architettura dell'RDBMS Oracle 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. Gestione dei dati nel database 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): SYSTEM contiene il Dizionario Dati RBS contiene i Rollback Segment TEMP a disposizione dei file temporanei USERS contiene gli oggetti degli utenti TOOLS contiene le tavole dei Tool di ORACLE (Forms, ReportWriter, ecc.) 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' ggetto 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 updatee utilizza piu’ blocchi umenta le performance perche’ Oracle deve riorganizzare piu’ raramente i blocchi Un basso PCTUSED: umenta le performance perche’ rientrano raramente nella insert block list umenta lo spazio inutilizzato Un alto PCTUSED: Diminuisce le performance perche’ rientrano frequentemente nella insert block list Migliora l' utilizzo dello spazio. Dimensionamento degli oggetti Oracle 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). Tipi di dati Oracle 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 anno mese giorno ora minuto secondo 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. Creazione del database 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 ALTER ALTER ALTER DATABASE DATABASE DATABASE DATABASE MOUNT (da NOMOUNT a MOUNT) OPEN (da MOUNT a OPEN) CLOSE (da OPEN a MOUNT) 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. Salvataggio e ripristino del database 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. Salvataggio logico dei dati 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. Salvataggio fisico offline 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). Salvataggio dei file di log 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. Salvataggio parziale del database 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. Salvataggio a database attivo 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. Gestione di Utenti, Profili, Ruoli 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: Default Tablespace: indica dove saranno creati gli oggetti dell' utente se non specificato diversamente nello statement di creazione Temporary Tablespace: indica dove saranno creati i segmenti temporanei dell' utente, che servono nell' esecuzione di statement SQL con ordinamenti o raggruppamento di dati Tablespace Quotas: indica qual' e’ la massima porzione di tablespace utilizzabile dall’ utente (0 = tablespace inutilizzabile, UNLIMITED = porzione illimitata) Profile: limita l' uso delle risorse di sistema da parte dell' utente 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: System privilege: il diritto di compiere una particolare azione o di compiere una particolare azione su un particolare tipo di oggetto Object privilege: il diritto di compiere una particolare azione su uno specifico oggetto 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: CONNECT: abilita la connessione database RESOURCE: abilita alla creazione di tabelle (in qualsiasi tablespace) DBA: abilita ai comandi DCL, DDL, DML, export e import dell' intero database 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 ALTER X DELETE X View Sequence Procedure Snapshot X X EXECUTE X INDEX X INSERT X REFERENCES X SELECT X X UPDATE X X X X X Grant 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; Revoke 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. Principali programmi di amministrazione 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: [email protected]