CorsoGiorno4

Giorno IVGiorno IV

Istanza Oracle, Strutture Istanza Oracle, Strutture Fisiche,Fisiche,

Dizionario Dati Dizionario Dati

Database Oracle

Un database Oracle è composto da:

• Aree di memoria

• Processi

• File fisici

Database Files

System Global Area

Background Processes

Cos’è un’istanza Oracle

Un’istanza Oracle viene identificata tramite un gruppo di strutture di memoria e processi background che accedono ad un set di file di database.

ISTANZA ORACLE

System Global Area

Background Processes

Istanza Oracle

Ogni qualvolta si avvia un database Oracle, viene allocata la System Global Area (SGA) e vengono avviati i processi background. Una istanza Oracle apre un SOLO database.

La combinazione di buffer di memoria e processi La combinazione di buffer di memoria e processi background viene chiamata background viene chiamata

ISTANZA ORACLEISTANZA ORACLE

Processi Oracle e processi utenteProcessi Oracle e processi utente

Un’istanza Oracle ha due tipi di processi: processi utente e processi Oracle:

• Un processo utente esegue il codice di una applicazione come una pacchetto di maschere o un tool di interfaccia al database.

• I processi Oracle sono processi server che effettuano operazioni per i processi utente e i processi background che fanno lavoro di manutenzione per il server Oracle.

Processi utenteProcessi utente

Gira su una macchina client

Viene aperto quando un tool o un’applicazione viene invocata

Permette di far girare un tool o una applicazione (SQL*Plus, Developer 2000) Include la User Program Interface (UPI)

Genera chiamate al server Oracle

Processi serverProcessi server

Gira su una macchina server (host)

Serve un singolo processo user in una configurazione server dedicated

Utilizza una PGA esclusiva

Include la Oracle Program Interface (OPI)

Le chiamate al processo vengono generate dal client

Restituisce i risultati al client

Architettura di un server OracleArchitettura di un server Oracle

System Global AreaDatabase Buffer Cache

Redo Log Buffer

SharedServerProcess

DedicatedServerProcess

DatafilesRedo Log

Files

ControlFiles

OfflineStorageDevice

SMONPMONRECOLCK0

CKPT

LGWR

ARC0DBW0

UserProcess

D000

UserProcess

• LCK0 Lock Process• RECO Recoverer Process• PMON Process Monitor• SMON System Monitor• CKPT Checkpoint• ARC0 Archiver• DBW0 Database Writer• LGWR Log writer

Processi BackgroundProcessi Background

I processi background eseguono le funzioni più comuni per servire gli utenti che accedono al database, senza compromettere l’integrità e le performance dell’intero sistema. Ogni istanza ha almeno questi cinque processi background:

System Monitor (SMON): la sua funzione primaria è quella di fare un check sulla consistenza del database ed avviare una fase di recovery se aprendo il db se ne riscontra la necessità;

Process Monitor (PMON): pulisce le risorse in caso di fallimento di un processo utente;

Database Writer (DBW0)

Log Writer (LGWR):

Checkpoint (CKPT): è responsabile dell’aggiornamento dello stato del database quando i cambiamenti all’interno della buffer cache vengono registrati nel database in maniera permanente

Database WriterDatabase Writer

Database

Datafiles

ControlFiles

Redo LogFiles

S G A

Shared Pool Redo log buffer

Database buffer cache

DBW0

DBWR scrive i ‘buffer dirty’ della database buffer cache sui datafile, questa scrittura sui datafile non avviene contestualmente alla modifica ma viene rimandata al verificarsi di uno dei seguenti eventi:

il numero di ‘buffer dirty’ raggiunge un valore di soglia

un processo cerca un buffer libero e non ne trova nessuno

avviene un timeout

avviene un checkpoint che invoca DBWR, ciò può accadere per vari eventi, come ad esempio alla chiusura del database.

Log WriterLog Writer

Database

Datafiles

ControlFiles

Redo LogFiles

S G A



LGWR

LGWR scrive le registrazioni dei cambiamenti dalla red log buffer ai file di redo log. Queste scritture avvengono nei seguenti casi:

quando la redo log buffer è piena per un terzo

avviene un timeout

quando viene eseguita la commit su una transazione

prima che DBWR scriva i blocchi modificati nella database buffer cache sui datafile

Strutture fisiche di un database Oracle

Datafiles

Contengono i dati presenti nel database. Le strutture logiche come tavole ed indici sono immagazzinati fisicamente nei datafile;

Redo Log

Contengono le registrazioni di tutti i cambiamenti fatti al database dalle transazioni correnti al fine di assicurare un corretto recovery se necessario;

Control Files

Contegono le informazioni necessarie per mantenere e verificare l’integrità della struttura fisica del database;

Altre strutture fisiche di un database Oracle

File dei parametri (parameter file)

Utilizzato per definire le singole caratteristiche di una istanza Oracle;

File di password (password file)

Utilizzato per autenticare gli utenti che si occuperanno dell’amministrazione remota del database;

Redo Log Archiviati

Copie fuori linea dei redo log archiviati che possono essere necessari in caso di rottura di uno o più dischi per eseguire un recovery;

Le Strutture fisiche

Database

Datafiles

ControlFiles

Redo LogFiles

Redo Log Archiviati

File parametri

File di password

La memoria condivisa

La memoria condivisa di Oracle è meglio conosciuta come SGA (System Global Area) contiene informazioni accessibili da tutti gli utenti ed ha tre componenti principali:

Shared Pool;

Database buffer Cache;

Redo log Buffer;

SGA (System Global Area)

Potete sentire nominare la SGA Shared Global Area, ma il significato è lo stesso.

S G A



La shared pool

La dimensione della shared pool è definita tramite il parametro

SHARED_POOL_SIZE

Shared Pool

Library Cache

Data dictionary CacheLa dictionary cache contiene contiene le definizioni delle tavole, delle colonne ed i privilegi relativi.

La library cache contiene il testo, il codice elaborabile ed il piano di esecuzione degli statement SQL.


La dimensione della database buffer cache è definita tramite il

prodotto tra il parametro DB_BLOCK_SIZE ed il parametro

DB_BLOCK_BUFFERS.

Database Buffer Cache

Contiene al suo interno i dati usati più di recente, Oracle utilizza l’algoritmo LRU per decidere quando far uscire i dati dalla database buffer cache.

Redo log buffer

La dimensione della redo log buffer cache è definita tramite il

parametro LOG_BUFFER.

Redo Log Buffer

La redo log buffer contiene la registrazione dei cambiamenti fatti internamente all’istanza, questa area di memoria viene acceduta sequenzialmente e sovrascritta in maniera ciclica.

Passi per processare uno statement DML

Uno statement DML viene processato tramite due passi procedurali:

PARSE: il processo server riceve lo statement ne verifica la validità e lo compila, alla fine di questa fase il processo server ritorna lo stato del parsing cioè fallimento o successo

EXECUTE:

1 Il processo server legge i dati e i blocchi di rollback dai datafile se non sono nella database buffer cache

2 Copia i blocchi letti nella database buffer cache

3 Il processo server mette il lock ai dati

4 Il processo server registra i cambiamenti da fare nei segmenti di rollback (before-image) e i dati (nuovi valori) nella redo log buffer

5 Il processo server registra la before-image sui blocchi di rollback e aggiorna i blocchi dati, entrambi nella database buffer cache, questi blocchi vengono marcati come ‘dirty’, cioè differenti da quelli sul datafile

Passi per processare uno statement DML

Processare uno statement DML

Processo server

Shared Pool Redo

log buffer


Datafiles

ControlFiles

Redo LogFiles

1

2

3

4

5Database

SGA

Segmenti di rollback

Segmenti di rollback

Tavola

Immagine precedente del dato

Statement DML

Nuova immagine del dato

L’immagine precedente del dato viene usata per:

Tornare indietro nel caso si esegua un rollback;

Assicurare alle altre transazioni un accesso a dati consistenti;

Eseguire un recovery ad una situazione consistente in caso di problemi;

Passi per processare una COMMIT

Il processo server mette una riga contenente la COMMIT con un SCN (System Change Number) nella redo log buffer;

LGWR si occupa di scrivere tutte le entries nei redo log compresa la COMMIT, solo a questo punto Oracle può garantire una scrittura consistente dei dati e che le modfifiche fatte non andranno perse;

A questo punto l’utente viene informato che la COMMIT è stata eseguita correttamente;

Il processo server registra che la transazione è completa e rilascia i lock;

La scrittura dei ‘dirty blocks’ sui datafile avviene in maniera indipendente e può avvenire anche prima o dopo la COMMIT;

Autenticazione al database

Nella creazione del database vengono creati automaticamente due utenti:

SYS con password change_on_install

SYSTEM con password manager

Per evitare accessi non desiderati al database che amministrate è opportuno cambiare queste password dopo la creazione del database.

Alla creazione del database viene creato anche un ruolo di nome DBA questo ruolo ha privilegi molto potenti e va assegnato con cautela.


I seguenti metodi per l’autenticazione al database sostituiscono la sintassi CONNECT INTERNAL fornita con le precedenti versioni di Oracle:

Autenticazione da sistema operativo

File di password

Se si desidera amministrare il database localmente sulla macchina dove il database risiede o da un client remote si può scegliere tra un metodo e l’altro.


Amministrazione locale del database

Utilizzare l’autenticazione da

OS

Si

Utilizzare un file di password

Si Volete utilizzare la

autenticazione da OS?

Amministrazione Remota di un

database

NoNo

Volete utilizzare la

autenticazione da OS?

Avete una connessione

sicura?

I ruoli OSDBA e OSOPER

Il ruolo OSOPER permette di eseguire i comandi: STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, RECOVER, e include il privilegio RESTRICTED SESSION.

Il ruolo OSDBA contiene tutti i privilegi con l’ADMIN OPTION, il ruolo OSOPER, permette di eseguire un comando CREATE DATABASE e di effettuare un time-based recovery.

Questi ruoli possono avere nomi diversi e funzionalità diverse a seconda del vostro OS, anche come la modalità di assegnazione di questi ruoli dipende dal sistema operativo.

Utilizzo del file di password

Affinchè questo tipo di autenticazione funzioni bisogna:

Creare il file di password utilizzando l’utility ORAPWD:ORAPWD FILE=filename PASSWORD=password ENTRIES=max_users

Impostare il parametro di inizializzazione: REMOTE_LOGIN_PASSWORDFILE a EXCLUSIVE

Aggiungere gli utenti al file di password utilizzando l’SQL per assegnare i privilegi appropiati agli utenti che dovranno occuparsi dell’amministrazione del database, come mostrato nell’esempio seguente:

GRANT SYSDBA TO utente01; oppure GRANT SYSOPER TO utente02;

Ora l’utente utente01 si dovrebbe poter connettere con il comando:CONNECT utente01/[email protected] AS SYSDBA

Creare un database

Ci sono una serie di passi da portare avanti per creare un database:

1) Creare le strutture informative del database, incluso il data dictionary (dizionario dei dati), Oracle ne ha bisogno per accedere ed utilizzare il database;

2) Creare e inizializzare i control files ed i files di redo log per il database;

3) Creare i nuovi datafile o cancellare i dati che esistevano in datafile precedenti;

Come creare un database

Per creare un database ci sono varie opzioni:

Creare il database con il comando CREATE DATABASE, ma affinchè il proprio db sia operativo bisogna fare una serie di procedure dopo la creazione, creare i tablespace temporanei ed assegnarli agli utenti, creare le viste del dizionario dati, installare i package predefiniti di Oracle;

Utilizzare Oracle Database Configuration Assistant (DBCA), questo tool permette di creare il database tramite una serie di schermate che permettono l’immissione dei requisiti del vostro database, DBCA ha anche l’opzione di non creare il database materialmente ma di preparare degli script;

DBCA

Questa è la schermata iniziale del DataBase Configuration Assistant, dove posso scegliere quale operazione effettuare con questo tool.

Il comando CREATE DATABASE

CREATE DATABASE DB_PROVA CONTROLFILE REUSE LOGFILE 'c:\oracle\db_prova\redo01.log' SIZE 2M REUSE, 'c:\oracle\db_prova\redo02.log' SIZE 2M REUSE, 'c:\oracle\db_prova\redo03.log' SIZE 2M REUSE

DATAFILE 'c:\oracle\db_prova\system.dbf' SIZE 20M REUSE

AUTOEXTEND ON NEXT 10M MAXSIZE 100M

CHARACTER SET WE8ISO8859P1;

Il comando CREATE TABLESPACE

CREATE TABLESPACE RBS

DATAFILE 'c:\oracle\db_prova\rbs.dbf' SIZE 10M REUSE

AUTOEXTEND ON NEXT 10M MAXSIZE 150M;

CREATE TABLESPACE UTENTI

DATAFILE 'c:\oracle\db_prova\utenti.dbf' SIZE 50M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 350M;

CREATE TABLESPACE TEMP

DATAFILE 'c:\oracle\db_prova\temp.dbf' SIZE 10M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 150M;

Parametri di inizializzazione

SQLPLUS> connect / as sysdba

SQLPLUS> startup pfile=/$ORACLE_HOME/dbs/init_sid.ora

Init_sid.ora

Shared Pool

Redo log bufferDatabase buffer

cache

SGAIstanza

SMON DBWR PMON CKPT LGWR ARCH

Esempio file di inizializzazione

# Initalization Parameter File: init_sid.oradb_name = nome_sidcontrol_files = (/mount_point01/control01.ctl, mount_point02/control02.ctl)db_block_size = 8192db_block_buffers = 2000shared_pool_size = 30000000log_buffer = 64Kprocesses = 50db_files = 100log_files = 10max_dump_file_size = 10240background_dump_dest = (/$ORACLE_BASE/admin/nome_sid/BDUMP)user_dump_dest = (/$ORACLE_BASE/admin/nome_sid/UDUMP)core_dump_dest = (/$ORACLE_BASE/admin/nome_sid/CDUMP)rollback_segments = (R0101, R0102, R0103, R0104, R0105, R0106, …, ...)…..

Startup e Shutdown

Startup in tre step differenti:

1. Avviare l’istanza

2. Montare il Database

3. Aprire il Database

Shutdown in tre step differenti:

1. Chiudere il Database

2. Smontare il Database

3. Chiudere l’istanza

Startup

Quando avviamo un’istanza: Leggiamo il file dei parametri init_sid.ora; Allochiamo la memoria necessaria per la SGA; Facciamo partire i processi in background; Tracciamo il nostro operato sull’Alert;

Quando montiamo il Database: Associamo un database con l’istanza precedentemente

avviata; Localizziamo ed apriamo i control files specificati sul file di

Parametri; Leggiamo i control file ed otteniamo nome e stato dei data

files e dei redo log files;

Startup

Quando apriamo il Database: Apriamo i data files in linea Apriamo i redo log files in linea Controlliamo la consistenza del database

Shutdown

Quando chiudiamo il Database:• Scriviamo i dati cambiati sui rego log files

• Chiudiamo tutti i data files ed i redo log files in linea

• I control files rimangono aperti finche è montato il database

Quando smontiamo il Database:

• Chiudiamo tutti i control files • Lasciamo solamente l’istanza aperta

Shutdown

Quando chiudiamo l’istanza:

• Chiudiamo i file di trace e l’ALERT • Liberiamo la memoria occupata dalla SGA

• Terminiamo i processi in background

Tipo di Shutdown

Esistono quattro modi differenti per fare lo shutdown di un’istanza:

1. Normal

2. Transactional

3. Immediate

4. Abort

Documents

CorsoGiorno4