Tecnologia di un Database Server

1
Tecnologia di un Database Server

• S. Costantini
• Dispensa per il Corso di Basi di dati e Sistemi
  Informativi

2
Premessa

• Questa dispensa integra i contenuti della seconda
  parte del Capitolo 9 del Libro di Testo del Corso
• Atzeni, Ceri, et al., Basi di Dati concetti,
  linguaggi e architetture, McGraw-Hill editore.
• Questa dispensa non sostituisce questo capitolo,
  che va comunque studiato.

3
Modello di un Sistema
Transazione 1
Transazione N
Bot, SQL Queries Commit, Abort
Ottimizzatore Query Esecutore Query Scheduler Buff
er Manager Recovery manager
Database Server
4
Gestore degli accessi

• E il modulo di piu basso livello del data
  manager
• Nei DBMS relazionali viene chiamato RSS
  (Relational Storage System)
• Effettua in pratica gli accessi alla BD
• Conosce lorganizzazione fisica delle pagine
• Conosce la disposizione delle tuple nelle pagine
• Usa un buffer manager per la gestione del
  trasferimento effettivo delle pagine

5
Indici

• Come si implementano Read e Write?
• Bisogna reperire i dati in Memoria di Massa
• A partire dal valore della chiave di una tupla,
  occorre trovare il record id
• Record id pagina-id, offset-nella-pagina
• Un indice collega i valori delle chiavi ai record
  id.
• Le strutture indice piu comuni tabelle hash e
  B-alberi

6
Hashing

• Lhashing usa una funzione HV?B, dalle chiavi al
  numero del blocco (pagina) dove si trova il dato
• V matricola B 1 .. 1000H(v) v mod
  1000
• se una pagina va in overflow, allora si deve
  aggiungere una lista di pagine extra
• Al 90 di carico delle pagine, 1.2 accessi per
  richiesta!
• ma, va male per accessi su intervalli (10 lt v lt
  75)

7
B-albero

• Ogni nodo e' un sequence di coppie puntatore,
  chiave
• K1 lt K2 lt lt Kn-2 lt Kn-1
• P1 punta a un nodo contenente chiavi lt K1
• Pi punta a un nodo contenente chiavi in
  intervallo Ki-1, Ki)
• Pn punta a un nodo contenente chiavi gt Kn-1
• Dunque, K 1 lt K 2 lt lt K n-2 lt K n-1

8
Esempio n3
127 496
221 352
521 690

• Notare che le foglie sono ordinate per chiave, da
  sinistra a destra
• Importante per ogni chiave, la foglia contiene
  il Record id della tupla, o la tupla stessa

9
Inserzione

• Per inserire la chiave v, si cerca la foglia dove
  v dovrebbe trovarsi se ce spazio, si inserisce
• Se no, si spezza la foglia in due, e si modifica
  il padre per prevedere i puntatori alle due
  foglie

• Per inserire la chiave 15
• si spezza la foglia
• nel padre, 0, 19)diventa 0, 15) e 15, 19)
• se il padre e pieno, bisogna
• spezzarlo (in modo simile)
• lalbero resta automaticamente
• bilanciato

X
X
10
B-albero Osservazioni

• Lalgoritmo di cancellazione riunisce nodi
  adiacenti con riempimento lt 50
• La radice ed i nodi di livello uno sono mantenuti
  in una cache, per ridurre gli accessi a
• Indice secondario le foglie contengono in
  realta coppie chiave, record id
• Indice primario le foglie contengono i record

11
BAlberi

• Ogni nodo foglia ha un puntatore al successivo
• facilita la ricerca su intervalli trovata la
  prima chiave dellintervallo, basta scorrere le
  foglie adiacenti mediante i puntatori

P
P
X
C
C
C
X
12 14
12
BAlbero ottimizzazione

• Balbero - ciascuna foglia ha un puntatore alla
  prossima, nellordine dato dalle chiavi
• Obbiettivo ottimizzare interrogazioni il cui
  predicato di selezione definisce un intervallo di
  valori ammissibili
• Trovato il primo valore della chiave, si
  scandiscono sequenzialmente i nodi foglia

13
Database system Recovery

• Controllore dellAffidabilita
• S. Costantini

14
Introduzione

• Un database puo divenire inconsistente a causa
  di
• fallimento di una transazione(abort)
• errore di sistema (a volte causato da un OS
  crash)
• media crash (disco corrotto)
• Il sistema di recovery assicura che il database
  contenga esattamente gli aggiornamenti prodotti
  dalle transazioni committed (cioe assicura
  atomicita e persistenza, nonostante i guasti )

15
Terminologia

• Affidabilita - il grado di certezza con il quale
  un sistema fornisce i risultati attesi su prove
  ripetute
• Laffidabilita si misura come mean-time-between-
  failures (MTBF)
• Disponibilita - frazione di tempo nel quale il
  sistema fornisce i risultati attesi.
• La disponibilita e ridotta anche dai tempi di
  riparazione e manutenzione preventiva
• Disponibilita MTBF/(MTBFMTTR), where MTTR is
  mean-time-to-repair

16
Terminologia (cont.)

• Failure (fallimento) - un evento dove il sistema
  dia risultati inattesi (sbagliati o mancanti)
• Fault (guasto) - causa identificata o ipotizzata
  di fallimento
• Es. Un guasto nella scheda di memoria che causa
  un malfunzionamento del software
• Transient fault - e occasionale, e non avviene
  nuovamente se si ritenta loperazione
• Permanent fault - non-transient fault

17
Quali sono le cause di guasto?
Tandem 89 Tandem
85 ATT/ESS 85 Environment 7
14 Hardware 8 18
Subtotal 15 32 20 system Mgmt 21
42 30 Software 64 25 50

• Il maggior problema e il software
• Environment - incendi, terremoti, vandalismi,
  mancanza di elettricita, guasto al
  condizionatore
• system management - manutenzione, configurazione

18
Assunzioni

• Ogni transazione mantiene i write locks fino a
  dopo il commit. Questo assicura
• no aborti a catena
• strictness (non si utilizzano mai dati non
  committed)
• Gestione a livello di pagine
• il database e un insieme di pagine
• le read e write operano su pagine

19
Modello della Memoria

• Memoria Stabile - resiste ai fallimenti di
  sistema
• Buffer (volatile) - contiene copie di alcune
  pagine, che vanno perse in caso di fallimenti

Fix, Flush Use, Unfix
Read, Write
Read, Write
20
Buffer Manager

• Fornisce primitive per accedere al buffer
• Fix carica una pagina nel buffer (la pagina
  diventa valida)
• Politica no-steal mai deallocare pagine attive
• Use accede ad una pagina valida

21
Buffer Manager

• Unfix rende una pagina non piu valida
• Politica no-force non riscrivere nel DB tutte
  le pagine attive al commit
• Flush periodicamente riscrive nel DB le pagine
  non piu valide
• Force trasferisce in modo sincrono una pagina
  dal buffer al DB (transazione sospesa fino a fine
  trasferimento)

22
Il LOG

• LOG file sequenziale del gestore
  dellaffidabilità
• scritto in memoria stabile
• e una registrazione delle attivita del sistema

23
Checkpoint

• operazione periodica coordinata con
  buffer-manager
• flush di tutte le pagine di transazioni terminate
• registrazione identificatori transazioni in corso
• non si accettano commit durante il checkpoint
• si scrive in modo sincrono (force) lelenco
  transazioni attive nel LOG
• formato del record CKPT(T1,...,Tn)

24
DUMP

• copia completa del DB, fatta quando il sistema
  non è operativo (non ci sono transazioni attive)
• copia memorizzata su memoria stabile (backup )
• record di dump nel LOG
• formato record DUMP(C) dove C è il dispositivo di
  backup

25
Organizzazione del LOG

• Record del LOG
• di transazione
• di sistema (checkpoint, DUMP)
• Record di TRANSAZIONE
• le transazioni registrano nel LOG le operazioni,
  nellordine in cui le effettuano
• begin record B(T)
• commit/abort C(T), A(T)
• T e lidentificatore della transazione

26
Organizzazione del LOG

• Record di UPDATE
• identificatore transazione T
• identificatore oggetto O
• valore di O prima della modifica, before state
• valore di O dopo la modifica, after state
• U(T,O,BS,AS)

27
Organizzazione del LOG

• Record di DELETE
• identificatore transazione T
• identificatore oggetto O
• valore di O prima della cancellazione, before
  state
• D(T,O,BS)

28
Organizzazione del LOG

• Record di INSERT
• identificatore transazione T
• identificatore oggetto O
• valore di O dopo linserzione, after state
• I(T,O,AS)

29
UNDO e REDO

• UNDO si ricopia BS su O,
• INSERT si cancella O
• REDO si ricopia AS su O
• DELETE si cancella O
• UNDO e REDO sono idempotenti
• UNDO(UNDO(A)) UNDO(A)
• REDO(REDO(A)) REDO(A)
• Utile se errori durante il ripristino

30
Gestione delle Transazioni

• Regola WAL Write Ahed Log
• BS scritta nel LOG prima di operare nella BD
• gtgtgt permette UNDO operazioni se no commit
• Regola Commit-Precedenza
• AS nel LOG prima del COMMIT
• gtgtgt permette REDO operazioni se problema dopo
  commit (in no force)

31
Gestione dei Guasti

• Guasto transitorio
• perso il contenuto del buffer
• resta il LOG
• RIPRESA A CALDO (warm restart)
• Guasto permanente ad un disco
• resta il LOG (assunzione memoria stabile)
• RIPRESA A FREDDO (cold restart)

32
Ripresa a caldo

• Si cerca ultimo checkpoint nel LOG
• Si decidono transazioni da rifare (insieme di
  REDO) e disfare (insieme di UNDO)
• UNDO transazioni attive al checkpoint
• REDO inizialmente vuoto
• Si scorre il LOG
• B(T) gt T in UNDO
• C(T) gt T in REDO
• Si applicano UNDO e REDO

33
Ripresa a Freddo

• Si usa lultimo DUMP per ripristinare uno stato
  stabile della BD
• si ripercorre il LOG rifacendo tutte le azioni
  successive al DUMP
• si fa ripresa a caldo dallultimo checkpoint

34
Ottimizzazioni User-Level

• Se la frequenza dei checkpoint si puo variare,
  regolarla mediante esperimenti
• Partitionare il DB su piu dischi per ridurre il
  tempo di restart

35
Media Failures

• Un media failure e la perdita di parte della
  memoria stabile
• La maggior parte dei dischi ha MTBF a piu di 10
  anni, ma su 10 dischi...
• E importante avere dischi shadow, ossia un
  disco duplicato che faccia da copia ombra
  della memoria stabile
• Le Write vanno su entrambe le copie.
• Le Read vanno su una sola copia (in alternanza,
  per efficienza)

36
RAID

• RAID - redundant array of inexpensive disks
• Array ridondante di dischi di basso costo
• Si basa su un array di N dischi in parallelo
• Soluzione ancora piu sicura rispetto al disco
  ombra

...
...
N-M blocchi di correzione errore
M blocchi dati
37
Dove Usare Dischi Ridondanti?

• Preferibilmente sia per il DB che per il LOG
• Ma almeno per il LOG
• in un algoritmo di UNDO, e lunico modo di avere
  before images sicure
• in un algoritmo di REDO, e lunico modo di avere
  after images sicure
• Se non si ha almeno un disco ombra per il LOG, il
  sistema ha un grosso punto debole

38
TP Monitors(Transaction Processing Monitors)

• Stefania Costantini

39
Architettura Client-Server
Utente finale
Front-End (Client)
Presentation Manager
richieste
Workflow Control (gestisce le richieste)
Back-End (Server)
Transaction Program
Database Server
40
Cosa fa un TP Monitor

• TP Monitor Transaction Processing Monitor
  Controllore dellelaborazione delle Transazioni
• Una richiesta e un messaggio che descrive una
  unita di lavoro che il sistema deve eseguire.
• Un TP monitor coordina il flusso di richieste di
  esecuzione di transazioni provenienti da varie
  fonti (terminali e programmi applicativi)

41
Cosa fa un TP Monitor

• Struttura fondamentale
• Traduce linput (proveniente da form/menu, o da
  unistruzione in qualche linguaggio) in forma
  standard
• Determina il tipo di transazione
• Fa partire la transazione
• Restituisce in forma opportuna loutput della
  transazione

42
Architettura 3-Tierdi un TP Monitor

• Gli elementi dello schema possono essere
  distribuiti in rete

Messaggio di richiesta
Richieste
Rete
Controllore di Workflow
Transaction Server
Transaction Server
43
Architettura 3-Tier

• La struttura dellapplicazione ricalca la
  struttura del sistema
• Elementi del TP Monitor in unarchitettura
  3-Tier
• Presentation server forms/menus, validazione
  degli input (password, connessione sicura)
• Workflow controller data una richiesta, produce
  la chiamata al programma corretto
• Transaction server esegue le richieste

44
Presentation Server

• Presentation independence - lapplicazione e
  indipendente dal tipo di dispositivo di i/o
• terminale, ma anche telefono cellulare o lettore
  di codici a barre, o di carte di credito
• Il Presentation server ha due livelli
• Raccogliere gli input
• Costruire le richieste

45
Autenticazione

• Autenticazione determinare lidentita
  dellutente e/o del dispositivo
• Il sistema client puo effettuare
  lautenticazione, che comunque il server effettua
  nuovamente (non si fida dei client)
• Encryption della comunicazione client/server
  opportuno
• Occorrono funzioni di sistema per creare
  accounts, initializzare passwords, assegnare ore
  di accesso
• E una parte importante dello sviluppo di
  applicazioni TP

46
Workflow Controller

• Routing - Mappa il tipo di richiesta nel network
  id del server che potra elaborarla, e invia la
  risposta al client
• Gestisce errori ed eccezioni

47
Transaction Server

• Transaction server - programma applicativo che
  effettua il real work dellelaborazione delle
  richieste
• Per portabilita, e opportuno che sia scritto in
  un linguaggio di programmazione standard (C, C,
  Java, COBOL) interfacciato con un Data
  Manipulation Language standard (SQL)

48
Basi di Dati e Web

• Stefania Costantini
• Basi di dati e Sistemi Informativi

49
Transazioni su Internet

• Web browser presentation manager
• Messaggio dal web browser al server richiesta
  di transazione su sistema (Transaction server) di
  cui si da lURL
• http protocollo di comunicazione client/server
• Web server include il workflow controller
• 3-Tier su Web
• Presentation manager su client
• Workflow controller su server
• Transaction server molteplici, distribuiti su
  Internet

50
TP Monitor per Internet

• Il web server deve operare da workflow
  controller. I transaction server sono in generale
  remoti.

• TP monitors and DB servers attualmente sono
  sempre piu spesso integrati nei Web server

51
Architettura tradizionale

• Sistema/Programma dove si vuole eseguire la
  transazione gateway
• CGI (Common gateway Interface) programma
  chiamato dal server
• CGI fornisce richiesta e parametri al gateway
  (nel nostro caso al TP system)