Sei sulla pagina 1di 7

Ottimizzatore di Oracle

Ottimizzatore di Oracle

Silvia Chiusano Politecnico di Torino chiusano@polito.it

1

Execution plan

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.

3

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

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)

2

Esempio

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

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

4

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

6

Ottimizzatore di Oracle

Tipi di access path • Full Table scan • Index Scan • By ROWID •
Tipi di access path
• Full Table scan
• Index Scan
• By ROWID
• Hash scan
• Cluster scan
7
Esempio #2
0
SELECT *
Select
FROM emp
WHERE job=‘clerk’;
1
Table access
by ROWID (emp)
2
Index range
scan (jobInd)
CREATE INDEX jonInd ON emp;
9
Esempio #3 0 Select SELECT * FROM dept, emp WHERE dept.deptno=emp.deptno; 1 Merge 2 4
Esempio #3
0
Select
SELECT *
FROM dept, emp
WHERE dept.deptno=emp.deptno;
1
Merge
2
4
Sort
Sort
3
5
Full access
Full access
11

Dicembre 2002

Esempio #1

SELECT *

FROM emp

WHERE job=‘clerk’;

0 Select 1 Table access full (emp)
0
Select
1
Table access
full (emp)

8

Tipi di join

Nested loop join

Sort merge join (equijoin)

Cluster Join

Hash join (equijoin; non in rule based)

10

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 dell’efficienza dei access path che è statica e scorrelata dalla effettiva distribuzione dei dati.

12

Ottimizzatore di Oracle

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

13

Obiettivi: – throughput (default) – response time 13 Cost-based e rule-based • Cost based: – in

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.

15

disponibili per decidere l’ordine e il tipo di join. 15 Calcolo di statistiche • Calcolo delle

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

17

Dicembre 2002

 

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.

14

 

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

16

 

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

 

18

Ottimizzatore di Oracle

 

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

 

Calcolo del piano di esecuzione

1.

Creazione di plan table

2.

Scelta della strategia di ottimizzazione

3.

Definizione di indici e hint

4.

Calcolo di statistiche

5.

Calcolo del piano di esecuzione

6.

Visualizzazione del piano di esecuzione

 

21

 

2. Scelta della strategia di ottimizzazione

 

ALTER SESSION SET OPTIMIZER_MODE=option;

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

Dicembre 2002

Procedimento di ottimizzazione

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.

20

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

22

4. Calcolo di statistiche

ANALYZE TABLE nametable COMPUTE STATISTICS

ANALYZE TABLE nametable EVALUATE STATISTICS

ANALYZE TABLE nametable COMPUTE STATISTICS FOR COLUMNS namecolumn SIZE #buckets

24

Ottimizzatore di Oracle

5. Calcolo del piano di esecuzione

EXPLAIN PLAN SET statement_id=‘name statement id’ INTO plan table FOR SQL statement;

 
 

25

 

Indici

Permettono di accedere in modo diretto e veloce ai campi ai quali si riferiscono

I campi su cui creare degli indici vanno scelti:

funzione della distribuzione dei dati nella base

in

di

dati

funzione delle interrogazioni che si andarnno

in

ad operare

Gli indici richiedono spazio e tempi di aggiornamento (vanno creati solo se sono utili)

 

27

Statistiche sugli indici

ANALYZE INDEX nome_indice COMPUTE STATISTICS

Esempio:

ANALYZE INDEX ind_deptno COMPUTE STATISTICS;

29

Dicembre 2002

 

6. Visualizzazione del piano di esecuzione

Interrogazione della tabella plan table

 

26

 

Creazione di indici

CREATE INDEX nome_indice ON nome_tabella(nome_campo)

 

Esempio:

CREATE INDEX ind_deptno ON emp(deptno);

 
 

28

 

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

 

30

Ottimizzatore di Oracle

 

Definizione di un hint

SELECT /*+ hint eventuali_commenti */

 
 

Esempio:

SELECT /*+ FULL(e) Uso di hint*/ ename from emp e where job=‘clerk’;

   
 

31

 

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)

 

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

 

Utilizzando l’hint ORDERED, le tabelle compaiono nel join nell’ordine specificato nella clausola FROM.

 

ORDERED

 
 

Esempio:

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;

35

Dicembre 2002

Hint per access path: FULL

L’hint FULL forza un accesso di tipo full table scan sulla tabella specificata

FULL( nome tabella)

FULL(alias tabella)

Esempio:

SELECT /*+ FULL(e) */ empno from emp e where empno < 7500;

32

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

34

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)

36

Ottimizzatore di Oracle

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 l’hash join nei join in cui è coinvolta la tabella.

USE_HASH (nome tabella)

USE_HASH (alias tabella)

37

Dicembre 2002

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’;

38