Che materia stai cercando?

Appunti di Gestione dell'Informazione

Appunti teorici per il corso GINFO, contenente tutta la teoria fatta a lezione più la parte di laboratorio, utili al superamento dell'esame scritto e basati su appunti personali del publisher presi alle lezioni della prof. Castano dell’università degli Studi di Milano - Unimi. Scarica il file in formato PDF!

Esame di Gestione dell'informazione e basi di dati docente Prof. S. Castano

Anteprima

ESTRATTO DOCUMENTO

- Fase di publishing – il mediatore supporta la costruzione di uno schema globale unificato di

più sorgenti informative eterogenee, da usare per la formulazione di query;

- Fase di querying – in cui il mediatore trasforma una user query basata sullo schema globale

in un set di sottoquery, ognuna per ogni sorgente dati coinvolta nella query, ottenendo i vari

risultati che successivamente ricompone per fornire il global result restituito all’utente.

I wrapper sono gli addetti a trasformare la global query ed eseguire le sottoquery nei vari schemi

locali, per poi passare i risultati al mediatore.

Ricapitolando, un sistema di integrazione dati è una tripla (Global schema, Set of source schemas,

Mappings), dove:

- le query globali sono espresse in termini di G e specificano a quali dati del DB globale

(virtuale) siamo interessati;

- i dati risiedono nelle sorgenti S;

- i mappings M esprimono quali dati reali nelle sorgenti corrispondono ai dati virtuali

intenzionalmente rappresentati dallo schema globale.

6.2 – Mappings

I sistemi di integrazione dati possono essere classificati in base al modo in cui definiscono il mapping

tra lo schema globale e i vari schemi locali. Generalmente i mapping sono definiti come viste SQL, e

la loro costruzione (in generale l’intero processo di data integration) prevede il lavoro di un Data

Integrator.

Esistono due approcci di base di mapping:

1. GAV (Global-as-View) – lo schema globale è creato sulla base dell’analisi degli schemi delle

sorgenti, attraverso la loro integrazione. Quest’approccio è basato sull’idea che il contenuto

di ogni elemento dello schema globale può essere caratterizzato in termini di una vista sulle

sorgenti. Il mapping GAV specifica come recuperare i dati (reali) dalle sorgenti locali per ogni

elemento dello schema globale (virtuale). Di seguito un esempio:

46

47

In questo caso elimina i duplicati.

UNION

L’integrazione degli schemi locali genera un’unione, dove tramite GAV gli attributi locali sono

relazionati nello schema globale: viene inoltre codificata eventuale conoscenza di dominio

(come caratteristiche sui dati), dipendente grazie all’interazione diretta di esperti di dominio

e data integrator.

Nell’esempio, il fatto che S1 contenga dati di prog esperti in DB ed S2 contenga dati di prof

italiani, viene codificato tramite l’inserimento di valori di default relativamente agli attributi

area (“DB”) e country (“ITA”) rispettivamente nelle tuple prese dalle tabelle opposte.

2. LAV (Local-as-View) – lo schema globale è costruito indipendentemente dagli schemi locali,

realizzato da un esperto data integrator. L’approccio è basato sull’idea che il contenuto di

ogni schema è descritto in termini di una vista sullo schema globale. Il mapping LAV specifica

come i dati locali (reali) contribuiscono agli elementi globali (virtuali). Di seguito l’esempio

con le tabelle usate per GAV: 48

Mettendo a confronto i due tipi di mapping, otteniamo le seguenti differenze:

 Nel LAV lo schema globale è costruito a priori, nessun tool di supporto è associato a questi

sistemi, inoltre la gestione delle query risulta più difficile rispetto a GAV. È più semplice

inserire nuove sorgenti dati, poiché basta semplicemente definire un nuovo mapping

(ovvero una vista).

 Nel GAV sono forniti tool di supporto alla costruzione semi-automatica dello schema globale,

con gli associati schema mapping. La gestione delle query è più intuitiva, poiché basta

scriverla utilizzando la vista globale in termini di schemi locali. È però più complessa

l’aggiunta di nuove sorgenti, in quanto può affliggere i mapping esistenti e quindi richiedere

una riscrittura completa.

Per questi motivi è più utilizzato il GAV del LAV.

6.2.1 – Analisi della Publishing Phase GAV

Gli schemi globali possono essere rappresentati con schemi relazionali, linguaggi object-oriented

oppure linguaggi semistrutturati/XML-based: consideriamo gli schemi relazionali.

La costruzione dello schema globale è basata sull’identificazione, l’analisi e la risoluzione di conflitti

tra le diverse sorgenti locali: 49

 Schema matching – identificazione di concetti semanticamente correlati in diversi schemi

locali, basata sulla capacità di implementazione di tecniche che possono identificare dati

simili in sorgenti diverse. L’obiettivo è identificare conflitti in terminologie, strutture, formati

di dati e significati caratterizzanti i dati salvati in ogni sorgente. Le tipologie di conflitto sono:

a. Sinonimi, concetti con nomi differenti ma stesso significato in sorgenti diverse;

b. Omonimi, concetti con nomi uguali ma diverso significato in sorgenti diverse.

c. Rappresentazioni diverse della stessa informazione;

 Schema unification – risoluzione dei conflitti tra concetti semanticamente correlati in un

unico concetto globale, definito come unica rappresentazione globale. Viene creata una

rappresentazione unificata dei concetti in conflitto trovati con lo schema matching,

attraverso la creazione di mapping su cui costruire lo schema globale.

50

 GAV mapping – creazione dello schema globale, dove i concetti globali sono mappati nei

corrispondenti concetti locali semanticamente correlati, da cui derivano. Per ogni elemento

dello schema globale:

a. Definizione nome globale, ovvero unificazione dei corrispondenti concetti locali

usando un nome tra essi o uno generico;

b. Definizione attributi globali, ovvero l’unificazione degli attributi correlati nei concetti

locali;

c. Definizione del GAV mapping, per specificare come ogni elemento globale

corrisponde a quelli locali da cui derivano.

51

Per integrare i diversi schemi di sorgenti diverse utilizzo modelli di dati a livello middleware, come

ad esempio schema ER.

Per disambiguare gli omonimi si applica il nome più specifico, per i sinonimi si cerca il nome più

appropriato, per le rappresentazioni si mantengono quelle più ricche. Gli attributi frammentati si

ricompongono in attributi unici, mentre per la risoluzione dei vincoli di integrità si mantiene il meno

restrittivo. 52

ESERCIZIO GAV – Publishing Phase

53

54

6.2.2 – Analisi della Querying Phase GAV

Questa fase permette la sottomissione di query formulate sullo schema globale, effettuando le

opportune operazioni per suddividere una query tra tutte le sorgenti e ottenere un risultato globale

come composizione dei risultati locali. Questa fase si suddivide in:

1. Query rewriting – riscrittura della query globale in base alle sorgenti locali, grazie all’utilizzo

della mapping table. Vengono generate un set di query locali.

A partire dalla query globale, vengono analizzati gli attributi ed associati ai relativi attributi

locali, come scritto nella mapping table, e create le opportune query locali. Ad esempio:

2. Local query execution – le query generate al passo precedente vengono sottomesse ai siti

locali dai rispettivi wrapper, i quali restituiscono i risultati per la fase successiva. Esempio:

55

3. Mediated query execution – i risultati ottenuti vengono quindi ricomposti, rimappando gli

attributi locali con quelli globali (attribute renaming e value conversion), e poi effettuare il

merge tra le istanze comuni (object fusion) ed ottenere il risultato globale della query

sottomessa.

a) Attribute renaming: processo opposto al query rewriting, tramite la mapping table

si compongono gli attributi locali per creare quelli globali.

b) Data transformation: i dati dalle sorgenti vengono trasformati nel formato globale.

56

c) Object fusion: le istanze dello stesso oggetto comuni tra diverse query locali devono

essere identificate ed unite per generare la risposta globale alla query di partenza

senza fornire dati duplicati, ovvero è quel meccanismo di riconoscimento delle tuple

che si riferiscono agli stessi oggetti in sorgenti diverse. Si utilizzano tecniche basate

sul join approssimato: vi è una JoinMap table che definisce il criterio di join con cui

confrontare le istanze di due diverse relazioni R e R’, contiene quindi la codifica dei

match scelti per riconoscere le istanze comuni.

i. Join esatto (diretto): le chiavi locali k e k’ sono omogenee e matchano, per cui

diventano attributi del join per la JoinMap e la condizione dell’equijoin su k e

k’ diventa la condizione per riconoscere le istanze corrispondenti di R e R’;

ii. Join approssimato (indiretto): gli attributi x e x’ del join sono definiti dal

designer (Data analist/integrator) diventando quindi gli attributi per la

JoinMap. Il predicato di similarità su x e x’ diventa la condizione per

riconoscere le istanze corrispondenti di R e R’. Questo paio di valori

corrispondenti di x e x’ è esplicitamente inserito nella JoinMap table.

La differenza tra questo join ed il precedente è che non viene ricercata una

coincidenza forzata sui valori, si considera la similarità.

Esempio: 57

Il risultato globale finale della query è quindi costruito come proiezione (select) sull’istanza ottenuta

tramite outer join tra i risultati delle query locali. Esempio:

I sistemi di Data Integration sono complessi, vengono costruiti a partire da una conoscenza della

struttura dei vari DB locali considerati. Gli accessi allo schema globale sono limitati alle sole

operazioni di lettura (read-only), mentre le scritture, per ragioni di consistenza, sono eseguite

localmente: sarebbe costosissimo e gravosa una propagazione di scritture.

58

Esercizio su Data Integration

59

60

ESAME:

- Domande a risposta chiusa su teoria e lab;

- Esercizio su gestione transazioni: questa T è conflict-serializable? Se si, qual è lo schedule seriale

equivalente?

- Esercizio su recovery: effettuare il recupero dato un file di log;

- Dare lo schema di frammentazione o allocazione, data una query;

- Trovare il piano di esecuzione della query che minimizza i costi (conoscendo i dati);

- Dato schema relazionale dare uno schema di frammentazione. coerenza > giustezza

- Esercizio su data integration: date due relazioni ed alcuni dettagli sui dati, costruire lo schema

globale GAV.

1:30/2:00 H 61

Matteo Seragiotto Appunti di

Laboratorio di Gestione dell’Informazione

A.A. 2017/2018

1 – Gli account SYS e SYSTEM

Oracle suddivide la creazione delle tabelle dall’amministrazione del sistema, tramite due utenti

principali:

 SYS, ovvero il proprietario di tutte le tabelle di sistema. Possiede due tipi di privilegi:

o SYSOPER, che esegue

 STARTUP e SHUTDOWN;

 ALTER DATABASE OPEN/MOUNT/BACKUP

 ALTER DATABASE ARCHIVELOG

 ALTER DATABASE RECOVER (solo recovery completo)

o SYSDBA

 Possiede tutti i permessi di SYSOPER

 CREATE DATABASE

 DROP DATABASE

 SYSTEM, l’amministratore con privilegi DML (Data Manipulation Language), che può eseguire

operazioni di INSERT e UPDATE sulla tabelle di SYS.

2 – Interfaccia e connessione

L’interfaccia predefinita è quella a linea di comando, che riceve comandi di tipo SQL, PL/SQL e

comandi specifici SQL*Plus.

Si avvia da un prompt/terminale, includendo anche l’username:

sqlplus username[/password]

oppure posticipando la connessione all’istanza:

sqlplus /nolog

la connessione ad Oracle si esegue tramite la seguente sintassi:

CONN[ECT] [{username[/password][@connect_identifier]}]

Quindi per connettere l’utente system al database chiamato xe sulla macchina locale il comando

sarà: CONNECT system@xe

La disconnessione si effettua con DISCONNECT

3 – Struttura di un Database Oracle

 Istanza: insieme di processi e strutture di memoria per la gestione di uno ed un solo DB

SELECT instance_name, host_name, version FROM v$instance

SGA (System Global Area) è lo

spazio di memoria gestito

dall’istanza dove:

o Shared Pool è lo spazio

di memoria riservato

alla gestione dei

comandi SQL;

o Large Pool è lo spazio

di memoria dedicato al

backup/ripristino.

La comunicazione tra istanze di

DB Oracle avviene tramite

l’utilizzo di un livello di rete

proprietario chiamato TNS

(Transparent Network Substrate), il quale si appoggia a tecnologie come TCP/IP.

Ogni istanza di Oracle deve essere configurata ed associata ad un nome TNS (esattamente

come ogni host in una rete TCP/IP deve essere associato ad un indirizzo IP).

 Database: spazio fisico su disco dove vengono memorizzati i dati. Può essere gestito da più

istanze.

 Tablespace: suddivisione ulteriore del database

SELECT tablespace_name FROM dba_data_files

Oracle memorizza un file per ogni tablespace.

Data files e Control files contengono informazioni sul database,

quali nome DB, nome e posizioni dei datafile e dei RedoLog,

timestamp creazione del DB, indici e informazioni di posizione dei

REDO log, informazioni su checkpoint, dump, eccetera.

REDO Log contiene ogni operazione di modifica/inserimento

eseguita dagli utenti del DBMS (anche se non ancora

materializzate sul DB). Devono sempre esistere almeno 2 file, così

uno è sempre aperto per la scrittura e uno viene archiviato.

 Schema: è lo spazio dati di un utente, non esiste alcuna distinzione tra username e schema.

SELECT username FROM dba_users

Ogni schema contiene la tabella virtuale dual, creata originariamente per duplicare le righe

di una tabella tramite ma nelle ultime versioni è utilizzata per chiamare funzioni di

join,

sistema o funzioni utente in modo ottimizzato. Quando si invocano funzioni di sistema si

utilizza (clausola FROM obbligatoria sempre con la SELECT). Esempi:

SELECT * FROM dual

4 – Creazione utente -> GRANT CREATE SESSION to scott

permette all’utente di effettuare il logging

nel DB;

-> GRANT CREATE TABLE to scott

permette all’utente di creare tabelle nel

DB;

5 – Transazioni e proprietà

Oracle garantisce le proprietà ACIDe (Atomicity, Consistency, Isolation, Durability) mediante il

concetto di transazione: ogni operazione DML (insert & update) eseguita fa parte della stessa

transazione fino all’invio del comando esplicito di COMMIT o ROLLBACK.

6 – Locking

La granularità dei locking in Oracle DB è a livello di tupla. È comunque possibile richiedere

esplicitamente il lock a livello di relazione o modificare l’impostazione predefinita con il comando

ALTER TABLE tname LOCKSIZE [TABLE|ROW]

Sono previste 5 modalità di lock:

 RS: row share;

 RX: row exclusive;

 S: share;

 SRX: share row exclusive;

 X: exclusive.

Dalla tabella sopra sono visibili le operazioni ed i relativi lock attivati: Footref1 indica che i lock RS

ed RX sono attivati solo se l’operazione non avviene su righe della tabella che siano in conflitto con

le righe già modificate o bloccate.

I lock in generale servono unicamente per risolvere diverse problematiche relative agli accessi

concorrenti, per cui in un DBMS single-user è inutile il concetto di lock.

È possibile fare a meno di lock in presenza di letture concorrenti solo in due casi:

1. Se accettiamo di poter leggere dati “sporchi”, ovvero dati che potrebbero ancora subire un

rollback;

2. Se utilizziamo altre tecniche per evitare le letture sporche.

Mentre in presenza di scritture concorrenti è impossibile fare a meno dei lock: potremmo avere

uno o più utenti connessi (o processi) che scrivono contemporaneamente sullo stesso blocco dati,

con conseguenze importanti.

Per risolvere il problema delle “dirty read”, ovvero le letture di dati in stato uncommitted è

necessario impostare un lock RX (row exclusive) sul dato prima di ogni scrittura e rilasciarlo solo

dopo aver terminato le operazioni della transazione, oltre a richiedere un lock RS (row shared) sul

dato prima di ogni lettura e rilasciarlo dopo la lettura stessa (il contro di quest’approccio è che le

transazioni che richiedono il dato bloccato rimarranno in attesa fino al commit della T che sta

attualmente detenendo il lock).

Per evitare le “nonrepeatable read”, cioè quando le letture di uno stesso dato in momenti diversi

della stessa transazione portano a risultati diversi, si applica la stessa soluzione del caso precedente

per le scritture. Per le letture invece si imposta un lock RS (row shared) e lo si mantiene fino al

commit, dopodichè si può rilasciare.

Per evitare le “phantom read”, letture aggregate che producono risultati diversi in momenti diversi

della stessa transazione (a causa di nuovi inserimenti), si imposta un lock S (shared) su tutte le

tabelle coinvolte nella query aggregata prima della prima esecuzione e lo si rilascia dopo aver

eseguito tutte le operazioni della T. Per contro questa soluzione impedisce l’accesso ai dati fino a

quando non termina la transazione che li ha bloccati.

Quando una transazione effettua un’operazione di scrittura su una riga di una relazione, due

tipologie di lock si attivano automaticamente:

 Lock a livello di DML (insert & update), che previene la sovrascrittura della riga da parte di

altre T. Tale lock viene rilasciato dopo il commit o rollback della T che sta modificando;

 Lock a livello di DDL (create, alter è drop), in modo da prevenire la modifica della struttura

della relazione. Verrà rilasciato solo dopo un commit o un rollback della T che sta

modificando.

Le informazioni sui lock sono mantenute nella tabella v$lock, i cui dati fanno riferimento ad

identificatori di oggetti (tabelle, viste, indici) e a codici che rappresentano la tipologia di lock.

ESEMPIO FUNZIONAMENTO LOCK:

- Locking no hang

- Locking hang

7 – Deadlock

Oracle rileva i deadlock in due modi:

1. Nel caso di transazioni locali si analizza il grafo delle dipendenze;

2. Per le transazioni distribuite si utilizza l’analisi del timeout.

Una volta che viene rilevato il deadlock viene effettuato il rollback a livello di statement. Ma come

è scelta la transazione su cui fare rolback?

Analizzando il grafo, la T che crea il ciclo chiudendolo è la T che spinge l’altra in deadlock: la T che

rileva il deadlock è la transazione che subisce il rollback.

Lock escalation: si verifica quando una grande quantità di lock è detenuta ad un livello di granularità

(ad esempio livello di riga) e il DBMS li innalza automaticamente (ad esempio a livello di tabella).

Oracle non effettua queste operazioni, poiché in questo modo previene eventuali deadlock, i quali

sono sempre costosi da gestire (sia per il sistema che per l’utente). Nel caso in cui si voglia acquisire

il lock ad un livello più alto, lo si richiede esplicitamente.

8 – Caching

Il sistema di caching funziona in modo intuitivo: quando il DBMS riceve un aggiornamento per il dato

A, esso viene memorizzato in una memoria cache. Solo quando è il momento il DBMS scarica la

cache su disco (flush), materializzando effettivamente il nuovo dato.

Ci sono due meccanismi di gestione della cache:

- Shadow paging: tutte le modifiche sono eseguite su copie dei file e, quando effettuo il

commit, il sistema sposta le modifiche della copia sul blocco dati principale. Questo metodo

garantisce consistenza in caso di guasti;

- Write Ahead Logging: il più usato, scrivo prima il record di log relativo all’azione (con gli

UNDO e REDO record), poi finalizzo la modifica nel blocco dati. In caso di guasti, al riavvio

leggo i log di REDO/UNDO e rieffettuo/disfo le operazioni.

Ovviamente il secondo meccanismo è il più usato perche nel caso del primo verrebbero create

moltissime copie inutili.

Oltre alla gestione di questo tipo, si gestisce il caching anche tramite lo stato (committed o no) delle

transazioni:

 Steal/No-steal: definisce se al DBMS è permesso (steal) o vietato (no-steal) eseguire il flush

dei blocchi cache relativi ad una T non ancora committed;

 Force/No-force: definisce se il DBMS è obbligato a memorizzare immediatamente (force) i

dati di una transazione dopo il suo commit oppure se può posticiparla (no-force).

9 – Logging

Per effettuare logging ci si avvale di due tipi di tecniche:

 UNDO/NO-UNDO: definisce se il DBMS è tenuto a memorizzare un log di UNDO (BFIM) o

meno. Il log di UNDO è indispensabile quando avviene un guasto e vi sono una o più T attive

e non committed, poiché al riavvio si riporta il sistema ad uno stato consistente, ripristinando

i valori precedenti alla modifica;

 REDO/NO-REDO: definisce se il DBMS è tenuto a memorizzare un log di REDO (AFIM) o

meno. Il log di REDO è indispensabile quando avviene un guasto e vi sono una o più T attive

che hanno eseguito il commit, poiché al riavvio per essere certi che la modifica sia stata

eseguita correttamente si ri-effettua l’operazione mettendo i dati correttamente.

Se vincoliamo troppo il DB, utilizzando la tecnica no-steal/force, abbiamo la sicurezza massima, ma

dobbiamo poi tener conto che il DB dovrà rispondere a mie specifiche regole per gestire la sua cache.

Invece se diamo libertà con la tecnica steal/no-force abbiamo bisogno di meccanismi di recovery.

Di default in Oracle il logging si basa sull’approccio UNDO/REDO e la cache è gestita con la tecnica

STEAL/NO-FORCE (infatti STEAL necessita dei record log UNDO e NO-FORCE dei record log REDO).

In Oracle è possibile disattivare i REDO log (per transazione o per tablespace), producendo due

effetti:

 Le transazioni che effettuano modifiche sui dati (insert/delete/update) risultano più veloci

del 30%;

 In caso di guasto disco dopo l’ultimo backup, i dati inseriti non saranno recuperati.

10 – Simulazione guasto in Oracle

Prima di tutto è necessario inizializzare i backup “online”

Il guasto è rappresentato dalla sostituzione del backup con un file vuoto, da cui è impossibile

recuperare i dati:

Provando a interrogare il DB da errore, lo stesso provando a mettere offline il tablespace.

Ora tentiamo di eseguire un ripristino:

Effettuando una select ora vedo i vecchi file e quelli aggiunti prima della sostituzione del file

USERS.dbf con quello vuoto.

Ripristiniamo ora lo stato iniziale della macchina:

Il sistema ora è riuscito a reinserire le due righe che in teoria non c’erano nel file USERS.dbf (poiché

messe con il file USERS.dbf vuoto), grazie ai REDO log.

Per attivare o disattivare la modalità (sovrascrittura dei REDO log) abbiamo spento il

archivelog

DB: è possibile farlo senza spegnerlo, ma se ci fossero utenti connessi sarebbe un problema. Come

soluzione esiste un modo per mettere a riposo il DB senza far perdere il lavoro agli utenti, ovvero lo

stato QUIESCED, attivabile solo da SYS e SYSTEM.

Quando il sistema si trova nello stato QUIESCED, non è consentito a nessuna sessione di

inactive

tornare ovvero tutti gli utenti che stanno attualmente lavorando (eseguendo transazioni),

active,

quindi continuano ad eseguire le operazioni fino al termine, mentre quelli che non stanno

active,

facendo nulla (inactive) non possono eseguire azioni: in questo stato è quindi possibile eseguire

modifiche sul DB senza problemi.

SYS e SYSTEM possono usare il comando

ALTER SYSTEM QUIESCE RESTRICTED;

Per far sì che la transazione venga messa in HANG (congelata) fino a che ogni altra T (non di SYS o

SYSTEM) termini (commit o rollback) o che ogni altra risorsa richiesta venga rilasciata. Quando la

richiesta è completata, il DBMS nega a qualunque T in stato inactive di passare a quello active.

Il controllo dello stato quiesced è demandato al Resource Manager, ovvero il processo che si

sostituisce al sistema operativo e si occupa dell’allocazione di memoria e dello scheduling (secondo

le direttive fornite dal DBA). Non è disponibile nella versione di Oracle utilizzata in lab.

Una volta terminate le operazioni di manutenzione, si ritorna allo stato normale con il comando

ALTER SYSTEM UNQUIESCE;

11 – Livelli di isolamento

Oracle utilizza due sistemi per la gestione della concorrenza:

 Sistema di locking;

 Sistema di versioning.

Sono due i problemi da risolvere legati alla concorrenza:

 Una singola query (statement-level) deve leggere, durante la sua esecuzione, dati consistenti

(no dirty read o nonrepeatable read) -> Read Consistency.

A livello di statement viene garantita la lettura delle sole modifiche apportate prima

dell’esecuzione della query, o apportate dalla query stessa.

Ogni blocco dati in memoria ha associato un SCN (System Change Number), quando una

nuova query/transazione viene avviata, le viene associato SCN .

1

I blocchi aventi SCN<=SCN vengono letti normalmente, mentre quelli aventi SCN>SCN

1 1

vengono invece recuperati dai segmenti di rollback (overo dagli UNDO record).

 Un’intera transazione (transaction-level) deve poter essere eseguita ad un alto livello di

isolamento. Sono disponibili tre possibili livelli di isolamento:

a. Read committed (default) – una T a questo livello si appoggia agli UNDO log ed al

SCN per accedere unicamente alle modifiche committed, ma soffre del problema

delle (1) nonrepeatable reads e dei (2) phantom record.

(1)

(2)

b. Serializable – una T a questo livello si appoggia agli UNDO log ed al SCN per lavorare

su una fotografia dello stato del DB al momento dell’inizio della T stessa (tutto ciò

che è committed), tenendo in considerazione solo le modifiche apportate (dalla T

stessa). Non soffre di nessun problema (immagine al punto precedente), ma questo

livello di isolamento può essere disturbato, come nel caso in cui una T tenti di

modificare tuple già modificate e committed da altre T.

Quindi se imposto la T come serializable posso leggere la mia vecchia versione del DB

anche mentre altri cambiano i dati, ma non posso modificare un dato sulla versione

vecchia se un altro utente l’ha aggiornato nella versione attuale: se ci si prova avviene

errore per serializzazione, le istruzioni in conflitto vengono bloccate ma il resto della

T resta valida.

Se invece lavorando sempre nella T serializable cerco di modificare una riga nella mia

vecchia versione, mentre una T di un altro utente ha effettuato una modifica sulla

stessa riga ma non ha ancora terminato (commit o rollback), la T serializable va in

HANG in attesa di conferma dell’altro utente (dalla versione 10 di Oracle,

precedentemente avrebbe generato errore di serializzabilità). Alla fine se il secondo

utente decide di fare commit, viene annullata la modifica della T serializable,

altrimenti se fa rollback viene confermata. SYS non può avere T serializable o read

only.

c. Read only – una T a questo livello si comporta come una T serializable, permette di

leggere tutto ciò che al momento dell’avvio della T è committed. Questa modalità è

utile per alleggerire il carico di lavoro del sitema (meno controlli dato che si assume

che la T non farà scritture, e quindi non servono recordo di UNDO o REDO). È adatta

per analisi statistiche sul DB, ma non rispetta lo standard SQL92 (img precedente)

________________________________________________________________________________

12 – Transazioni distribuite

Oracle permette la distribuzione grazie agli Oracle Net Services, un layer di comunicazione di rete

proprietario, basato sulla pila OSI (Open System Interconnection), inserendosi nei livelli Session e

Transport.

Vi è il Net Foundation Layer, il quale si occupa di stabilire e mantenere la connessione tra client e

server, gestire lo scambio di messaggi. Sfrutta la tecnologia proprietaria TNS (Transparent Network

Substrate), che permette la gestione di connessioni P2P e del servizio di naming.

Poi c’è il Protocol Support, layer posizionato tra il Net Foundation Layer ed il layer Network. Esso

supporta i protocolli TCP/IP (anche con SSL) e le Named Pipes.

È possibile aggiungere un host per il TNS, configurabile tramite il file tnsnames.ora, nel quale

abbiamo inserito il riferimento per connettersi al database dell’ISLab.

A partire dalla tabella PERSON creata dall’utente scott e l’accesso all’istanza Oracle dell’ISLab posso

utilizzare le due istanze (scott e Island) e le rispettive due tabelle person e person_role creando un

Database link (come utente system):

create [public] database link [dblink name] connect to [remote user]

identified by [password] using ‘[nome macchina]’

dopodichè sempre da system si esegue il comando:

CREATE PUBLIC DATABASE LINK island CONNECT TO scott IDENTIFIED BY

islabtiger USING ‘islandtns’;

la query distribuita userà il join tra la tabella person di scott e la tabella person_role sull’istanza

island.

Per sapere tutti i link creati dai vari database in memoria basta visualizzare la tabella con la query

SELECT * FROM dba_db_links;

la gestione dei lock è basata sul timeout: se si esegue update su person_role da entrambi system e

scott sulla stessa tupla (attributo della tupla), uno dei due riuscirà ad ottenere il lock, mentre l’altro

dopo 10 secondi di attesa annulla l’operazione.

A livello locale la consistenza è garantita dal sistema di gestione dei lock e dalle funzionalità di

rollback, mentre nel caso di transazioni distribuite i problemi sono più complessi:

 Le singole istanze possono procedere al commit solo quando tutte le parti hanno completato

correttamente la transazione;

 Una volta iniziato il commit, questo deve essere eseguito da tutte le istanze.

13 – Oracle 2PC (2-Phase Commit)

Prima dell’esecuzione della transazione distribuita il sistema designa:

1. Il CPS (Commit Point Site), ovvero il nodo che decide se effettuare il commit o il rollback

della transazione. Solitamente è il nodo sul quale risiede la porzione più critica dei dati;

2. Il GC (Global Coordinator), il nodo che ha originato la transazione;

3. I LC (Local Coordinator), ogni nodo che deve richiedere risorse agli altri nodi, per eseguire la

propria parte della transazione.

Dopodichè seguono le due fasi principali:

 PREPARE phase: dopo l’esecuzione della query da parte di tutti i nodi, il GC richiede a tutti i

nodi, escluso il CPS, di promettere un commit;

 COMMIT phase: se tutti i nodi si dichiarano pronti, il GC richiede al CPS di fare commit. In

caso positivo richiede il commit a tutti gli altri nodi. Ogni LC propaga la richiesta ai suoi client.

Successivamente si passa ad un’ulteriore fase finale di FORGET, nella quale dopo la conferma del

commit da parte di tutti i nodi, il GC cancella le informazioni parziali riguardanti la transazione.

Ogni nodo, prima di dichiararsi pronto alla fase di commit, compila i REDO log e le informazioni di

UNDO per il rollback, e attiva i lock necessari sulle tabelle coinvolte. Al termine della prima fase

PREPARE risultano quindi memorizzate tutte le informazioni di log necessarie al completamento

della transazione o al suo rollback.

Questo protocollo garantisce che tutti i nodi facciano commit, oppure che non lo faccia nessuno. Se

anche un solo nodo non si dichiara pronto, l’intera transazione verrà annullata, su segnale del GC,

da ogni singolo nodo.

Possono verificarsi situazioni di dubbio, come possibili errori di comunicazione di rete, crash di uno

dei nodi coinvolti oppure il sollevarsi di un’eccezione non controllata durante l’esecuzione della T

da parte di uno dei nodi: a supporto di questi avvenimenti esiste il sistema RECO.

RECO (Oracle RECOverer Process) è un processo in background creato all’avvio di un’istanza relativa

a transazioni distribuite, utile a risolvere transazioni in dubbio.

Il RECO di un nodo distribuito si connette automaticamente agli altri database coinvolti, risolvendo

automaticamente il problema della transazione in dubbio rimovendo da ogni pending transaction

table ogni riga che corrisponde ad una T in dubbio risolta.

Se il RECO non riesce a connettersi con un server remoto, riprova automaticamente dopo un certo

intervallo di tempo (che aumenta ad ogni tentativo).

Questo processo è presente solo per le istanze che permettono le transazioni distribuite.

Quando RECO identifica una transazione in dubbio, blocca automaticamente tutti i dati coinvolti da

lettura/scrittura, dato che risulta impossibile determinare quali siano consistenti e quali no (essendo

appunto una situazione in dubbio).

Viene eseguito il rollback automatico (o completamento automatico) della transazione non appena

tornano ad essere disponibili tutti i nodi.

Se il sistema RECO è disattivo durante il crash di una transazione distribuita, il DBA dovrà occuparsi

manualmente del recupero:

- leggere i log contenuti nel GC;

- eseguire il commit o il rollback della T sui singoli nodi coinvolti;

- disattivare i lock e cancellare le informazioni sulla T fallita.

Se eseguiamo il commit di una transazione con il seguente commento:

COMMIT comment'ORA-2PC-CRASH-TEST-n;

con n appartenente a questa tabella:

Possiamo simulare il tipo di crash descritto sopra.

Simulando il crash di tipo 4 (guasto dopo la fase di prepare) sull’host remoto (island), vediamo che

il RECO si è attivato convergendo l’esito della T sul rollback.

Eseguendo la stessa simulazione con RECO disattivo sull’host locale (scott), la transazione rimane

sospesa: benchè il CPS abbia deciso per il rollback (capito dopo aver visionato manualmente le

tabelle che compongono quella distribuita), in locale nessun nodo si è occupato di seguire le

indicazioni del GC (il RECO se ne occupa).

Andando a visionare la tabella (creando una vista accessibile da system con

dba_2pc_pending

l’utente sys), si possono osservare le informazioni sulle transazioni in attesa attualmente nel DB.

Osservando il fail time FT ed il retry time RT delle transazioni visualizzate: se sono uguali significa

che il RECO non è mai intervenuto, per cui è intuibile che sia disabilitato. Gli attributi visibili nella

tabella dba_2pc_pending:

- identificatore locale della transazione;

LOCAL_TRAN_ID:

- identificatore globale della transazione, composto da:

GLOBAL_TRAN_ID:

global_db_name.db_hex_id.local_transaction_id

dove

 Global_db_name identifica il nome del DB del GC;

 Db_hex_id identifica localmente il DB del GC;

 Local_transaction_id identifica la transazione locale del GC.

Se local e global transaction id sono uguali, il nodo corrente è il GC.

- collecting (GC), prepared, committed, forced commit, forced termination;

STATE:

- indica se alcuni nodi hanno fatto commit ed altri no, o meno.

MIXED: NO/YES,

Siamo quindi rientrati nel caso in cui la transazione remota fatta da island è stata completata dal

RECO con un rollback, mentre quella locale fatta da scott con RECO disabilitato ha RT=FT ed è in

stato prepared.

A questo punto, dato che il RECO sull’host remoto ha già effettuato il rollback, significa che il CPS ha

deciso di annullare la T, per cui forziamo il rollback anche sul’host locale dove il RECO è disattivo:

ROLLBACK FORCE ‘global_tran_id’;

per ripulire l’elenco delle T sospese (ovvero basta riattivare il RECO.

dba_2pc_pending)

POSSIBILI DOMANDE ESAME:

 Come funzionano i sistemi di logging in Oracle?

Oracle basa il logging sull’approccio UNDO/REDO, mantiene quindi in memoria tutti i

cambiamenti effettuati sui dati, nel momento in cui avviene la singola modifica. Ogni istanza

di Oracle ha associato un archivio di REDO log, ovvero l’insieme di tutti i redo log salvati ad

ogni operazione effettuata (contenenti la BFIM e la AFIM, in caso di ri-esecuzione

dell’azione). Inolte Oracle crea e gestisce le informazioni per effettuare il rollback delle

transazioni sotto forma di UNDO record, prima ancora che le T siano committed: quando si

eseguono operazioni al’interno di una T, ognuna di esse viene registrata con un UNDO

record, in modo che se viene fatto il rollback si possono annullare tutte le azioni.

In definitiva, durante l’esecuzione del DB recovery, gli UNDO record sono utilizzati per

smontare tutti i cambiamenti non committed applicati a partire dai REDO log salvati.

È possibile interagire con lo store dei REDO log, per migliorare le prestazioni del sistema,

impedendone l’archiviazione, mentre la gestione degli UNDO record è automaticamente

gestita dal sistema Oracle.

 Quali sono le policy con cui il sistema gestisce la cache?

Oracle gestisce la cache con l’approccio STEAL/NO-FORCE, ovvero è permesso il flush dei dati

relativi a transazioni uncommitted e non viene forzato il flush dopo ogni singolo commit

(flush su dati di più T committed riduce gli accessi alla memoria). Questa policy è in accordo

al sistema di logging, che prevede sia UNDO record che REDO record: infatti la regola STEAL

necessita dei record log UNDO (appunto perche si salvano dati di T non committed) e la

regola NO-FORCE dei record log REDO (appunto perche si posticipa il salvataggio dati di T

committed).

 Come funziona (a grandi linee) il sistema di recovery in Oracle?

Oracle mette a disposizione il Recovery Manager, per l’esecuzione di backup e attività di

recupero dati in modo automatico. È possibile per l’utente gestire i backup direttamente,

utilizzando l’operazione di begin backup, la quale salva in memoria i data files, i control files,

assieme al redo log archive e il file init.ora.

Quando deve essere effettuata una modifica su un dato, viene salvato l’UNDO record per

eventuale rollback, poi viene eseguita la modifica: al commit viene salvato quindi il REDO log


PAGINE

84

PESO

3.14 MB

PUBBLICATO

4 mesi fa


DETTAGLI
Corso di laurea: Corso di laurea magistrale in informatica
SSD:
Università: Milano - Unimi
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher matteo.seragiotto di informazioni apprese con la frequenza delle lezioni di Gestione dell'informazione e basi di dati e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Milano - Unimi o del prof Castano Silvana.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea magistrale in informatica

Mobile Computing - Teoria
Appunto