Все здравствуйте!!!

Есть запрос на выборку данных. При этом параллельно производится (не интенсивное, но постоянное) внесение новых данных.
Время от времени (причем промежутки никак не нормированы) выполнение этого запросы происходит очень долго и ресурсоемко. Остальное время с ним нет никаких проблем....


С чем это может быть связано?

Вот додумался засечь используемый план... Может быть, что это происходит пересчет плана или оптимизации (я в этом просто практически ничего не понимаю, если не считать наличие какого-то абстарактног представления)?

Может это также быть следствием того, что все запросы идут по соединениям одинакового типа.
Я имею виду, есть ли в Оракл возможность производить  различные типы запросов (чтение/запись), используя рзличные типы соединений (по уровню изоляции/способу доступа)? И может ли это поспособствовать разоешение исходной проблемы?


Спасибо!!!

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

Но эта гипотиреоза из разряда "пальцем в небо". Такая штука встречается весьма редко. Может у тебя все проще - касперксий каконить делает плановое сканирование в "периоды торможениия"

Это сообщение отредактировал(а) Zloxa - 23.6.2009, 14:04

Ага это этот запрос....

Да, я тоже об этом думал, и это очень на это похоже (что перестраивается план)



Запроса ведет себя наоборот: примерно раз в час-два тормозит (единично). Как только тормознутый запрос выполняется - далее повторные запросы выполняются быстро (До следующего "чекпоинта")... Т.е. на перестройку очень похоже... 


Врядли.... часто делаешь запрос и, очевидно, в этот же момент набухает проц.  Далле по сценарию. Плюс, параллельно с тормозящим запросом, другие отрабатыаются нормально....

Но!
Неужели отстройка плана может осуществляться до 2 минут????????
И это при отм, что обновлятся он после добавления 20 - 30 записей?

GATHER_STATS_JOB - У меня Enabled = true

Это он пересчитывает статистику, или пеестраивает планы? (Прошу прощения, все никак руки не дойдут до статистики)...


Каксательно запроса. После тормозов план и окружение оптимизации у него не меняется. Но меняется (что бросилось в глаза)
CHILD_ADDRESS (все же что это такое)
и CONCURRENCY_WAIT_TIME (опять кошусь в сторону уровней изоляции запрососв. В Оракле это есть?)


Это сообщение отредактировал(а) setnull - 23.6.2009, 14:38

Хм. А загрузка данных идёт через одну сессию или через несколько? И есть ли там update или только insert. Может элементарная блокировка на запись вызывает лавину сессий? 
Думаю что чем годать на гуще лучше awr репорт изучить для этого времени. 

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

Тут, увы, я мало могу помочь. Я не DBA, программист.

Добавлено через 3 минуты и 40 секунд
PS Так все тки что тормозит то. Чтение или запись? Если запись, то действительно забываем обо всем ранее сказанном, блокировки смотрим.

Не не, тормозят именно  селекты.... 

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


а как это можно выяснить?

Добавлено через 3 минуты и 2 секунды

Все идет через различные сессии..........

есть buffer cashe

Можно оценить что нам даст его увеличение/уменьшение
7.2.2.2 Using V$DB_CACHE_ADVICE
Можно посмотреть под что у нас он занят
7.2.7 Determining Which Segments Have Many Buffers in the Pool

Только что это нам дает?
Не будешь же ты кэш увеличивать пропорционально росту количества данных в твоей таблице.

Однако от чего последующие запросы не тормозят, это знание может таки дать объяснение 

Попробуй на тестовом окружении сбросить  кэшбуфер. Глянуть не проявится ли симптоматика в этом случае. 

Это сообщение отредактировал(а) Zloxa - 23.6.2009, 16:53

setnull, 
Ты вроде, как-то спрашивал как настроить EM. Он там у тебя есть? 
Если да то пройдись по адвизорам: Зайди на страничку perfomance и запусти оттуда awr репорт для того момента времени когда база тормозила. 
А потом с той же странички попади в ADDM он более нагляден и даже даст тебе советы. 

З.Ы. Всё это можно сделать и без EM, но объяснять дольше.