close

Вход

Забыли?

вход по аккаунту

?

Презентация

код для вставкиСкачать
Борчук Леонид
Стратегия настройки SQL запросов.
Новые возможности на основе пакета
dbms_sqltune
Задача: Уменьшить время ответа
2
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Методы решения задачи настройки
Модель времени ответа в системе с разделением ресурсов:
Время ответа = Время обработки + Время ожидания
100% = 75%
+ 25%
Локальные
Глобальные
Уменьшить количество
итераций при выполнении
запроса или количество затрат
ресурсов за счет изменения
способа обработки
Уменьшить затраты ресурсов в разы
Частота и количество
процессоров
Размер буфера
Скорость дисковой
подсистемы
Увеличение не более 10%
3
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Проблемы локальных методов настройки
По классификации К. Миллсапа:
Методы настройки
Метод R
Метод “Время ответа”
Метод C
Метод гипотез
Как строить временную
диаграмму, если отчет
выполняется 5 суток?
Зачем строить диаграмму, если
проблемный запрос итак ясен?
Что делать с 25%
неизмеренного времени?
4
Как правильно выбрать метрику
для настройки?
Когда следует прекратить
настройку по метрике?
Как оценить результаты
настройки?
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. Метрика время выполнения
SELECT /*+ INDEX(arc_portfolio
ARC_PRT_FINE_IN_CNT_IDX) */
*
FROM arc_portfolio
WHERE prt_fine_in_vir = '0005.00'
AND prt_fine_res_vir = '0005.00'
SELECT /*+ INDEX(arc_portfolio
ARC_PRT_FINE_RES_CNT_IDX) */
*
FROM arc_portfolio
WHERE prt_fine_in_vir = '0005.00'
AND prt_fine_res_vir = '0005.00'
------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Cost (%CPU)|
------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
| 17215 |
354
(2)|
|* 1 | TABLE ACCESS BY INDEX ROWID| ARC_PORTFOLIO
| 17215 |
354
(2)|
|* 2 |
INDEX SKIP SCAN
| ARC_PRT_FINE_IN_CNT_IDX |
622 |
30
(0)|
------------------------------------------------------------------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Cost (%CPU)|
------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
| 17215 |
459
(2)|
|* 1 | TABLE ACCESS BY INDEX ROWID| ARC_PORTFOLIO
| 17215 |
459
(2)|
|* 2 |
INDEX FULL SCAN
| ARC_PRT_FINE_RES_CNT_IDX |
469 |
7
(0)|
-------------------------------------------------------------------------------------
Elapsed: 00:00:00.04
421 consistent gets
Elapsed: 00:00:00.04
467 consistent gets
1. Какой из вариантов запроса использовать, если их время выполнения одинаково?
2. Как не учитывать время ожидания на исполнение?
5
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. Стоимость
SELECT
FROM
WHERE
AND
AND
AND
a.*,fin_system.get_value (dpt_bonus, 'dpr_type') AS prt_dpr_type
arc_portfolio a, dic_portfolio_type
prt_dt_buh <= fin_system.get_buh_date
prt_dt_next > fin_system.get_buh_date
prt_dpt_id = dpt_id
prt_deleted = 0
--------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
2 | 538 |
73 (16)| 00:00:01 |
|
1 | NESTED LOOPS
|
|
2 |
538 |
73 (16)| 00:00:01 |
|* 2 |
TABLE ACCESS FULL
| ARC_PORTFOLIO
|
2 |
426 |
71 (16)| 00:00:01 |
|
3 |
TABLE ACCESS BY INDEX ROWID| DIC_PORTFOLIO_TYPE |
1 |
56 |
1
(0)| 00:00:01 |
|* 4 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
0
(0)| 00:00:01 |
---------------------------------------------------------------------------------------------------
Rows
Row Source Operation
160 NESTED LOOPS (cr=281 pr=35 pw=0 time=0.0399s)
160 TABLE ACCESS FULL ARC_PORTFOLIO (cr=109 pr=31 pw=0 time=0.0378s)
160 TABLE ACCESS BY INDEX ROWID DIC_PORTFOLIO_TYPE (cr=172 pr=4 pw=0 time=0.0018s)
160
INDEX UNIQUE SCAN DPT_ID (cr=12 pr=0 pw=0 time=0.0006s)
6
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Стратегия
Неоднозначности
Метрики
Способы настройки
Методы оценки
результатов
Универсального
метода настройки
не существует
Стратегия настройки – общий, недетализированный план
настройки, охватывающий длительный период времени, способ
достижения сложной цели, являющейся неопределённой и в
дальнейшем корректируемой под изменившиеся условия.
7
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Проблемы стратегий настройки
Проблема: В
большинстве случаев стратегия настройки
определена неявно, в результате в процессе настройки происходит
подмена цели.
Примеры:
Метод “время ответа”: Цель - построить временную диаграмму. Средство
– трассировка 10046. Недостатки – требует полного выполнения
операции, занимает большие объемы данных, содержит ошибки
измерения.
Настройка на основе правил: Цель – добиться красивого плана
выполнения. Средство – избавиться от полного сканирования таблиц,
hash и merge join.
Настройка на основе метрик. Цель – минимизировать количество
логических чтений. Средство – анализ статистики выполнения.
8
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Стратегия локальной настройки
Частная задача – настройка плана выполнения запроса.
Стратегия:
Локальная цель – получить любой план выполнения запроса,
отвечающий требованиям производительности.
Средство – добиться адекватности оценок стоимостного
оптимизатора.
Получить требуемое время выполнения не всегда возможно.
Адекватные оценки – необходимое условие выбора
оптимального способа выполнения.
Преимущества предлагаемой стратегии – минимизация
времени выполнения настройки.
Wolfgang Breitling SQL Tuning with Statistics
9
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
План действий локальной настройки
Определить текущий план выполнения
Получить актуальную статистику плана выполнения
Определить момент возникновения ошибки оценки
Определить предикаты, вызывающие неправильную оценку
Исправить статистику
10
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. История изменений
SELECT * FROM curr_portfolio
SELECT a.*,fin_system.get_value (dpt_bonus,
'dpr_type') AS prt_dpr_type
FROM arc_portfolio a, dic_portfolio_type
WHERE
prt_dt_buh <= fin_system.get_buh_date
AND prt_dt_next > fin_system.get_buh_date
AND prt_dpt_id = dpt_id
AND prt_deleted = 0
11
-------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
409 | 10510 (29)|
|
1 | SORT ORDER BY
|
|
1 |
409 | 10510 (29)|
|
2 |
NESTED LOOPS
|
|
1 |
409 | 10509 (29)|
|
3 |
NESTED LOOPS OUTER
|
|
1 |
375 | 10508 (29)|
|
4 |
NESTED LOOPS
|
|
1 |
330 | 10507 (29)|
|
5 |
VIEW
|
|
1 |
290 |
|
|* 6 |
FILTER
|
|
|
|
|
|
7 |
SORT GROUP BY
|
|
1 |
367 | 10506 (29)|
|
8 |
NESTED LOOPS
|
|
1 |
367 | 10505 (29)|
|
9 |
NESTED LOOPS
|
|
1 |
326 | 10505 (29)|
| 10 |
NESTED LOOPS
|
|
1 |
293 | 10502 (29)|
| 11 |
VIEW
|
|
4 | 1008 |
|
| 12 |
UNION-ALL
|
|
|
|
|
| 13 |
SORT UNIQUE
|
|
4 |
844 | 10504 (82)|
| 14 |
UNION-ALL
|
|
|
|
|
|* 15 |
TABLE ACCESS BY INDEX ROWID
| ARC_COUNT1
|
1 |
41 |
4 (25)|
| 16 |
NESTED LOOPS
|
|
1 |
271 | 2632 (29)|
| 17 |
NESTED LOOPS
|
|
1 |
230 | 2629 (29)|
| 18 |
NESTED LOOPS
|
|
1 |
171 | 2626 (29)|
| 19 |
NESTED LOOPS
|
|
1 |
138 | 2624 (29)|
|* 20 |
HASH JOIN
|
|
1 |
98 | 2623 (29)|
|* 21 |
TABLE ACCESS BY INDEX ROWID| ARC_CREDIT
|
1 |
22 |
4 (25)|
| 22 |
NESTED LOOPS
|
|
21 | 1029 | 2606 (29)|
|* 23 |
TABLE ACCESS FULL
| ARC_CONTRACT
|
20 |
540 | 2544 (29)|
|* 24 |
INDEX RANGE SCAN
| ARC_CRE_STATE_NEXT2
|
1 |
|
3 (34)|
|* 25 |
TABLE ACCESS FULL
| ARC_PORTFOLIO
|
1 |
49 |
17 (48)|
| 26 |
TABLE ACCESS BY INDEX ROWID | DIC_PORTFOLIO_TYPE
|
1 |
40 |
2 (50)|
|* 27 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
|
|* 28 |
INDEX RANGE SCAN
| DAT_CREDITCOUNTS_PRI |
1 |
33 |
3 (34)|
|* 29 |
TABLE ACCESS BY INDEX ROWID
| ARC_COUNT3
|
1 |
59 |
4 (25)|
|* 30 |
INDEX RANGE SCAN
| ARC_CN3_CNT_NUM
|
1 |
|
3 (34)|
|* 31 |
INDEX RANGE SCAN
| ARC_CN1_CNT_NUM
|
1 |
|
3 (34)|
|* 32 |
TABLE ACCESS BY INDEX ROWID
| ARC_COUNT1
|
1 |
41 |
4 (25)|
| 33 |
NESTED LOOPS
|
|
1 |
184 | 2620 (28)|
| 34 |
NESTED LOOPS
|
|
1 |
143 | 2617 (29)|
| 35 |
NESTED LOOPS
|
|
1 |
103 | 2616 (29)|
| 36 |
NESTED LOOPS
|
|
5 |
270 | 2606 (29)|
|* 37 |
TABLE ACCESS FULL
| ARC_CONTRACT
|
20 |
540 | 2544 (29)|
|* 38 |
TABLE ACCESS BY INDEX ROWID | ARC_CREDIT
|
1 |
27 |
4 (25)|
|* 39 |
INDEX RANGE SCAN
| ARC_CRE_STATE_NEXT2
|
1 |
|
3 (34)|
|* 40 |
TABLE ACCESS BY INDEX ROWID | ARC_PORTFOLIO
|
1 |
49 |
3 (34)|
|* 41 |
INDEX RANGE SCAN
| ARC_PRT_ID
|
1 |
|
2 (50)|
| 42 |
TABLE ACCESS BY INDEX ROWID
| DIC_PORTFOLIO_TYPE
|
1 |
40 |
2 (50)|
|* 43 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
|
|* 44 |
INDEX RANGE SCAN
| ARC_CN1_CNT_NUM
|
1 |
|
3 (34)|
|* 45 |
TABLE ACCESS BY INDEX ROWID
| ARC_COUNT1
|
1 |
41 |
4 (25)|
| 46 |
NESTED LOOPS
|
|
1 |
199 | 2626 (29)|
| 47 |
NESTED LOOPS
|
|
1 |
158 | 2623 (29)|
| 48 |
MERGE JOIN CARTESIAN
|
|
20 | 2360 | 2561 (29)|
| 49 |
NESTED LOOPS
|
|
1 |
91 |
18 (45)|
|* 50 |
TABLE ACCESS FULL
| ARC_PORTFOLIO
|
1 |
51 |
17 (48)|
| 51 |
TABLE ACCESS BY INDEX ROWID
| DIC_PORTFOLIO_TYPE
|
1 |
40 |
2 (50)|
|* 52 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
|
| 53 |
BUFFER SORT
|
|
20 |
540 | 2559 (29)|
|* 54 |
TABLE ACCESS FULL
| ARC_CONTRACT
|
20 |
540 | 2544 (29)|
|* 55 |
TABLE ACCESS BY INDEX ROWID
| ARC_CREDIT
|
1 |
40 |
4 (25)|
|* 56 |
INDEX RANGE SCAN
| ARC_CRE_STATE_NEXT2
|
1 |
|
3 (34)|
|* 57 |
INDEX RANGE SCAN
| ARC_CN1_CNT_NUM
|
1 |
|
3 (34)|
|* 58 |
TABLE ACCESS BY INDEX ROWID
| ARC_COUNT1
|
1 |
41 |
4 (25)|
| 59 |
NESTED LOOPS
|
|
1 |
190 | 2626 (29)|
| 60 |
NESTED LOOPS
|
|
1 |
149 | 2623 (29)|
| 61 |
MERGE JOIN CARTESIAN
|
|
20 | 2300 | 2561 (29)|
| 62 |
NESTED LOOPS
|
|
1 |
88 |
18 (45)|
|* 63 |
TABLE ACCESS FULL
| ARC_PORTFOLIO
|
1 |
48 |
17 (48)|
| 64 |
TABLE ACCESS BY INDEX ROWID
| DIC_PORTFOLIO_TYPE
|
1 |
40 |
2 (50)|
|* 65 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
|
| 66 |
BUFFER SORT
|
|
20 |
540 | 2559 (29)|
|* 67 |
TABLE ACCESS FULL
| ARC_CONTRACT
|
20 |
540 | 2544 (29)|
|* 68 |
TABLE ACCESS BY INDEX ROWID
| ARC_CREDIT
|
1 |
34 |
4 (25)|
|* 69 |
INDEX RANGE SCAN
| ARC_CRE_STATE_NEXT2
|
1 |
|
3 (34)|
|* 70 |
INDEX RANGE SCAN
| ARC_CN1_CNT_NUM
|
1 |
|
3 (34)|
| 71 |
TABLE ACCESS BY INDEX ROWID
| TMP_COUNT_SD
|
1 |
41 |
|
|* 72 |
INDEX RANGE SCAN
| TCS_CNT_NUM
|
1 |
|
|
|* 73 |
TABLE ACCESS BY INDEX ROWID
| ACC_COUNT
|
1 |
33 |
4 (25)|
|* 74 |
INDEX RANGE SCAN
| CNT_NUM
|
1 |
|
3 (34)|
| 75 |
TABLE ACCESS BY INDEX ROWID
| TMP_COUNT_SD
|
1 |
41 |
|
|* 76 |
INDEX RANGE SCAN
| TCS_CNT_NUM
|
1 |
|
|
| 77 |
TABLE ACCESS BY INDEX ROWID
| DIC_PORTFOLIO_TYPE
|
1 |
40 |
2 (50)|
|* 78 |
INDEX UNIQUE SCAN
| DPT_ID
|
1 |
|
|
| 79 |
TABLE ACCESS BY INDEX ROWID
| DIC_RES_COUNTS
|
1 |
45 |
2 (50)|
|* 80 |
INDEX UNIQUE SCAN
| DRC_ID
|
1 |
|
|
| 81 |
TABLE ACCESS BY INDEX ROWID
| DIC_DEPARTMENTS
|
1 |
34 |
2 (50)|
|* 82 |
INDEX UNIQUE SCAN
| DEP_ID
|
1 |
|
|
--------------------------------------------------------------------------------------------------------------
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. Представление с версионностью
SELECT * FROM curr_portfolio
Соотношение
Строк
Оценка
Операция
80
160
2 SELECT STATEMENT
80
160
2
80
160
2
TABLE ACCESS FULL
160
160
1
TABLE ACCESS BY INDEX ROWID DIC_PORTFOLIO_TYPE
160
160
1
NESTED LOOPS
INDEX UNIQUE SCAN
ARC_PORTFOLIO
DPT_ID
PRT_DELETED=0 AND PRT_DT_BUH<=FIN_SYSTEM.GET_BUH_DATE() AND PRT_DT_NEXT>FIN_SYSTEM.GET_BUH_DATE()
Предикат
Селективность
PRT_DT_BUH
0,0500
PRT_DT_NEXT
0,0500
PRT_DELETED
0,9764
12
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. Настройка представления
SELECT * FROM v$sql WHERE UPPER (sql_text) LIKE '%CURR_PORTFOLIO%';
variable stmt_task VARCHAR2(64);
EXEC :stmt_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id =>'94j7a7adr62jd');
EXEC DBMS_SQLTUNE.EXECUTE_TUNING_TASK(:stmt_task);
EXEC DBMS_SQLTUNE.ACCEPT_SQL_PROFILE(:stmt_task);
Operation
Name
SELECT STATEMENT
MERGE JOIN
TABLE ACCESS BY INDEX ROWID DIC_PORTFOLIO_TYPE
INDEX FULL SCAN
DPT_ID
SORT JOIN
TABLE ACCESS FULL
ARC_PORTFOLIO
Rows
Cost
160
160
14
14
160
160
80
80
8
1
72
71
Note
- SQL profile "SYS_SQLPROF_01492e8d033f0001" used for this statement
13
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
SQL Profile
Tom Kyte
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6131308
6268493
Jonathan Lewis
http://jonathanlewis.wordpress.com/2007/02/11/profiles/
Wolfgang Breitling
http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf
Christian Antognini
http://antognini.ch/papers/SQLProfiles_20060622.pdf
Деев Илья
http://www.ruoug.org/library/2/index.html
14
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Уточнение статистики по таблице
OPT_ESTIMATE(@"SEL$F5BB74E1", TABLE, "A"@"SEL$2",
SCALE_ROWS=70.09857612)
Table: ARC_PORTFOLIO Alias: A
Card: Original: 934 >> Single Tab Card adjusted from: 2.28 to: 160.00
Rounded: 160 Computed: 160.00 Non Adjusted: 2.28
EXEC DBMS_STATS.SET_TABLE_STATS(ownname=>'ABSMAIN',tabname =>
'ARC_PORTFOLIO', numrows => 18000);
Operation
SELECT STATEMENT
HASH JOIN
TABLE ACCESS FULL
TABLE ACCESS FULL
15
Name
DIC_PORTFOLIO_TYPE
ARC_PORTFOLIO
Rows
Cost
3084
3084
14
3084
267
267
15
251
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Уточнение статистики по соединению
OPT_ESTIMATE(@"SEL$40F01EED", JOIN, ("A"@"SEL$3", "A"@"SEL$2"),
SCALE_ROWS=0.2652425153)
Join order[294]: ARC_PORTFOLIO[A]#1 ARC_CREDIT[A]#4
DIC_PORTFOLIO_TYPE[DIC_PORTFOLIO_TYPE]#0 ARC_CONTRACT[T]#2
DAT_CREDITCOUNTS[DAT_CREDITCOUNTS]#5 ARC_COUNT3[A]#3 ARC_COUNT1[A]#6
***************
Now joining: ARC_CREDIT[A]#4
***************
NL Join
Outer table: Card: 161.58 Cost: 70.89 Resp: 70.89 Degree: 1 Bytes: 57
Inner table: ARC_CREDIT Alias: A
Join Card: 63089.65 = outer (161.58) * inner (20836.88) * sel (0.018739)
>> Join Card adjusted from 63089.65 to: 16734.06, prelen=2
Adjusted Join Cards: adjRatio=0.27 cardHjSmj=16734.06 cardHjSmjNPF=16734.06
cardNlj=16734.06 cardNSQ=16734.06 cardNSQ_na=63089.65
Join Card - Rounded: 16734 Computed: 16734.06
16
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Другие способы уточнения статистики
Уточнение статистики по индексу:
OPT_ESTIMATE(<Query Block>, INDEX_FILTER, <table>, <index>,
SCALE_ROWS=<number>)
Уточнение отсутствующей или устаревшей статистики по объектам :
TABLE_STATS(<owner.table>, scale, blocks=405 rows=6116)
COLUMN_STATS(<owner.table>, <column>, scale, length=8)
INDEX_STATS(<owner.table>, <index>, scale, blocks=56
index_rows=6116)
17
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Принцип бритвы Оккама
Бритва (лезвие) Оккама — методологический принцип. В
упрощенном виде он гласит: «Не следует множить сущее без
необходимости» (либо «Не следует привлекать новые сущности
без самой крайней на то необходимости»).
Когда ученики Платона попросили дать определение человека,
философ сказал: «Человек есть животное о двух ногах, лишённое
перьев». Услышав это, Диоген Синопский поймал петуха, ощипал его и,
принеся в Академию, объявил: «Вот платоновский человек!». После
чего Платон вынужден был добавить к своему определению: «И с
плоскими ногтями».
Аналогично, в профиле должен присутствовать минимальный набор
статистик, используемый для получения адекватных оценок. По мере
необходимости набор статистик следует уточнять.
18
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Модернизация статистик профиля
EXEC DBMS_SQLTUNE.CREATE_STGTAB_SQLPROF
(table_name,schema_name);
EXEC DBMS_SQLTUNE.PACK_STGTAB_SQLPROF (staging_table_name,
staging_schema_owner, profile_name);
EXEC DBMS_SQLTUNE.UNPACK_STGTAB_SQLPROF(replace => TRUE,
staging_table_name, staging_schema_owner);
Operation
Name
SELECT STATEMENT
MERGE JOIN
TABLE ACCESS BY INDEX ROWID DIC_PORTFOLIO_TYPE
INDEX FULL SCAN
DPT_ID
SORT JOIN
TABLE ACCESS FULL
ARC_PORTFOLIO
19
Rows
Cost
114
114
14
14
114
114
80
80
8
1
72
71
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Cost-based transformation
Разбор
грамматики
Эвристическое
преобразование
VLDB Sep 06
Cost-based query transformation in Oracle
http://delivery.acm.org/10.1145/1170000/1164215/p1026ahmed.pdf?key1=1164215&key2=7529733711&coll=&dl=
ACM&CFID=15151515&CFTOKEN=6184618
VLDB 1994
Query Optimization by Predicate Move-Around
http://www.sigmod.org/vldb/conf/1994/P096.PDF
Преобразование,
основанное на
стоимости
Физическая
оптимизация
20
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Query block
SELECT e1.employee_name, j.job_title
FROM employees e1, job_history j
WHERE e1.emp_id = j.emp_id and
j.start_date > '19980101' and
e1.salary >
(SELECT AVG (e2.salary)
FROM employees e2
WHERE e2.dept_id = e1.dept_id)
and e1.dept_id IN
(SELECT dept_id
FROM departments d, locations l
WHERE d.loc_id = l.loc_id and
l.country_id = 'US');
SUBQUERY UNNESTING
DISTINCT VIEW
SELECT e1.employee_name, j.job_title
FROM employees e1, job_history j,
(SELECT DISTINCT dept_id
FROM departments d, locations l
WHERE d.loc_id = l.loc_id and
l.country_id IN ('US')) VD
WHERE e1.emp_id = j.emp_id and
j.start_date > '19980101' and
e1.salary >
(SELECT AVG (e2.salary)
FROM employees e2
WHERE e2.dept_id = e1.dept_id)
and e1.dept_id = VD.dept_id;
21
SELECT e1.employee_name, j.job_title
FROM employees e1, job_history j,
(SELECT AVG(e2.salary) avg_sal, dept_id
FROM employees e2
GROUP BY dept_id) V
WHERE e1.emp_id = j.emp_id and
j.start_date > '19980101' and
e1.dept_id = V.dept_id and
e1.salary > V.avg_sal and
e1.dept_id IN
(SELECT dept_id
FROM departments d, locations l
WHERE d.loc_id = l.loc_id
and l.country_id = 'US');
Состояние
Query blocks
"(0,0)"
Qs1 Qs2 Qo
"(1,0)"
T(Qs1) Qs2 Qo
"(0,1)"
Qs1 T(Qs2) Qo
"(1,1)"
T(Qs1) T(Qs2) Qo
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
QB_NAME
SELECT /*+ QB_NAME(qb) FULL(@qb e) */ employee_id, last_name
FROM employees e
WHERE last_name = 'Smith';
Query block name изменяется при трансформации запроса:
JPPD - join predicate push-down
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
ST - star transformation
22
EVENT 10053:
**************************
Predicate Move-Around (PM)
**************************
PM: Considering predicate move-around in SEL$15 (#0).
Query block (c000000093a75658) before join elimination:
SQL:******* UNPARSED QUERY IS *******
SELECT …
Query block (c000000093a75658) unchanged
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Пример. Запрос 2380507833
Количество строк запроса: 124
Количество шагов плана выполнения до применения
профиля: 82
Количество шагов плана выполнения после применения
профиля: 74
Время выполнения до применения профиля: 14 с
Время выполнения после применения профиля: 8 c
Время построения профиля: 20 мин
Процент адекватных оценок кардинальности: 70%
Количество блоков запроса; 15
Количество хинтов QB_NAME: 6
Количество оставшихся названий Query Block: 1
23
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Резюме
1. Для настройки требуется стратегия.
2. Для задачи настройки плана выполнения конкретного запроса
одна из выигрышных стратегий состоит в обеспечении
адекватности оценок стоимостного оптимизатора.
3. В последнее время появляются новые средства для реализации
стратегии – например, пакет dbms_sqltune.
4. Адекватность оценок стоимостного оптимизатора требуется для
реализации других стратегий.
24
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Вопросы и ответы
?.?.?.
Борчук Леонид
Администратор БД, г. Череповец
le.borchuk@gmail.com
25
RuOUG:Стратегия настройки SQL запросов. 11.11.2009
Документ
Категория
Презентации
Просмотров
5
Размер файла
944 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа