Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Странное явление - очень простой запрос тормозит  [new]
NGL
Member

Откуда:
Сообщений: 14
Привет!

Есть простая таблица
ARP(ID  NUMBER(6), EVENT_DATE DATE, PRICE NUMBER(10,6))
первичный ключ по
EVENT_DATE + ID
. Запрос вида

select * from arp where event_date in (?,?,?,?,?,?,?) and id in (?)

из тоада выполняется быстро, доли секунды, план хороший - доступ по индексу из первичного ключа. Записей в таблице около 7 миллионов. Когда приложение выполняет этот запрос из нескольких ниток одновременно (с разными параметрами естественно), то время выполнения подскакивает до нескольких десятков секунд. Оракл 10, приложение на Java, доступ JDBC Type 4/Hibernate/Spring. Базу никто не апдэйтает в этот момент, никто другой не грузит. Грешил на пул коннектов, но загрузка CPU именно ораклом подскакивает. Воспроизводится на разных машинах. Идеи?


Спасибо,
Гена
4 апр 09, 03:28    [7021628]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Надо снимать трассировку 10046 с тормозящей сессии и смотреть реальный план/события ожидания/чтения. Одни вопрос: для приведенного запроса важным является порядок полей в индексе первичного ключа. Первым должен идти ID. Это так?
4 апр 09, 04:13    [7021632]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
Lord British
Member

Откуда: На Камчатке красиво?
Сообщений: 758
Совсем недавно у меня были Звиздопляски с разными планами... и мистика была и полтергейст. И то запрос на одних входных данных отрабатывает нормально то вообще никак.

Вобщем почесав в итоги репу я пришёл ко мнению, что всё таки порядок полей в индексе который и должен был помочь этому запросу бул не тот. Сделал тот порядок. И всё работает как часы. Быстро.
4 апр 09, 13:11    [7021906]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
A. S.
Member

Откуда: Донецк
Сообщений: 320
wurdu
для приведенного запроса важным является порядок полей в индексе первичного ключа. Первым должен идти ID. Это так?


Какая разница если есть условия на оба поля?

event_date in (?,?,?,?,?,?,?) and id in (?)
4 апр 09, 15:32    [7022060]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
Власов Алексей
Member

Откуда: Москва
Сообщений: 193
A. S.

Какая разница если есть условия на оба поля?

event_date in (?,?,?,?,?,?,?) and id in (?)


Потому что id одно значение, а дат несколько. Если в индексе дата спереди, то надо в индекс заходит 7 раз с разных дат. А если id спереди, то зайти с ID а уже внутри данного значения продолжить поиск 7 дат. Во втором случае объем просматриваемых данных существенно меньше.
4 апр 09, 15:48    [7022073]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
A.K.
Member

Откуда: Пенза
Сообщений: 2571
Власов Алексей
Потому что id одно значение, а дат несколько.

Из примера это не слишком очевидно. Если в условии по id всегда одно значение - не совсем ясно, зачем автор применяет in.
4 апр 09, 19:13    [7022314]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
NGL,

Снятие трассировки с многопоточного приложения может быть морокой. Для начала можно посмотреть что в v$sqlarea по этому запросу/запросам, если много вариантов.
4 апр 09, 20:24    [7022415]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
NGL
Member

Откуда:
Сообщений: 14
Первое поле в индексе event_date, id. Такой порядок более правильный, так как id это внешний ключ из другой таблицы, по нему есть свой индекс. Вообще уверен, что порядок полей в индексе в данном случае не важен, доступ по индексу к таблице с 7 миллионами записей не может длится полминуты, тут либо скан всей таблицы либо локировки и ожидание.
In в запросе потому, что может быть несколько id, но данный конкретный запрос тормоз имеет только один.
По опыту с MS SQL могу сказать, что иногда, когда таблица небольшая, он может применять полное сканирование таблицы даже при доступе к одной записи по первичному ключу. Но тут 7 миллионов ...
5 апр 09, 14:10    [7023322]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
Lord British
Member

Откуда: На Камчатке красиво?
Сообщений: 758
Чего годать на кофейной гуще. Автор, перестройте индекс - не поможет верните назад. У вас всего лишь 7 млн записей - это ни о чём. Такой индекс построиться очень быстро.
5 апр 09, 15:39    [7023533]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
A.K.
Member

Откуда: Пенза
Сообщений: 2571
NGL
доступ по индексу к таблице с 7 миллионами записей не может длится полминуты...

Imho, это слишком категоричное утверждение. Сколько записей из этих 7 миллионов в среднем отбирает ваш запрос? Какова селективность поля event_date?
5 апр 09, 15:51    [7023549]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
A.K.
Member

Откуда: Пенза
Сообщений: 2571
NGL
По опыту с MS SQL могу сказать, что иногда, когда таблица небольшая, он может применять полное сканирование таблицы даже при доступе к одной записи по первичному ключу.

Естественно, так как доступ по индексу тоже не бесплатен. В случае, если процент записей таблицы, выбираемых запросом, достаточно велик, использовать индекс может оказаться накладнее, чем сделать full table scan.
5 апр 09, 15:53    [7023554]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
NGL
Member

Откуда:
Сообщений: 14
A.K.
Imho, это слишком категоричное утверждение. Сколько записей из этих 7 миллионов в среднем отбирает ваш запрос? Какова селективность поля event_date?


Вообще-то id + event_date это первичный ключ, так что запрос возвращает от 0 до 7 записей.
5 апр 09, 17:03    [7023699]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
A.K.
Member

Откуда: Пенза
Сообщений: 2571
Попробуйте хинтом заставить оптимизатор использовать индекс.
5 апр 09, 17:11    [7023720]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
Lord British
Member

Откуда: На Камчатке красиво?
Сообщений: 758
соберите статистику для таблицы и для её индексов
5 апр 09, 19:57    [7024035]     Ответить | Цитировать Сообщить модератору
 Re: Странное явление - очень простой запрос тормозит  [new]
NGL
Member

Откуда:
Сообщений: 14
Перестройка индексов и сбор статистики не помогли. Трассировку не включал, смотрел живые планы и байндинг через динамические вью. Разница в том, какой тип байндится - через жабку DATE как в таблице, через Hibernate/JDBC TIMESTAMP. Думаю в этом трабл. Что-то похожее здесь описано https://www.sql.ru/forum/actualthread.aspx?tid=641977 Попробую взять драйвер от 11g, тут детали http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.html#08_01
6 апр 09, 22:43    [7029544]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить