Processo di ottimizzazione. Ottimizzatore di Oracle. Execution plan. Esempio. Albero di esecuzione. Ottimizzatore di Oracle Dicembre 2002

Transcript

1 Processo di ottimizzazione Ottimizzatore di Oracle Silvia Chiusano Politecnico di Torino Scelta della esecuzione più efficiente per uno statement SQL Influenzato da: Metodi di accesso ai dati (access path) Statistiche sui dati (dimensioni delle tabelle, distribuzione dei dati nelle tabelle, etc.) Strategia di ottimizzazione Hint specificati dall utente (ordine di esecuzione dei join, access path, strategia di ottimizzazione, etc) Execution plan Esempio Indica l esecuzione di uno statement SQL Lo statement SQL è diviso in un insieme di passi Ad ogni passo è assegnato un ordine di esecuzione Rappresentato graficamente con un albero di esecuzione. Contiene due tipi di passi: per accedere fisicamente ai dati (access path) per elaborazione dei dati. DATABASE EMP( job, deptno, ) DEPT(deptno, ) FROM dept, emp WHERE dept.deptno=emp.deptno; 4 Albero di esecuzione Flusso di esecuzione Access to emp Join operation Access to dept Row source Elaborazione Accesso fisico ai dati Flusso di esecuzione 5 I nodi figli sono processati prima del nodo padre Un nodo è eseguito quando: tutti i dati sono stati forniti dal nodo figlio (per i nodi di tipo sort, merge join, group by, funzioni aggregate) oppure ad ogni nuovo dato fornito dal nodo figlio (per i nodi di tipo nested loop join). 6

2 Tipi di access path Esempio # Full Table scan Index Scan By ROWID Hash scan Cluster scan FROM emp WHERE job= clerk ; Table access full (emp) 7 8 Esempio # Tipi di join FROM emp WHERE job= clerk ; Table access by ROWID (emp) Nested loop join Sort merge join (equijoin) Cluster Join Hash join (equijoin; non in rule based) Index range scan (jobind) CREATE INDEX jonind ON emp; 9 Esempio # FROM dept, emp WHERE dept.deptno=emp.deptno; Strategie di ottimizzazione Due possibili strategie per definire execution plan: Cost-based approach Rule-based approach Sort Merge 4 Sort Cost based è una strategia legata ad una analisi dinamica della distribuzione dei dati Rule based è una strategia legata ad una analisi dell efficienza dei access path che è statica e scorrelata dalla effettiva distribuzione dei dati. Full access 5 Full access

3 Cost-based approach Un insieme di piani di esecuzione (execution plan) è definito in base a access path disponibili ed hint Ad ogni execution plan è assegnato un costo usando le statistiche disponibili nel dizionario dei dati Il costo è l utilizzo atteso delle risorse (I/O, CPU time, memoria) per eseguire lo statement SQL. Obiettivi: throughput (default) response time Rule-based approach Si basa su un ranking a priori degli access path Analizza gli access path disponibili e sceglie l esecuzione che utilizza gli access path ottimali rispetto al ranking. 4 Cost-based e rule-based Cost based: in base alla distribuzione dei dati sceglie tra accesso tramite indici o full scan: accesso poco frequente a dati è più efficiente tramite indice, molto frequente tramite full scan esecuzione del join: throughput: privilegia esecuzione del merge join response time: privilegia esecuzione del nested loop join. uso della distribuzione dei dati e access path disponibili per decidere l ordine e il tipo di join. Cost-based e rule-based Rule based: privilegia sempre l accesso tramite indici (anche quando non è vantaggioso) nell esecuzione del join privilegia il nested loop join in cui la inner table è acceduta tramite un indice 5 6 Calcolo di statistiche Calcolo delle statistiche relative alle caratteristiche memorizzazione fisica e distribuzione dei dati di tabelle, indici, colonne, cluster Sono memorizzate nel dizionario dei dati. Sono accessibili interrogando le view corrispondenti. Possono essere calcolate in modo esatto o in modo approssimato (su un campione dei dati). Statistiche disponibili Indice: # valori distinti # ROWID (foglie) con lo stesso indice Tabella # righe # data block contenenti i dati Colonna: distribuzione dei dati (equivalente a istogrammi) Istogramma 7 8

4 Istogrammi Procedimento di ottimizzazione Per analizzare la distribuzione di valori in una colonna Utili nel caso di dati non distribuiti uniformemente Width-balanced histograms: divide i dati in un numero fisso di sottoinsiemi (bucket) e poi conta quanti dati appartengono ad ogni bucket. Heigth-balanced histograms: definisce il numero di dati in ogni bucket; ogni bucket è caratterizzato dalla distribuzione di valori diversi nel bucket (valore min e max). Trasformazione/Semplificazione dello statement SQL Scelta della strategia di ottimizzazione Analisi dei cammini di accesso ai dati Definizione dell ordine di esecuzione delle join e del tipo di operazione di join. 9 Calcolo del piano di esecuzione. Creazione di plan table. Scelta della strategia di ottimizzazione. Definizione di indici e hint 4. Calcolo di statistiche 5. Calcolo del piano di esecuzione 6. Visualizzazione del piano di esecuzione. Creazione di Plan Table Ogni riga contiene un passo del piano di esecuzione I campi principali sono i sequenti: STATEMENT_ID: identificatore delle righe che appartengono allo stesso piano di esecuzione OPERATION, OPTIONS: tipo di operazione (ad esempio join) e modalità con cui è eseguita (ad esempio nested loop) OBJECT_NAME: nome tabella o indice OPTIMIZER: strategia di ottimizzazione ID, PARENT_id, POSITION: #ordine del passo, # nodo padre, ordine per processamento di nodi con lo stesso padre COST. Scelta della strategia di ottimizzazione 4. Calcolo di statistiche ALTER SESSION SET OPTIMIZER_MODE=option; ANALYZE TABLE nametable COMPUTE STATISTICS Opzioni: CHOOSE: cost-based (throughput) se sono disponibili statistiche nel dizionario dei dati, rule based altrimenti FIRST_ROWS: cost-based (response time) ALL_ROWS: cost-based (throughput) RULE: rule based ANALYZE TABLE nametable EVALUATE STATISTICS ANALYZE TABLE nametable COMPUTE STATISTICS FOR COLUMNS namecolumn SIZE #buckets 4 4

5 5. Calcolo del piano di esecuzione 6. Visualizzazione del piano di esecuzione Interrogazione della tabella plan table EXPLAIN PLAN SET statement_id= name statement id INTO plan table FOR SQL statement; 5 6 Indici Permettono di accedere in modo diretto e veloce ai campi ai quali si riferiscono I campi su cui creare degli indici vanno scelti: in funzione della distribuzione dei dati nella base di dati in funzione delle interrogazioni che si andarnno ad operare Gli indici richiedono spazio e tempi di aggiornamento (vanno creati solo se sono utili) Creazione di indici CREATE INDEX nome_indice ON nome_tabella(nome_campo) CREATE INDEX ind_deptno ON emp(deptno); 7 8 Statistiche sugli indici ANALYZE INDEX nome_indice COMPUTE STATISTICS ANALYZE INDEX ind_deptno COMPUTE STATISTICS; Hint Permettono di definire i seguenti aspetti: strategia di ottimizzazione access path per le tabelle ordine delle tabelle nell esecuzione di un join tipo di join. rendono il codice SQL non più portabile 9 5

6 Definizione di un hint SELECT /*+ hint eventuali_commenti */ Hint per access path: FULL L hint FULL forza un accesso di tipo full table scan sulla tabella specificata FULL( nome tabella) SELECT /*+ FULL(e) Uso di hint*/ ename from emp e where job= clerk ; FULL(alias tabella) SELECT /*+ FULL(e) */ empno from emp e where empno < 75; Hint per access path: INDEX L hint INDEX forza un accesso di tipo index scan sull indice specificato INDEX( nome tabella nome indice) INDEX( alias tabella nome indice) Hint per access path: INDEX Se in INDEX( ) sono specificati più indici per una tabella, l ottimizzatore sceglie quello più vantaggioso Se in INDEX( ) non sono specificati indici ma viene solo indicata la tabella, l ottimizzatorer analizza tutti gli indici definiti sulla tabella e sceglie quello più vantaggioso Si assuma un indice sal_ind sul campo sal in emp SELECT /*+ INDEX(e sal_ind) */ ename, job from emp e where sal < 75; 4 Hint per ordine di esecuzione delle join: ORDERED Utilizzando l hint ORDERED, le tabelle compaiono nel join nell ordine specificato nella clausola FROM. ORDERED SELECT /*+ ORDERED */ e.sal from emp e, salgrade s where s.hisal= e.sal; Hint per la scelta del tipo di join Forza il nested loop join nei join in cui è coinvolta la tabella. La tabella è considerata la inner table. Questa istruzione deve sempre essere preceduta da ORDERED ORDERED USE_NL (nome tabella) ORDERED USE_NL (alias tabella) Il piano di esecuzione indica un nested loop join, dove la tabella SALGRADE è la inner table; 5 6 6

7 Hint per la scelta del tipo di join Esempio Forza il merge sort join nei join in cui è coinvolta la tabella. USE_MERGE (nome tabella) USE_MERGE (alias tabella) Forza l hash join nei join in cui è coinvolta la tabella. explain plan for select /*+ FULL(e) ORDERED USE_NL(e) */ e.ename, e.sal from salgrade s, emp e where s.hisal < e.sal and e.job='clerk ; USE_HASH (nome tabella) USE_HASH (alias tabella) 7 8 7