tutorial su Oracle

Panoramica Oracle
Oracle è il leader di mercato in ambito di RDBMS di fascia alta, ed è un prodotto
commerciale non open source. E’ disponibile su varie piattaforme (fra cui Linux e Windows
e MAC) ed è ottimizzato per ospitare grandi quantità di dati offrendo funzionalità evolute.
Vista l’elevata quantità di risorse che richiede viene installato in DB server dedicati,
tipicamente il LAN con l’accesso effettuato da applicazioni client server intranet e
attraverso WEB services o reverse proxy dalla DMZ, anche se, tramite opportuna
configurazione è possibile utilizzarlo anche per l’accesso diretto da internet con
autenticazioni evolute quali SSL, PKI etc…
Struttura fisica
Un RDBMS Oracle è fatto, come tutti da un insieme di processi e da un insieme di dati. I
processi, a seconda delle richieste che ricevono e/o dei propri compiti di routine,
interagiscono coi dati memorizzati nei file fisici non direttamente ma caricandoli prima in
memoria RAM in un’area detta SGA o System Global Area.
L’insieme di processi in esecuzione, che si comportano in un certo modo a seconda dei
valori dei parametri di avvio contenuti in un opportuno file detto init.ora, e della SGA
costituisce un’entità che mette in comunicazione utente e dati ovvero una manifestazione
di questi che di solito è chiamata istanza ed è indicata da un nome univoco detto SID.
Un’istanza per funzionare deve riferirsi a dei file fisici ma non è detto che per ogni istanza
ci siano dei file fisici, in quanto sono anche possibili soluzioni cluster dove due istanze
diverse installate su due server (ad esempio Blade) operano sugli stessi file di dati che
risiedono sulla stessa Storage Area Network.
Ancora se è vero che un’istanza ha bisogno di un server su cui girare non è detto che
debba essere per forza l’unica, anche se a dire il vero quello di una sola istanza con file di
dati solo propri risiedente su un server dedicato (come nella figura precedente) è quello
più comune.
Processi di gestione
I processi principali (che possiamo vedere tramite il task manager su Windows o con un
comando tipo “ps –ax” su Linux) sono i seguenti:
Processo
SMON
PMON
DBWR
LGWR
CKPT
ARCH
RECO
Descrizione
Avvio del DB, gestione estensioni libere, pulizia DB.
Ripulisce i processi falliti dagli utenti rendendo disponibili le risorse
Scrive sui file di dati i blocchi modificati contenuti nella area SGA
Gestisce la scrittura dei file di Redo Log
Facilita il ripristino scrivendo ad ogni checkpoint i dati relativi ai blocchi modificati
Gestisce la scrittura ciclica dei file di Log
Recupera le transazioni fallite
Nel funzionamento ciclico questi processi non scrivono solo file di dati ma anche altri file di
sistema ovvero:
-
File di Redo Log
Control Files
File di tracciamento
I primi due gruppi di files sono indispensabili per il funzionamento dell’RDBMS che senza
questi (ad esempio se vengono cancellati accidentalmente) non può neanche partire.
I file di Redo Log memorizzano il codice SQL di tutte le operazioni di modifica dei dati che
arrivano al server. In pratica all’invio del comando da parte del client si succedono le
seguenti fasi:
-
il comando viene scritto nel file di Redo Log corrente
il comando viene lanciato sulle righe interessate
Questi file sono in numero scelto al momento dell’installazione e successivamente
modificabile. Vengono scritti ciclicamente di modo che, se non sono attivate gestioni
particolari (ARCHIVELOG, vedi più oltre) il contenuto più vecchio viene via via perso. Dato
che contengono liste di comandi possono essere utilizzati per il backup o il recupero del
database.
I Control Files, come i Redo Log vengono di continuo scritti dai processi di gestione ma
servono per contenere informazioni utilizzate per mantenere la coerenza interna. Sono
anch’essi utilizzati nel recovery, essenzialmente in quello fisico on line (vedi più oltre).
I file di tracciamento infine contengono semplicemente traccia di errori o eventi
significativi. Sono nient’altro che comunissimi file di log come normalmente intesi (ovvero
se anche si cancellano, magari dopo averli guardati, non succede niente).
File del Database
I file in una macchina che ospita software oracle server sono normalmente organizzati a
partire da una opportuna cartella, associata alla variabile di ambiente ORACLE_BASE. Nella
ORACLE_BASE si trovano tante ORA_HOME quante sono le versioni del server, di norma
una. La ORA_HOME contiene tutti gli eseguibili ed i file di configurazione principali di
estensione “.ora”. Insieme alla ORA_HOME vi sono normalmente altre due cartelle admin
ed oradata.
La prima contiene una sottocartella per ogni istanza dove si trovano i file di trace e il
corrispondente initXXX.ora (dove XXX=SID Istanza=es. ORCL1). La seconda contiene allo
stesso modo una cartella per istanza e dentro i vari file ovvero:
-
file di dati (tipicamente nominati myTABLESPACEnn.dbf)
file di log (REDOnn.log)
control files (CONTROLnn.ctl)
Abbiamo già accennato ai file di log e di controllo, parliamo ora meglio dei file di dati. Le
TABLESPACES sono in pratica raggruppamenti logici di file di dati : in pratica non esiste
alcun oggetto tablespace su disco ma solo file di dati che sono gestiti con politiche
comuni, che sono appunto i parametri della tablespace di cui fanno parte. Alcuni esempi di
queste politiche sono:
-
la posizione fisica
il comportamento quando viene chiesto nuovo spazio
il comportamento quando devono essere cancellati degli oggetti
..etc. I datafile sono divisi in SEGMENTI che sono la controparte fisica degli oggetti come
tabelle, indici etc… Ogni segmento è composto da ESTENSIONI ovvero pezzi di unità di
allocazione elementari detti BLOCCHI. In pratica si ha un’organizzazione dello spazio
secondo questi livelli:
Un’organizzazione così complessa è utile per poter ottenere il massimo delle prestazioni,
ad esempio:
-
raggruppando oggetti con caratteristiche simili in tablespaces in modo da poter
gestire l’accesso parallelo memorizzandoli su HD diversi;
configurare la grandezza di blocchi ed estensioni a seconda di buffer del SO e
dimensioni
degli oggetti e quantità di dati che vengono aggiornati
etc…
Un esempio di struttura può essere questo:
Dove ORA_BASE = D:\Oracle ed ORA_HOME=Ora92 e dove si suppongono presenti due
istanze di SID ORCL1 e ORCL2 sulla macchina. Questa struttura è in realtà solo un
esempio perché di norma conviene posizionare le tablespaces (e talvolta i datafiles
all’interno delle varie tablespaces) in posizioni diverse ad esempio per poter sfruttare
l’accesso contemporaneo alle informazioni posizionate in due HD diversi da parte dei
relativi controller.
Come detto in precedenza la controparte fisica degli oggetti sono i segmenti. Esistono tipi
diversi di segmenti a seconda delle caratteristiche dell’oggetto corrispondente. I principali
tipi sono questi:
-
TABLE
INDEX
ROLLBACK
TEMPORARY
Backup
Oracle offre varie modalità di backup, ovvero:
-
backup logico
backup fisico off line (o “a freddo”)
backup fisico on line (o “a caldo”)
Il backup logico viene attuato mediante l’utilità EXP. E’ possibile esportare anche solo
alcuni oggetti, oltrechè ovviamente un utente o l’intero DB. Il suo complementare è l’utility
IMP che a partire dai dump in ASCII generati da EXP ricrea gli oggetti in questione. Con
l’uso combinato di EXP ed IMP è possibile anche esportare gli oggetti da un utente e
importarli in un altro.
Se è buona norma far seguire l’EXP logico ad uno stop (e ovviamente nel suo caso un
riavvio altrimenti non sarebbe possibile accedere ai dati!) nel caso del backup fisico off line
è obbligatorio farlo seguire ad uno stop. In pratica si arresta il DB si copiano i file in un
posto “sicuro” e si fa ripartire.
Il backup fisico on line presuppone l’utilizzo della modalità ARCHIVIELOG ovvero il
salvataggio completo di tutto ciò che viene scritto nei log. Per lo meno a partire da un
precedente backup corente (magari ottenuto anche in modalità off line).
In pratica succede che se si è attivata la modalità ARCHIVIELOG il processo ARCH crea a
partire dalle righe che continuano ad essere gestite a rotazione nei LOG files degli
opportuni files .arc. Questi files possono poi essere tradotti in files fisici di backup con
istruzioni sqlplus di questo tipo:
alter tablespace myTABLESPACE begin backup;
D:\...\ORCL1myTABLESPACE0*.dbf D:\backup\ORCL1\
alter tablespace myTABLESPACE end backup;
Da notare che anche se per il backup/recovery fisico on line non è obbligatorio (come si è
visto nell’esempio precedente) l’utilizzo del programma RMAN facilita molto le cose. Per
utilizzare RMAN è necessario comporre (in genere tramite procedure guidate) un
opportuno catalogo di recupero. Normalmente questo catalogo è realizzato in un’istanza a
parte rispetto a quella di produzione detta OEMREP e contenente un utente RMAN che
viene utilizzato da ARCH per creare via via il catalogo a partire dalla informazioni che
ruotano nei REDO log e nei control files. In questo contesto lanciando il programma RMAN
si può ad esempio create il backup fisico dell’intero RDBMS con questo semplice comando:
RMAN>RUN {
Allocate channell DefaultChannel type disk
‘D:\BCK\ORCL1\d_%u_%s_%p”;
Backup (database include current controlfile)
}
Disaster Recovery
Il caso più frequente è quello di utilizzare EXP/IMP più una buona dose di inventiva anche
se ovviamente lo strumento “principe” sarebbe RMAN con cui è possibile anche avere degli
wizard di recupero. Da notare che RMAN mette a disposizione anche una serie di
strumenti di verifica dei files che possono rilevare e rimediare molti dei possibili problemi.
Ovviamente non tutti.
Dialogo attraverso la rete
Le modalità di dialogo possibili in ambiente oracle sono molte e non sono limitate
semplicemente alla comunicazione client-server ma includono anche quella server-server
essendoci un ampio supporto anche per le elaborazioni distribuite.
Per ogni server (anche se non necessariamente “su” ogni server) è presente un opportuno
processo detto listener il cui modo di operare è definito tramite un opportuno file
listener.ora E’ costituito da due parti:
-
Nella prima si ha un elenco (ADDRESS_LIST) dei protocolli e degli indirizzi da cui il
listener accetta connessioni;
Nella seconda si ha un elenco delle istanze per cui il listener risponde;
Nel dettaglio i protocolli che sono utilizzabili sono questi:
-
TCP/IP
TCP/IP con SSL
Named Pipes (Nomi Netbios)
IPC (Comunicazione interprocesso : più veloce quando server e listener sono sulla
stessa macchina)
Per la seconda parte abbiamo quanto segue sono possibili tre tipi di configurazioni di
accesso:
Access
Database
Description
Provides network access to an Oracle
database instance
PLSExtProc Method for PL/SQL packages to access
operating system executables
Executable Provides network access to operating
system executables
The "Database" mode is the most widely used mode and is the standard mode used by
every database for connectivity. "PLSExtProc" allows PL/SQL database packages to access
external programs and is configured by default for many instances. "Executable" mode
allows an external program to be defined and accessed through a TNS connection.
Un esempio concreto per capirsi: col seguente listato:
LISTENER =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(Key = EXTPROC))
(ADDRESS = (PROTOCOL = TCP)(PORT = 1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\ora92)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = ORCL)
(ORACLE_HOME = D:\oracle\ora92)
(SID_NAME = ORCL)
)
)
… stiamo dicendo questo: il nostro listener
-
ascolta sulla chiave “EXTPROC” con le funzioni del operativo locale
ascolta tutto il traffico TCP in arrivo sulla porta 1521
ha un servizio di tipo Extproc di SID=PLExtProc il sui eseguibile si trova sotto
D:\oracle\ora92
ha un servizio di tipo DB di SID=ORCL il sui eseguibile si trova sotto
D:\oracle\ora92
Come si nota con queste informazioni il listener sa quali “porte aprire” e chi “andare a
chiamare” ma non sa che ciò che ascolta ad esempio sulla porta 1521 per chi sia. Ecco
perché nei pacchetti entranti deve essere presente anche il SID o in generale il riferimento
ad un “metodo di denominazione” di istanze.
Sono essenzialmente possibili questi tipi di metodi di denominazione:
-
SID
Nome Servizio di Rete
Nome LDAP
Il client può risolvere questi nomi in modi diversi, essenzialmente dinamici (interrogando
opportuni server DNS-like) o statici. I secondi sono chiaramente meno flessibili ma molto
più diffusi e qui faremo riferimento solo a tali metodi.
In pratica ogni client possiede in locale un opportuno file denominato tnsnames.ora che
consiste in una lista di alias, o meglio di corrispondenze alias-istanze. Riferendosi
all’esempio precedente avremo qualcosa del genere:
DBORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.1.1)(PORT = 1521))
)
(CONNECT_DATA =
(SID = ORCL)
)
)
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(CONNECT_DATA =
(SID = PLSExtProc)
)
)
Questo implica che con il comando:
>sqlplus utente/password@DBORCL
.. si possa ottenere una shell sqlplus sul DB remoto dal client in questione. Infatti succede
questo:
[client]
DBORCL Æ (tnsnames.ora) Æ SID=ORCL su 172.16.1.1:1521
[server]
Pacchetto TCP in arrivo sulla porta 1521 per il SID=ORCL Æ (listener.ora) Æ oracle.exe
Probabilmente la specifica TCP è nella parte options dell’header TCP.
Fra i file necessari a livello client oltre al tnsnames.ora di cui sopra c’è anche un altro file
ovvero sqlnet.ora. In questo sono contenute informazioni più globali ovvero:
-
l’ordine di priorità di applicazione dei metodi di denominazione
tipo di autenticazione
nome di dominio di default (nome servizio = SID + “.” + nome dominio)
Un esempio di listato:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)
NAMES.DEFAULT_DOMAIN = WORLD
Frammentazione
Presenti comandi di rebuild di tabelle ed indici. Possibile inoltre definire attraverso i
parametri PCTFREE e PCTUSED a livello di blocco lo spazio libero con cui il blocco viene
allocato e il minimo livello di utilizzo per cui il blocco possa essere marcato come da
spostare al successivo accesso. Da notare che il blocco inserisce un numero di byte iniziali
diverso a seconda del tipo di segmento corrispondente all’oggetto : la conoscenza di
questi valori (Oracle 9i DBA pag 180) può essere utilizzata per dimensionare in modo
adeguato dimensione di datafiles ed extent nelle varie tablespaces a seconda di cosa
conterranno.
Struttura logica
Aspetti generali
Un database oracle è costituito da più utenti. Ad ogni utente sono associati dei diritti (uno
o più profili) quindi una serie di operazioni possibili. I risultati di queste operazioni
determinano che esisteranno:
-
un insieme di oggetti che l’utente ha creato (di cui è il proprietario ovvero detiene
tutti i possibili diritti)
un insieme di oggetti su cui l’utente ha acquisito (a seguito dell’operato proprio o di
altri utenti) diritti
L’insieme degli oggetti su cui un utente ha dei diritti (di vario tipo, ad esempio sola lettura
oppure lettura e modifica etc..) si chiama schema. Tutto questo comporta che dal punto di
vista logico il nostro database si può vedere nei seguenti due modi:
Il primo dei due è incentrato sul concetto di “appartenenza”, mentre il secondo è invece
basato sullo “spazio accessibile”. Da notare infatti che in uno schema possono essere
presenti oggetti di più utenti o addirittura di più database utilizzando strumenti come:
-
sinonimi
link fra database
In questo modo si ha elevato supporto ai meccanismi di replica e alle elaborazioni
distribuite. Una breve tabella riepilogativa prima di proseguire:
Oggetto
Sinonimo
DBLink
Sintassi
CREATE SYNONYM
"[DestUser]"."
[DestTable]" FOR
"[SourceUser]
"."[SourceTable]";
Applicazione
SELECT * FROM
[DestTable]
CREATE PUBLIC
DATABASE LINK
[DBLinkName] CONNECT
TO [RemoteUser]
IDENTIFIED BY
[RemotePwd] USING
'[RemoteDBAlias]'
SELECT * FROM
[AnyTable]@[DBLinkName]
Note
Da concedere
prima la GRANT
al [DestUser]
sulla
[SourceUser]
.[SourceTable]
Dove si è supposto di lanciare entrambi i comandi da SYSTEM oppure da un utente coi
privilegi adeguati (vedi qui si seguito).
[DestUser]
[DestTable]
[SourceUser]
[SourceTable]
[DBLinkName]
[RemoteUser]
[RemotePwd]
[RemoteDBAlias]
[AnyTable]
=
=
=
=
=
=
=
=
=
Utente destinazione del sinonimo
Nome tabella nell’utente di destinazione
Utente sorgente del sinonimo
Nome tabella nell’utente sorgente
Nome da assegnare al link
Utente con cui accedere al DB Remoto da linkare
Password del [RemoteUser]
Conn. string che punta al DB remoto (TNSNAMES.ORA)
Una qualunque delle tabelle del DB Remoto
E’ evidente che l’utilità di un sinonimo è quella di far accedere con un nome “breve” un
utente ad un oggetto di non sua proprietà mentre un DB link permette ad esempio di
trasferire dati senza fare export ed in seguito import, ovvero di fare in modo che le
modifiche appaiano sui due db contemporaneamente.
Si è parlato di privilegi, spieghiamo meglio cosa sono. Ad ogni utente (e non ad ogni
schema!) vengono associati dei diritti, che possono essere sugli oggetti o al limite anche
sull’intero database. Per semplificare la gestione di questi diritti Oracle prevede dei “profili“
ovvero degli insiemi di privilegi. In genere per applicazioni non troppo “spinte” si usano i
profili standard quali ad esempio i seguenti:
-
CONNECT
RESOURCE
DBA
Ovviamente niente vieta di definirne altri secondo le proprie esigenze. Dall’incrocio fra
l’utente e i profili ad esso collegati viene composto lo schema ossia, come appare a tale
utente il “mondo” ovvero l’insieme di utenti e di database fra loro collegati con GRANT,
SYNONYM, DBLINK.
Autenticazione
In Oracle sono possibili varie modalità per autenticarsi ovvero:
•
•
•
autenticazione livello utente
autenticazione livello amministratore
- tramite file orapwd
- integrata a livello di sistema operativo
autenticazione via rete (internet)
La prima modalità è quella comune per gli utenti da locale (ovvero sulla stessa macchina)
oppure all’interno di una rete intranet. Le password sono contenute all’interno di una
tabella nella tablespace SYSTEM e sono trasmesse in chiaro nella comunicazione
client/server.
E’ ovvio che questo tipo di autenticazione funziona solo se il DB è aperto. Dunque affinché
alcuni utenti potessero avviare o stoppare il DB era necessario pur nello stesso cotesto
(locale o intranet) rendere disponibile un meccanismo ulteriore magari solo per quegli
utenti privilegiati (ovvero quelli che hanno i profili di SYSDBA e SYSOPER). Questo
meccanismo è la seconda modalità di cui sopra. In pratica se l’utente SYSDBA o SYSOPER
(es. SYS) questo viene autenticato non leggendo il DB ma leggendo un opportuno file di
password, ricreabile con l’utility orapwd. Dunque non è necessario avere alcun DB già
funzionante. In alternativa è possibile utilizzare l’autenticazione integrata con sistema
operativo : se l’utente che ha fatto accesso alla macchina appartiene al gruppo degli
amministratori (dba in Linux, ORA_DBA in Windows) come ad esempio root oppure
Administrator Oracle può ragionevolmente supporre che si tratti di un utente “fidato”. Ecco
quindi che può farlo entrare senza chiedergli alcuna password ed il “celebre” comando di
SQL Plus di cui nel seguente esempio:
D:\temp>sqlplus /nolog
SQL*Plus: Release 9.2.0.6.0 - Production on Tue Dec 2 18:10:12 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> connect / as sysdba
Connected.
SQL> show user
USER is "SYS"
Per l’accesso via rete i meccanismi visti finora sono evidentemente poco sicuri perché non
prevedono alcuna cifratura della password trasmessa (anche se la password memorizzata
non è in chiaro!). Sono possibili vari meccanismi alternativi quali ad esempio:
-
SSL
Kerberos
PKI
Radius
Per utilizzare questi sistemi deve essere configurato opportunamente il server (ad esempio
nel caso di SSL deve essere presente una opportuna riga relativa al protocollo TCPS con
una porta dedicata a tale traffico).
Altre funzionalità di sicurezza
Agli utenti possono essere associate anche funzionalità di sicurezza avanzate come l’audit
(il tenere traccia delle operazioni che fa) o il VPD o Virtual Private Database, ossia
l’inserire a livello di dati delle WHERE aggiuntive che impediscano l’accesso a certe
informazioni anche da client oracle o ODBC non solo da applicativo.
L’audit viene attivato tramite comandi SQL e inserisce il suo output in opportune tabelle (o
in files a seconda del parametro di configurazione AUDIT_TRAIL). Può essere fatto a vari
livelli come mostra la seguente tabella:
Audit Per
Istruzione
Privilegio
Serve per loggare
Quando un utente lancia un comando SQL di un certo tipo
(indipendentemente dall’oggetto su cui lo lancia).
Quando un utente utilizza un certo privilegio a lui attribuito
(indipendentemente dal perché e dall’oggetto coinvolto).
Quando un utente interagisce con un certo oggetto
(indipendentemente dal comando SQL che lancia).
Quando un utente esegue una certa operazione su un
oggetto per certi valori dei dati.
Oggetto
Dati
La tabella è SYS.AUD$ ed il suo contenuto può essere esaminato attraverso le viste
DBA_AUDIT_TRAIL, DBA_FGA_AUDIT_TRAIL e DBA_COMMON_AUDIT_TRAIL.
Oggetti utente
Sono molti e di vario tipo alcuni esempi sono questi:
-
Tabella
Vista
Indice
Trigger
Store Procedure
Oggetti di sistema
In oracle ogni operazione DML viene incapsulata in una transazione, tanto è vero che se
si lancia una qualunque istruzione di INSERT/UPDATE/DELETE e ci si scorda di dare il
commit si perdono tutte le modifiche fatte. La sequenza delle operazioni con cui agisce ad
esempio una transazione di UPDATE su TABELLA1 è questa:
Tempo
0
1
2 (rollback)
3 (commit)
TABELLA1
Stato Iniziale
Valori Modificati
Stato Iniziale
Valori Modificati
TABELLA1 (visibile)
Stato Iniziale
Stato Iniziale
Stato Iniziale
Valori Modificati
ROLLBACK SEGMENT
Stato Iniziale
-
Quando viene lanciata una transazione che coinvolge la TABELLA1 in pratica succede che
Oracle non applica subito la modifica ma crea prima degli opportuni segmenti “di rollback”.
Di default (modalità AUTOMATIC UNDO) questi vengono creati nella tablespace SYSTEM
ma di norma vengono creati manualmente con il comando CREATE ROLLBACK SEGMENT e
associati ad un’opportune TABLESPACE di UNDO per non frammentare inutilmente la
SYSTEM.
In ogni caso, dovunque sia, il segmento di rollback viene riempito coi dati originari mentre
su questi viene applicata la modifica. Se la transazione termina con rollback i dati vengono
ripresi dal segmento di rollback e riportati al posto originario, viceversa vengono lasciati i
valori modificati nel segmento utente (es. TABLE).
La transazione è un oggetto con una propria individualità quindi è possibile anche
associare ad una transazione (come ad un qualunque altro oggetto) una propria
tablespace. Questo è particolarmente utile per transazioni di massiccio caricamento dati
che, se non dirette su tablespaces temporanee, introdurrebbero inutile frammentazione.
E’ importante notare che questo vale per le operazioni sui dati : un DROP TABLE
accidentale non sarà mai rimediabile tramite una semplice rollback.
I lock sono possibili sia a livello di oggetto, che nel caso in cui l’oggetto sia una tabella a
livello di record.
Amministrazione
Installazione
L’installazione viene normalmente eseguita con l’aiuto di un opportuno programma ad
interfaccia grafica e questo sia in ambiente Windows che Linux. In generale i passi
fondamentali sono questi:
Passo
1
2
3
4
5
6
Descrizione
Creazione Utente dbowner e relativo gruppo
Modifica delle variabili di ambiente del SO
Modifica dei percorsi
Configurazione XServer
Run Installer
Impostazione Avvio Automatico
Windows
Setup.exe
Setup.exe
Setup.exe
Setup.exe
Setup.exe
Setup.exe
Linux
Manuale
Manuale
Manuale
Manuale
./RunInstaller
Manuale
L’installer a sua volta compie i seguenti passi principali:
Passo
1
2
3
4
5
5
6
7
Descrizione
Scelta path, ORACLE_BASE e ORACLE_HOME
Scelta del tipo di server
Scelta dalla lingua DB e e del character set
Scelta prodotti da installare
Installazione eseguibili
Configurazione script per creazione database
Lancio script
Configurazione Oracle.Net
Da notare l’importanza fondamentale del Character Set : non è possibile importare dati da
un dump fatto con un DB che gestisce i dati con un diverso set di caratteri. Riguardo al
“tipo di server” le scelte più importanti riguardano ad esempio:
-
Server OLTP/OLAP (transazioni semplici molti utenti/poche query molto complesse)
Server Dedicato/Condiviso (poche connessioni e persistenti/molte e leggere)
Parametri di Memoria (SGA, PGA)
Archivie Log Mode Attivato o No
Operazioni comuni
Start/Stop
In Oracle l’istanza non è semplicemente “ferma” o “avviata” ma passa dal primo stato al
secondo attraverso due stati intermedi. Sono possibili in altre parole quattro stati:
Stato
Stopped
No Mount
Mount
Open
Descrizione
Chiuso
Caricato
Avviato
Aperto
L’avvio (ovvero il passaggio da uno stato ad un altro obbligatoriamente successivo) si fa
con il comando sqlplus startup seguito dallo stato desiderato. Esempio:
SQL> startup mount;
Anche sullo stop del database non possibili più modalità, come mostra la seguente tabella:
Il comando sql stavolta à shutdown è tutto va in modo simile al caso precedente. Ad
esempio si potrà dare:
Stato
Descrizione
Normal
Attende che si disconnettano tutti gli utenti
Transactional
Immediate
Abort
Disconnette gli utenti una volta terminate le
transazioni
Esegue il rollback di tutte le transazioni attive e
disconnette tutti gli utenti
Chiude istantaneamente l’istanza fermando i
servizi
SQL> shutdown immediate;
Avvio e stop del database possono essere fatti solo da utenti con il privilegio di SYSOPER.
Listener Start/Stop
Talvolta il listener si blocca. Si utilizzano in genere questi comandi (da sistema operativo)
di ovvio significato:
>lsnrctl start
>lsnrctl stop
>lsnrctl status
Aggiunta/Cancellazione Datafile
A livello di creazione di un datafile è possibile specificare un importante parametro di
memoria che è l’autoextend. Se è ON il file una volta riempito alloca da solo il nuovo
spazio, a pezzi “extent” di dimensione specificabile, eventualmente fino ad una dimensione
massimo. Se è OFF invece quando il file è pieno la transazione non viene accettata e viene
generato un messaggio di errore. Tipicamente vengono definite con autoextend=ON sono
alcune tabelle di sistema quali SYSTEM o TEMP. Per la altre, si preferisce aggiungere
datafiles quando servono. Per farlo si può usare un comando come il seguente:
ALTER TABLESPACE TablespaceName
ADD
DATAFILE '/u01/app/oracle/oradata/ORCL/NewDataFileName.dbf'
REUSE
SIZE
262144K
..dove chiaramente il path è quello di un caso particolare che è stato preso ad esempio.
Oppure da interfaccia grafica posizionarsi su un datafile esistente ed usare la funzionalità
“Create Like”.
Per cancellare un datafile occorrono i seguenti passi:
-
spostarne l’eventuale contenuto in un altro datafile
porre il datafile offline specificando “FOR DROP”
cancellare il file da sistema operativo
L’istruzione di cui al primo passo è la seguente:
ALTER DATABASE
DATAFILE '/u01/app/oracle/oradata/ORCL/OldDataFileName.dbf' OFFLINE FOR DROP