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 dallutente (ordine di esecuzione dei join, access path, strategia di ottimizzazione, etc)

Ottimizzatore di Oracle

Silvia Chiusano Politecnico di Torino chiusano@polito.it

1

Execution plan
Indica lesecuzione 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.

Esempio
DATABASE EMP(job, deptno, ) DEPT(deptno,)

SELECT * FROM dept, emp WHERE dept.deptno=emp.deptno;

3 4

Albero di esecuzione
0 Select Accesso fisico ai dati 1 Join operation Row source 2 Access to emp 3 Access to dept Flusso di esecuzione
5

Flusso di esecuzione
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).

Elaborazione

Ottimizzatore di Oracle

Dicembre 2002

Tipi di access path

Full Table scan Index Scan By ROWID Hash scan Cluster scan

Esempio #1
SELECT * FROM emp WHERE job=clerk; 0 Select

1 Table access full (emp)

Esempio #2
SELECT * FROM emp WHERE job=clerk; 0 Select

Tipi di join
Nested loop join Sort merge join (equijoin) Cluster Join Hash join (equijoin; non in rule based)

1 Table access by ROWID (emp) 2 Index range scan (jobInd)

CREATE INDEX jonInd ON emp;

10

Esempio #3
SELECT * FROM dept, emp WHERE dept.deptno=emp.deptno; 0 Select 1 Merge

Strategie di ottimizzazione
Due possibili strategie per definire execution plan: Cost-based approach Rule-based approach Cost based una strategia legata ad una analisi dinamica della distribuzione dei dati Rule based una strategia legata ad una analisi dellefficienza dei access path che statica e scorrelata dalla effettiva distribuzione dei dati.

2 Sort

4 Sort

3 Full access

5 Full access 11
12

Ottimizzatore di Oracle

Dicembre 2002

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 lutilizzo 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 lesecuzione che utilizza gli access path ottimali rispetto al ranking.

13

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 lordine e il tipo di join.
15

Cost-based e rule-based
Rule based: privilegia sempre laccesso tramite indici (anche quando non vantaggioso) nellesecuzione del join privilegia il nested loop join in cui la inner table acceduta tramite un indice

16

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

17

18

Ottimizzatore di Oracle

Dicembre 2002

Istogrammi
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).
19

Procedimento di ottimizzazione
Trasformazione/Semplificazione dello statement SQL Scelta della strategia di ottimizzazione Analisi dei cammini di accesso ai dati Definizione dellordine di esecuzione delle join e del tipo di operazione di join.

20

Calcolo del piano di esecuzione

1. 2. 3. 4. 5. 6. 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

1. 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

21

22

2. Scelta della strategia di ottimizzazione

ALTER SESSION SET OPTIMIZER_MODE=option;

4. Calcolo di statistiche
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

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

26

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)

Esempio: CREATE INDEX ind_deptno ON emp(deptno);

27

28

Statistiche sugli indici

ANALYZE INDEX nome_indice COMPUTE STATISTICS

Hint
Permettono di definire i seguenti aspetti: strategia di ottimizzazione access path per le tabelle ordine delle tabelle nellesecuzione di un join tipo di join.

Esempio: ANALYZE INDEX ind_deptno COMPUTE STATISTICS;

rendono il codice SQL non pi portabile

29

30

Ottimizzatore di Oracle

Dicembre 2002

Definizione di un hint

Hint per access path: FULL

Lhint FULL forza un accesso di tipo full table scan sulla tabella specificata

SELECT /*+ hint eventuali_commenti */ FULL( nome tabella) FULL(alias tabella) 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 32

Esempio:

Hint per access path: INDEX

Lhint INDEX forza un accesso di tipo index scan sullindice specificato 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 access path: INDEX

Se in INDEX() sono specificati pi indici per una tabella, lottimizzatore sceglie quello pi vantaggioso Se in INDEX() non sono specificati indici ma viene solo indicata la tabella, lottimizzatorer analizza tutti gli indici definiti sulla tabella e sceglie quello pi vantaggioso

34

Hint per ordine di esecuzione delle join: ORDERED

Utilizzando lhint ORDERED, le tabelle compaiono nel join nellordine specificato nella clausola FROM. ORDERED Esempio:

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)

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

Ottimizzatore di Oracle

Dicembre 2002

Hint per la scelta del tipo di join

Forza il merge sort join nei join in cui coinvolta la tabella. USE_MERGE (nome tabella) USE_MERGE (alias tabella) Forza lhash join nei join in cui coinvolta la tabella. USE_HASH (nome tabella) USE_HASH (alias tabella)

Esempio

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;

37

38