Caso 1 6WUXWWXUHÃILVLFKHÃLQÃDOFXQLÃ'%06 6WUXWWXUHÃILVLFKHÃQHLÃ'%06ÃUHOD]LRQDOL 3URJHWWD]LRQHÃILVLFD HXULVWLFKHÃVXJJHULWHÃGDÃ,QIRUPL[

Transcript

1 6WUXWWXUHÃILVLFKHÃQHLÃ'%06ÃUHOD]LRQDOL Struttura primaria: disordinata (heap, "unclustered") ordinata ("clustered"), anche su una pseudochiave hash ("clustered"), anche su una pseudochiave, senza ordinamento clustering di più relazioni Indici (densi/sparsi, semplici/composti): ISAM (statico), di solito su struttura ordinata B-tree (dinamico) 6WUXWWXUHÃILVLFKHÃLQÃDOFXQLÃ'%06 Oracle (1995 ca): file heap (eventualmente con cluster, anche plurirelazionali) indici secondari (anche su cluster) DB2 (1998): file heap indice sulla chiave primaria (automaticamente) indici secondari (e primari: "cluster") Ingres: file heap, hash, ISAM (ciascuno anche compresso) indici secondari Informix (per DOS, 1994): file heap indici secondari (e primari [cluster] ma non mantenuti) 15/02/2000 Basi di dati: tuning 1 15/02/2000 Basi di dati: tuning 2 3URJHWWD]LRQHÃILVLFD HXULVWLFKHÃVXJJHULWHÃGDÃ,QIRUPL[ 6FHOWDÃGHOODÃVWUXWWXUDÃVHFRQGRÃ6KDVKD n creare indici su relazioni piccole (<200 ennuple) non creare indici su campi con pochi valori (se proprio servono, che siano primari) creare indici su campi con selezioni per i join: creare indici sulla relazione più grande Enorme e senza tempi morti? Relazione piccola? Heap con indice Heap senza indice Intervalli, estremi, ordinamenti? Hash Chiave seq? Dinamica? Hash Cluster ISAM Cluster B-Tree 15/02/2000 Basi di dati: tuning 3 15/02/2000 Basi di dati: tuning 4 &DVLÃGLÃVWXGLRÃSHUÃLOÃWXQLQJ GHOOHÃVWUXWWXUHÃILVLFKHÃ6KDVKD Employee (SSN, Name, Dept, Manager, Salary) Student(SSN, Name, Course, Grade, Stipend,WrittenEvaluation) dal testo: D. Shasha. Database Tuning: a principled approach. Prentice-Hall, 1992 Caso 1 Sulla relazione Student viene definito un indice, ma l'interrogazione seguente non lo usa: FROM Student WHERE Name = 'Bayer' Le statistiche potrebbero non essere aggiornate, e quindi l'ottimizzatore sceglie di non usare l'indice, ritenendo la relazione piccola 15/02/2000 Basi di dati: tuning 5 15/02/2000 Basi di dati: tuning 6 1

2 Caso 2 Caso 3 Sull'attributo Salary della relazione Employee viene definito un indice, ma l'interrogazione seguente non lo usa, anche dopo l'aggiornamento delle statistiche: FROM Employee WHERE Salary/12 = 4000 L'indice non viene utilizzato perché c'è l'espressione aritmetica Sull'attributo Salary della relazione Employee viene definito un indice, l'interrogazione seguente lo usa, ma senza beneficio: FROM Employee WHERE Salary = Probabilmente ci sono molti impiegati con stipendio e l'indice è secondario. L'interrogazione deve quindi accedere a molte pagine (magari quasi tutte). 15/02/2000 Basi di dati: tuning 7 15/02/2000 Basi di dati: tuning 8 Caso 4 Casi 5 e 6 La relazione Studente ha una struttura ordinata con indice su SSN e si generano liste di overflow quando si modifica il valore di "WrittenEvaluation" WrittenEvaluation ha probabilmente lunghezza variabile. La struttura ordinata è poco flessibile in questo caso. Probabilmente conviene una struttura disordinata con indice secondario su SSN La relazione impiegato ha un fattore di blocco (numero di ennuple per blocco) pari a 30. Ogni impiegato (si vede dallo schema) afferisce ad un dipartimento. Caso 5: Ci sono 50 dipartimenti diversi. Caso 6: Ci sono 2000 dipartimenti diversi. Conviene avere un indice secondario su Dept? 5LVSRVWD Nel caso 5 no, perché ogni pagina contiene mediamente impiegati di tutti o quasi i dipartimenti, e quindi un accesso con indice non è più efficiente di una scansione sequenziale, anzi. Nel caso 6 sì, perché ogni pagina contiene solo record di al più 30 dipartimenti su /02/2000 Basi di dati: tuning 9 15/02/2000 Basi di dati: tuning 10 Caso 7 Caso 8 Viene effettuata una copia della relazione Employee, per eseguire su di essa interrogazioni fuori linea (e nessun aggiornamento), in particolare: 1 Contare gli impiegati con un certo stipendio (frequente) 2 Trovare gli impiegati con lo stip max in un dip (frequente) 3 Trovare un impiegato dato il SSN (un po' meno frequente) un indice secondario potrebbe essere più efficiente per (1) perché denso per (2) serve un indice su Dept, Salary (secondario va bene) per (3) un indice primario può essere meglio di un secondario Stipend (in Student) è retribuzione mensile, mentre Salary (in Employee) è annuale. Vogliamo trovare impiegati e studenti con la stessa retribuzione. Che differenza c'è (quale conviene?) fra: 6(/(&7Ã )520Ã(PSOR\HHÃ6WXGHQW :+(5(Ã6DODU\Ã 6WLSHQG 6(/(&7Ã )520Ã(PSOR\HHÃ6WXGHQW :+(5(Ã6DODU\Ã Ã6WLSHQG 15/02/2000 Basi di dati: tuning 11 15/02/2000 Basi di dati: tuning 12 2

3 Caso 8, risposta Caso 9 Indici e espressioni, vedi caso (2): un indice su Stipend potrebbe non essere usato nella prima interrogazione (su Salary sì) un indice su Salary potrebbe non essere usato nella seconda interrogazione (su Stipend sì) Quindi se c'è un indice solo, abbiamo una risposta Se ci sono entrambi, se uno è primario, conviene farlo usare Se sono entrambi secondari, conviene far usare quello sulla relazione più grande (salvo in caso in cui esso sia poco selettivo) Onorder(Supplier,Part,Quantity,Price) Operazioni 1 Inserimento (molto frequente) 2 Eliminazione, dati Supplier e Part (molto frequente) 3 Trovare la quantità totale degli ordini di una Part (frequente) 4 Trovare l'importo totale degli ordini di un fornitore (rara) Se ci sono tempi morti: indice primario su Part e Supplier (hash non va bene per la 3) altrimenti, secondario 15/02/2000 Basi di dati: tuning 13 15/02/2000 Basi di dati: tuning 14 Caso 10 Caso 11 Onorder(Supplier,Part,Quantity,Price) Operazioni sola lettura 3 Trovare la quantità totale degli ordini di una Part (frequente) 4 Trovare l'importo totale degli ordini di un fornitore (meno frequente) Indice primario su Part e Supplier Indice secondario su Supplier Archivio clienti di una carta di credito. Operazioni: 1 Inserimento nuovo cliente (frequente) 2 Trovare un cliente dato il codice fiscale (frequente) 3 Trovare un cliente dato il "ClientNumber" (meno frequente) 4 Scandire l'archivio per intero (rara) C'è una struttura primaria hash sul codice fiscale e un indice secondario B-tree sul " ClientNumber" (che viene generato sfruttando le primitive sui contatori). Le transazioni però sono molto lente. l'ultima pagina del B-tree è un collo di bottiglia; se il sistema la prevede su può usare struttura hash secondaria (cioè struttura hash con un livello aggiuntivo di puntatori) 15/02/2000 Basi di dati: tuning 15 15/02/2000 Basi di dati: tuning 16 Caso 12 Caso 13 Una relazione ha un indice B-tree sul codice fiscale e le operazioni principali sono ricerche e aggiornamenti su ennuple individuate sulla base del codice fiscale. Se le prestazioni non sono soddisfacenti, come provare a migliorarle? B-tree ordinato (in alcuni casi) hash Una relazione disordinata risulta inefficiente in caso di molti inserimenti concorrenti Se le prestazioni non sono soddisfacenti, come provare a migliorarle? Essendo la relazione disordinata, gli inserimenti sono sempre nell'ultimo blocco, su cui i lock generano ritardi. Quindi: si può usare una struttura hash che "sparpagli" usare lock a livello di record riorganizzare le applicazioni, per ridurre i picchi di inserimenti (può non essere possibile) raggruppare più inserimenti in ciascuna transazione 15/02/2000 Basi di dati: tuning 17 15/02/2000 Basi di dati: tuning 18 3

4 Caso 14 Ellis Island gestisce l'archivio dei milioni di immigrati negli USA dell'800 e primo 900. Per ogni immigrato ci sono molti campi, e viene offerto un servizio che dato cognome (talvolta anche nome) e anno di arrivo fornisce le altre info. Che struttura fisica? Abbiamo solo lettura, quindi soluzioni statiche ok Indice primario (anche ISAM) su cognome e nome forse un indice secondario su cognome e anno altri indici probabilmente poco selettivi (ma comunque valutabili, perché senza costi di aggiornamento) &DVLÃGLÃVWXGLRÃSHUÃLOÃWXQLQJ GLÃEDVLÃGLÃGDWL dal testo: D. Shasha. Database Tuning: a principled approach. Prentice-Hall, /02/2000 Basi di dati: tuning 19 15/02/2000 Basi di dati: tuning 20 Caso 1 Caso 2 Abbiamo una base di dati con dieci relazioni su due dischi: cinque e cinque; su un disco c'è anche il log. Compriamo un nuovo disco; che cosa ci mettiamo? 3RVVLELOHÃULVSRVWD Il log Il tempo di risposta è variabile, in particolare ci sono rallentamenti quando vengono eseguite operazioni DDL 3RVVLELOHÃULVSRVWD Le operazioni DDL richiedono lock in scrittura sul catalogo 15/02/2000 Basi di dati: tuning 21 15/02/2000 Basi di dati: tuning 22 Caso 3 Caso 4 Transazioni così organizzate sono insoddisfacenti: attribuzione di un nuovo numero di pratica richiesta di info interattive effettuare l'inserimento transazione troppo lunga; vanno riordinati i passi, e nella transazione ci devono essere solo i l primo e il terzo Una transazione così organizzata eseguita a fine mese, di sera, è inefficiente: per ogni conto stampare tutte le info... essendo di sola lettura, di sera (tempo morto) potrebbe essere senza lock (Uncommitted Read) 15/02/2000 Basi di dati: tuning 23 15/02/2000 Basi di dati: tuning 24 4

5 Casi 5 e 6 Caso 7 Nell'ambito di una transazione, si calcola lo stipendio medio per ciascun dipartimento. Contemporaneamente si fanno modifiche su singoli stipendi. Le prestazioni sono insoddisfacenti. si può eseguire in un tempo morto (senza aggiornamenti) senza lock (Read Uncommitted) se sono tollerate (leggere) inconsistenze, si può procedere senza lock (Read Uncommitted) si può fare una copia e lavorare su di essa (dati non attuali) se nessuna delle alternative è praticabile (non ci sono tempi morti e si vogliono dati attuali e consistenti) si può provare con Read Committed (non c'è rischio di "phantom") Un'applicazione prevede: migliaia di inserimenti ogni ora centinaia di migliaia di piccoli aggiornamenti ogni ora Gli inserimenti arrivano in transazioni grandi ogni mezz'ora e durano 5 minuti. In queste fasi le prestazioni sono inaccettabili (tempo di risposta 30 sec, rispetto a mezzo secondo) e si nota che uno dei dischi è sovraccarico spezzare le transazioni con gli inserimenti riorganizzare i file, in modo che gli inserimenti si ripartiscano su tutti i dischi 15/02/2000 Basi di dati: tuning 25 15/02/2000 Basi di dati: tuning 26 Caso 8 Caso 9 Un'applicazione che prevede un'istruzione SQL all'interno di un ciclo è lenta (e usa molto tempo di CPU) usare bene il cursore (facciamo fare i cicli all'sql) Un disco è inefficiente anche se non pieno. Ci sono relativamente pochi inserimenti molte letture lunghe (scansioni) separare il log su un disco a sé riorganizzare i file in modo contiguo 15/02/2000 Basi di dati: tuning 27 15/02/2000 Basi di dati: tuning 28 Caso 10 Una società di servizi emette tutte le bollette a fine mese, con un programma che ha bisogno di tutta la notte, impedendo così l'esecuzione di altri prorammi batch che sarebbero necessari è proprio necessario che le bollette siano emesse tutte insieme? se è proprio necessario, magari facciamolo durante il week-end (tempo morto più lungo) 15/02/2000 Basi di dati: tuning 29 5