Progetto fisico e tuning del DB. Tecnologie delle Basi di Dati M

Transcript

1 Progetto fisico e tuning del DB Tecnologie delle Basi di Dati M

2 Progetto fisico e tuning La valutazione del progetto di un DB avviene tramite la misurazione delle prestazioni del DBMS rispetto alle interrogazioni ed alle operazioni di modifica del DB tipicamente utilizzate È possibile migliorare le prestazioni A-priori tramite i 3 tipi di progettazione (concettuale, logica, fisica) A-posteriori tramite il tuning di parametri e/o oggetti del DB 2

3 Workload La chiave per un buon progetto fisico è ottenere una descrizione (il più possibile) accurata del carico di lavoro atteso Il workload include: Un elenco di query con la rispettiva frequenza di esecuzione Un elenco di transazioni (operazioni di modifica) con la rispettiva frequenza di esecuzione Un obiettivo di prestazioni per ciascun tipo di query/operazione di modifica 3

4 La lista della spesa Per ogni query nel workload occorre conoscere: Quali relazioni sono interessate Quali attributi vengono mantenuti (proiezione) Quali attributi sono interessati da predicati (selezione/join) Qual è la selettività di ogni predicato Per ogni transazione nel workload occorre conoscere: Che tipo di modifica viene realizzata (insert/delete/update) Quali relazioni sono interessate Quali attributi sono interessati da predicati (selezione/join) Qual è la selettività di ogni predicato Quali campi sono modificati 4

5 Scelte per progetto fisico/tuning Quali indici creare? Un indice può velocizzare alcune query/update, ma tipicamente rallenta le transazioni Su quali relazioni/attributi conviene costruire un indice? L indice deve essere clustered? L indice deve essere denso o sparso? Occorre modificare lo schema concettuale per migliorare le prestazioni? Schemi di normalizzazione alternativi Denormalizzazione Partizionamento verticale/orizzontale Viste materializzate Occorre riscrivere alcune query/transazioni? Il tutto si complica in scenari distribuiti 5

6 Tuning Il tuning è necessario perché, spesso, le condizioni al contorno cambiano È quindi necessario rivedere alcune delle scelte progettuali effettuate all inizio Nuove query/transazioni Modifica delle frequenze delle query/transazioni Upgrade/downgrade dell hardware Modifica/aggiornamento del DBMS 6

7 I 5 principi fondamentali Think globally, fix locally Non limitarsi all ottimizzazione di singole query Partitioning breaks bottlenecks Partizionare nel tempo, nello spazio o in risorse Start-up costs are high, running costs are low Es.: letture sequenziali, compilazione di query, connessione al DB da applicazioni Render unto server what is due unto server Sviluppare le applicazioni per ridurre il carico sui server Be prepared for trade-offs You want speed: how much are you willing to pay? 7

8 Il problema del progetto fisico Il progetto fisico può essere visto come un problema di ottimizzazione in cui il costo di ogni query/transazione viene modificato dalla presenza/assenza di un indice È però evidente che lo spazio delle possibili soluzioni è enorme Usiamo un approccio euristico incrementale Prima vediamo quali indici potrebbero migliorare le prestazioni delle query/transazioni più importanti Quindi vediamo se l aggiunta di ulteriori indici può migliorare la soluzione 8

9 Linee guida (i) Creazione di un indice Non creare indici inutili Creare prima indici che velocizzino più di una query Scelta dell attributo da indicizzare Gli attributi presenti nella clausola WHERE delle query sono candidati come chiavi di ricerca Predicati di uguaglianza suggeriscono l uso di hash Predicati di range suggeriscono l uso di B-tree Il join index nested loop funziona meglio con indici hash 9

10 Linee guida (ii) Uso di chiavi multiple in un indice Presenza di predicati WHERE su più attributi di una relazione Possibilità di sfruttare piani index-only Attenzione all ordine degli attributi in caso di predicati di range Clusterizzazione di un indice Le query di range sono quelle che beneficiano maggiormente dalla clusterizzazione di un indice Anche le ricerche su attributi non chiave traggono vantaggio da indici clustered I piani di accesso index-only non necessitano di indici clustered 10

11 Selezione degli indici (i) SELECT E.name, D.mgr FROM Employees E, Departments D WHERE D.name= Toy AND E.dno=D.dno Quali indici? D.name (hash)! E.dno? D.dno? Un possibile piano di accesso sarebbe: Recuperare i dipartimenti su D.name Usare un index nested loop su E (indice su E.dno) Quindi, indice (hash) su E.dno! 11

12 Selezione degli indici (ii) SELECT E.name, D.mgr FROM Employees E, Departments D WHERE D.name= Toy AND E.dno=D.dno AND E.age=25 Quali indici? D.name? E.age? E.dno? D.dno? Se esistesse già l indice su E.age potrebbe essere inutile creare l indice su E.dno 12

13 Selezione degli indici (iii) SELECT E.name, D.mgr FROM Employees E, Departments D WHERE E.sal BETWEEN and AND E.hobby= stamps AND E.dno=D.dno Quali indici? E.sal? E.hobby? E.dno? D.dno? Tipicamente, la scelta cadrà sull indice più selettivo tra E.sal e E.hobby con l aggiunta di D.dno E se la selettività non è nota? 13

14 Indici clustered (i) SELECT E.dno FROM Employees E WHERE E.age>40 L indice su age (B + -tree, ovviamente) dovrebbe essere clustered? Se ci sono molti ultra-quarantenni l indice non è utile E se ci sono, ad esempio, il 10% di ultra-quarantenni? 14

15 Indici clustered (ii) SELECT E.dno, count(*) FROM Employees E WHERE E.age>20 GROUP BY E.dno L indice su age (B + -tree, ovviamente) è utile? Dipende dalla selettività del predicato su età Un alternativa potrebbe essere un indice su dno In questo caso l indice dovrebbe essere clustered Alternativamente, l ottimizzatore sceglierebbe di ordinare E in base a dno 15

16 Indici clustered (iii) SELECT E.dno FROM Employees E WHERE E.hobby= stamps L indice su hobby deve essere clustered? Dipende dalla selettività del predicato su hobby E in questo caso? SELECT E.dno FROM Employees E WHERE E.eid=552 16

17 Indici clustered (iv) SELECT E.name, D.mgr FROM Employees E, Departments D WHERE D.name= Toy AND E.dno=D.dno Gli indici su D.name e E.dno devono essere clustered? Probabilmente, ci saranno pochi dipartimenti che soddisfano il predicato, quindi indice unclustered Viceversa, l indice per l index nested loop dovrebbe essere clustered 17

18 Indici clustered (v) SELECT E.name, D.mgr FROM Employees E, Departments D WHERE E.hobby= stamps AND E.dno=D.dno In questo caso, E dovrebbe essere esterna? Quali indici? Un sort-merge join potrebbe sfruttare un B + -tree clustered su D.dno Se il predicato su E.hobby è selettivo, un indice (clustered) su E.hobby può essere utile 18

19 Indici clustered (vi) costo In generale, il costo dell accesso ai record di una tabella segue questo andamento: indice unclustered indice clustered scansione sequenziale frazione di record acceduti 19

20 Indici multi-attributo SELECT E.eid FROM Employees E WHERE E.age BETWEEN 20 AND 30 AND E.sal BETWEEN 3000 AND 5000 Un indice (B + -tree clustered) su <age,sal> potrebbe essere utile E un indice su <sal,age>? E in questo caso? SELECT E.eid FROM Employees E WHERE E.sal BETWEEN 3000 AND 5000 AND E.age = 25 20

21 Indici per piani index-only (i) SELECT D.mgr FROM Departments D, Employees E WHERE D.dno=E.dno Se abbiamo un indice denso su E.dno possiamo usarlo per un index nested loop Non ha senso che l indice sia clustered (nessun record di E viene recuperato) 21

22 Indici per piani index-only (ii) SELECT D.mgr, E.eid FROM Departments D, Employees E WHERE D.dno=E.dno Se abbiamo un indice denso su E.dno possiamo usarlo per un index nested loop In questo caso l indice deve essere clustered! Se abbiamo un B + -tree denso su <dno,eid> possiamo usare un piano index-only Ancora, non è necessario che l indice sia clustered Un indice hash andrebbe bene? 22

23 Indici per piani index-only (iii) SELECT E.dno, COUNT(*) FROM Employees E GROUP BY E.dno Se abbiamo un indice su E.dno possiamo usarlo per un piano index-only 23

24 Indici per piani index-only (iv) SELECT E.dno, COUNT(*) FROM Employees E WHERE E.sal=10000 GROUP BY E.dno È meglio avere un indice su <sal,dno> o su <dno,sal>? Meglio <sal,dno> Hash o B + -tree? B + -tree perché dobbiamo ordinare su dno E se il predicato è E.sal>10000? 24

25 Indici per piani index-only (v) SELECT E.dno, MIN(E.sal) FROM Employees E GROUP BY E.dno È meglio avere un indice su <sal,dno> o su <dno,sal>? In questo caso, un B + -tree su <dno,sal> ci darebbe immediatamente il risultato Il piano che usa l indice <sal,dno> richiederebbe anch esso un B + -tree ma sarebbe comunque meno efficiente 25

26 Indici per piani index-only (vi) SELECT AVG(E.sal) FROM Employees E WHERE E.age=25 AND E.sal BETWEEN 3000 AND 5000 È meglio avere un indice su <sal,age> o su <age,sal>? In questo caso, un B + -tree su <age,sal> ci darebbe immediatamente il risultato Il piano che usa l indice <sal,age> richiederebbe anch esso un B + -tree ma sarebbe comunque meno efficiente 26

27 Tuning del DB (i) Tuning degli indici Rivedere le scelte in base a statistiche modificate Aggiornare le statistiche di indici/db Riorganizzare periodicamente gli indici Tuning dello schema concettuale Denormalizzazione Decomposizione verticale Decomposizione orizzontale Eventuale creazione di viste 27

28 Tuning del DB (ii) Tuning di query (e viste) Uso di UNION al posto di OR Eliminazione del DISTINCT Sostituzione delle sub-query con join Eliminazione delle tabelle temporanee Riscrittura di predicati con condizioni aritmetiche Es., E.age=2*D.age rispetto a E.age/2=D.age Selezioni con valori NULL Impatto della concorrenza Ridurre il livello di isolation delle query 28

29 Strumenti automatici Quasi tutti i DBMS commerciali forniscono degli strumenti automatici per la progettazione fisica e il tuning del DB DB2 design advisor, SQL Server database tuning advisor, Oracle access advisor Tipicamente basati su analisi what-if? Uso dell ottimizzatore per valutare l impatto di una possibile scelta Ogni sistema ha poi una varietà di strumenti per la gestione fisica dei dati, l analisi dei piani di accesso, ecc. 29

30 Una raccomandazione I suggerimenti forniti dagli advisor si riferiscono unicamente al workload fornito Non è possibile trarre considerazioni generali che valgano per workload diversi da quello fornito Analogia: il computer non sa giocare a scacchi Questo significa che non è mai opportuno sovra-ottimizzare un DB Occorre comunque che il DBA conosca quali siano le conseguenze di ciascuna azione suggerita dall advisor Ricordando la dipendenza dall HW 30

31 Collezionare statistiche in DB2 Le informazioni statistiche su tabelle e indici sono fondamentali per permettere all ottimizzatore di operare scelte acccurate In DB2 si usa il comando RUNSTATS Esistono molte varianti, tra cui: RUNSTATS ON TABLE MySchema.TableName WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL La forma WITH DISTRIBUTION forza DB2 a collezionare statistiche dettagliate sulle distribuzioni dei valori delle varie colonne (istogrammi e valori frequenti) 31

32 Statistiche detailed sugli indici La forma DETAILED INDEXES ALL genera informazioni utili per capire il costo di una scansione via indice In particolare, il sistema genera una lista di 11 PAGE_FETCH_PAIRS Ogni coppia ha la forma (buffer_size,#i/o) e stima quanti I/O (fisici) sarà necessario eseguire per effettuare una scansione completa avendo a disposizione un certo numero di buffer 32

33 Esempi di curve PAGE_FETCH_PAIRS Le curve tipiche sono: 1: clustering praticamente nullo 2: buon clustering, avendo un buffer size modesto si evitano I/O inutili 3: situazione intermedia, assunta dall ottimizzatore in assenza di statistiche dettagliate

34 Riorganizzazione dei dati Il comando REORGCHK: REORGCHK ON TABLE MySchema.TableName fornisce alcuni indicatori utili per capire se una table deve essere riorganizzata fisicamente Idem per gli indici Il comando esegue automaticamente anche RUNSTATS (secondo la modalità presente in catalogo) 34

35 Info da REORGCHK Vengono forniti tre indicatori, con relativi valori di soglia F1: % di record in overflow (< 5%) F2: % di spazio utilizzato nelle pagine allocate (> 70%) F3: NPAGES/FPAGES (> 80%) 35

36 Riorganizzazione di dati e indici Per riorganizzare i dati e gli indici: REORG TABLE MySchema.MyTable Per riorganizzare solo gli indici: REORG INDEXES ALL FOR TABLE MySchema.MyTable 36

37 Esempio: frammentare i dati Per generare una situazione in cui la riorganizzazione può rendersi necessaria generiamo una tabella con molte righe Eseguiamo REORGCHK Poi ne cancelliamo una buona parte Rieseguiamo REORGCHK 37

38 Esempio: generare i dati (i) Creiamo la seguente tabella: CREATE TABLE TEST ( A INT, B INT, C CHAR(100) ) in cui C serve solo a occupare spazio Per generare i dati usiamo un trigger ricorsivo: DB2 supporta al massimo 16 livelli di ricorsione Non permette ricorsione multipla (ovvero non possiamo avere più di 1 azione di inserimento nel trigger) Usiamo uno statement trigger 38

39 Esempio: generare i dati (ii) CREATE TRIGGER AUTO_INSERT AFTER INSERT ON TEST FOR EACH STATEMENT WHEN (10000 > (SELECT COUNT(*) FROM TEST)) INSERT INTO TEST(A,B,C) SELECT MOD(3*A+1,20),MOD(3*B+1,50),C FROM TEST Il trigger va creato dopo l inserimento del 1 record e prima dell inserimento del 2 : INSERT INTO TEST VALUES (1,10, ) INSERT INTO TEST VALUES (2,20, ) Così si generano record! (16384 = ) 39

40 Esempio: situazione iniziale Eseguiamo RUNSTATS ON TABLE B16884.TEST WITH DISTRIBUTION ON ALL COLUMNS B16884 è lo schema in cui si trova TEST Quindi REORGCHK: 40

41 Esempio: dopo le cancellazioni Dopo DELETE FROM TEST WHERE B>3: Dopo REORG TABLE B16884.TEST: 41

42 Explain tables Informazioni dettagliate sul piano di accesso scelto dall ottimizzatore possono essere mantenute in un insieme di tabelle chiamate Explain tables Le Explain tables possono essere esaminate mediante tool grafico del Command Editor (Visual Explain) interrogazioni SQL 42

43 Visual Explain Eseguendo una query dal Command Editor 43

44 Esercizio: scelta degli indici (i) Usiamo il Visual Explain per vedere come viene scelto l indice migliore da usare nell esecuzione di una query A tale scopo creiamo e popoliamo una tabella (TEST) con pochi valori nel campo A, ma più valori distinti nel campo B: CREATE TABLE TEST( A INT, B INT, C CHAR(250)) 44

45 Esercizio: scelta degli indici (ii) Creiamo gli indici su A, B, (A,B) e (B,A), ad es: CREATE INDEX IDXA ON B16884.TEST(A) Eseguiamo RUNSTATS Eseguiamo query del tipo: SELECT * FROM TEST WHERE A <op> :a AND B <op> :b e verifichiamo il piano di accesso scelto Sistemi Informativi L-B 45