Производительность и план запроса

sibrin

Может такое быть, что select, записанный в st05, позже по кнопке Explain показывает не тот же план запроса, что было в момент записи? Может кто замечал, если часто пользовался st05? Это явно не тот случай, когда между двумя этими событиями успела поменяться статистика в БД, потому что ситуация стабильно воспроизводится.

БД = Oracle

ROKO

sibrin написал:

Может такое быть, что select, записанный в st05, позже по кнопке Explain показывает не то, что было в момент записи? Может кто замечал, если часто пользовался st05? Это явно не тот случай, когда между двумя этими событиями успела поменяться статистика в БД, потому что ситуация стабильно воспроизводится.

БД = Oracle

Ради интереса снял трассу запроса. Затем через некоторое время посмотрел и у меня отслаось все без изменения. Oracle 9.2.0.7.0.
А если не секрет, зачем нужна трасса по прошествии времени ? Лично я смотрю трассу сразу и потом забываю......

Zharik

Может хинтами явно подсказать Ораклу как план строить?

dump

а как ты узнал что не то что на самом деле ?

ArmAnn

Период между двумя измерениями большой? Индексы поменяться/добавиться не могли?

slash

мне казалось st05 и план запроса записывает. В принципе, можно проверить - оттрасировать нажатие Explain=)

если запросы в целевые таблицы будут - сто пудово план перестраивается, и может не совпадать с тем, что было.

sibrin

ROKO написал:

А если не секрет, зачем нужна трасса по прошествии времени ? Лично я смотрю трассу сразу и потом забываю......

Так речь идёт о промежутке времени в 5 секунд.

Sergo

А не мог статистику перестроить другой запрос?
Можно посмотреть все обращения к таблице, и соответственно глянуть как и кто к ней обращался

sibrin

slash написал(а):

мне казалось st05 и план запроса записывает. В принципе, можно проверить - оттрасировать нажатие Explain=)

Оттрассировал - лезет в Oracle c EXPLAIN'ом.
Ну это и понятно - в реалтайме как из БД статистику получить? Не сопровождать же каждый SELECT ещё и EXPLAIN'ом.

slash написал(а):

если запросы в целевые таблицы будут - сто пудово план перестраивается, и может не совпадать с тем, что было.

Sergo написал:

А не мог статистику перестроить другой запрос?

Так через 30 сек я снова эксперимент повторяю. Потом ещё через минуту.

Короче говоря, вопрос в том, что может ли БД по команде EXPLAIN одно показать, а когда ей реальный SELECT даётся, то передумать и по-другому отработать, причём стабильно при многократном чередовании EXPLAIN и SELECT в течении короткого времени, так что внешние факторы влиять не должны.

sibrin

Два селекта отличаются на одну строчку.
В тесте оба селекта выполняются быстро.
В продуктиве время исполнения второго в 400 раз больше,
в то время как планы запросов одинаковы.

БД = Oracle
Индекс CDHDR~Z01 = (MANDANT, OBJECTCLAS, UDATE)

Время исполнения 10 мс.:

Code:

select cdhdr~objectid
  into table lt_hdr
  from cdhdr
  inner join konh
     on konh~KNUMH = cdhdr~objectid
    and konh~kvewe = 'A'
    and konh~kappl = 'V'
  where cdhdr~objectclas = 'COND_A'
    AND cdhdr~udate >= '20070401'
    AND cdhdr~udate >= '20070401'.

SELECT STATEMENT ( Estimated Costs = 83 , Estimated #Rows = 395 )

       6 FILTER
       | Filter Predicates
       |
       |-- 5 NESTED LOOPS
           | ( Estim. Costs = 83 , Estim. #Rows = 395 )
           | Estim. CPU-Costs = 866.576 Estim. IO-Costs = 83
           |
           |-- 2 TABLE ACCESS BY INDEX ROWID CDHDR
           |   | ( Estim. Costs = 4 , Estim. #Rows = 395 )
           |   | Estim. CPU-Costs = 187.852 Estim. IO-Costs = 4
           |   | 
           |   |-- 1 INDEX RANGE SCAN CDHDR~Z01
           |         ( Estim. Costs = 3 , Estim. #Rows = 71 )
           |         Search Columns: 3
           |         Estim. CPU-Costs = 181.354 Estim. IO-Costs = 3
           |         Access Predicates = "T_00"."OBJECTCLAS"=:A4 AND "T_00"."UDATE">=:A5
           |         Filter Predicates = "T_00"."UDATE">=:A6 
           | 
           |-- 4 TABLE ACCESS BY INDEX ROWID KONH
               | ( Estim. Costs = 1 , Estim. #Rows = 1 )
               | Estim. CPU-Costs = 1.718 Estim. IO-Costs = 1
               | Filter Predicates
               |
               |-- 3 INDEX UNIQUE SCAN KONH~0
                     ( Estim. Costs = 1 , Estim. #Rows = 1 )
                     Search Columns: 2
                     Estim. CPU-Costs = 220 Estim. IO-Costs = 1
                     Access Predicates Filter Predicates

Время исполнения 3776 мс.:

Code:

select cdhdr~objectid
  into table lt_hdr
  from cdhdr
  inner join konh
     on konh~KNUMH = cdhdr~objectid
    and konh~kvewe = 'A'
    and konh~kappl = 'V'
  where cdhdr~objectclas = 'COND_A'
    AND cdhdr~udate >= '20070401'.

SELECT STATEMENT ( Estimated Costs = 910 , Estimated #Rows = 7.897 )

       6 FILTER
       | Filter Predicates
       | 
       |-- 5 HASH JOIN
           | ( Estim. Costs = 910 , Estim. #Rows = 7.897 )
           | Estim. CPU-Costs = 48.647.828 Estim. IO-Costs = 904
           | Access Predicates
           |  
           |-- 2 TABLE ACCESS BY INDEX ROWID CDHDR
           |   | ( Estim. Costs = 10 , Estim. #Rows = 7.897 )
           |   | Estim. CPU-Costs = 290.863 Estim. IO-Costs = 10
           |   |  
           |   |-- 1 INDEX RANGE SCAN CDHDR~Z01
           |         ( Estim. Costs = 3 , Estim. #Rows = 1.421 )
           |         Search Columns: 3
           |         Estim. CPU-Costs = 167.139 Estim. IO-Costs = 3
           |         Access Predicates = "T_00"."OBJECTCLAS"=:A4 AND "T_00"."UDATE">=:A5
           |         Filter Predicates 
           |  
           |-- 4 TABLE ACCESS BY INDEX ROWID KONH
               | ( Estim. Costs = 898 , Estim. #Rows = 38.091 )
               | Estim. CPU-Costs = 39.109.602 Estim. IO-Costs = 893
               | Filter Predicates
               |  
               |-- 3 INDEX RANGE SCAN KONH~0
                     ( Estim. Costs = 295 , Estim. #Rows = 152.363 )
                     Search Columns: 1
                     Estim. CPU-Costs = 24.777.102 Estim. IO-Costs = 292
                     Access Predicates Filter Predicates

Можно предположить, что при сканировании индекса CDHDR~Z01 условие >= игнорируется.
Понятно, что где-то по этому условию данные всё-таки фильтруются,
но из плана запроса это не видно. Как будто во втором случае сначала идёт
FULL SCAN для cdhdr, потом JOIN, а потом FILTER по дате.
В чём тут прикол?

ArmAnn

Я бы предложил для начала пересобрать статистику для таблиц CDHDR и KONH

Sergo

sibrin написал:

Два селекта отличаются на одну строчку.
В тесте оба селекта выполняются быстро.
В продуктиве время исполнения второго в 400 раз больше,
в то время как планы запросов одинаковы.

Статистики в тесте и в продуктиве разные.
Можно попробовать собрать их по новой и там, и там, и по новой посмотреть.

ROKO

sibrin написал:

Короче говоря, вопрос в том, что может ли БД по команде EXPLAIN одно показать, а когда ей реальный SELECT даётся, то передумать и по-другому отработать, причём стабильно при многократном чередовании EXPLAIN и SELECT в течении короткого времени, так что внешние факторы влиять не должны.

Была такая проблема вот с этим запросом. Вроде и индекс брал такой какой надо, а крутился сволочь 5 минут. Моск ломал неделю. Потом плюнул позвонил базиснику

. Базисник ломал голову ещо один день и затем мне выдал такую фразу: "Когда ты смотришь в ST05 ты видишь одну трассу, но реально когда запрос лезет в БД он лезет совсем по другой трассе. Таковы уж особенности Oracle ". Причем такая вещь наблюдалась только в одном манданте. Базисник поставил какую-то заплатку и жизнь у меня наладилась

.

Sergo

sibrin написал:

...
Короче говоря, вопрос в том, что может ли БД по команде EXPLAIN одно показать, а когда ей реальный SELECT даётся, то передумать и по-другому отработать, причём стабильно при многократном чередовании EXPLAIN и SELECT в течении короткого времени, так что внешние факторы влиять не должны.

Таблица то CDHDR глобальная, так что на нее в продуктиве могут влиять внешние факторы, а в тесте как раз никто если к ней не обращается, план и не перестраивается.

sibrin

ArmAnn написал:

Я бы предложил для начала пересобрать статистику для таблиц CDHDR и KONH

Sergo написал:

Статистики в тесте и в продуктиве разные.
Можно попробовать собрать их по новой и там, и там, и по новой посмотреть.

Да пересобирал, конечно. Инвариантно.

ROKO написал:

"Когда ты смотришь в ST05 ты видишь одну трассу, но реально когда запрос лезет в БД он лезет совсем по другой трассе. Таковы уж особенности Oracle ".

Спасибо! Вопрос был как раз про это.

Правила форума

Производительность и план запроса

Кто сейчас на конференции