Tecnologia di un Database Server S. Costantini Dispensa per il Corso di Basi di dati e Sistemi Informativi.

Presentazione sul tema: "Tecnologia di un Database Server S. Costantini Dispensa per il Corso di Basi di dati e Sistemi Informativi."— Transcript della presentazione:

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 1Transazione N Database Server Bot, SQL Queries Commit, Abort Ottimizzatore Query Esecutore Query Scheduler Buffer Manager Recovery manager Database

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 H:V B, dalle chiavi al numero del blocco (pagina) dove si trova il dato –V = matricola B = {1.. 1000} H(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 < v < 75)

7 B-albero KiKi PiPi K i+1 K1K1 P1P1 K n-1 PnPn... K´ i P´ i K´ i+1 K´ 1 P´ 1 K´ n-1 P´ n... Ogni nodo e' un sequence di coppie [puntatore, chiave] K 1 < K 2 < … < K n-2 < K n-1 P 1 punta a un nodo contenente chiavi < K 1 P i punta a un nodo contenente chiavi in intervallo [K i-1, K i ) P n punta a un nodo contenente chiavi > K n-1 Dunque, K ´ 1 < K ´ 2 < … < K ´ n-2 < K ´ n-1

8 Esempio n=3 127 496 14 83 221 352 127 145 189 221 245 320 521 690 352 353 487 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 19 -- 12 14 17 X 15 19 12 14 X 15 17 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

10 B-albero: Osservazioni Lalgoritmo di cancellazione riunisce nodi adiacenti con riempimento < 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 B+Alberi 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 19 -- 12 14 17 P C X 15 19 12 14 X 15 17 P C´ C

12 B+Albero: ottimizzazione B+albero - 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/(MTBF+MTTR), 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? Il maggior problema e il software Environment - incendi, terremoti, vandalismi, mancanza di elettricita, guasto al condizionatore system management - manutenzione, configurazione Tandem 89 Tandem 85 AT&T/ESS 85 Environment 7% 14% Hardware 8% 18% Subtotal 15% 32%20% system Mgmt 21% 42%30% Software 64% 25%50%

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 Database Log Read, Write Fix, Flush Use, Unfix Buffer Manager Buffer 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/abortC(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 >>> permette UNDO operazioni se no commit Regola Commit-Precedenza AS nel LOG prima del COMMIT >>> 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) => T in UNDO C(T) => 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... M blocchi dati N-M blocchi di correzione errore

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 Presentation Manager Workflow Control (gestisce le richieste) Database Server Front-End (Client) Back-End (Server) Utente finale Transaction Program richieste

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 Presentation Server Controllore di Workflow Transaction Server Rete Richieste Messaggio di richiesta Architettura 3-Tier di un TP Monitor Gli elementi dello schema possono essere distribuiti in rete Code

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. Web browser Trad. URL Workflow Controller TP system Web Server Transaction Server DB Server 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)