Basi di Dati
Tecnologia di un DBMS:
Concorrenza e Affidabilità
Concetti Avanzati
versione 2.0
Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons
(vedi ultima pagina)
G. Mecca – [email protected] – Università della Basilicata
Tecnologia DBMS >> Sommario
Concetti Avanzati
 Transazioni
proprietà “acide”
rapporto con il S. O.
 Concorrenza
consistenza
isolamento
 Affidabilità
 Architettura
di un DBMS
G. Mecca - [email protected] - Basi di Dati
2
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni
 Transazione
sequenza di operazioni effettuate da una
applicazione sulla base di dati
 Transazioni
semplici
es: aggiungi un nuovo studente
 Transazioni
complesse
es: bonifico bancario
 Approccio
alla descrizione: sviluppatori
G. Mecca - [email protected] - Basi di Dati
3
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni
 Normalmente:
modalità non concatenata
una transazione per operazione
(“autocommit”)
 Conseguenza
il completamento di un’operazione della
transazione non implica necessariamente il
completamento delle successive
possibilità di inconsistenze nella base di dati
G. Mecca - [email protected] - Basi di Dati
4
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni

Modalità concatenata
una transazione contiene più operazioni
tutte le operazioni della transazione vengono
eseguite oppure non ne viene eseguita nessuna
(esecuzione “atomica”)

Inizio della transazione
sintassi non standard
SQL:1999: START TRANSACTION)
in PgSQL: START TRANSACTION (>=7.3)
oppure BEGIN TRANSACTION
G. Mecca - [email protected] - Basi di Dati
5
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni
 Fine
della transazione
>> esempio di transazione
-commit con successo
-commit dopo errore
-rollback
istruzioni COMMIT e ROLLBACK (ABORT)
(standard SQL-92)
 Esito
della transazione
esecuzione come unità indivisibile
COMMIT: rende permanenti le operazioni
errore: operazioni annullate dal sistema
ROLLBACK: annulla esplicitamente le
operazioni
G. Mecca - [email protected] - Basi di Dati
6
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni: La Base di Dati dei Video
CREATE TABLE Tessere (
CREATE TABLE Videoc (
cod char(4) PRIMARY KEY,
cod integer PRIMARY KEY,
nomeCliente varchar(50),
titolo varchar(50) NOT NULL,
indirizzo varchar(50),
regista varchar(20),
totalenoleggi integer DEFAULT 0
quantita integer DEFAULT 1,
);
prezzo numeric(4,2)
);
CREATE TABLE Noleggi (
video integer NOT NULL
REFERENCES Videoc(cod),
tessera char(4) NOT NULL
REFERENCES Tessere(cod),
data date NOT NULL,
PRIMARY KEY
(video, tessera, data)
);
Esempio: noleggio di una videocassetta
G. Mecca - [email protected] - Basi di Dati
BEGIN TRANSACTION;
INSERT INTO Noleggi VALUES
(110, ‘pp02’, ‘2002-04-15’);
UPDATE Videoc SET quant.=quant.-1
WHERE cod=110;
UPDATE Tessere SET totn.=totn.+1
WHERE cod=‘pp02’;
COMMIT;
7
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Proprietà “ACIDE” delle Transazioni
 Atomicità
tutte le operazioni oppure nessuna
 Consistenza
stati consistenti della base di dati
 Isolamento
correttezza dell’accesso concorrente
 Durevolezza
effetto persistente sulla base di dati (guasti)
G. Mecca - [email protected] - Basi di Dati
8
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Gestione delle Transazioni in un DBMS
 Due
moduli fondamentali
 Gestore della concorrenza
garantisce isolamento e consistenza
implementa tecniche più sofisticate di sincr.
 Gestore
dell’affidabilità
garantisce atomicità e durevolezza
utilizza un file di registrazioni (“log”) per
consentire il recupero in caso di guasti
G. Mecca - [email protected] - Basi di Dati
9
Tecnologia DBMS >> Concetti Avanzati >> Gestione della Concorrenza
Gestione della Concorrenza
 Assume
atomicità e durevolezza
fornite dal gestore dell’affidabilità
 Due
>>
obiettivi fondamentali
garantire la consistenza della base di dati
(partendo da uno stato consistente, la
transazione genera uno stato consistente)
garantire l’isolamento delle transazioni
(le transazioni devono essere eseguite come
se fossero isolate)
G. Mecca - [email protected] - Basi di Dati
10
Tecnologia DBMS >> Concetti Avanzati >> Gestione della Concorrenza
Consistenza
 Impone
i vincoli di integrità
definiti nel DDL (più eventuali “trigger”)
 Vincoli
di riferimento
la verifica può essere immediata o differita
 Istruzione
SET CONSTRAINTS
SET CONSTRAINTS ALL DEFERRED;
 Vincoli
differibili (“deferrable”)
i vincoli vengono verificati solo al COMMIT
G. Mecca - [email protected] - Basi di Dati
11
Tecnologia DBMS >> Concetti Avanzati >> Gestione della Concorrenza
Consistenza
 Esempio:
in Noleggi
video integer NOT NULL
REFERENCES Videoc(cod) DEFERRABLE;
BEGIN TRANSACTION;
SET CONSTRAINTS ALL DEFERRED;
INSERT INTO Noleggi VALUES
(200, ‘pp02’, ‘2002-04-15’);
INSERT INTO Videoc VALUES
(200, ‘Clerks’, ...);
UPDATE Videoc SET
quantita=quantita-1
WHERE cod=200;
COMMIT;
G. Mecca - [email protected] - Basi di Dati
Attenzione: parte
dell’integrità è a
carico del
programmatore
(in questo caso non
viene aggiornato
il totalenoleggi della
tessera)
12
Tecnologia DBMS >> Concetti Avanzati >> Gestione della Concorrenza
Isolamento
 L’esecuzione
di una transazione deve
essere indipendente da quella delle altre
 Strategia di esecuzione (“schedule”)
ordine di esecuzione delle operazioni
 Correttezza
di una strategia concorrente
proprietà di “serializzabilità”
il risultato è equivalente a quello di
un’esecuzione seriale (in ordine qualsiasi)
evita vari problemi di esecuzione (>>)
G. Mecca - [email protected] - Basi di Dati
13
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità
 Due
obiettivi fondamentali
garantire l’atomicità delle transazioni
garantire la durevolezza degli effetti, anche
in caso di guasti (recupero della base di dati)
 Idee
di base
registrare tutte le azioni eseguite in un file di
registro (“log”)
mantenere copie dei dati e del log (“mirror”)
strettamente legato alla gestione del buffer
G. Mecca - [email protected] - Basi di Dati
14
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità

File di registro (“log”)
si registrano tutte le istruzioni di aggiornamento
tutte le istruzioni di start transaction
tutte le istruzioni commit
tutte le istruzioni rollback

Formato dei record del log
ciascun record del log registra la modifica di un
record della base di dati da parte di una transazione
<id trans, id record, vecchio val, nuovo val.>
G. Mecca - [email protected] - Basi di Dati
15
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità

Protocollo di scrittura anticipata
“Write Ahead Logging” (WAL)

Idea
le informazioni vengono scritte secondo un ordine
che garantisce la ripristinabilità in caso di guasti
i record del log sono scritti prima dei record della
base di dati (garantisce l’atomicità)
i record del log di una transazione sono scritti tutti
prima di effettuare il commit (garantisce la
durevolezza)
G. Mecca - [email protected] - Basi di Dati
16
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità

Attenzione
in ogni istante parte delle pagine del disco sono nel
buffer in memoria centrale
se sono state modificate, in caso di guasto si
perdono le modifiche

Punto di controllo (“checkpoint”)
“fotografia” stabile della situazione della base di dati
in un certo istante
informazioni sulle transazioni attive in quel momento
scrittura su disco delle pagine relative del buffer
G. Mecca - [email protected] - Basi di Dati
17
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità

Situazione di guasto
es: corrente, rottura disco, crash sistema

Problema: ripristinare la base di dati
ripetere l’esecuzione delle transazioni a partire dal
contenuto del log
attenzione alle transazioni interrotte a metà

Algoritmo ARIES
sul log viene localizzato il primo checkpoint
azione di ripetizione (in avanti)
azione di annullamento (indietro)
G. Mecca - [email protected] - Basi di Dati
18
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità
Localizzazione del checkp.
 Fase 1: Analisi

ricerca di transazioni concluse
e fallite dal checkpoint

Fase 2: REDO
ripetizione di tutte le azioni
delle transazioni attive

Fase 3: UNDO
annullamento di tutte le azioni
delle transazioni interrotte
log
Punto di inizio
della
transazione
più antica tra
quelle fallite
Punto di inizio
della
transazione
più antica tra
quelle
concluse
Checkpoint
Guasto
A R U
G. Mecca - [email protected] - Basi di Dati
19
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità
 Descrizione
semplificata
 Tipicamente
in caso di interruzione improvvisa, il recupero
è completamente automatico
supponendo di avere a disposizione log e
checkpoint
es: PostgreSQL /var/lib/pgsql/data
al riavvio la base di dati viene ripristinata
G. Mecca - [email protected] - Basi di Dati
20
Tecnologia DBMS >> Concetti Avanzati >> Gestione dell’Affidabilità
Gestione dell’Affidabilità
 Tecniche
per l’affidabilità
mantenere copie del log; es: mirror
mantenere copie di backup della base di dati
 Copie
della base di dati (“dump”)
copia di /var/lib/pgsql/data (a DBMS fermo)
pg_dump: estrae un file di comandi
esempio:
pg_dump –U pguser deputati > deputati.sql
psql –d deputati –f deputati.sql
G. Mecca - [email protected] - Basi di Dati
21
Tecnologia DBMS >> Concetti Avanzati >> Architettura di un DBMS
Architettura di un DBMS
Gestione dei Metodi di acc.
Gestione del buffer
Affidabilità
Algebra (Operatori)
Concorrenza
Sicurezza e
Autorizzazioni
Connessioni
(TCP/IP)
Esecuzione interrogazioni
Ottimizzazione
Gestione del disco
DB
G. Mecca - [email protected] - Basi di Dati
22
Tecnologia DBMS >> Concetti Avanzati >> Architettura di un DBMS
Architettura di un DBMS
 PostgreSQL
piattaforma Linux
transazionale
SQL-92 intermediate
estensioni SQL:1999
sicurezza (connessioni in chiaro e cifrate)
“multi-version concurrency control”
WAL
G. Mecca - [email protected] - Basi di Dati
23
Tecnologia DBMS >> Concetti Avanzati >> Architettura di un DBMS
Architettura di un DBMS
 MySQL
(3.xx)
piattaforma Linux e Windows
non transazionale (componenti esterni)
sottoinsieme di SQL-92 intermediate
mancano i vincoli di riferimento
mancano le viste
mancano intersezione e differenza
mancano le query nidificate
enfasi sulle prestazioni
G. Mecca - [email protected] - Basi di Dati
24
Tecnologia DBMS >> Concetti Avanzati >> Architettura di un DBMS
Architettura di un DBMS
 Access
piattaforma Windows
non transazionale
sottoinsieme di SQL-92 intermediate
no intersezione e differenza
limitate autenticazioni
limitato controllo di concorrenza
enfasi sull’interfaccia utente
client grafico o SQL per DBMS di fascia alta
G. Mecca - [email protected] - Basi di Dati
25
Tecnologia DBMS >> Sommario
Concetti Avanzati
 Transazioni
proprietà “acide”
rapporto con il S. O.
 Concorrenza
consistenza
isolamento
 Affidabilità
 Architettura
di un DBMS
G. Mecca - [email protected] - Basi di Dati
26
Tecnologia DBMS >> Concetti Avanzati >> Transazioni
Transazioni: La Base di Dati dei Video
CREATE TABLE Tessere (
CREATE TABLE Videoc (
cod char(4) PRIMARY KEY,
cod integer PRIMARY KEY,
nomeCliente varchar(50),
titolo varchar(50) NOT NULL,
indirizzo varchar(50),
regista varchar(20),
totalenoleggi integer DEFAULT 0
quantita integer DEFAULT 1,
);
prezzo numeric(4,2)
);
CREATE TABLE Noleggi (
video integer NOT NULL
REFERENCES Videoc(cod),
tessera char(4) NOT NULL
REFERENCES Tessere(cod),
data date NOT NULL,
PRIMARY KEY
(video, tessera, data)
);
G. Mecca - [email protected] - Basi di Dati
27
Termini della Licenza
Termini della Licenza

This work is licensed under the Creative Commons AttributionShareAlike License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/1.0/ or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California
94305, USA.

Questo lavoro viene concesso in uso secondo i termini della
licenza “Attribution-ShareAlike” di Creative Commons. Per ottenere
una copia della licenza, è possibile visitare
http://creativecommons.org/licenses/by-sa/1.0/ oppure inviare una
lettera all’indirizzo Creative Commons, 559 Nathan Abbott Way,
Stanford, California 94305, USA.
G. Mecca - [email protected] - Basi di Dati
28