Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
не стоит цепляться за то что было - оно было уже 2 раза, возможно будет ещё. Поэтому мониторь текущую ситуацию в БД и поймёшь кто и сколько
27 фев 08, 11:05    [5342420]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Эталон Этанолович
Груня
Съимитировать пожирание PGA с помощью соответствующего запроса конечно можно, а как их отловить в базе?
Я знаю 2 способа.
Первый - документированный - требует режима разделяемого сервера и установки профильных ограничений.
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)


А если перевести всех временно на период обнаружения на sort_area_size, указав небольшое значение. Как следствие будет интенсивно использоваться TEMP, и в этом случае можно будет по v$temp_usage(v$sort_usage) точно узнать какой запрос сколько требует памяти:
автор
SQL> desc v$sort_usage
Name
------------------------
USERNAME
USER
SESSION_ADDR
SESSION_NUM
SQLADDR
SQLHASH

А , Серёг, что скажешь?
27 фев 08, 11:18    [5342529]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 332
пgа
Эталон Этанолович
Груня
Съимитировать пожирание PGA с помощью соответствующего запроса конечно можно, а как их отловить в базе?
Я знаю 2 способа.
Первый - документированный - требует режима разделяемого сервера и установки профильных ограничений.
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)


А если перевести всех временно на период обнаружения на sort_area_size, указав небольшое значение. Как следствие будет интенсивно использоваться TEMP, и в этом случае можно будет по v$temp_usage(v$sort_usage) точно узнать какой запрос сколько требует памяти:
автор
SQL> desc v$sort_usage
Name
------------------------
USERNAME
USER
SESSION_ADDR
SESSION_NUM
SQLADDR
SQLHASH

А , Серёг, что скажешь?
Скажу, что pga_aggregate_target, *_area_size ограничивают (это упрощенно) только рабочие области. То есть, отожрал для сортировки слишком много - твои проблемы, пиши/читай в TEMP. Если какому-то прид... упс... разработчику захочется загрузить таблицу размером в 1Gb в PL/SQL-таблицу, запретить ему это можно только предложенными мной средствами. Согласно информации, представленной вопрошателем - "была найдена сессия отожравшая 1,1Г и десяток сессий скушавшие в среднем по 0,5Г PGA" - нечто подобное и происходит. Они будут жрать память, свопиться, жрать кактусы, но запросто в TEMP могут писать очень мало или вообще ничего.

P.S. Только гильотина 10261 :)
27 фев 08, 11:49    [5342812]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
Эталон Этанолович
пgа
Эталон Этанолович
Груня
Съимитировать пожирание PGA с помощью соответствующего запроса конечно можно, а как их отловить в базе?
Я знаю 2 способа.
Первый - документированный - требует режима разделяемого сервера и установки профильных ограничений.
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)


А если перевести всех временно на период обнаружения на sort_area_size, указав небольшое значение. Как следствие будет интенсивно использоваться TEMP, и в этом случае можно будет по v$temp_usage(v$sort_usage) точно узнать какой запрос сколько требует памяти:
автор
SQL> desc v$sort_usage
Name
------------------------
USERNAME
USER
SESSION_ADDR
SESSION_NUM
SQLADDR
SQLHASH

А , Серёг, что скажешь?
Скажу, что pga_aggregate_target, *_area_size ограничивают (это упрощенно) только рабочие области. То есть, отожрал для сортировки слишком много - твои проблемы, пиши/читай в TEMP. Если какому-то прид... упс... разработчику захочется загрузить таблицу размером в 1Gb в PL/SQL-таблицу, запретить ему это можно только предложенными мной средствами. Согласно информации, представленной вопрошателем - "была найдена сессия отожравшая 1,1Г и десяток сессий скушавшие в среднем по 0,5Г PGA" - нечто подобное и происходит. Они будут жрать память, свопиться, жрать кактусы, но запросто в TEMP могут писать очень мало или вообще ничего.

P.S. Только гильотина 10261 :)


Имеется в виду это:

alter system set events '10261 trace name errorstack level 10';

Если да, то трассировка много ресурсов отожрет? и trace-файл насколько будет велик?

Поправьте меня, ежели я не прав! :)
27 фев 08, 11:54    [5342846]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Груня

Имеется в виду это:

alter system set events '10261 trace name errorstack level 10';

Если да, то трассировка много ресурсов отожрет? и trace-файл насколько будет велик?

Поправьте меня, ежели я не прав! :)


я так понимаю, что это не столько трассировка сколько ограничение накладываемое на потребление pga. Сессии будут просто получать ora- о невозможности выделить pga и запросы будут отваливаться.

Эталон Этанолович:

или не только это?
27 фев 08, 11:58    [5342879]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Эталон Этанолович

пga

А , Серёг, что скажешь?
Скажу, что pga_aggregate_target, *_area_size ограничивают (это упрощенно) только рабочие области. То есть, отожрал для сортировки слишком много - твои проблемы, пиши/читай в TEMP. Если какому-то прид... упс... разработчику захочется загрузить таблицу размером в 1Gb в PL/SQL-таблицу, запретить ему это можно только предложенными мной средствами. Согласно информации, представленной вопрошателем - "была найдена сессия отожравшая 1,1Г и десяток сессий скушавшие в среднем по 0,5Г PGA" - нечто подобное и происходит. Они будут жрать память, свопиться, жрать кактусы, но запросто в TEMP могут писать очень мало или вообще ничего.

P.S. Только гильотина 10261 :)


Понятно, спасибо.

"Убивал" бы этих любителей коллекций.
27 фев 08, 12:00    [5342890]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 7126
Утро
Груня

Потерянные сессии это те процессы, информации о которых нет в V$SESSION?
Если я не прав объясните или укажите ссылку, по связке "потерянные сессии" ничего найти не удалось :)

Да..., в 8.1.7 бала такая бага
Я пользовался примерно таким скриптом:
-------- start chksess.sh ----------
#!/bin/sh
# process in v$process in system
(
echo "set head off feedback off pages 0 line 100"
echo "select 'ps -fp '||p.spid as cmd"
echo "from v\$process p, v\$session s"
echo "where  p.addr = s.paddr"
echo "and p.background is null"
echo "and p.spid not in (0"
ps -ef|grep -v grep |grep "oracle$ORACLE_SID (LOCAL="|while read user pid tail
 do echo ,$pid
 done
echo "); "
---- stop ------------
) | sqlplus -s / as sysdba
$ chksess.sh | while read cmd; do $cmd; done
orapfa3   1971     1  2 12:12 ?        00:00:00 ora_j000_pfa3
orapfa3   1973     1  0 12:12 ?        00:00:00 ora_j001_pfa3
Скрипт сидел только вместо ps стоял kill :)
Разумеется надо дошаркать напильником, чтобу job не убивал
плюс дополнительно проверять на то что процесс
есть в v$process но нет в v$sesssion (И наоборот)

Удачи
27 фев 08, 12:22    [5343063]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 332
Груня
Имеется в виду это:

alter system set events '10261 trace name errorstack level 10';

Если да, то трассировка много ресурсов отожрет? и trace-файл насколько будет велик?

Поправьте меня, ежели я не прав! :)

10261, 00000, "Limit the size of the PGA heap"
// *Cause: the limit is one kilobyte times the level of the event. If the
// pga grows bigger than this signal an internal error.

пример (ограничение на 65536 = 64M PGA):

alter system set events '10261 trace name context forever, level 65536';

Все, кто попытается хватануть больше - схватит не память, а ORA-600.
Разумеется, тридиционная запись об этом в alert.log и трассу.

1. За ORA-600 Stax'у, например, админ бьет по лицу :) - можно поступать так же.
2. Саму 600-тую уже можно перехватывать и, например, выдавать дамп памяти,
где разбираться в причинах:
... '600 trace name heapdump level XXXXX'
27 фев 08, 12:40    [5343215]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
Эталон Этанолович
Груня
Съимитировать пожирание PGA с помощью соответствующего запроса конечно можно, а как их отловить в базе?
Я знаю 2 способа.
Первый - документированный - требует режима разделяемого сервера и установки профильных ограничений.
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)


Вопрос к Эталоновичу по первому способу: как ограничить в 9-ке потребление PGA?
Какой RESOURCE_NAME имеется в виду, окромя PRIVATE_SGA в DBA_PROFILES на тему памяти ничего не нашел! :)
27 фев 08, 12:44    [5343249]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
Эталон Этанолович
Груня
Имеется в виду это:

alter system set events '10261 trace name errorstack level 10';

Если да, то трассировка много ресурсов отожрет? и trace-файл насколько будет велик?

Поправьте меня, ежели я не прав! :)

10261, 00000, "Limit the size of the PGA heap"
// *Cause: the limit is one kilobyte times the level of the event. If the
// pga grows bigger than this signal an internal error.

пример (ограничение на 65536 = 64M PGA):

alter system set events '10261 trace name context forever, level 65536';

Все, кто попытается хватануть больше - схватит не память, а ORA-600.
Разумеется, тридиционная запись об этом в alert.log и трассу.

1. За ORA-600 Stax'у, например, админ бьет по лицу :) - можно поступать так же.
2. Саму 600-тую уже можно перехватывать и, например, выдавать дамп памяти,
где разбираться в причинах:
... '600 trace name heapdump level XXXXX'


Бить по фэйсу у нас не принято, да и плодить 600-ые ошибки не хотелось бы! А вот ограничить наглецов по профилю энто в самый раз!
27 фев 08, 12:47    [5343273]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
Груня
Эталон Этанолович
Груня
Съимитировать пожирание PGA с помощью соответствующего запроса конечно можно, а как их отловить в базе?
Я знаю 2 способа.
Первый - документированный - требует режима разделяемого сервера и установки профильных ограничений.
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)


Вопрос к Эталоновичу по первому способу: как ограничить в 9-ке потребление PGA?
Какой RESOURCE_NAME имеется в виду, окромя PRIVATE_SGA в DBA_PROFILES на тему памяти ничего не нашел! :)


PRIVATE_SGA и есть ограничение размера занятого PGA пользовательским процессом?
27 фев 08, 12:55    [5343350]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Груня

Бить по фэйсу у нас не принято, да и плодить 600-ые ошибки не хотелось бы! А вот ограничить
наглецов по профилю энто в самый раз!


А если посмотреть с другой стороны: ты ограничишь pga, думая, что предотвратишь от черезмерного использования коллекций, а в жизни юзеру pga понадобится для запроса, которому без сортировок никак. И что, ты ему кислород перекрывать?

Не думаю, что подобный способ воздействия на стиль программирования самый правильный.
Наверняка известно кто там у вас лабает, им конкретно и перекрыть кислород. Если я правильно понимаю, то 10261 можно не только на уровне экземпляра, а и на уровне сессии выставить.
27 фев 08, 13:29    [5343620]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
пgа
Груня

Бить по фэйсу у нас не принято, да и плодить 600-ые ошибки не хотелось бы! А вот ограничить
наглецов по профилю энто в самый раз!


А если посмотреть с другой стороны: ты ограничишь pga, думая, что предотвратишь от черезмерного использования коллекций, а в жизни юзеру pga понадобится для запроса, которому без сортировок никак. И что, ты ему кислород перекрывать?

Не думаю, что подобный способ воздействия на стиль программирования самый правильный.
Наверняка известно кто там у вас лабает, им конкретно и перекрыть кислород. Если я правильно понимаю, то 10261 можно не только на уровне экземпляра, а и на уровне сессии выставить.


Ограничение предполагаю делать в разумных пределах, например PRIVATE_SGA=250M (больше этой цифры потребляет только сессия Sportlite и парочка постоянно висящих Job-ов) и только для рядовых пользователей!
Эталонович писал, что 10261 - вещь недокументированная, а я не сторонник недокументированных инструментов, потому как после использования таковых, ежели чаво техподдержка (хоть от нее и мало толку) просто "умоет руки".
27 фев 08, 14:00    [5343852]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Груня

Эталонович писал, что 10261 - вещь недокументированная, а я не сторонник недокументированных инструментов, потому как после использования таковых, ежели чаво техподдержка (хоть от нее и мало толку) просто "умоет руки".


я думаю, что все эвенты кроме 10046 можно считать недокументированными по большому счёту :))
27 фев 08, 14:11    [5343960]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
пgа
Груня

Эталонович писал, что 10261 - вещь недокументированная, а я не сторонник недокументированных инструментов, потому как после использования таковых, ежели чаво техподдержка (хоть от нее и мало толку) просто "умоет руки".


я думаю, что все эвенты кроме 10046 можно считать недокументированными по большому счёту :))


Меня больше отпугивают 600-тые ошибки и возможные последствия связанные с ними, тем паче наша база перегружается крайне редко ...
27 фев 08, 14:20    [5344035]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
нуб
Member

Откуда:
Сообщений: 171
Груня
Эталонович писал, что 10261 - вещь недокументированная

С чего бы это?

Документация ;-)
27 фев 08, 14:23    [5344053]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
нуб
Member

Откуда:
Сообщений: 171
пgа
я думаю, что все эвенты кроме 10046 можно считать недокументированными по большому счёту :))

Если на то пошло, то 10046 тоже недокументирован, без всяких счетов :)
27 фев 08, 14:24    [5344063]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
нуб
пgа
я думаю, что все эвенты кроме 10046 можно считать недокументированными по большому счёту :))

Если на то пошло, то 10046 тоже недокументирован, без всяких счетов :)


достаточно документирован в публичной литературе: Кайт, Милсап, статьи на oramag, metalink.

Остальные эвенты не так широко (ну может быть ещё 10053).
27 фев 08, 14:39    [5344195]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
нуб
Member

Откуда:
Сообщений: 171
пgа
нуб
пgа
я думаю, что все эвенты кроме 10046 можно считать недокументированными по большому счёту :))

Если на то пошло, то 10046 тоже недокументирован, без всяких счетов :)


достаточно документирован в публичной литературе: Кайт, Милсап, статьи на oramag, metalink.

Остальные эвенты не так широко (ну может быть ещё 10053).

В моем понимании, документирован - значит описан в стандартной документации и официально поддерживается. Личные мысли Кайта, Миллсапа, конечно, хорошо, но никакого отношения к документированности не имеют. Кстати, тот же Кайт где-то писал, что 10046 недокументирован. metalink вроде как с утра еще не был публичным (public - общий), и к тому же там можно найти достаточно информации не только по 10046, но и по большинству основных event'ов, а так еще есть oraus.msg, Lewis, Duke, Adams, китайские и корейские сайты на худой конец :)
27 фев 08, 15:13    [5344534]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Поставь точку с запятой и будет тебе счастье и спокойствие в душе.
автор
достаточно документирован в публичной литературе: Кайт, Милсап, статьи на oramag; metalink.
27 фев 08, 16:17    [5345113]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Эталон Этанолович
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)
Можно поредактировать чуток? Типа:
"всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью, не понимая, что творят :("

Всего
27 фев 08, 20:11    [5346520]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
пgа
Guest
Ааз
Эталон Этанолович
Второй - недокументированный. Event 10261. Бьет больно, как серпом, всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью :)
Можно поредактировать чуток? Типа:
"всяких засранцев, балующихся PL/SQL-таблицами и прочей хренью, не понимая, что творят :("

Всего


да всё они понимают, по лёгкому пути хотят пойти
28 фев 08, 11:15    [5348052]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Груня
Member

Откуда:
Сообщений: 227
пgа
Груня

Бить по фэйсу у нас не принято, да и плодить 600-ые ошибки не хотелось бы! А вот ограничить
наглецов по профилю энто в самый раз!


А если посмотреть с другой стороны: ты ограничишь pga, думая, что предотвратишь от черезмерного использования коллекций, а в жизни юзеру pga понадобится для запроса, которому без сортировок никак. И что, ты ему кислород перекрывать?

Не думаю, что подобный способ воздействия на стиль программирования самый правильный.
Наверняка известно кто там у вас лабает, им конкретно и перекрыть кислород. Если я правильно понимаю, то 10261 можно не только на уровне экземпляра, а и на уровне сессии выставить.


Извиняюсь за столь длинный тайм-аут, просто надоело убивать сессии-паразиты!

А если действительно попытаться обойтись без каких-либо ограничений и попытаться вычислить наиболее ресурсоемкие курсоры, открытые этими сессиями?

Допустим есть сессия-паразит, которая уже съела более 400 метров PGA:

select s.sid,s.serial#,SPID,s.username,osuser,s.machine,ADDR,PGA_USED_MEM,PGA_ALLOC_MEM
from v$process p,v$session s where p.addr=s.paddr and p.PGA_USED_MEM>400000000;

SID SERIAL# SPID USERNAME OSUSER MACHINE ADDR PGA_USED_MEM PGA_ALLOC_MEM
352 19296 31342778 PYATKOVA Pyatkova ITB\F01C06 07000001E2461F88 407453410 409834098

Как выявить какие из 280-ти курсоров:

select * from V$OPEN_CURSOR WHERE SID=352;

SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_TEXT
07000001E2692698 352 PYATKOVA 07000001FA99A668 3219829653 SELECT * FROM IBS.VW_Criteria_Columns WHERE Criteria_Id = :C
07000001E2692698 352 PYATKOVA 0700000206598B88 4145186628 SELECT A1.ID, A1.CLASS_ID FROM Z#PR_CRED A1 WHERE A1.ID = :B
07000001E2692698 352 PYATKOVA 07000001EF120A60 1270449797 SELECT CLASS_ID FROM Z#PRODUCT WHERE ID=:B1
07000001E2692698 352 PYATKOVA 07000002053640D0 3238505970 SELECT /*+ FIRST_ROWS */ A2.C_SHORT_NAME FROM Z#DISPOSITION
07000001E2692698 352 PYATKOVA 07000002038A8490 3029127155 SELECT C_HIGH_LEVEL_CR FROM Z#PR_CRED WHERE ID=:B1

....

открытые в процессе ее выполнения были самые ненасытные?
14 мар 08, 14:28    [5411156]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
nixo
Member

Откуда:
Сообщений: 57
Груня
[Как выявить какие из 280-ти курсоров:

открытые в процессе ее выполнения были самые ненасытные?


v$sql_workarea_active, v$sql_workarea
14 мар 08, 15:02    [5411459]     Ответить | Цитировать Сообщить модератору
 Re: Запросы, пожирающие PGA  [new]
Siveron
Member

Откуда: Екатеринбург
Сообщений: 100
Груня, у вас 3-х звенка?
14 мар 08, 15:22    [5411628]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить