Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Oracle > Падение производительности

Автор: setnull 23.6.2009, 12:14

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

Автор: Zloxa 23.6.2009, 13:45

Это http://forum.vingrad.ru/forum/topic-263512.html начинает периодически тормозить? План запроса при торможении и при нормальной работе одинаков? Как гипотеза - у тебя может периодически обрабатывать http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41282. После того как статистика по объекту изменяется, сбрасываются все планы запросов, в которых использовался этот объект, при первом выполнении запроса, планы строятся заново. При этом, если при первом выполнении запрос использует не типичные значения в бинде(например значение с высокой http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i55109, в то время как обычно используется значение с низкой селективностью), в результате http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref944 план может оказаться не эффективным для типичных значений биндов. Этот план закрепится и будет использован для последующих вызовов и на типичных вызовах проявятся тормоза. Но эта гипотиреоза из разряда "пальцем в небо". Такая штука встречается весьма редко. Может у тебя все проще - касперксий каконить делает плановое сканирование в "периоды торможениия"

Автор: setnull 23.6.2009, 14:34

Ага это этот запрос.... Да, я тоже об этом думал, и это очень на это похоже (что перестраивается план) Цитата Этот план закрепится и будет использован для последующих вызовов и на типичных вызовах проявятся тормоза. Запроса ведет себя наоборот: примерно раз в час-два тормозит (единично). Как только тормознутый запрос выполняется - далее повторные запросы выполняются быстро (До следующего "чекпоинта")... Т.е. на перестройку очень похоже...  Цитата Но эта гипотиреоза из разряда "пальцем в небо". Такая штука встречается весьма редко. Может у тебя все проще - касперксий каконить делает плановое сканирование в "периоды торможениия" Врядли.... часто делаешь запрос и, очевидно, в этот же момент набухает проц.  Далле по сценарию. Плюс, параллельно с тормозящим запросом, другие отрабатыаются нормально.... Но! Неужели отстройка плана может осуществляться до 2 минут???????? И это при отм, что обновлятся он после добавления 20 - 30 записей? GATHER_STATS_JOB - У меня Enabled = true Это он пересчитывает статистику, или пеестраивает планы? (Прошу прощения, все никак руки не дойдут до статистики)... Каксательно запроса. После тормозов план и окружение оптимизации у него не меняется. Но меняется (что бросилось в глаза) CHILD_ADDRESS (все же что это такое) и CONCURRENCY_WAIT_TIME (опять кошусь в сторону уровней изоляции запрососв. В Оракле это есть?)

Автор: ToshaCh 23.6.2009, 14:40

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

Автор: Zloxa 23.6.2009, 14:42

Цитата(setnull @  23.6.2009,  14:34 ) Как только тормознутый запрос выполняется - далее повторные запросы выполняются быстро Это более похоже на кэширование. При первом запросе блоки таблиц попадают в кэш, далее берутся успешно из кэша, много времени погодя, данные вымываются из кэша, на их считку требуется время. Тут, увы, я мало могу помочь. Я не DBA, программист. Добавлено через 3 минуты и 40 секунд PS Так все тки что тормозит то. Чтение или запись? Если запись, то действительно забываем обо всем ранее сказанном, блокировки смотрим.

Автор: setnull 23.6.2009, 15:59

Не не, тормозят именно  селекты....  Да, и окешировании я думал, только забыл спросить, есть ли такое..... а как это можно выяснить? Добавлено через 3 минуты и 2 секунды Цитата(ToshaCh @ 23.6.2009,  14:40) Хм. А загрузка данных идёт через одну сессию или через несколько? И есть ли там update или только insert. Может элементарная блокировка на запись вызывает лавину сессий?  Думаю что чем годать на гуще лучше awr репорт изучить для этого времени. Все идет через различные сессии..........

Автор: Zloxa 23.6.2009, 16:35

Цитата(setnull @  23.6.2009,  15:59 ) есть ли такое..... есть http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/glossary.htm#sthref4117 Можно оценить что нам даст его увеличение/уменьшение http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref368 Можно посмотреть под что у нас он занят http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#i44438 Только что это нам дает? Не будешь же ты кэш увеличивать пропорционально росту количества данных в твоей таблице. Однако от чего последующие запросы не тормозят, это знание может таки дать объяснение  Попробуй на тестовом окружении http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_2013.htm#sthref4644 кэшбуфер. Глянуть не проявится ли симптоматика в этом случае.

Автор: ToshaCh 23.6.2009, 17:28

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)