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

Откуда: Saint Petersburg
Сообщений: 389
Добрый день!
Имеются следующие исходные данные:

SQL> select LOW_OPTIMAL_SIZE/1024, HIGH_OPTIMAL_SIZE/1024, OPTIMAL_EXECUTIONS, ONEPASS_EXECUTIONs,total_executions from v$sql_workarea_histogram where total_executions!=0;
 
LOW_OPTIMAL_SIZE/1024 HIGH_OPTIMAL_SIZE/1024 OPTIMAL_EXECUTIONS ONEPASS_EXECUTIONS TOTAL_EXECUTIONS
--------------------- ---------------------- ------------------ ------------------ ----------------
                    2           3.9990234375         8499599343                  0       8499599343
                   64         127.9990234375           12523329                 15         12523344
                  128         255.9990234375            3598778                 54          3598832
                  256         511.9990234375             452430                  0           452430
                  512        1023.9990234375            5819080                 26          5819106
                 1024        2047.9990234375           60401626                 16         60401642
                 2048        4095.9990234375             983221                 16           983237
                 4096        8191.9990234375              22301                  8            22309
                 8192       16383.9990234375              36528                  4            36532
                16384       32767.9990234375               5207                  2             5209
                32768       65535.9990234375               3479                  0             3479
                65536       131071.999023438                683               1678             2361
               131072       262143.999023438                842                  4              846
               262144       524287.999023438                214                  4              218
               524288       1048575.99902344                 56                 37               93
              1048576       2097151.99902344                 17                  2               19
              2097152       4194303.99902344                  0                  1                1
              4194304       8388607.99902344                  0                  2                2
 
18 rows selected
 


и
SQL> select * from v$pgastat;
 
NAME                                                                  VALUE UNIT
---------------------------------------------------------------- ---------- ------------
aggregate PGA target parameter                                   3758096384 bytes
aggregate PGA auto target                                        2036148019 bytes
global memory bound                                              1073741824 bytes
total PGA inuse                                                  1499231436 bytes
total PGA allocated                                              1842589081 bytes
maximum PGA allocated                                            2265264640 bytes
total freeable PGA memory                                        2716860416 bytes
process count                                                           474 
max processes count                                                    1199 
PGA memory freed back to OS                                      1245198830 bytes
total PGA used for auto workareas                                    563200 bytes
maximum PGA used for auto workareas                              1347088384 bytes
total PGA used for manual workareas                                       0 bytes
maximum PGA used for manual workareas                                542720 bytes
over allocation count                                                     0 
bytes processed                                                  1162744506 bytes
extra bytes read/written                                         1679237130 bytes
cache hit percentage                                                  99.85 percent
recompute count (total)                                              994608 
 
19 rows selected



вопрос уже задавал,но ответа,к сожалению, так и не получил, но вопрос все-таки мучает, как так получилось, что при global memory bound = 1G(если я правильно понимаю - это максимальное значение до которого любая из рабочих областей может дорасти , аля hash_area_size и sort_area_size,только для workarea_size_policy=auto,после этого начинается выливание в temp).
Так вот не совсем понимаю,почему у меня при обработке массивов данных в размере от 65мб до 130мб так много onepass'ов??!
4 авг 14, 12:32    [16395307]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 510
global memory bound пересчитывается раз в 3 секунды.
4 авг 14, 16:56    [16397256]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
гистограммы явно неравномерные....тему "Bind variable peeking" покопайте... а мож нафик гистограммы (в данном случае) ? ))))
4 авг 14, 18:53    [16398026]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Э-ээ, а должны быть равномерные?
5 авг 14, 01:59    [16399231]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
дуремаръъъ
Guest
AG#
гистограммы явно неравномерные....тему "Bind variable peeking" покопайте... а мож нафик гистограммы (в данном случае) ? ))))
жжошь :-)
5 авг 14, 02:09    [16399238]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
лан не буду вдаваться в детали :)

Jonathan Lewis:

http://jonathanlewis.wordpress.com/2006/12/11/bind-peeking/
5 авг 14, 10:55    [16399920]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
bigsov
Member

Откуда:
Сообщений: 282
AG#
лан не буду вдаваться в детали :)

Jonathan Lewis:

http://jonathanlewis.wordpress.com/2006/12/11/bind-peeking/


кмк, bind variable peeking тут не причем, оптимайзер уже выбрал план с hash join и человек спрашивает почему хэш джойн лезет на диск хотя памяти хватает.

Вобще максимально сессия может брать до 5% (иногда до 10) от pga:

select  3758096384/1023/1024/1024/20 from dual

        GB
----------
       .18
5 авг 14, 11:32    [16400103]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
bigsov
Member

Откуда:
Сообщений: 282
Имел ввиду не сессию а workarea для которой выбирается количество проходов
5 авг 14, 11:54    [16400296]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
bigsov,

Вобще максимально сессия может брать до 5% (иногда до 10) от pga:

-------------------------------------------------------------------------
вовсе необязательно....

версия то хоть какая ? PGA_AGGREGATE_LIMIT если 12C (хотя врят-ли...сырой еще)

мож поможет ? правда "hidden"

http://christianbilien.wordpress.com/2007/05/01/two-useful-hidden-parameters-_smm_max_size-and-_pga_max-size/

_smm_max_size

_pga_max_size:
5 авг 14, 13:01    [16400796]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
вообще это все от лукавого ))) если памяти дохрена и сам TEMP можно в RAM засунуть :) зачем он нужен ? ведь можно и пересоздать :D
мож над дизайном приложения подумать ?
5 авг 14, 13:23    [16400960]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
Paranoiac
Member

Откуда: Saint Petersburg
Сообщений: 389
Версия 11.2.0.4. насчет global memory bound и 3 сек я в курсе,но у меня вроде не скачет,тем более так...
bigsov
Вобще максимально сессия может брать до 5% (иногда до 10) от pga:

а можно вот про это немножко поподробнее?ссылочку там почитать...
6 авг 14, 10:32    [16404931]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
Paranoiac
Member

Откуда: Saint Petersburg
Сообщений: 389
AG#
мож над дизайном приложения подумать ?

это ЦФТ, там ребята итак "очень много думают"))
6 авг 14, 10:34    [16404945]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
Paranoiac,

Привет ребятам из ЦФТ !!! :)
6 авг 14, 10:40    [16404989]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
Paranoiac,

bigsov
Вобще максимально сессия может брать до 5% (иногда до 10) от pga:


а можно вот про это немножко поподробнее?ссылочку там почитать

------------------------------------------------------------------------

bigsov имел ввиду наверное это:

"No RAM sort may use more than 5% of pga_aggregate_target or _pga_max_size, whichever is smaller. This means that no task may use more than 200 megabytes for sorting or hash joins. The algorithm further reduces this to (200/2) for sorts so the actual limit for pure sorts will be 100 megabytes"
6 авг 14, 10:48    [16405036]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
bigsov
Member

Откуда:
Сообщений: 282
AG#
Paranoiac,
bigsov
Вобще максимально сессия может брать до 5% (иногда до 10) от pga:
а можно вот про это немножко поподробнее?ссылочку там почитать
------------------------------------------------------------------------
bigsov имел ввиду наверное это:
"No RAM sort may use more than 5% of pga_aggregate_target or _pga_max_size, whichever is smaller. This means that no task may use more than 200 megabytes for sorting or hash joins. The algorithm further reduces this to (200/2) for sorts so the actual limit for pure sorts will be 100 megabytes"
ну да, все верно.

почитать я бы посоветовал главу 12 Льюиса, а по вашему вопросу может быть такое поможет: PGA tour: Maximize workareas for ETL in Oracle 11.2.0.3

если не брать варианты с недокументированными параметрами, то я вижу только вариант сильно распараллелить тестовый запрос (для упрощения будем считать что он один) и увеличить pga_aggregate_target. После этого можно сравнить количество onepass проходов с тем что у вас сейчас.
6 авг 14, 11:17    [16405273]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
bigsov,

распараллелить тестовый запрос

------------------------------------

CPU хватит на парралели с учетом background процесс ? по ядрам....
7 авг 14, 01:33    [16409593]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
кста..для парраллели что нуно кроме ЦПУ ;) ? лардж....

за сим на сон ;)

удачи
7 авг 14, 01:46    [16409602]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
отложенный rollback (deferred) не взлетает ? для CPU норм ;)
7 авг 14, 01:56    [16409609]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Да сколько можно бухать?
7 авг 14, 02:02    [16409612]     Ответить | Цитировать Сообщить модератору
 Re: v$sql_workarea_histogram  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
Вячеслав Любомудров,

Слав...

чтоб ядерный пездец устроить по нашему... :)

по хорошему еснно... ;)
7 авг 14, 02:34    [16409627]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить