DATABASE TUNING UNIVERSITÀ DEGLI STUDI DI CATANIA ROBERTO MIRABELLA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI.

Transcript

1 UNIVERSITÀ DEGLI STUDI DI CATANIA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA DI 1 LIVELLO IN INFORMATICA ROBERTO MIRABELLA DATABASE TUNING Tesi di Laurea Relatrice: Chiar.ma Prof.ssa ROSALBA GIUGNO ANNO ACCADEMICO

2 2 Ai miei genitori.

3 SOMMARIO PREMESSA DATABASE E DATABASE TUNING Cenni storici sui database I database ai giorni nostri Che cos è il database tuning? I principi fondamentali Livelli di intervento TUNING DEL SISTEMA Tuning dell Hardware Tuning del sottosistema di archiviazione Modifica e aggiunta di componenti Hardware Tuning del Sistema Operativo Gestione dei Threads Database buffer File System Tuning del DBMS Locking Tuning Logging Tuning

4 2.4. Tuning Applicativo Modello Client-Server Tuning delle Interfacce Applicative TUNING DEL DATABASE Tuning a Livello Logico Normalizzazione Denormalizzazione Overnormalizzazione Tuning a Livello Fisico Tuning degli indici Tuning delle query APPLICAZIONE PRATICA DEL TUNING I Benchmark Sistemi di Archiviazione MySQL MyISAM InnoDB Implementazione I Risultati: Analisi Sintetica Query per secondo Byte per secondo Tempi di risposta minimi Tempi di risposta massimi

5 4.5. I risultati: Analisi Analitica Tempi di esecuzione New-Order Tempi di esecuzione Payment Tempi di esecuzione Delivery Tempi di esecuzione Order-Status Tempi di esecuzione Stock-Level Conclusioni BIBLIOGRAFIA

6 PREMESSA Al giorno d oggi, con l evoluzione sempre più veloce e prodigiosa dei mezzi di comunicazione, la società si è abituata ad avere accesso, in pochi secondi, quando vuole, alle informazioni che vuole. Basti pensare ai sistemi di gestione della sanità, alle banche dati delle forze dell ordine, alla gestione dei mezzi di trasporto o anche, a livello più piccolo, alla gestione delle attività di un azienda o, perché no, ai social network, per capire come tutti gli aspetti importanti della vita di ciascuno di noi siano condizionati da questa premessa. Se nel piccolo, garantire velocità e portabilità delle informazioni è abbastanza semplice e chiunque, con un minimo di conoscenze informatiche, è ormai in grado di creare un database in Access che soddisfi tali esigenze, quando, invece, le informazioni da gestire diventano milioni o più, ottenere lo stesso risultato non è altrettanto scontato. Se un ritardo più o meno lungo nell accesso all informazione può essere in certi casi tollerato, come ad esempio nella ricerca di un libro in una biblioteca, in altri casi, come l elaborazione in tempo reale di dati scientifici, la velocità diventa di fondamentale importanza. Proprio per venire incontro a queste necessità nasce il Database Tuning. Per la stesura di questo lavoro, inizialmente è stata condotta una ricerca di articoli, testi, linee guida e schematizzazioni, reperiti attraverso internet, 6

7 insieme alla revisione di letteratura cartacea disponibile. Successivamente, è stata effettuata una valutazione del materiale raccolto e, infine, si è passati alla stesura della tesi. Cercando di non trascurare nessun aspetto relativo a questa tematica l argomento è stato suddiviso in quattro macroaree. Nella prima, viene introdotto l argomento partendo da una serie di accenni storici sull evoluzione dei database così da evidenziare come sono nate le esigenze degli utenti che il tuning cerca di soddisfare. Poi è stata data una definizione formale del database tuning e si è entrati nel merito di quali sono i principi fondamentali a cui gli amministratori devono attenersi. Per finire, vista la complessità dell argomento, si è cercato di schematizzare la trattazione suddividendola in vari livelli di intervento. La seconda macroarea ha come tema principale la trattazione analitica di tutti i livelli di intervento non legati a operazioni dirette sul database, ovvero a tutte quelle scelte che riguardano l hardware, il sistema operativo, il DBMS e i programmi applicativi del sistema. La terza macroarea riguarda invece tutti i livelli le cui operazioni modificano direttamente il database, concentrandosi soprattutto sui concetti di normalizzazione, denormalizzazione, gestione degli indici e ottimizzazione delle query. 7

8 La quarta macroarea infine è il risultato della realizzazione di un esperimento di tuning pratico realizzato in MySQL. Dopo una breve introduzione vengono presentati i dati raccolti, le loro rielaborazioni, e le conclusioni da essi derivate a conferma di quanto esposto nell intero elaborato. 8

9 1. DATABASE E DATABASE TUNING Prima di iniziare a parlare delle tecniche di tuning è importante soffermarsi un attimo a riflettere sul passato per capire quale è stata, fino ad oggi, l evoluzione dei database e cosa ha portato alla nascita del database tuning. Molte sono le domande che possiamo farci in proposito. Come erano strutturati i primi database? Chi ha ideato i modelli su cui si basa oggi la progettazione di una base di dati? Come si sono evolute le esigenze degli utenti negli anni? In che modo interviene il tuning per ottimizzare le prestazioni di un database? 1.1. CENNI STORICI SUI DATABASE. La nascita del concetto di database o base di dati risale a molti anni prima dell avvento dei calcolatori, quando le informazioni venivano scritte e memorizzate in forma cartacea. Archivi, schedari, rubriche possono tranquillamente essere considerate le antenate delle moderne basi di dati. Con il passare degli anni e con l evolversi della tecnologia, il termine database ha assunto un significato sempre più legato all aspetto informatico. Le prime forme di database elettronici risalgono agli anni Sessanta, quando il miglioramento dei calcolatori permise la creazione di una serie di raccolte dati destinate a varie applicazioni. Negli anni 9

10 seguenti, gli informatici si concentrarono a perfezionare e ottimizzare i programmi di gestione e non apportarono nessun miglioramento alla struttura usata per organizzarli. Nel 1968 l IBM sviluppò il primo ambiente di gestione soprannominato IMS. I dati erano strutturati in forma gerarchica. Al caricamento veniva visualizzato il primo dato e un collegamento al dato successivo. Per selezionare un gruppo di informazioni o trovarne una in particolare, l utente doveva scorrere l intero archivio in sequenza fino a trovare l informazione desiderata. Non esistevano query di ricerca. Anche le query più semplici richiedevano, per le risorse dell epoca, notevoli quantità di memoria e di tempo. Qualche anno dopo, nel 1971, per opera di Charles W. Bachman, fu lanciato sul mercato un altro standard, che prese il nome di "Approccio Codasyl. L Approccio Codasyl supportava una struttura dati a rete ma per il resto era molto simile all IMS. I database di entrambi gli standard furono classificati, per il loro funzionamento, con il nome di database navigazionali. La vera idea innovativa, nacque solo più tardi, nel Un dipendente dell IBM, Edgar F. Codd durante il suo lavoro di ricerca per il prototipo del nascente harddisk, si rese conto che l approccio Codasyl era inefficiente se applicato alla nuova tecnologia. Codd capì che per migliorare le prestazioni era necessario concentrarsi non solo sui 10

11 programmi di gestione ma anche, soprattutto, sull organizzazione dei dati da gestire. Formulò diverse teorie, scrisse trattati, distinse la struttura logica del database dalla sua realizzazione fisica, definì le regole per la creazione del Modello Relazionale e per la sua normalizzazione. In pratica gettò le basi per la nascita dei database relazionali e del linguaggio SQL. Le sue idee ebbero un esito positivo nella comunità scientifica: non solo l IBM ma anche diverse università italiane, puntarono su di lui e crearono il System R, predisposto per la gestione dei dati in una monotabella e successivamente SQL/DS, DB2, INGRES ed un precursore di Oracle. Questi nuovi sistemi permisero per la prima volta di suddividere i dati in tabelle separate. L idea di Codd fu talmente buona che, tre anni dopo, Peter Chen la perfezionò proponendo il suo Modello E/R (Entity-Relationship), valido ancora oggi. Questo modello prevede tre livelli di progettazione dei database (a differenza dei due definiti da Codd): il livello concettuale, il livello logico e il livello fisico. Chen introdusse anche il concetto di Entità (oggetti astratti o concreti) e Relazioni (legami tra le entità) I DATABASE AI GIORNI NOSTRI. Dagli anni Ottanta in poi, con la diffusione dei personal computer e la standardizzazione del linguaggio SQL, i programmi di gestione dei 11

12 database relazionali (RDBMS) sono proliferati: Oracle, MySql, Microsoft Access, DB2 ne sono solo alcuni esempi. L uso recente di internet ha poi contribuito a centrare l attenzione della comunità su nuove problematiche. Il modello di Chen è stato, negli anni Novanta, affiancato dal Modello Client/Server che permette, non solo una migliore ripartizione delle funzioni tra database e applicativo ma anche la possibilità di gestire il sistema attraverso la rete. L uso dei database in remoto, prima con le pagine ASP, poi, soprattutto, con il linguaggio PHP, ha consentito ai dipendenti delle aziende di accedere a informazioni prima inaccessibili ed ha anche permesso alle persone comuni di poter usufruire di servizi prima inesistenti. Si potrebbero citare tantissimi esempi: l accesso ai dati di una filiale dagli uffici della sede centrale di un azienda, la creazione di siti e-commerce, i sistemi di pagamento online, i social network, i forum di discussione, i guestbook personali. Dietro ognuna di queste cose c è un server che interroga una base di dati e soddisfa le richieste dell utente. Quelli che erano i requisiti fondamentali di un database (l affidabilità, la struttura semplice, la gestione di dati alfanumerici, le transazioni brevi, la condivisione e la gestione delle query più complesse) si sono rivelati, in diversi campi di applicazione, insufficienti. Ispirati dall evoluzione delle tecniche di programmazione, gli informatici hanno, quindi, ideato un nuovo modo di concepire le basi di dati: il 12

13 modello a oggetti. Questo nuovo tipo di database, ancora oggi poco diffuso, permette agli utenti di creare e gestire direttamente non solo informazioni alfanumeriche, ma qualsiasi altro tipo di oggetto come foto, video, brano musicale, ecc. Durante tutto questo processo di innovazione, gli utenti si sono velocemente abituati ad avere le informazioni che vogliono in pochi secondi, indipendentemente dalla quantità di dati che il database deve gestire. L efficienza è tornata ad essere quindi il fattore di principale importanza e di conseguenza anche il database tuning CHE COS È IL DATABASE TUNING? Database tuning is the activity of making a database application run more quickly. More quickly usually means higher throughput though it may mean lower response time for some applications. To make a system run more quickly, the database tuner may have to change the way applications are constructed, the data structures and parameters of a database system, the configuration of the operating system, or the hardware (Shasha/Bonnet 2004, XIX). Con database tuning si intende, come sopracitato, una serie di operazioni pianificate a medio o lungo termine, con le quali si cerca di migliorare al massimo le prestazioni di un database in un ben predefinito ambiente di lavoro. 13

14 Ciò significa che, per ottenere le massime prestazioni, non basta operare sul database, ma bisogna andare ad agire anche sul DBMS, sul sistema operativo e sull hardware in uso. Molte persone, condizionate dal significato inglese di tuning, lo associano alla semplice ottimizzazione ma, in realtà, si tratta di due concetti distinti. L ottimizzazione è un operazione che viene svolta nella fase finale della progettazione logica o direttamente sulla struttura fisica del database. Serve a migliorare il suo funzionamento a prescindere dal contesto in cui dovrà poi funzionare. Il tuning invece è qualcosa di più. Si tratta di un insieme di attività che coprono l intera vita del database, dallo studio del contesto iniziale all attività costante di monitoraggio dei flussi di dati. Le migliorie apportate al database tramite il tuning non risultano sempre efficaci se applicate in altri contesti I PRINCIPI FONDAMENTALI Proprio per come è stato definito, studiare il tuning diventa estremamente complicato. Non ci sono soluzioni decontestualizzate che producono risultati ottimali, stabilire delle dettagliate regole di comportamento per situazioni predefinite è difficile. L efficacia di ogni scelta va valutata caso per caso. Per questo motivo, ciascun amministratore deve sempre tenere presente cinque principi cardine e agire di conseguenza. 14

15 Il primo principio è stato riassunto, con la frase: pensare globalmente e agire a livello locale (Trad. Shasha/Bonnet 2004, 2). Ciò significa che, un buon amministratore, pur avendo ben presente la situazione complessiva del database, per fare un buon tuning deve essere in grado di individuare i piccoli cambiamenti necessari alla base di dati per ottenere grossi miglioramenti prestazionali. Un intervento che stravolge la natura del database, andando a riprogrammare anche parte degli aspetti prima funzionanti, non è considerato un buon tuning. Tale intervento, non solo vanificherebbe lo studio del problema ma ne produrrebbe di nuovi e imprevisti. Il tipico problema con cui si ha a che fare quando si lavora con i database e, in generale con l informatica, è quello soprannominato bottleneck o collo di bottiglia. In pratica, qualsiasi progetto strutturato in più componenti è considerato efficiente nella misura in cui lo è il suo componente peggiore. Nel database non serve cambiare tutto, ma solo migliorare o sostituire i componenti difettosi. Il secondo principio, Il partizionamento per risolvere i colli di bottiglia (Trad. Shasha/Bonnet 2004, 2), ci dà una guida su come agire in queste particolari situazioni. Se una componente è satura, si possono scegliere due strade diverse: o si suddividono le informazioni smistandole in più risorse così da riuscire a 15

16 gestire tutte le partizioni senza che nessuna crei sovraccarico, o si suddividono le informazioni frazionando la loro gestione nel tempo. Prima di procedere al partizionamento è sempre bene provare l alternativa più semplice: controllare la struttura e il codice del componente difettoso ed eseguire, se possibile, le opportune correzioni per eliminare alla radice il collo di bottiglia. Ad esempio, se abbiamo una query che non usa gli indici o li usa male è sempre meglio riscrivere la query che partizionare la tabella a cui fa riferimento. Il partizionamento, infatti, è una di quelle scelte che non sempre produce un aumento di prestazioni. Va valutato il singolo caso. Potrebbe succedere che i costi accessori dovuti alla gestione delle partizioni siano maggiori del costo, in termini di prestazioni, del bottleneck. Il terzo principio fondamentale da seguire riguarda un aspetto tipicamente umano. Davanti ad un obiettivo da raggiungere, il primo passo è sempre il più costoso. Forse consapevolmente o forse inconsciamente, l essere umano trasmette questa caratteristica anche alle sue creazioni. Un esempio esaustivo potrebbe essere il processo produttivo di un azienda di manufatti in vetro. La realizzazione del primo manufatto, con l accensione iniziale del forno e il raggiungimento della temperatura adatta, richiede un costo di risorse e di tempo molto più alto rispetto alla produzione dei manufatti successivi. 16

17 Gli elaboratori non fanno eccezione. Si pensi al processo di bootstrap, alla lettura di un informazione dal disco o anche all attivazione di una connessione di rete. La prima fase è sempre la più costosa in termini di risorse. Lo stesso principio vale per i database. E ancora, l amministratore deve dare al server quello che è del server. (Trad. Shasha/Bonnet 2004, 2). Una buona progettazione tiene accuratamente distinto il carico di lavoro del database (il server), da quello che invece spetta al programma applicativo (il client). Prendiamo un interfaccia grafica che visualizza un dato inserito nella base di dati e permette all utente di modificarlo e salvarlo. Caricare il server delle funzioni di ricerca, visualizzazione, interazione e salvataggio comporterebbe un inutile sovraccarico. La soluzione più giusta sarebbe invece quella di affidare la visualizzazione e l interazione con l utente all applicativo e coinvolgere il database solo per le restanti operazioni. L ultimo principio, che un amministratore di database deve tenere costantemente presente è che deve essere pronto ad accettare dei compromessi (Trad. Shasha/Bonnet 2004, 2). Non esiste una soluzione efficace senza controindicazioni. Se progettiamo un database che fa grande ricorso agli indici per migliorare l accesso alle sue tabelle, dovremo tener conto che ogni indice richiederà un costo aggiuntivo sia al processore sia alla memoria di buffer e fisica. 17

18 Trovare il giusto equilibrio non è mai facile ma è proprio il compito che si ci prefigge con il tuning del database LIVELLI DI INTERVENTO Le operazioni di ottimizzazione compiute da un amministratore che opera tuning non solo devono tener conto di conoscenze che vanno oltre lo studio dei database, abbracciando altri temi come la gestione dei buffer di memoria o il sistema di archiviazione dei dati sul supporto fisico, ma coinvolgono l intero sistema. Cercando di organizzare e semplificare i vari aspetti coinvolti, è possibile definire i seguenti livelli di intervento: Hardware; Sistema Operativo; DBMS; Applicativo Modello Logico del Database Modello Fisico del Database Saper scomporre il problema e individuare i giusti livelli di intervento è fondamentale se si vogliono ottenere dei miglioramenti reali e a lungo termine. Un intervento a livello hardware, consiste nel compiere tutte quelle scelte che prevedono la modifica dei componenti fisici del sistema. 18

19 Principalmente tali modifiche riguardano l aggiornamento del processore, l aggiunta di memoria principale e secondaria nonché l ottimizzazione dei bus di sistema. La difficoltà nell operare le scelte di tuning su questo livello consistono nella ricerca del miglior compromesso tra costo hardware ed efficienza. Per quanto riguarda il livello del Sistema Operativo, sarebbe necessario fare una lunga premessa specificando, per ogni Sistema Operativo, i relativi parametri di configurazione inerenti le procedure di tuning. Premesso però che non è mai possibile eliminare tutti i colli di bottiglia presenti nel sistema, alcuni strettamente legati alle limitazioni hardware, è necessario sottolineare che proprio questo numero di questi parametri può a sua volta rappresentare un bottleneck. Considerando tale argomento meritevole di un più attento approfondimento e impossibile da concentrare in poche righe, in questa trattazione si è preferito affrontarlo con le dovute astrazioni. Si parlerà quindi di gestione ottimizzata dei Threads, dell organizzazione del buffer di database e del file system. Intervenire con operazioni di tuning significa ottimizzare il software che si occupa della gestione del database: il DBMS. Tali interventi vertono principalmente su due aspetti della gestione: i locking delle transazioni e l ottimizzazione del sistema di logging. 19

20 Altro aspetto importante è la configurazione dei programmi posti tra gli utenti finali e il DBMS. Considerando che gli applicativi di norma vengono eseguiti su macchine diverse da quelle che gestiscono il database server, non solo sarà importante ottimizzare le interfacce eseguite dai client ma anche la rete di connessione tra le macchine. Demandati i problemi inerenti la scelta del giusto protocollo, dei giusti canali di comunicazione, dell instradamento migliore dei pacchetti, dell ottimizzare degli algoritmi che gestiscono le collisioni, ecc. ai livelli del modello ISO/OSI o TCP/IP relativi alle reti, si ci concentrerà, in questo elaborato, sulle tematiche più legate ai database quali i vantaggi e gli svantaggi dell utilizzo del modello Client/Server inteso come modello Applicativo/Database Server e l ottimizzazione del codice dei programmi applicativi. Iniziare il tuning del database in fase di progettazione, può rappresentare un notevole vantaggio per il sistema. Partire da un modello logico ottimizzato ed efficiente significa creare un database predisposto ad affrontare le situazioni critiche che potranno verificarsi durante il suo funzionamento e persino evitarle. Gli interventi sul database possono essere effettuati sui diversi modelli di progettazione. Quando si interviene sul modello logico, in genere, si parla di normalizzazione (ottimizzazione dei dati), denormalizzazione (creazione di ridondanza per migliorarementi funzionali) e 20

21 overnormalizzazione. (creazione di ridondanza per snellire le strutture dati). Gli interventi di questo tipo sono consigliati solo durante la fase di progettazione anche se, l amministratore, può naturalmente ritenere farlo anche successivamente. In questi casi deve però tenere conto che essendo la struttura dati già funzionante, operare modifiche al livello logico comporta dei costi aggiuntivi e alto rischio di perdita d integrità del database. Pratica più comune vuole, che il tuning si concentri sul modello fisico del database, ovvero su interventi al codice SQL delle query a alle strutture di database già funzionanti. Si può intervenire sul modello fisico in tanti modi: a) Attraverso l utilizzo di strutture distinte per la memorizzazione dei dati; b) Con l uso dei raw devices (se il database opera su sistemi UNIX); c) Con l aggiunta di indici e informazioni temporanee alle tabelle; d) Attraverso la valutazione della frequenza d accesso delle singole strutture; e) Attraverso il controllo e l eliminazione di indici inutili o inutilizzati; f) Attraverso il controllo delle colonne degli indici affinché mantengano dimensioni contenute; 21

22 g) Attraverso il controllo della quantità di dati di ogni tabella e, se necessario, il partizionamento. Ottimizzare il linguaggio SQL non è per niente facile. Una grossa parte di bottleneck presenti nel sistema spesso è legata ad una programmazione SQL superficiale e non ottimizzata. Ecco una veloce panoramica delle situazioni da valutare e che si presentano più frequentemente ad un amministratore: a) l esistenza di selezioni generiche come SELECT * FROM..." in quanto SQL impiega ulteriori risorse per decodificare il significato dell * in base alle tabelle inserite nel FROM ; b) il mancato uso di indici nelle query che coinvolgono una notevole quantità di dati, la presenza di indici disattivati di importanza rilevante o l uso di indici non opportuni; c) l ordine delle tabelle e delle condizioni di selettività nelle query; d) l uso di elaborazioni statistiche mediante cicli al posto di sfruttare le funzioni di gruppo standard; e) l uso dei valori null e la loro corretta gestione; f) la presenza e l efficacia delle selezioni annidate; g) la presenza di operazioni che richiedano grandi quantità di memoria (ad esempio ORDER BY, DISTINCT e GROUP BY in tabelle molto voluminose); 22

23 h) la presenza, in generale, di codici la cui esecuzione prevede lunghe transazioni. In generale, bisogna comunque tenere presente che, la suddivisione a livelli è una schematizzazione logica personale che è volta esclusivamente a dare un ordine all esposizione di concetti che sono profondamente interconnessi tra loro. Stabilire, pertanto, a quale livello appartenga una specifica operazione, non è sempre facile ai fini del tuning vero e proprio. 23

24 2. TUNING DEL SISTEMA Aver visto cos è il Database Tuning e quali sono i principi fondamentali su cui esso si basa non basta se si vuole operare concretamente tuning. Nei paragrafi seguenti vengono esposte, sinteticamente, le nozioni di tuning fondamentali relative al livello hardware, del Sistema Operativo, del DBMS e dei programmi applicativi TUNING DELL HARDWARE La prima cosa che viene in mente, quando il funzionamento del sistema sembra rallentato e poco efficiente, è di intervenire a livello hardware per aumentare le risorse disponibili. Premettendo che non sempre un intervento del genere comporta un effettivo miglioramento di prestazioni, è evidente che la scelta del componente del sistema su cui intervenire è di cruciale importanza per evitare costi inutili. Preso ad esempio, un sistema che soffre di saturazione del buffer di memoria, l acquisto e l aggiunta di RAM nel sistema rappresenta una buona strategia di tuning? Supposto che il costo della RAM coincida a 15 /Mb (costo non eccessivamente oneroso), non sappiamo se la saturazione è effettivamente legata alla scarsa capienza di memoria o 24

25 alla larghezza di banda del suo bus. L aggiunta di RAM, mentre nel primo caso rappresenta una buona soluzione di tuning, nel secondo comporta un completo spreco di soldi. In realtà, un calo di prestazioni non può essere mai attribuito esclusivamente all hardware. Per questo motivo è difficile distinguere in maniera netta la necessità di tuning sull hardware da quella di tuning sul software TUNING DEL SOTTOSISTEMA DI ARCHIVIAZIONE Quando si parla di sistemi su larga scala, la gestione della memoria secondaria viene implementata attraverso l uso di un array di dischi (RAID) così da sfruttare le sue due principali caratteristiche: da un lato il RAID crea nel sistema una certa tolleranza d errore, fault tollerance, dovuta alla ridondanza dei dati introdotta nei dischi multipli; dall altro aumenta il throughput del sistema perché consente l accesso simultaneo a più dischi. Un array di dischi insieme al software per configurare e gestire le periferiche di archiviazione che lo compongono, costituiscono uno Storage Subsystem. Le operazioni di tuning sullo Storage Subsystem prevedono: 1. La configurazione dell array di dischi 2. L ottimizzazione della cache del controller 3. La ricerca di equilibrio nello Storage Subsystem 25

26 Esistono diversi livelli di RAID, ognuno con particolari vantaggi e svantaggi. Per ottenere prestazioni ottimali, dobbiamo assicurarci, per ogni tipo di file, di adottare il livello di RAID che soddisfi meglio le esigenze ad esso associate LIVELLI DI RAID I livelli di RAID più importanti, ai fini del tuning, sono: RAID 0: che divide i dati equamente tra due o più dischi con nessuna informazione di parità o ridondanza (Striping). Le operazioni di I/O vengono divise in blocchi di dimensioni uguali e apportate equamente su tutti i dischi. Per questo l'affidabilità del sistema è uguale all'affidabilità media dei dischi diviso il numero di dischi presenti. Se un drive si guasta, il file system non è in grado di gestire la perdita dei dati e la sostituzione del componente danneggiato comporta la perdita di tutti i dati del sistema. I vantaggi sono: il costo economico di implementazione basso, le alte prestazioni in scrittura e lettura grazie al parallelismo delle operazioni I/O dei dischi concatenati. Gli svantaggi sono: la scarsa affidabilità e la non fault tolerant. RAID 1: che crea una copia esatta (mirror) di tutti i dati su due o più dischi. È utile nei casi in cui mantenere la ridondanza è più importante che usare i dischi alla loro massima capacità 26

27 complessiva. Il sistema ha come capacità massima quella del disco più piccolo. Poiché ogni disco presenta la copia esatta degli altri dischi, può essere gestito autonomamente in caso di guasti e l'affidabilità aumenta linearmente rispetto al numero di dischi presenti. RAID-1 incrementa allo stesso modo le prestazioni in lettura, visto che le transazioni possono accedere ai dati da un disco mentre gli altri sono occupati. I vantaggi sono: l aumento lineare di affidabilità in base ai mirror implementati, la fault tolerant, la velocità di lettura che dipende dal disco più veloce. Gli svantaggi sono: l overhead legato ai mirror, l alto costo hardware legato all acquisto di numerosi dischi dedicati interamente alla ridondanza e la velocità di scrittura che dipende sia dal disco più lento sia dal numero di dischi collegati. RAID 5: una delle implementazioni più popolari in hardware e in software, che divide i dati in blocchi e stripe e distribuisce le informazioni di parità, per rotazione, in tutti i dischi appartenenti al RAID. Il blocco di parità non viene considerato durante le operazioni di lettura e viene usato solo in caso di errore per ricostruire le parti danneggiate. Se a danneggiarsi è un intero disco, RAID 5 permette, attraverso tutti gli altri blocchi (di dati e di parità) il recupero integrale del contenuto 27

28 del disco guasto. Il sistema esterno può comunque continuare a operare in lettura e scrittura anche se con un calo di prestazioni. Il numero di blocchi di parità per ogni stripe è direttamente proporzionale al valore di fault tollerance. Se un blocco di parità per ogni stripe permette il recupero del contenuto di un intero disco in caso di guasto, più blocchi di parità permettono il recupero dei dati in caso di guasti simultanei di più dischi. Le implementazioni con doppia parità sono dette anche RAID 6. I vantaggi sono: la distribuzione dei blocchi di parità e le operazioni di lettura più veloci. Lo svantaggio consiste nelle operazioni di scrittura più lente dovute al calcolo del blocco di parità. RAID 10: è un sistema RAID 1+0 ovvero un insieme di RAID1 gestiti in RAID0. Poiché i dischi fisici sono organizzati in una serie di gruppi RAID 1, il danneggiamento di un disco all interno di un singolo gruppo RAID 1 non comporta nessuna perdita di dati. In caso però tutti i dischi di un gruppo si danneggino, anche i dati negli altri gruppi sono inutilizzabili. Il sistema di database deve gestire tre tipi di file: File di Log File Temporanei File di Indici o Dati 28

29 Nel caso dei file di log, è consigliabile utilizzare RAID 1 perché questa struttura garantisce fault tollerance mantenendo un alto livello di throughput in scrittura. Se i log richiedono scritture brevi e frequenti può essere più appropriato anche l uso di RAID 10. Per i file temporanei è consigliato, invece, l uso di RAID 0. Il sistema può operare in lettura e in scrittura velocemente senza che, per la natura di questi file, l eventuale perdita di informazioni influisca sulle performance del sistema. Per i file di dati o di indici la fault tollerance è fondamentale. Le prestazioni migliori si ottengono utilizzando RAID 5. Per questo tipo di informazioni, infatti, la frequenza di lettura è molto più alta rispetto a quella di scrittura e le scarse performance di RAID 5 per questo tipo di operazioni, possono essere mascherate attraverso un buon utilizzo della cache del controller e non influiscono sensibilmente sul funzionamento globale. Fig. 1: Struttura RAID0 a due dischi. Fig. 2: Struttura RAID1 a due dischi 29

30 Fig. 3: Struttura RAID5 a quattro dischi Fig. 4: Struttura RAID 1+0 a sei dischi CHACHE DEL CONTROLLER L ottimizzazione della cache del controller si basa sui principi di read-ahead e write-back. Read-ahead considera che il tempo necessario a leggere un blocco dati dipende più dal tempo impiegato dal braccio meccanico del 30

31 disco per raggiungerlo che dal tempo di lettura vero e proprio. Read-ahead prova a ridurre lo spreco dovuto a questo limite hardware implementando l idea di non interrompere il processo di lettura non appena si raggiunge la fine del blocco richiesto ma di continuare a leggere i blocchi successivi inserendoli nella memoria cache. Se questa tecnica risulta efficace per l accesso sequenziale ai dati, diventa invece inefficiente quando si tratta di accessi random. Write-back, ipotizza invece conclusa a buon fine l operazione di scrittura su disco con l inserimento dell informazione nella cache. Spetta al controller garantire che l operazione vada effettivamente a buon fine. Le eventuali saturazioni possono essere gestite attraverso una serializzazione delle richieste e una distribuzione delle medesime in più intervalli di tempo IL TUNING DELLO STORAGE SUBSYSTEM Premesse tutte le considerazioni esposte fino a questo momento in materia, l amministratore di un sistema di database, durante il tuning hardware deve trovare il miglior bilanciamento possibile tra le dimensioni dello Storage Subsystem e le sue prestazioni. Per farlo dovrà tenere presente che: Nonostante l uso dello Storage Subsystem permetta di considerare un insieme di dischi come un unico disco dalle prestazioni elevate, aumentare il numero dei componenti del 31

32 sottosistema comporta un aumento del flusso di dati legato alla sua gestione (log e index files). Ogni componente avrà le sue caratteristiche hardware quali seek time, rotational latency, cache size, ecc che vanno a influire sulle prestazioni complessive del sottosistema. Il bus di interconnessione SCSI, scelto in tutti i grossi sistemi di database perché permette l aggiunta e la rimozione dei dischi a sistema funzionante, ha comunque dei limiti per quanto riguarda la tolleranza d errore MODIFICA E AGGIUNTA DI COMPONENTI HARDWARE Ci sono tre principali fattori su cui intervenire quando si parla di aggiunta di nuovo hardware: la memoria, i dischi e i processori LA MEMORIA Aggiungere memoria al sistema, oltre a essere l operazione, a livello hardware più economica, comporta un aumento del buffer pool 1 e delle prestazioni di sistema. La memoria aggiuntiva riduce il carico sui dischi e aumenta l hit ratio 2 mantenendo la stessa paginazione. Si potrebbe intervenire direttamente sulla memoria di cache del disco, ma in questo caso, la memoria extra verrebbe 1 Buffer pool: area di memoria in cui le pagine del database vengono lette, modificate e gestite durante l'elaborazione. 2 Hit ratio: indice ottenuto dalla formula (# accessi logici # accessi fisici) / (# accessi logici) 32

33 utilizzata esclusivamente per velocizzare le operazioni di quel disco e non di tutto il sistema I DISCHI L aggiunta di dischi, in linea di principio, è indicata quando i dati da gestire superano la capacità dei dischi in uso. In realtà i database considerano la larghezza di banda un fattore più rilevante rispetto alla capacità di archiviazione. Per migliorare la larghezza di banda si può intervenire in due modi: o si aumenta la memoria di cache dei singoli dischi o si acquistano nuovi dischi da inserire nello Storage Subsystem. Quest ultima ipotesi comporta una serie di vantaggi aggiuntivi, quali: a) la possibilità di gestire i log su dischi separati garantendone l accesso sequenziale in scrittura e lettura. b) la possibilità di modificare il livello RAID in uso. c) La possibilità di partizionare tabelle o applicazioni di grandi dimensioni su diversi dischi logici per non sovraccaricare un unico disco I PROCESSORI Che un sistema di database riesca a sovraccaricare un processore moderno sembra a primo impatto quasi impossibile. Eppure si tratta di qualcosa di estremamente concreto. Anche se un sistema di database non opera sui dati come può ad esempio fare un 33

34 applicativo audio-visivo, le risorse di elaborazione necessarie al database sono direttamente proporzionali ai dati da gestire. Quando la mole di dati supera l ordine di grandezza del terabyte, l ipotesi di aggiungere altri processori al sistema non appare più così insensata. Il modo più economico per creare un sistema multiprocessore è quello di collegare più sistemi informatici indipendenti tra loro con una rete ad alta velocità. Questa soluzione può andare bene quando: 1. Una parte dell'applicazione può essere demandata ad un altro sistema per essere lavorata separatamente. 2. Le applicazioni possono essere suddivise tra applicazioni di elaborazione e di supporto. In questo caso si demandano le applicazioni di supporto (che non modificano il database) agli altri sistemi che, scaricato periodicamente il database dalla rete (backend), eseguono in locale i compiti a loro assegnati. 3. Nel sistema ci sono molte transazioni di sola lettura e poche transazioni in scrittura. E difficile, infatti, garantire l atomicità delle transazioni in scrittura ed evitare che si creino sovraccarichi legati agli aggiornamenti. 4. Sia possibile il partizionamento dei dati. L'obiettivo da perseguire è semplice: ogni grande struttura dovrebbe essere partizionata in base al carico di lavoro ad essa associata e poi suddivisa uniformemente su tutti i sistemi. In alternativa al 34

35 carico di lavoro è possibile considerare come parametro di partizionamento il fattore tempo 3. Per il partizionamento delle tabelle in particolare, si parlerà di Hash Partitioning o di Range Partitioning. Il primo metodo partiziona i dati suddividendoli in base al valore di un record di riferimento A e attraverso il calcolo di una funzione h detta funzione di hash; il secondo metodo smista i dati della struttura dividendoli tra quelli che contengono l attributo di riferimento e quelli che non lo contengono. 5. E possibile inserire una memoria condivisa con cui gestire i dati necessari alle applicazioni che, a causa della loro interconnessione, non è possibile partizionare. Ci sono tre diversi tipi di sistemi multiprocessore: 1. Sistemi Tightly Coupled: che dispongono di diversi processori ma di un'unica memoria logica principale e un unico set di dischi. 2. Sistemi Shared Nothing: in cui ogni processore è dotato di propria memoria principale e proprio set di dischi. Il lavoro viene distribuito uniformemente e gli applicativi suddivisi in una serie di sottoapplicativi indipendenti tra loro. 3 fattore tempo: ogni sistema dovrebbe contenere i dati legati ad un intervallo di tempo specifico. 35

36 3. Sistemi Shared Disk: in cui ogni processore ha la propria memoria principale, ma set di dischi condiviso. Questa architettura andrebbe bene al posto dei sistemi tightly coupled quando gli applicativi tendono a produrre sovraccarichi ai singoli sistemi. Fig. 5: Rappresentazione schematica dei tre tipi di sistemi multiprocessore 2.2. TUNING DEL SISTEMA OPERATIVO Per parlare di tuning a livello di sistema operativo è necessario fare una panoramica dei concetti fondamentali riguardanti il suo funzionamento e la multiprogrammazione. Le performance di un sistema di database sono strettamente legate a quelle del sistema operativo ospitante. Da qui la necessità di ottimizzare i threads 36

37 e il loro sistema di gestione e la necessità di un corretto utilizzo del buffer del database e del file system GESTIONE DEI THREADS Qualsiasi processo del sistema operativo viene suddiviso in più threads che vengono poi eseguiti in ordine sequenziale o contemporaneo. Se fino a qualche anno fa il multithreading si basava esclusivamente su tecniche a divisione di tempo e scheduling ogni thread veniva eseguito per un certo periodo di tempo, poi passava il controllo ad un altro thread con l avvento dei sistemi multicore il parallelismo ha assunto una connotazione reale. In termini di prestazioni, il tempo necessario ad ogni thread è dato dal tempo di esecuzione delle sue istruzioni, sommato al tempo necessario a passare il controllo al thread successivo, sommato a quello legato ai tempi di attesa per eventuali lock delle risorse comuni. Il tuning del sistema operativo si concentra sull ottimizzazione dello Scheduling e delle Priorità per ridurre appunto il tempo di esecuzione di ogni thread TUNING DELLO SCHEDULING Per ottimizzare lo Scheduling ci sono due strategie: 1. Scegliere un sistema operativo che usi tecniche di switching (dei thread) poco costose in termini di prestazioni; 37

38 2. Ridurre al minimo il numero di switches. Uno switch è inevitabile quando l'applicazione esegue una richiesta di I/O; per tutti gli altri casi, in cui il suo uso sarebbe opzionale, è meglio evitarli. Questo vuol dire ridurre al minimo gli interrupts e dare priorità all aumento del throughput piuttosto che ai tempi di risposta. Il compromesso usato nei moderni microprocessori consiste nell assegnare a ogni thread un tempo di esecuzione massimo di un secondo, valore sufficiente, nella maggior parte dei casi, per terminare correttamente l esecuzione di un thread GESTIONE DELLE PRIORITÀ In un sistema che fa uso di priorità, le prestazioni del database risultano influenzate negativamente quando: 1. I processi del database vengono eseguiti con una priorità più bassa rispetto agli altri processi. Se le risorse disponibili diminuiscono, il valore delle prestazioni del database precipita a zero. 2. I threads vengono eseguiti tutti con la stessa priorità generando i cosiddetti fairness Si verificano casi di inversione di priorità. Dati tre thread con priorità decrescente T1, T2 e T3, ipotizzato che al tempo t1 4 fairness: situazione che si verifica quando un thread pronto all esecuzione non può essere avviato perché alcune risorse necessarie sono bloccate da altri thread. 38

39 venga avviata l esecuzione di T3 e che T3 richieda immediatamente il lock di una risorsa in comune con T1, al tempo t2 l esecuzione di T1 è pronta per essere avviata ma la risorsa a lui necessaria è ancora bloccata. T1 e T3 vengono deschedulizzati T3 per la sua bassa priorità e T1 per mancanza di risorse e viene avviato ed eseguito il thread T2. In definitiva, la superiore priorità di T1 non viene rispettata e avviene uno scavalcamento da parte di T2. Fig. 6: Schema che illustra il fenomeno dell inversione di priorità In definitiva si avrà che, per evitare l inversione si dovrebbero eseguire i threads tutti con la stessa priorità, per evitare i fairness, si dovrebbe diversificarla il più possibile. Ecco nuovamente la 39

40 necessità di trovare un compromesso: la priorità dinamica. L idea è quella di assegnare, ad ogni thread in avvio, priorità massima e poi decrementarla ogni volta che il thread blocca una risorsa LA MULTIPROGRAMMAZIONE Molti amministratori credono che un alto livello di multiprogrammazione sia la soluzione migliore per i loro sistemi. È vero che l aumento del numero di thread riduce i cicli inattivi dei processori e quindi gli sprechi, ma è anche vero che provoca un aumento della possibilità che il sistema risenta di un calo prestazionale. Le cause di questo calo dipendono da: la quantità di RAM usata dagli utenti. Se supera la quantità di memoria reale il sistema compensa con la paginazione dell area riservata ai processi, il buffer e la memoria secondaria. i conflitti di Lock derivati da un eccessivo numero di transazioni eseguite contemporaneamente. Un metodo valido per prevenire entrambi i casi consiste nell incrementazione progressiva della concorrenza. Il metodo è strutturato in tre fasi distinte: 1. Viene avviato il sistema utilizzando il minimo di transazioni simultanee consentite. 40

41 2. Viene aumentato tale limite di uno e misurato l andamento delle prestazioni del sistema. 3. Se le prestazioni subiscono un miglioramento, si procede ad ulteriori aumenti del limite di concorrenza, altrimenti il limite trovato è il massimo consentito senza calo di prestazioni. La grossa limitazione del metodo appena esposto è che non può essere applicato ai database se non a fronte di un continuo monitoraggio del sistema. Gerhard Weikum e i suoi studenti, sono riusciti a trovare un metodo meno oneroso attraverso il calcolo dell indice di criticità del sistema. Si tratta del rapporto tra il numero di lock delle transazioni e il numero di lock totali. Quando questo indice supera il 23% la possibilità di crash del sistema diventa abbastanza concreta. Secondo Gerhard spetterebbe al DBMS gestire questo indice ma, attualmente, nessun DBMS implementa al suo interno le funzioni necessarie DATABASE BUFFER E stato visto che l accesso dei dati dal disco richiede, per configurazione dell hardware, molto più tempo rispetto all accesso degli stessi dati sulla RAM. Per minimizzare le prestazioni, il database deve cercare di ridurre al minimo il numero di accessi alla memoria secondaria. Ricordando la teoria sulle transazioni simultanee, si può 41

42 destinare una certa porzione di memoria virtuale, conosciuta come buffer, database buffer o database cache, alla condivisione dei dati in comune. L'impatto del buffer sul numero di accessi fisici dipende da tre fattori: 1. Letture e scritture logiche: Quando le operazioni di lettura e scrittura del sistema operano sulle pagine di memoria che fanno parte del buffer. 2. Sostituzione delle pagine: A seguito di un operazione di scrittura su disco può verificarsi la necessità di ricaricare alcune pagine nel buffer. E possibile minimizzare questa situazione attraverso una buona gestione delle scritture da parte del database tuner La paginazione del Sistema Operativo: Se lo spazio dedicato al buffer supera lo spazio disponibile della memoria RAM il sistema operativo integra lo spazio mancante procedendo alla paginazione della memoria secondaria. Il tuner deve assicurarsi che questo non succeda. L aspetto importante consiste dunque nel capire come la presenza del buffer influisce sul numero di accessi logici e fisici al disco. Il valore del parametro Hit Ratio, presentato nel paragrafo , non solo serve da indicatore del livello di ottimizzazione del sistema, ma aiuta l amministratore nella scelta della dimensione di buffer più opportuna. 5 database tuner: inteso come i moduli software del DBMS che si occupano dell ottmizzazione automatizzata della base di dati e, in caso di errori o rallentamenti, aiutano ad individuarne le cause. 42

43 Fig. 7: Schema di un Database Buffer In generale, per raggiungere le prestazioni ottimali, esistono due strategie: 1. Aumentare la dimensione del buffer fino ad ottenere un appiattimento dell incremento di Hit Ratio mantenendo al contempo basso il numero di sostituzioni delle pagine e la paginazione dei dischi. 2. Acquistare e aggiungere RAM FILE SYSTEM I File System permettono agli utenti di creare, eliminare, leggere e scrivere flussi di informazioni organizzati in file. I principali parametri regolabili per quanto riguarda il file System sono: 43

44 La dimensione dei chunks 6 del disco. Alcuni file System li chiamano extent. Poiché molte query tendono a scansire solo parti di file, per migliorare le prestazioni è bene specificare le dimensioni della traccia relativa a ogni extent. Se si tratta di file di grosse dimensioni è consigliato l'uso di extents grandi. Quando invece l'accesso ad un file è completamente casuale un piccolo extent riduce lo spreco di spazio. I fattori d uso sulle pagine del disco. Più alto è il fattore di utilizzo, più completa può essere la pagina al momento in cui si verificano degli inserimenti. Se si tratta di oggetti, ad esempio tabelle, che prevedono numerosi aggiornamenti con a seguito un aumento di dimensioni è bene mantenere un fattore di utilizzo basso, in caso contrario un valore alto aiuta le scansioni da parte delle query. Il numero di pagine che possono essere precaricate. Il prefetching è utile per le query che scansionano i file. A meno di una piccola quantità di RAM è bene che il numero di pagine precaricate coincida quasi interamente a una traccia del disco. Il numero di livelli di back-link per accedere a una determinata pagina. Questo punto assume particolare importanza per i 6 chunks: blocchi di memoria contigua in un file system riservati per un file. Quando si inizia a scrivere un file, viene allocato un intero chunk. Quando si scrive di nuovo sul file, i dati vengono scritti a partire dagli ultimi. Questo riduce la frammentazione dei file. 44

45 sistemi basati su Unix perché la struttura indicizzata dei file prevede l inserimento di molti più back-link nelle pagine finali piuttosto che nelle pagine iniziali di un file TUNING DEL DBMS Le applicazioni di database dividono il loro lavoro in transazioni. Le transazioni, come i threads, possono essere eseguite in parallelo o in modo sequenziale purchè venga rispettata la loro proprietà di atomicità. Anche per le transazioni valgono quindi le considerazioni esposte per il multithreads e la multiprogrammazione: operare tuning equivale a trovare il punto di incontro tra performance e concorrenza. Il tuning del DBMS si basa su due principali aspetti: la gestione dei lock delle transazioni ed il sistema di logging e recovery del database LOCKING TUNING Per prima cosa è necessaria una breve panoramica su come funzionano i lock nelle transazioni. Ci sono due tipi di lock: i write lock, che garantiscono a una transazione l accesso esclusivo alla risorsa con la possibilità di modificarne il contenuto, e i read lock che non bloccano l accesso in lettura sulla risorsa alle altre transazioni ma bloccano qualsiasi write lock. Il sistema di gestione si basa poi su due semplici regole: 45

46 1. Una transazione deve ottenere il lock della risorsa X prima di accedervi. 2. Se una transazione vuole ottenere il lock della risorsa Y deve prima rilasciare la risorsa X. Per quanto riguarda il tuning, l intervento dell amministratore può consistere in: Operare la cosiddetta Transaction Chopping, ovvero scomporre una transazione articolata in più transazioni semplici; Ridurre i lock eliminando quelli non necessari; Favorire i lock condivisi piuttosto che i lock esclusivi; Ridurre il tempo di ogni lock per migliorare i tempi di attesa tra le transazioni. Definire la granularità dei lock; TRANSACTION CHOPPING La prima domanda che deve farsi l amministratore è: quanto deve essere lunga una transazione? Per rispondere a questa domanda si deve tener presente che: 1. Più lunga è la transazione, più sono le risorse necessarie alla sua esecuzione e più facilmente può capitare che un altra transazione rimanga in attesa di qualche risorsa bloccata; 46

47 2. Più lunga è l esecuzione della transazione A più tempo un altra transazione dovrà aspettare per il rilascio delle risorse bloccate da A. Transazioni corte sono quindi migliori di transazioni lunghe in termini di prestazioni. Ecco perché la necessità di cercare di scomporre le transazioni più corpose in transazioni atomiche senza perdere il livello di isolamento originale. A volte, per riuscirci, può essere necessario riformulare l intera transazione RIDURRE I LOCK E importante eliminare i lock superflui nel sistema. A questa categoria fanno parte i lock generati quando viene eseguita una transazione alla volta e quelli generati nonostante tutte le transazioni siano di sola lettura LA GRANULARITÀ DEI LOCK I moderni sistemi di database permettono di distinguere e specificare la granularità dei lock. In ordine decrescente di granularità ci sono: i record-level lock, i page-level lock e i tablelevel lock. Un record-level lock impedirà l accesso simultaneo di più transazioni a un determinato record, un page-level lock impedirà l accesso a tutti i record che fanno parte di una determinata pagina; un table-level lock opererà allo stesso modo 47

48 riferendosi però a tutte le pagine che compongono una specifica tabella e quindi a tutti i record di quella tabella. Utilizzare lock con granularità più alta, basandosi su una prima impressione, sembrerebbe la scelta migliore. Un record lock, permettendo a più transazioni che operano su record della stessa pagina di essere eseguite contemporaneamente, dovrebbe, infatti, produrre un miglioramento di prestazioni. In realtà, ogni transazione difficilmente richiede l accesso a singoli record all interno di una pagina e la scelta di usare record lock porterebbe, al sistema, un inutile aumento di richieste di lock da gestire con tutte le relative conseguenze in termini di tempi d attesa delle singole transazioni. In definitiva, per evitare i deadlock 7 e di ridurre l overhead, è consigliato l uso di page-level lock per transazioni brevi e tablelevel lock per transazioni più lunghe LOGGING TUNING All interno del sistema possiamo classificare le transazioni in base al loro stato. Una volta attivata una transazione, questa potrà o essere eseguita o interrotta. A livello teorico gli effetti delle transazioni eseguite dovrebbero essere permanenti mentre le transazioni interrotte 7 Deadlock: situazione di stallo tra più transazioni in cui ognuna aspetta il verificarsi di qualcosa per sbloccare il proprio lock. 48

49 non dovrebbero lasciare traccia. Questo principio, apparentemente facile da rispettare, in realtà dipende dal momento in cui la transazione viene interrotta. Basta pensare a una transazione che prevede la modifica di una serie di record e che viene interrotta a pochi istanti dalla fine. Gli effetti di tale transazione restano nel sistema che, a seguito dell interruzione, presenta record incongruenti e modificati irreversibilmente. Tali record potrebbero diventare la causa di ulteriori errori e interruzioni. In generale si distinguono le interruzioni hardware, causate da un malfunzionamento fisico, e le interruzioni software, causate da errori di programma. E stato visto che, la risoluzione dei problemi legati alle interruzioni hardware, prevede l uso di sistemi fault tollerance. Per quanto riguarda invece le interruzioni software, la soluzione è il sistema di logging e recovery. In pratica, quando si presenta un interruzione, il sistema deve poter ripristinare il dato originale e poi decidere se riavviare o meno la transazione che ha generato l interruzione. Per farlo si serve di appositi file di log. Si tratta di file che contengono una serie di azioni organizzate in record di tipo REDO e UNDO a cui sono associati i valori dei dati originali e dei dati modificati a seguito di una transazione. Lo scopo del tuning è ottimizzare il processo di creazione e gestione di questi file. 49

50 In particolare l amministratore deve assicurarsi che: 1. La scrittura dei file di log avvenga con accesso sequenziale al disco (ovvero i file di log vengano creati su dischi separati dai dati) 2. Le informazioni contenute in ogni record di log siano minime così da permettere l inserimento di più aggiornamenti nella stessa pagina. 3. Venga rispettato il protocollo Write-Ahead Logging (WAL)., ossia che tutte le modifiche prima di essere apportate fisicamente devono essere inserite in un record di log. 4. Siano garantiti i principi di atomicità e durabilità delle transazioni TUNING APPLICATIVO La maggior parte delle applicazioni che interagiscono con i sistemi database, lo fanno in due modi: attraverso l utilizzo di un linguaggio specifico di quarta generazione o mediante l utilizzo di un linguaggio di programmazione come PHP, Java, Visual Basic, C, ecc. che si basano su un'interfaccia a livello di chiamata. Diversi fornitori offrono numerosi software proprietari di quarta generazione che risolvono le query ottenendo i risultati desiderati con esecuzioni di alto livello prestazionale a costo della portabilità di tali applicazioni. I programmi che 50

51 interagiscono, invece, con il database mediante interfaccia a livello di chiamata, si basano su librerie di funzioni che consentono loro di connettersi ad un database server, eseguire istruzioni SQL, recuperare i risultati della query ed eseguire o interrompere le transazioni MODELLO CLIENT-SERVER Poichè l esecuzione dell applicativo dei client è asincrona rispetto al funzionamento del database server, la connessione tra i due può essere possibile solo mediante un buffer di memoria. L utilizzo di questo modello di interconnessione offre due principali vantaggi: Se l interazione con il client è molto lenta e, ad esempio, i tempi per la lettura delle risposte di una query sono eccessivamente lunghi, l utilizzo del buffer di memoria permette al database server di memorizzare all interno del buffer l intero risultato della query e svincolare subito le proprie risorse senza risentire delle basse prestazioni del client. I dati vengono inviati dal server al client non appena il buffer di comunicazione lato server si riempie o non appena termina l esecuzione del processo attivo. L uso di buffer grandi avrà quindi l effetto di allungare i tempi di risposta percepiti dal client riducendo però il numero di pacchetti che attraversano la rete e quindi il rischio di errori. L uso di un piccolo buffer, 51

52 d altra parte, avrà l effetto opposto. Come sempre la parola chiave è equilibrio. Fig. 8: Modello Client Server con sistema di buffer TUNING DELLE INTERFACCE APPLICATIVE Analizzare l interfaccia applicativa utilizzata dall utente per interagire con il DBMS alla ricerca di codici dal basso rendimento spesso è di cruciale importanza ai fini delle prestazioni. I principali principi che l interfaccia deve rispettare sono: 1. Evitare l interazione con l utente all interno di una transazione. 2. Ridurre al minimo il numero di passaggi d esecuzione tra applicazione e database server. 3. Recuperare solo le righe e le colonne necessarie. 4. Minimizzare il numero di query da compilare. 5. Utilizzare lock ad alta granularità. 52

53 3. TUNING DEL DATABASE Se fino ad ora sono stati presentati una serie di interventi mirati all ottimizzazione del sistema su cui il database opera, adesso verranno analizzate le operazioni che l amministratore può compiere direttamente sulla struttura dati per migliorarne al massimo l efficienza. In particolare, dando per assodata la conoscenza delle progettazione del modello concettuale del database (modello E/R), vedremo quali sono i possibili interventi di tuning prima sul livello logico e poi sul livello fisico della base di dati TUNING A LIVELLO LOGICO La progettazione logica si occupa di definire l organizzazione dei dati e di stabilire: 1. gli attributi relativi alle entità già definite a livello concettuale 2. le chiavi primarie ed esterne per la concretizzazione delle relazioni emerse dal modello E/R. In generale, si definisce attributo un informazione relativa ad un entità che rispetti le seguenti regole: contiene un unica informazione. Non assume valori costanti. 53

54 Non si tratta di un campo il cui valore può essere calcolato tramite operazioni su altri campi. Una volta definiti in questo modo gli attributi del modello logico, si procedere alla concretizzazione delle relazioni del modello E/R e alla creazione di speciali attributi definiti come chiavi primarie ed esterne. Per potere due attributi rappresentare una relazione, ed essere quindi chiave primaria ed esterna, devono soddisfare le seguenti condizioni: 1. Devono avere la stessa natura. Se un attributo è di tipo intero e l altro è di tipo testo i due attributi insieme non possono mai rappresentare una relazione tra entità. 2. Devono avere sempre valori not null 3. Almeno uno dei due attributi deve essere univoco. L utilizzo delle chiavi permette di rappresentare fisicamente le relazioni di cardinalità uno a molti ma, da sole, non sono sufficienti alla concretizzazione delle relazioni con cardinalità molti a molti. Per risolvere questo problema, rendere la struttura più flessibile, ridurre la ridondanza e il rischio di incoerenza, occorre procedere a una serie di operazioni dette di normalizzazione. La normalizzazione aiuta a mantenere alte le prestazioni anche se, in certi casi, si possono raggiungere risultati migliori con l aggiunta di ridondanza e quindi la parziale denormalizzazione del modello. 54

55 NORMALIZZAZIONE Dopo aver stabilito le entità, gli attributi e le chiavi che andranno a comporre il modello fisico del database al fine di raggiungere lo scopo previsto dalla base di dati, per ottenere il massimo dell efficienza è necessario procedere alla normalizzazione dello schema realizzato. Tale processo si fonda su un unico semplice criterio: se una relazione presenta più concetti tra loro indipendenti, la si decompone in relazioni più piccole, una per ogni concetto. Questo tipo di processo non è sempre applicabile in tutte le tabelle. In taluni casi potrebbe comportare una perdita d'informazioni. Esistono vari livelli di normalizzazione detti anche forme normali che certificano la qualità del modello di un database. In genere si ritiene che l applicazione delle prime tre forme normali permetta di raggiungere un adeguato compromesso tra efficienza e ridondanza. Un modello logico si dice: in Prima Forma Normale, quando ogni tabella non presenta gruppi di attributi ripetuti ciascun attributo è definito su un dominio con valori atomici e contiene un attributo che funge da chiave primaria in Seconda Forma Normale, quando il modello è in Prima Forma Normale e, in più, per ogni tabella tutti i campi non chiave 55

56 dipendono funzionalmente dalla chiave primaria o, in caso di chiave composta, da tutti gli attributi che ne fanno parte. In Terza Forma Normale, quando il modello è in Seconda Forma Normale e la dipendenza tra gli attributi è basata solo sulla chiave primaria e non esistono dipendenze tra attributi. Sono state formalizzate altre forme normali quali: la forma normale Boyce/Codd, la quarta forma normale, la quinta, ecc. ma raramente vengono utilizzate, in quanto ad un incremento di rigore nell'eliminazione della ridondanza corrisponde un degrado delle prestazioni. Per capire bene la normalizzazione può essere utile un esempio. Di seguito è preso in considerazione lo schema, attualmente funzionante, del database dei docenti di religione di una Diocesi le cui funzioni principali consistono nel calcolo della graduatoria e nell assegnazione delle cattedre, definite come insieme di ore di servizio distribuite in un massimo di tre scuole diverse, ai singoli insegnanti. 56

57 Fig. 9: Elenco attributi della tabella Insegnanti. La prima cosa che notiamo dalla struttura della tabella Insegnanti è che il suo secondo attributo (COGNOME_NOME) viola una delle caratteristiche di definizione degli attributi. Esso non rappresenta infatti un informazione univoca bensì l unione del cognome e del nome dell insegnate. Anche correggendo questo errore, si ci rende conto che la struttura ottenuta (Fig. 10) non rispetta le regole della prima forma normale. Fig. 10 Struttura della tabella dopo la correzione dell attributo COGNOME_NOME. 57

58 Pur esistendo il campo ID_ASPIRANTE che funge da chiave primaria, sono presenti gruppi di attributi ripetuti. Applicare la prima forma normale significherebbe eliminare tutti gli attributi sovrabbondanti e semplificare la consultazione dei dati che appare confusionaria e di difficile consultazione (Fig. 11). Fig. 11: Visualizzazione dei dati della tabella non normalizzata Gli effetti della normalizzazione di primo livello (Fig. 12) sono i seguenti: Effetti Positivi: si riducono gli sprechi di spazio legati alle tuple lasciate incomplete, si semplificano le interrogazioni e soprattutto si rende la struttura più elastica permettendole di memorizzare per ogni insegnante un numero massimo indefinito di scuole al posto delle tre che prevedeva inizialmente Effetti Negativi: aumentano le tuple inserite nella tabella e la ridondanza dei dati in relazione all anagrafica degli insegnanti; 58

59 Fig. 12: I dati della tabella insegnanti a seguito della normalizzazione di primo livello. Per semplificare e rimuovere la nuova ridondanza, ci viene incontro il principio della Seconda Forma Normale. In questo caso possiamo notare che non tutti gli attributi della tabella dipendono funzionalmente dalla chiave primaria già definita bensì è possibile scomporre gli attributi in due gruppi: quelli legati all anagrafica e quelli che invece dipendono dalla scuola di insegnamento. Si procedere, quindi, alla normalizzazione di secondo livello aggiungendo una chiave primaria ID legata alla scuola di riferimento, una chiave esterna ID_INSEGNANTE e spezzando la struttura in due strutture distinte. 59

60 Fig. 13: I dati nelle due strutture distinte. Dallo studio di questa nuova situazione iniziale si ci rende conto che, mentre la tabella insegnanti risulta adesso normalizzata al secondo livello, la nuova tabella Scuole continua a non essere normalizzata in quanto l attributo PER_ORE e ANNO non sono legate esplicitamente alla chiave primaria ID_SCUOLA. Procedendo come già esposto e normalizzando ulteriormente in secondo livello si avrà alla fine la seguente struttura: 60

61 Fig. 14: I dati dopo la normalizzazione di secondo livello. Se da un lato la Seconda Forma Normale ha rimosso quasi interamente le ridondanze, dall altro ha complicato le query che ora devono tenere conto delle nuove relazioni tra le tre strutture. Analizzando ulteriormente l esempio proposto e trascurando la ridondanza del campo DI della tabella Scuole per cui sarebbe necessaria un ulteriore normalizzazione di secondo livello, si ci rende conto che la struttura è già in terza forma normale perché nessun campo attributo dipende da un altro campo attributo DENORMALIZZAZIONE Denormalizzazione significa violare la normalizzazione. Tenuto conto di tutti gli svantaggi di una tale mossa, l uso della denormalizzazione è 61