|
|
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Добрый день. При полном сканировании больших таблиц, когда выполняется непосредственно select ..., или при выполнении create table ... as select ... производится чтение, минуя буферный кеш, с событиями direct path read, а при выполнении insert ... select ... - чтение через буферный кеш с событиями db file scattered read. Не могу понять в чём причина, и как заставить insert ... select ... работать через direct path read. Версия Oracle - 11.2.0.4.0. Пример запросов: Код: plsql 1. 2. 3. 4. 5. 6. Выписка из разбора трассировки: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. На всякий случай значения параметров: _serial_direct_read = auto _direct_read_decision_statistics_driven = TRUE _small_table_threshold = 12207 (Количество блоков в таблице - более 5 млн.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 14:25:34 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Grmsh, oracle делает так вполне разумно: create - ddl - данные будут сразу зафиксированы и поэтому в буфере не нужны insert - dml - что ты будешь делать дальше с ними - oracle точно не знает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 14:57:59 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Grmsh как заставить insert ... select ... работать через direct path read. parallel или append ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 15:16:33 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Grmsh, вставка в ту же таблицу, что участвует в селекте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 15:22:08 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
параллелъGrmsh, вставка в ту же таблицу, что участвует в селекте? Код: plsql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 15:38:20 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Fogel, С append пробовал, то же самое. parallel поможет, но переводить же из-за этого все запросы типа insert ... select ... с возможным полным сканированием на параллелизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 16:13:19 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
хм..хм..Grmsh, oracle делает так вполне разумно: create - ddl - данные будут сразу зафиксированы и поэтому в буфере не нужны insert - dml - что ты будешь делать дальше с ними - oracle точно не знает Не вижу логики. Подтвержу я эту вставку, или откачу, текущему запросу отобранные данные всё равно уже не нужны. В дальнейшем текущей ли сессии или параллельной эти данные могут понадобиться или не понадобиться независимо от того, доставались ли они для операции create или для операции insert. Если это всё-таки действительно так, то не могли бы вы сослаться на какой-либо подтверждающий источник? Сколько не искал, мне ничего подобного не попадалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 16:30:20 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Grmsh_direct_read_decision_statistics_driven = TRUE _small_table_threshold = 12207 (Количество блоков в таблице - более 5 млн.) [/quote] А статистика то актуальна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2016, 19:45:53 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
xtenderGrmsh_direct_read_decision_statistics_driven = TRUE _small_table_threshold = 12207 (Количество блоков в таблице - более 5 млн.) А статистика то актуальна?[/quot] Актуальна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2016, 10:51:41 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
alter session set events 'trace[nsmtio]' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2016, 17:07:02 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
А.alter session set events 'trace[nsmtio]' Попробовал на больших таблицах. При create table ... as select ... получаю трассу подобного вида: NSMTIO: qertbFetch:NoDirectRead:[- STT < OBJECT_SIZE < MTT]:Obect's size: 1 (blocks), Threshold: MTT(0 blocks), _object_statistics: enabled, Sage: enabled, Direct Read for serial qry: disabled(::recursive_call::::), Ascending SCN table scan: FALSE flashback_table_scan: FALSE, Row Versions Query: FALSE SqlId: 77mtwmnd4c4pk, plan_hash_value: 1096442870, Object#: 352919, Parition#: 0 *** 2016-08-22 13:05:52.543 NSMTIO: qertbFetch:DirectRead:[OBJECT_SIZE>VLOT] NSMTIO: Additional Info: VLOT=3051950 Object# = 53074, Object_Size = 8854616 blocks SqlId = af98f2r04txbs, plan_hash_value = 1849149188, Partition# = 0 Соответствует примерно ожиданиям. А при insert ... select ... по тем же данным - что-то непонятное: ksesethighpri: (ksb.c:4201) Failed to elevate LGWR's priority from -100 to 60 Error Info: Category(-2), Opname(skgdism_create), Loc(sp.c:1684), ErrMsg(Error 0) Dism(16) *** SESSION ID:(601.1) 2016-07-20 04:45:57.055 *** SERVICE NAME:(SYS$BACKGROUND) 2016-07-20 04:45:57.055 *** 2016-07-20 04:45:57.055 Warning: log write elapsed time 632ms, size 1025KB *** 2016-07-20 04:46:15.805 Warning: log write elapsed time 2521ms, size 467KB ... На средних же таблицах трасса по insert ... select ... в нормальном виде получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 16:06:23 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
GrmshА при insert ... select ... по тем же данным - что-то непонятное: ksesethighpri: (ksb.c:4201) Failed to elevate LGWR's priority from -100 to 60 Error Info: Category(-2), Opname(skgdism_create), Loc(sp.c:1684), ErrMsg(Error 0) Dism(16) *** SESSION ID:(601.1) 2016-07-20 04:45:57.055 *** SERVICE NAME:(SYS$BACKGROUND) 2016-07-20 04:45:57.055 *** 2016-07-20 04:45:57.055 Warning: log write elapsed time 632ms, size 1025KB *** 2016-07-20 04:46:15.805 Warning: log write elapsed time 2521ms, size 467KB ... На средних же таблицах трасса по insert ... select ... в нормальном виде получается. Это LGWR трейс. Нужен трейс файл foreground процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 16:10:21 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
A.Это LGWR трейс. Нужен трейс файл foreground процесса. Да, нужный трейс в таком случае не создаётся, только LGWR. Нашёл, впрочем, таблицу по-меньше, на которой эта проблема не возникает, но поведение при create table ... as select ... и при insert ... select ... аналогичное. create table ... as select ... NSMTIO: qertbFetch:NoDirectRead:[- STT < OBJECT_SIZE < MTT]:Obect's size: 1 (blocks), Threshold: MTT(0 blocks), _object_statistics: enabled, Sage: enabled, Direct Read for serial qry: disabled(::recursive_call::::), Ascending SCN table scan: FALSE flashback_table_scan: FALSE, Row Versions Query: FALSE SqlId: 77mtwmnd4c4pk, plan_hash_value: 1096442870, Object#: 352919, Parition#: 0 NSMTIO: qertbFetch:[MTT < OBJECT_SIZE < VLOT]: Checking cost to read from caches(local/remote) and checking storage reduction factors (OLTP/EHCC Comp) NSMTIO: kcbdpc:DirectRead: tsn: 10, objd: 32136, objn: 32136 ckpt: 1, nblks: 168430, ntcache: 0, ntdist:0 NSMTIO: Additional Info: VLOT=3051950 Object# = 32136, Object_Size = 168430 blocks SqlId = 1dgznnwp91ngn, plan_hash_value = 1993557499, Partition# = 0 А при insert ... select ... только в трейсе это: NSMTIO: qertbFetch:NoDirectRead:[- STT < OBJECT_SIZE < MTT]:Obect's size: 13 (blocks), Threshold: MTT(0 blocks), _object_statistics: enabled, Sage: enabled, Direct Read for serial qry: disabled(::recursive_call:pgapls:::), Ascending SCN table scan: FALSE flashback_table_scan: FALSE, Row Versions Query: FALSE SqlId: bazquck2vuvm1, plan_hash_value: 2135017060, Object#: 89004, Parition#: 0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2016, 18:52:23 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
Пока не очень ясно откуда Direct Read for serial qry: disabled(::recursive_call::::) Либо это от вспомогательных рекурсивных запросов, либо основной INSERT считается рекурсивным. INSERT вызывается напрямую или вложен куда-то? Какой-либо из этих object# 352919 32136 89004 53074 является gl_je_lines или gl_je_lines_copy? SR не создан на эту тему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:30:27 |
|
||
|
Не выбирается direct path read при insert ... select ...
|
|||
|---|---|---|---|
|
#18+
ОК, вроде разобрался. Действительно в 11g внутри INSERT serial direct reads отключаются. Легко воспроизводится в 11g на простом примере Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Пофиксено в (12.1) Код: plaintext Если сильно нужна эта функциональность, можешь создать SR и запросить бэкпорт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2016, 16:53:40 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39295748&tid=1887471]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
175ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 429ms |

| 0 / 0 |
