|
|
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. скажите, я верно рассуждаю: в колонке TempSpc показано сколько ориентировочно займет запрос в TEMP, каких-то космических цифр нет. я верно понимаю, что исходя из цифр 120 гигов никак не должны было потребляться в TEMP ? скорее всего какой-то баг ? P.S. база SE 11.2.0.3, статистика в колонке Rows может не абсолютно точная, но порядок цифр верен, например TABLE4 не 25 млн, а 39 млн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 13:22:51 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plus, выполните запрос с хинтом /*+ gather_plan_statistics */ и посмотрите реальные значения Rows и Temp select * from table(dbms_xplan.display_cursor(null,null,'allstats last cost')); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 13:52:43 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
piheljoiner_plus, выполните запрос с хинтом /*+ gather_plan_statistics */ и посмотрите реальные значения Rows и Temp select * from table(dbms_xplan.display_cursor(null,null,'allstats last cost'));Не надо никаких хинтов. Лучше смотреть реальный прогресс с помощью dbms_sqltune.report_sql_monitor. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:02:59 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plus, наблюдай за выполнением через real-time sql monitor - все станет понятно Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:04:04 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
понаблюдать теперь уже врядли получиться, это был прод и TABLE1 заполняется из файлов клиента. теперь там совсем другой порядок цифр приходит (всего лишь сотни). да и боязно, если TEMP переполниться снова он и другие процессы может завалить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:10:28 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plus, посмотри может еще он есть в v$sql_monitor, если есть, то возьми его sql_id и sql_exec_id и подставь в запрос выше, раскомментировав 3-ю строку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:16:00 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plus, а что на счет плана, который я показал ? он снят DBA непосредственно во время исполнения. я к тому, что даже если все перечисленные таблицы сложить, прибавить хеши по соединяемым колонкам, все равно сотня гигов не наберется. разве это из этого нельзя сделать какой-то вывод ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:16:41 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
А насколько точно известно, 1) что именно этот план использовался? 2) что этот SQL упал, потому что именно он весь темп забил, а не кто-то другой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:20:06 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
Nobody1111А насколько точно известно, 1) что именно этот план использовался? 2) что этот SQL упал, потому что именно он весь темп забил, а не кто-то другой? точно. потому что сначала упал запрос из системы, а потом я запустил запрос уже от себя и попросил DBA посмотреть реальный план, и снять трейс (уже после запуска запроса правда). трейс вышел крошечный и не интересный. несколько строк в стиле nam='db file sequential read' ela= 17588 и SQL*Net break/reset to client в конце. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:36:12 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plus, приведенный тобой план смахивает на обычный плюсовский вывод эксплайна. где реалии ресурсов выполнения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 14:57:01 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
нереальный планjoiner_plus, приведенный тобой план смахивает на обычный плюсовский вывод эксплайна. где реалии ресурсов выполнения? не знаю о чем вы, toad мне с сервера показывает такие же отформатированные планы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 16:36:15 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
ash включен? на 11.2.0.3 в ash есть колонка потребления темп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2016, 17:01:47 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_minusash включен? на 11.2.0.3 в ash есть колонка потребления темп наверно нет: Код: plsql 1. 2. 3. ну а все же, все таблицы участвующие в плане занимают 12G, я верно мыслю что приведенный план не оставляет шансов такому запросу сожрать 120G в TEMP ? даже если все заджоинить и добавить пару гб на хеши и записать дважды в TEMP (ради сортировки например), все равно не выйдет забить 120G ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2016, 10:40:36 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
Nobody1111А насколько точно известно, ...... 2) что этот SQL упал, потому что именно он весь темп забил, а не кто-то другой в то же время? Ошибка воспроизводится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2016, 14:00:23 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
Nobody1111Ошибка воспроизводится? там сильно изменились данные и это прод, за эксперименты меня могут побить. сейчас у меня вопрос теоретический: мог ли такой план в теории нагенерить 120G TEMP, если во всех таблицах лишь 12G ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2016, 15:09:17 |
|
||
|
HASH JOIN кушает 120Gb в TEMP segment и вылетает
|
|||
|---|---|---|---|
|
#18+
joiner_plusNobody1111Ошибка воспроизводится? там сильно изменились данные и это прод, за эксперименты меня могут побить. сейчас у меня вопрос теоретический: мог ли такой план в теории нагенерить 120G TEMP, если во всех таблицах лишь 12G ? Ну может если multipass, что с того ? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2016, 17:33:01 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39269127&tid=1887938]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 193ms |
| total: | 300ms |

| 0 / 0 |
