Ottimizzatore di Oracle - DataBase and Data Mining Group
Transcript
Ottimizzatore di Oracle - DataBase and Data Mining Group
Ottimizzatore di Oracle Dicembre 2002 Processo di ottimizzazione • 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) Ottimizzatore di Oracle Silvia Chiusano Politecnico di Torino [email protected] 1 Execution plan 2 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,…) SELECT * FROM dept, emp WHERE dept.deptno=emp.deptno; 3 Albero di esecuzione 0 Flusso di esecuzione Elaborazione Select Accesso fisico ai dati 1 Join operation Row source 2 Access to emp 4 • 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). 3 Access to dept Flusso di esecuzione 5 6 1 Ottimizzatore di Oracle Dicembre 2002 Tipi di access path • • • • • Esempio #1 SELECT * FROM emp WHERE job=‘clerk’; Full Table scan Index Scan By ROWID Hash scan Cluster scan 0 Select 1 Table access full (emp) 7 8 Esempio #2 Tipi di join 0 Select SELECT * FROM emp WHERE job=‘clerk’; • • • • 1 Table access by ROWID (emp) Nested loop join Sort merge join (equijoin) Cluster Join Hash join (equijoin; non in rule based) 2 Index range scan (jobInd) CREATE INDEX jonInd ON emp; 9 Esempio #3 Strategie di ottimizzazione 0 Select SELECT * FROM dept, emp WHERE dept.deptno=emp.deptno; 10 • Due possibili strategie per definire execution plan: – Cost-based approach – Rule-based approach 1 Merge 2 4 Sort Sort 3 5 Full access Full access 11 • 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. 12 2 Ottimizzatore di Oracle Dicembre 2002 Cost-based approach Rule-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 • 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. 13 Cost-based e rule-based 14 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. • 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 15 Calcolo di statistiche 16 Statistiche disponibili • 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). 17 • Indice: – # valori distinti – # ROWID (foglie) con lo stesso indice • Tabella – # righe – # data block contenenti i dati • Colonna: – distribuzione dei dati (equivalente a istogrammi) • Istogramma 18 3 Ottimizzatore di Oracle Dicembre 2002 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. 19 Calcolo del piano di esecuzione 1. 2. 3. 4. 5. 6. 20 1. Creazione di Plan Table Creazione di plan table Scelta della strategia di ottimizzazione Definizione di indici e hint Calcolo di statistiche Calcolo del piano di esecuzione Visualizzazione del piano di esecuzione 21 • 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 22 2. 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 23 ANALYZE TABLE nametable EVALUATE STATISTICS ANALYZE TABLE nametable COMPUTE STATISTICS FOR COLUMNS namecolumn SIZE #buckets 24 4 Ottimizzatore di Oracle Dicembre 2002 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; 25 Indici 26 Creazione di 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) CREATE INDEX nome_indice ON nome_tabella(nome_campo) Esempio: CREATE INDEX ind_deptno ON emp(deptno); 27 28 Hint Statistiche sugli indici ANALYZE INDEX nome_indice COMPUTE STATISTICS Esempio: • 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 ANALYZE INDEX ind_deptno COMPUTE STATISTICS; 29 30 5 Ottimizzatore di Oracle Dicembre 2002 Definizione di un hint Hint per access path: FULL • L’hint FULL forza un accesso di tipo full table scan sulla tabella specificata SELECT /*+ hint eventuali_commenti */ FULL( nome tabella) FULL(alias tabella) Esempio: Esempio: SELECT /*+ FULL(e) Uso di hint*/ ename from emp e where job=‘clerk’; SELECT /*+ FULL(e) */ empno from emp e where empno < 7500; 31 Hint per access path: INDEX 32 Hint per access path: INDEX • L’hint INDEX forza un accesso di tipo index scan sull’indice specificato • 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 INDEX( nome tabella nome indice) INDEX( alias tabella nome indice) Esempio: Si assuma un indice sal_ind sul campo sal in emp SELECT /*+ INDEX(e sal_ind) */ ename, job from emp e where sal < 7500; 33 Hint per ordine di esecuzione delle join: ORDERED 34 Hint per la scelta del tipo di join • Utilizzando l’hint ORDERED, le tabelle compaiono nel join nell’ordine specificato nella clausola FROM. ORDERED • 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 Esempio: ORDERED USE_NL (nome tabella) SELECT /*+ ORDERED */ e.sal from emp e, salgrade s where s.hisal= e.sal; • Il piano di esecuzione indica un nested loop join, dove la tabella SALGRADE è la inner table; ORDERED USE_NL (alias tabella) 35 36 6 Ottimizzatore di Oracle Dicembre 2002 Hint per la scelta del tipo di join Esempio • Forza il merge sort 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_MERGE (nome tabella) USE_MERGE (alias tabella) • Forza l’hash join nei join in cui è coinvolta la tabella. USE_HASH (nome tabella) USE_HASH (alias tabella) 37 38 7