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

Откуда:
Сообщений: 55
HP-UX 11.31 IA
Oracle 10.2.0.5

Постоянно слетают планы запросов в которых участвуют темповые таблицы.
У некоторых запросов по 50 планов!! Хинты с самплингом не помогают.
Обычно туда что-то вставляют insert-ом с select-ом а потом клеят с другими таблицами и т.д.
При этом в плане по темповой таблице практически всегда FTS.
Это нормально, так как обычно они у нас содержат 10-100 строк (бывает и больше но редко, предугадать невозможно).

До этого был Sles 10 IA-64 и Oracle 10.2.0.5 и такого явления не было.

Это более или менее объяснимая ситуация, странность же следующая :
Проблему удалось решить обойти созданием джоба который каждые 5 минут собирает статистику по самым горячим темповым таблицам.
Точнее по темповым таблицам которые участвуют в топовых запросах.

Причём, обратите внимание, что легчает всем сессиям которые используют эти таблицы.
А ведь каждая сессия имеет свой независимый от других набор данных, а значит и свою статистику.

Вот именно этот момент мне абсолютно не понятен.

Есть у кого то идеи почему такое происходит?
20 июл 17, 12:59    [20661131]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
Добрый Э - Эх
Guest
VDom,

плохие планы до сбора статистики и хорошие после сбора - предлагается выдумать самим?
20 июл 17, 13:01    [20661139]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
VDom
А ведь каждая сессия имеет свой независимый от других набор данных, а значит и свою статистику.
Вот именно этот момент мне абсолютно не понятен.

Как ни удивительно, но прямой связи между актуальностью статистики и производительностью запросов нет.
Статистика лишь должна наводить оптимизатор на правильные мысли, помогая принимать выгодные решения.
Если система стабильна (в плане изменений) и работает в стабильном окружении (установившиеся потоки данных) - то статистику можно и вообще не собирать :)
Поэтому собираеть ее non-stop - просто греть атмосферу, расплачиваясь за собственную лень и некомпетентность общим снижением производительности системы.

Хинт: dbms_stats.set%
20 июл 17, 13:26    [20661286]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
VDom
HP-UX 11.31 IA
Oracle 10.2.0.5

Постоянно слетают планы запросов в которых участвуют темповые таблицы.
У некоторых запросов по 50 планов!! Хинты с самплингом не помогают.
Обычно туда что-то вставляют insert-ом с select-ом а потом клеят с другими таблицами и т.д.
При этом в плане по темповой таблице практически всегда FTS.
Это нормально, так как обычно они у нас содержат 10-100 строк (бывает и больше но редко, предугадать невозможно).

До этого был Sles 10 IA-64 и Oracle 10.2.0.5 и такого явления не было.

Это более или менее объяснимая ситуация, странность же следующая :
Проблему удалось решить обойти созданием джоба который каждые 5 минут собирает статистику по самым горячим темповым таблицам.
Точнее по темповым таблицам которые участвуют в топовых запросах.

Причём, обратите внимание, что легчает всем сессиям которые используют эти таблицы.
А ведь каждая сессия имеет свой независимый от других набор данных, а значит и свою статистику.

Вот именно этот момент мне абсолютно не понятен.

Есть у кого то идеи почему такое происходит?


в Oracle есть еще такая штука, как hot objects (см. dbms_shared_pool.markhot)
необъяснимо большое количество планов было замечено при переводе объекта в эту категорию (это не баг, а фича)
20 июл 17, 13:32    [20661317]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
вообще хинт cardinality на 90% решает проблемы производительности запросов с временными таблицами
без дополнительных телодвижений
20 июл 17, 13:35    [20661328]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
andrey_anonymous
VDom
А ведь каждая сессия имеет свой независимый от других набор данных, а значит и свою статистику.
Вот именно этот момент мне абсолютно не понятен.

Как ни удивительно, но прямой связи между актуальностью статистики и производительностью запросов нет.
Статистика лишь должна наводить оптимизатор на правильные мысли, помогая принимать выгодные решения.
Если система стабильна (в плане изменений) и работает в стабильном окружении (установившиеся потоки данных) - то статистику можно и вообще не собирать :)
Поэтому собираеть ее non-stop - просто греть атмосферу, расплачиваясь за собственную лень и некомпетентность общим снижением производительности системы.

Хинт: dbms_stats.set%


выглядит даже как-то нелепо, настолько категорично. или вы просто не имели с range based partitioning, когда каждый новый день - новая партиция, и данных не пара сотен тысяч, а сотни миллионов строк. или просто пара миллионов

в таких условиях неправильная статистика порой чревата полным отказом системы - в смысле запросы начинают выполняться бесконечно долго, и вероятность такого - чуть менее, чем половина случаев.
20 июл 17, 13:36    [20661330]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
dbpatch
в таких условиях неправильная статистика порой чревата полным отказом системы - в смысле запросы начинают выполняться бесконечно долго, и вероятность такого - чуть менее, чем половина случаев.


в таких случаях "правильная" статистика, собранная в неудачное время и испоганившая текущий план выполнения, способна нагадить больше, чем ее отсутствие , или "неправильная", но заранее импортированная )))

А вообще уважающие себя запросы на быстро растущей партиции должны вести себя с точки зрения, что партиция заполнена по максимуму, а не менять планы как перчатки )
20 июл 17, 13:44    [20661398]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
dbpatch
выглядит даже как-то нелепо, настолько категорично. или вы просто не имели с range based partitioning, когда каждый новый день - новая партиция, и данных не пара сотен тысяч, а сотни миллионов строк. или просто пара миллионов

Ну куда уж нам, сирым...
20 июл 17, 14:02    [20661517]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
DВА
dbpatch
в таких условиях неправильная статистика порой чревата полным отказом системы - в смысле запросы начинают выполняться бесконечно долго, и вероятность такого - чуть менее, чем половина случаев.


в таких случаях "правильная" статистика, собранная в неудачное время и испоганившая текущий план выполнения, способна нагадить больше, чем ее отсутствие , или "неправильная", но заранее импортированная )))

А вообще уважающие себя запросы на быстро растущей партиции должны вести себя с точки зрения, что партиция заполнена по максимуму, а не менять планы как перчатки )


пока стабильного решения этой проблемы нам найти не удалось. вернее стабилизировали в 10.2 несколько лет назад, методом копирования статистики с прошлого дня и блокировки пересбора оной, но в 11.2 оптимизатор нет нет и уйдет в штопор

пока мужественно пытаемся прикрутить interval partitioning + dynamic sampling, впечатления очень противоречивые

оно конечно понятно, что задача нетиповая, но ....
20 июл 17, 14:07    [20661545]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
dbpatch,

Вполне типовая и одно из решений практически как у вас, но нарезают секции немного наперед и сразу же копируют статистику с нужными правками(например по ночам с субботы на воскресенье) , при этом сбор статистики блокируют на уровне таблицы.
20 июл 17, 14:46    [20661709]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
dbpatch
пока стабильного решения этой проблемы нам найти не удалось. вернее стабилизировали в 10.2 несколько лет назад, методом копирования статистики с прошлого дня и блокировки пересбора оной, но в 11.2 оптимизатор нет нет и уйдет в штопор

пока мужественно пытаемся прикрутить interval partitioning + dynamic sampling, впечатления очень противоречивые

оно конечно понятно, что задача нетиповая, но ....

очень даже типовая )
в 10 версии успешно решаемая вашим методом, а вот с 11 то гистограммы картинку подпортят, то кардиналити фидбак, а в 12 придут еще и адаптивные курсоры )
Я по-возможности пока отключаю всю эту хрень, есть надежда на адаптивные курсоры и расширенную статистику, но пока видимо реализация оставляет желать лучшего
20 июл 17, 14:47    [20661712]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
VDom,

Или как уже советовали хинтуйте cardinality или отключите dynamic sampling в них
20 июл 17, 14:50    [20661719]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
DВА,

Cardinality feedback c 12.1 появился) а адаптивные планы даже оракл рекомендует выключать) гистограммы, кстати, я в таких случаях тоже правил тем же джобом, если они нужны
20 июл 17, 14:54    [20661734]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
DВА
dbpatch
пока стабильного решения этой проблемы нам найти не удалось. вернее стабилизировали в 10.2 несколько лет назад, методом копирования статистики с прошлого дня и блокировки пересбора оной, но в 11.2 оптимизатор нет нет и уйдет в штопор

пока мужественно пытаемся прикрутить interval partitioning + dynamic sampling, впечатления очень противоречивые

оно конечно понятно, что задача нетиповая, но ....

очень даже типовая )
в 10 версии успешно решаемая вашим методом, а вот с 11 то гистограммы картинку подпортят, то кардиналити фидбак, а в 12 придут еще и адаптивные курсоры )
Я по-возможности пока отключаю всю эту хрень, есть надежда на адаптивные курсоры и расширенную статистику, но пока видимо реализация оставляет желать лучшего


гистограммы и в 10.2 портили
а вот про Cardinality Feedback мужики-то и не знали! надо тщательнее New Features изучать, спасибо за наводку.
кстати из последних стабилизаций - CREATE VIEW table_pq SELECT * FROM (SELECT /*+ PARALLEL(t,4) FULL(t) */ FROM table t)

не панацея, но хоть как-то позволят не срываться в merge join и nested loop на ad-hoc запросах, вместо hj.
осталось только популяризировать у пользователей понимание, где им нужно ожидать и применять индексный доступ, а где "быстрый" :)
20 июл 17, 14:55    [20661741]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
xtender
DВА,

Cardinality feedback c 12.1 появился) а адаптивные планы даже оракл рекомендует выключать) гистограммы, кстати, я в таких случаях тоже правил тем же джобом, если они нужны


чо?

https://blogs.oracle.com/optimizer/cardinality-feedback
20 июл 17, 14:56    [20661748]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
dbpatch,
хитрый ход ))
20 июл 17, 14:58    [20661756]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
xtender
DВА,

Cardinality feedback c 12.1 появился) а адаптивные планы даже оракл рекомендует выключать) гистограммы, кстати, я в таких случаях тоже правил тем же джобом, если они нужны


конкретно так появились может и в 12.1 , а жить мешать начали еще с 11 )))
20 июл 17, 15:00    [20661761]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
dbpatch,

Да, глюканул, перепутал... Давненько уже только с 12 работаю)
20 июл 17, 15:01    [20661764]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
DВА
dbpatch,
хитрый ход ))


ну, ты же понимаешь, это не от хорошей жизни, в смысле это не техническое решение, это больше борьба с человеческим фактором.
пользователи у нас люди хорошие, и Java знают отлично, но почему-то вопрос посмотреть explain plan у 99% популяции - непреодолимая задача, а вписать хинты... что такое хинты?
20 июл 17, 15:22    [20661846]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
DВА
Member

Откуда:
Сообщений: 5439
dbpatch
DВА
dbpatch,
хитрый ход ))


ну, ты же понимаешь, это не от хорошей жизни, в смысле это не техническое решение, это больше борьба с человеческим фактором.
пользователи у нас люди хорошие, и Java знают отлично, но почему-то вопрос посмотреть explain plan у 99% популяции - непреодолимая задача, а вписать хинты... что такое хинты?


жертвы ООП )))
20 июл 17, 15:23    [20661850]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
DВА
dbpatch
пропущено...


ну, ты же понимаешь, это не от хорошей жизни, в смысле это не техническое решение, это больше борьба с человеческим фактором.
пользователи у нас люди хорошие, и Java знают отлично, но почему-то вопрос посмотреть explain plan у 99% популяции - непреодолимая задача, а вписать хинты... что такое хинты?


жертвы ООП )))


скорее веры в стабильные и добрые черные ящики :)
хотя их тоже можно понять - ну как так, вот вчера и в течение месяца все работало отлично, а сегодня нет!

значит это ты все сам лично поломал, давай чини, разбирайся!

пояснять им, что CBO это во сама себе по дизайну такая штука, что из лучших побуждений может ломаться просто потому что
сегодня чуть другие данные - в их представление о мире не входит - ни в одной другой программисткой среде таких поведений софта
обычно не наблюдается, дескать ты нас обманываешь, а вчера просто взял и индекс небось удалил (!) и оно теперь тормозит

да даже сама фраза "давайте удалим индексы, оно быстрее заработает" - уже в головах вызывает диссонанс (учили же в ВУЗе что индексы это хорошо!)

потому ... вносим стабильность, удваиваем ВВП !
20 июл 17, 15:36    [20661907]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
oragraf
Member

Откуда: Moscow
Сообщений: 1317
dbpatch
значит это ты все сам лично поломал, давай чини, разбирайся!
Блин, как знакомо! У нас еще говорят: Может, у тебя какие то скрипты недонакатились? И смотрят так подозрительно )))
20 июл 17, 15:44    [20661934]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dba123
Member

Откуда:
Сообщений: 1054
VDom,

VDom
HP-UX 11.31 IA
Oracle 10.2.0.5
...
Причём, обратите внимание, что легчает всем сессиям которые используют эти таблицы.
А ведь каждая сессия имеет свой независимый от других набор данных, а значит и свою статистику.

Вот именно этот момент мне абсолютно не понятен.

Есть у кого то идеи почему такое происходит?

Имхо, до 12с, если действительно сделан "джоб, который каждые 5 минут собирает статистику", то
такой джоб должен устанавливать для всех сессий numrows, numblks в любом случае 0, так как
- dbms_stats.gather_table_stats начинался раньше с коммита (а он обнулит таблицу для on commit delete rows)
- сессия новая в gtt нет строк (для preserve rows)


другое дело в 12с: там для таких таблиц можно указать (dbms_stats.set_table_prefs) видимость статистики на уровне scope:shared|session (dbms_stats.gather_table_stats не коммитит теперь)
20 июл 17, 16:04    [20661995]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
VDom
Member

Откуда:
Сообщений: 55
Уточняю - БД у меня растёт на 600ГБ в месяц с тенденцией к увеличению.

Конечно не все таблицы растут так быстро , но десятка 3-4 таки да. Регулярно штатными средствами Oracle собирается статистика. Для чего это делается и почему всем понятно и так.

Но прямого отношения к теме это не имеет.

dbpatch
dynamic sampling
- не помогает
DВА
cardinality
- тоже не помогает
С них мы начинали. Временно помогает, потом планы опять плывут.

Вопрос в следующем - как влияет сбор статистики на темповой таблице в одной сессии на планы запросов в других сессиях использующих эту таблицу?

Вот в этом состоит загадка. Этого я не понимаю, это противоречит документации и логике.
20 июл 17, 17:26    [20662318]     Ответить | Цитировать Сообщить модератору
 Re: Странное поведение временных таблиц.  [new]
dbpatch
Member

Откуда:
Сообщений: 1130
VDom
dbpatch
dynamic sampling
- не помогает

увы, да

VDom
Вопрос в следующем - как влияет сбор статистики на темповой таблице в одной сессии на планы запросов в других сессиях использующих эту таблицу?

Вот в этом состоит загадка. Этого я не понимаю, это противоречит документации и логике.

а можно ссылку на упопянутое место в документации?
20 июл 17, 17:45    [20662386]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить