SQL.RU
 client/server technologies
Peoplemind  
 Главная | Документация | Статьи | Книги | Форум | Опросы | Рассылка | Работа | Поиск | FAQ |

Добро пожаловать в форум, Guest  >>  Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик  Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Есть запрос. В условии where используются bind переменные. Условие следующее:

WHERE p_post.ip_postid BETWEEN :pisbrange AND :piebrange

выполняю запрос в TOAD, при вводе значений bind переменных задаю их тип (Integer), запрос выполняется 30 сек, если тип переменных string запрос выполняется 100 миллисекунд.

План естественно один и тот же (поскольку текст самого запроса не меняется)

p_post.ip_postid - NUMBER, PRIMARY KEY

Oracle 9.1.0.1

Что за эффект, кто-нить сталкивался с чем-нить подобным?
Кстати, на аналогичном серваке с другим железом (Oracle настроен аналогично, данные пратически совпадаюь), этот же запрос работает одинаково быстро вне зависимости от типа bind-переменной
21 апр 04, 14:46    [640765] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Scott Tiger
Member

Откуда: Солнышко
Сообщений: 6074
План запросов сравни.
21 апр 04, 14:56    [640814] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Планы совпадают (текст запроса не меняется, в БД изменений не выполняется, статистика между выполнениями не собиралась ;) )

Кароче запрос один и тот же, план один и тот же, значения переменных одни и те же, только в одном случае тип переменных string, а в другом Integer
21 апр 04, 15:06    [640847] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Scott Tiger
Member

Откуда: Солнышко
Сообщений: 6074
Трассу этой сессии посмотри, в чём различаются отправляемые запросы.
21 апр 04, 15:09    [640860] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Да, действительно, в трассе планы различаются...

Но почему? Исходный текст ведь один и тот же.
21 апр 04, 15:22    [640929] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Oracle newbie
Member

Откуда:
Сообщений: 1008
Ну раз планы ты не хочешь показывать, то давай статистику
SQL> set timing on
SQL> set autot trace stat
SQL> /

и трассировку все равно включи.
иногда были случаи когда explain plan показывал одно, а реально запрос выполнялся по другому .
21 апр 04, 15:22    [640933] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Это когда bind переменные типа Integer


SELECT p_post.ROWID aaa, p_post.*,
DECODE (p_post.bissummdone, 'T', 'Да', 'Нет') sb_done,
klient.vcklientname, kte.icurrencyid iklientcurrid,
currklient.vcbriefname
vcklientcurrname,
currpay.vcbriefname vcpaycurrname, clapaytype.vcname vcpaytype,
clapaytype.ipriznak
ipaytypepriznak, clapaynota.vcname vcpaynota,
users.vcfirstname
vcfio, tip_opr.vcname vctipopr,
tip_opr.ikod_type itipoprtype, tip_opr.ipriznak itipoprpriznak,
pck_plp.maintpoplsid (p_post.itip_oprid, 1, p_post.dtofor, 2)
iplsid
FROM ve_p_post p_post,
klient,
users,
classif clapaytype,
classif clapaynota,
tip_opr,
currency currpay,
currency currklient,
(SELECT *
FROM klienttypeext
WHERE klienttypeext.iuselid = :piuselid
AND klienttypeext.ikod_type = :pipostkod_type) kte
WHERE p_post.ip_postid BETWEEN :pisbrange AND :piebrange
AND p_post.iklientid = klient.iklientid
AND p_post.iusersid_enter = users.iusersid
AND p_post.ikod_paytype = clapaytype.ikod
AND p_post.icti_paytype = clapaytype.iclassiftypeid
AND p_post.ikod_nfwhat = clapaynota.ikod
AND p_post.icti_nfwhat = clapaynota.iclassiftypeid
AND p_post.itip_oprid = tip_opr.itip_oprid
AND p_post.icurrencyid_pay = currpay.icurrencyid
AND p_post.iklientid = kte.iklientid
AND kte.icurrencyid = currklient.icurrencyid
AND (p_post.bisarchive = :isarchive OR 'T' = :ignorearchivflag)
AND (p_post.inumber >= 33000 AND p_post.inumber <= 55000)
ORDER BY inumber

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 61.42 61.49 0 64102 0 50
------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 6 61.42 61.49 0 64102 0 50

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 77

Rows Row Source Operation
------- ---------------------------------------------------

25 SORT ORDER BY
44 FILTER
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
516 TABLE ACCESS BY INDEX ROWID KLIENTTYPEEXT
516 INDEX RANGE SCAN IEKLIENTTYPEEXT_USELTYPE (object id 83290)
44 TABLE ACCESS BY INDEX ROWID P_POST
33692 BITMAP CONVERSION TO ROWIDS
278 BITMAP AND
278 BITMAP CONVERSION FROM ROWIDS
67381 INDEX RANGE SCAN FKP_POST_KLIENT (object id 83470)
278 BITMAP CONVERSION FROM ROWIDS >9366376 SORT ORDER BY >9366376 INDEX RANGE SCAN PKP_POST (object id 83471)
44 TABLE ACCESS BY INDEX ROWID CLASSIF
44 INDEX UNIQUE SCAN PKCLASSIF (object id 83045)
44 TABLE ACCESS BY INDEX ROWID CLASSIF
44 INDEX UNIQUE SCAN PKCLASSIF (object id 83045)
44 TABLE ACCESS BY INDEX ROWID TIP_OPR
44 INDEX UNIQUE SCAN PKTIP_OPR (object id 83736)
44 TABLE ACCESS BY INDEX ROWID USERS
44 INDEX UNIQUE SCAN PKUSERS (object id 83808)
44 TABLE ACCESS BY INDEX ROWID KLIENT
44 INDEX UNIQUE SCAN PKKLIENT (object id 83272)
44 TABLE ACCESS BY INDEX ROWID CURRENCY
44 INDEX UNIQUE SCAN PKCURRENCY (object id 83067)
44 TABLE ACCESS BY INDEX ROWID CURRENCY
44 INDEX UNIQUE SCAN PKCURRENCY (object id 83067)

********************************************************************************



А это когда bind переменные типа string



SELECT p_post.ROWID aaa, p_post.*,
DECODE (p_post.bissummdone, 'T', 'Да', 'Нет') sb_done,
klient.vcklientname, kte.icurrencyid iklientcurrid,
currklient.vcbriefname
vcklientcurrname,
currpay.vcbriefname vcpaycurrname, clapaytype.vcname vcpaytype,
clapaytype.ipriznak
ipaytypepriznak, clapaynota.vcname vcpaynota,
users.vcfirstname
vcfio, tip_opr.vcname vctipopr,
tip_opr.ikod_type itipoprtype, tip_opr.ipriznak itipoprpriznak,
pck_plp.maintpoplsid (p_post.itip_oprid, 1, p_post.dtofor, 2)
iplsid
FROM ve_p_post p_post,
klient,
users,
classif clapaytype,
classif clapaynota,
tip_opr,
currency currpay,
currency currklient,
(SELECT *
FROM klienttypeext
WHERE klienttypeext.iuselid = :piuselid
AND klienttypeext.ikod_type = :pipostkod_type) kte
WHERE p_post.ip_postid BETWEEN :pisbrange AND :piebrange
AND p_post.iklientid = klient.iklientid
AND p_post.iusersid_enter = users.iusersid
AND p_post.ikod_paytype = clapaytype.ikod
AND p_post.icti_paytype = clapaytype.iclassiftypeid
AND p_post.ikod_nfwhat = clapaynota.ikod
AND p_post.icti_nfwhat = clapaynota.iclassiftypeid
AND p_post.itip_oprid = tip_opr.itip_oprid
AND p_post.icurrencyid_pay = currpay.icurrencyid
AND p_post.iklientid = kte.iklientid
AND kte.icurrencyid = currklient.icurrencyid
AND (p_post.bisarchive = :isarchive OR 'T' = :ignorearchivflag)
AND (p_post.inumber >= 33000 AND p_post.inumber <= 55000)
ORDER BY inumber

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 9 0.00 0.00 0 0 0 0
Execute 9 0.00 0.00 0 0 0 0
Fetch 9 0.56 0.53 0 44370 0 225
------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 27 0.56 0.54 0 44370 0 225

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 77

Rows Row Source Operation
------- ---------------------------------------------------

25 SORT ORDER BY
44 FILTER
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 NESTED LOOPS
44 HASH JOIN
5 TABLE ACCESS BY INDEX ROWID CLASSIF
5 INDEX RANGE SCAN FKCLASSIF_CLASSIFTYPE (object id 83046)
44 TABLE ACCESS BY INDEX ROWID P_POST
33692 INDEX RANGE SCAN PKP_POST (object id 83471)
44 TABLE ACCESS BY INDEX ROWID KLIENTTYPEEXT
44 INDEX UNIQUE SCAN AKKLIENTTYPEEXT_TYPE (object id 87920)
44 TABLE ACCESS BY INDEX ROWID CLASSIF
44 INDEX UNIQUE SCAN PKCLASSIF (object id 83045)
44 TABLE ACCESS BY INDEX ROWID TIP_OPR
44 INDEX UNIQUE SCAN PKTIP_OPR (object id 83736)
44 TABLE ACCESS BY INDEX ROWID USERS
44 INDEX UNIQUE SCAN PKUSERS (object id 83808)
44 TABLE ACCESS BY INDEX ROWID KLIENT
44 INDEX UNIQUE SCAN PKKLIENT (object id 83272)
44 TABLE ACCESS BY INDEX ROWID CURRENCY
44 INDEX UNIQUE SCAN PKCURRENCY (object id 83067)
44 TABLE ACCESS BY INDEX ROWID CURRENCY
44 INDEX UNIQUE SCAN PKCURRENCY (object id 83067)

********************************************************************************



Объясните, почему так происходит
21 апр 04, 15:29    [640966] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
stdio
Member

Откуда: 100 км. от точки сингулярности
Сообщений: 4052
Потому что во втором случае гистограмма используется.
_______________
Alex
There are three kinds of people: those who can count and those who can't
21 апр 04, 15:35    [641000] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Не понял про гистограмму, где это видно?
21 апр 04, 15:38    [641011] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
stdio
Member

Откуда: 100 км. от точки сингулярности
Сообщений: 4052
Если есть металинк, то на Note:1031826.6
_______________
Alex
There are three kinds of people: those who can count and those who can't
21 апр 04, 15:48    [641046] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
stdio
Member

Откуда: 100 км. от точки сингулярности
Сообщений: 4052
На плане это не видно, разумеется. Просто оптимизатор, видя конкретные числа может очень точно узнать селективность выборки и принять решение о применении/непримении индекса.
_______________
Alex
There are three kinds of people: those who can count and those who can't
21 апр 04, 15:50    [641061] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Металинка нет.

То, что ты описал про гистограммы - это понятно. Но ведь у меня нет конкретных чисел. Я использую bind переменные. Значения для них задаю одинаковые (ТИПЫ разные).

Выходит, что реальный план запроса строится уже после определения переменных.

Где в доке про это написано? Ткните носом, плз
21 апр 04, 15:58    [641091] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Oracle newbie
Member

Откуда:
Сообщений: 1008
какие такие гистограммы когда используется RBO?
21 апр 04, 16:01    [641107] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
А где видно, что RBO

там же написано CHOOSE, статистика есть, значит все-таки CBO
21 апр 04, 16:07    [641134] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Oracle newbie
Member

Откуда:
Сообщений: 1008
CHOOSE это значит CHOOSE
Значит выбрать между RBO и CBO в зависимости от условий.
21 апр 04, 16:09    [641147] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
stdio
Member

Откуда: 100 км. от точки сингулярности
Сообщений: 4052
То, что ты описал про гистограммы - это понятно. Но ведь у меня нет конкретных чисел. Я использую bind переменные. Значения для них задаю одинаковые (ТИПЫ разные).

Выходит, что реальный план запроса строится уже после определения переменных.

Оп. Невнимательно посмотрел на запросы. Смотрю внимательно.
_______________
Alex
There are three kinds of people: those who can count and those who can't
21 апр 04, 16:10    [641155] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Oracle newbie
Member

Откуда:
Сообщений: 1008
а видно это из вашего плана. Стоимостей нет? Кардиналитей нет?
=====> RBO
21 апр 04, 16:10    [641157] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
В трейс файле стоимость и не отображается вроде. Если из sql plusа план смотреть, то стоимость есть и кардиналити тоже.
21 апр 04, 16:15    [641175] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Вот из доки выжимка по поводу CHOOSE

CHOOSE
The optimizer chooses between a cost-based approach and a rule-based approach, depending on whether statistics are available. This is the default value.

If the data dictionary contains statistics for at least one of the accessed tables, then the optimizer uses a cost-based approach and optimizes with a goal of best throughput.
If the data dictionary contains only some statistics, then the cost-based approach is still used, but the optimizer must guess the statistics for the subjects without any statistics. This can result in suboptimal execution plans.
If the data dictionary contains no statistics for any of the accessed tables, then the optimizer uses a rule-based approach
21 апр 04, 16:20    [641205] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
Нашел причину такого странного поведения CBO в доке:

Peeking of User-Defined Bind Variables
The CBO peeks at the values of user-defined bind variables on the first invocation of a cursor. This feature lets the optimizer determine the selectivity of any WHERE clause condition, as well as if literals have been used instead of bind variables. On subsequent invocations of the cursor, no peeking takes place, and the cursor is shared, based on the standard cursor-sharing criteria, even if subsequent invocations use different bind values.

То есть все-таки значения (и соответственно тип) bind перменных используются при построении плана.
21 апр 04, 17:03    [641422] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
stdio
Member

Откуда: 100 км. от точки сингулярности
Сообщений: 4052
Вот оно и получается: оптимизатор рассматривает выполняемые запросы как _разные_ из-за того, что переменные привязки имеют разные типы, при первом запросе с Integer-ом были подсунуты "хорошие" значения, с String-ом переменные оказались не такие удачные...
Что остаётся делать:
1) Использовать to_number с переменными привязки для определённости
2) Либо отключать эту возможность, либо через login-триггер выставлять "правильные" значения.
_______________
Alex
There are three kinds of people: those who can count and those who can't
21 апр 04, 17:17    [641509] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Oracle newbie
Member

Откуда:
Сообщений: 1008
Jajahama
В трейс файле стоимость и не отображается вроде. Если из sql plusа план смотреть, то стоимость есть и кардиналити тоже.

Дык.Лажанулся...
21 апр 04, 17:23    [641535] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
2 stdio

Наоборот, при использовании стрингов получается хороший план. Вот в этом и залепень. У нас вся контора на ушах ;) Надо пожалуй идти домой.

Кроме того, если использовать вместо переменных константы в запросе (как целые так и стринговые), то все работает жутко медленно
21 апр 04, 17:31    [641573] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 4773
The key here, I believe, is in BITMAP CONVERSION FROM ROWIDS. This tells me you either have bitmap indexes or B_TREE_BITMAP_PLANS or _B_TREE_BITMAP_PLANS is set in init.ora. And it appears that bitmap index (or bitmap conversion from rowid) and NESTED LOOP is slower than regular index and HASH JOIN. When bind valiable is a string, it implies string to number conversion. As a result optimizer decides not to use bitmap and it ends up being faster. So check for bitmap indexes and/or (_)B_TREE_BITMAP_PLANS and see if it was a right decision.

SY.
P.S. B_TREE_BITMAP_PLANS = TRUE allows optimizer to produce bitmap plans for B-Tree indexes even if there is no bitmap index.
22 апр 04, 02:52    [642197] Ответить | Цитировать    Сообщить модератору

 Re: Bind variable effect   [new]
Jajahama
Member

Откуда: Москва
Сообщений: 247
B_TREE_BITMAP_PLANS - устаревший параметр для 9-ки. Его изменение результатов не дало.
22 апр 04, 12:34    [643048] Ответить | Цитировать    Сообщить модератору

Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить
Rambler's Top100 Powered by ActualForum 1.5.2 Copyright (c) Alex Sibilev 2000-2010