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