ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных
25 сообщений из 40, страница 1 из 2
  1  все
Быстрая вставка данных
    #39478882
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
Всем доброго.
Есть задача, нужно быстро вставить порядка 50млн строк. Выполнять каждый день, берём из одной партиции + совершили небольшие манипуляции и вставить в другую. На данный момент самое быстрое
Код: plsql
1.
2.
insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML NO_GATHER_OPTIMIZER_STATISTICS*/
into table1  partition for(date ****)


Но хочется ещё быстрее. Пробовал и через exchange partition, выйгрыша нет. Смотрел документацию, но может не обратил внимание - есть ли возможность в оракл сделать дубликат партиции? Т.е. аналог exchange partition, но только копию. Есть мысль, что это позволит повысить скорость.
Если упустил какой-то вариант буду признателен за подсказку.
...
Рейтинг: 0 / 0
28.06.2017, 11:08
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39478959
kaldorey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kaldorey
Участник
Pavel_PV,

Можно попробовать CTAS + Exchange Partition
...
Рейтинг: 0 / 0
28.06.2017, 12:28
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39479403
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
CTAS + Exchange partition пробовал, время потраченное на ctas сопоставимо со временем вставки в партицию и это думаю вполне логично.
В рамках темы хотел спросить про особенность. Не совсем понятно почему при "partition for" insert работает быстрее чем без него, причем порядка ~30%. При этом во втором случае из плана исчезает строчка partition send key(если верно запомнил), но основная особенность в том что при указании "partition for" таблица из которой читаются данные полноценно читается в параллель, а без "partition for" чтение в 1 нитку. Не думаю, что это связано именно с чтением таблицы, видимо есть какая-то связь именно с распараллеливанием и передачей данных между потоками. Вышеизложенное исходя из поведения в EM. По необходимости могу приложить планы.
...
Рейтинг: 0 / 0
29.06.2017, 05:47
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39482711
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Pavel_PVCTAS + Exchange partition пробовал.

without validation или с ?
...
Рейтинг: 0 / 0
04.07.2017, 19:34
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39482716
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Pavel_PV,

+ CTAS NOLOGGING должно работать way more faster > CTAS.
...
Рейтинг: 0 / 0
04.07.2017, 19:41
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39482744
Да ну...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Да ну...
Гость
ora601Pavel_PV,

+ CTAS NOLOGGING должно работать way more faster > CTAS.Сомневаюсь, что NOLOGGING хоть где-то применим.
...
Рейтинг: 0 / 0
04.07.2017, 20:54
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39482758
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Да ну...,

табличку там посмотри, ага)

https://recurrentnull.wordpress.com/2013/06/30/direct-path-nologging-ctas-and-gtt-a-comparison-of-undo-and-redo-generated/
...
Рейтинг: 0 / 0
04.07.2017, 21:19
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39482817
Да ну...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Да ну...
Гость
ora601табличку там посмотри, ага) /Я не говорил, что это медленно - я говорил что NOLOGGING операции трудно представить уместным на рабочей базе. Не читайте между строк.
...
Рейтинг: 0 / 0
04.07.2017, 23:19
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483100
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
ora601 c without validation конечно делал, отрабатывает быстро. Но само заполнение той самой таблицы с которой будет осуществляться обмен не очень быстрый. Как итог - профита фактически нет. Но тут мне ещё нужно - INCLUDING INDEXES.
CTAS + NOLOGGING разумеется. Но хотя правильнее сказать, что таблица создана с параметром NOLOGGING, и выполняется в ней insert table as select. Справедливости ради нужно сказать, что если выбросить все индексы из таблицы то вставка выполняется на очень хорошем уровне, с индексами всё хуже. По распределению примерно так - 1/3 на голую вставку и 2/3 на всё остальное. Вариант с отключением индексов и их последующим пересчетом не должен дать профит ввиду использования ENABLE_PARALLEL_DML.

Guest не совсем понимаю почему NOLOGGING не может быть применена на рабочей базе? В данной ситуации вполне и никаких проблем в этом не вижу.
...
Рейтинг: 0 / 0
05.07.2017, 12:38
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483194
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Pavel_PVНо хотя правильнее сказать, что таблица создана с параметром NOLOGGING, и выполняется в ней insert table as select.

Ну так CTAS nologging и insert (не дайрект пас) into nologging разные вещи по производительности.
...
Рейтинг: 0 / 0
05.07.2017, 14:34
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483210
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Pavel_PV
Код: plsql
1.
2.
insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML NO_GATHER_OPTIMIZER_STATISTICS*/
into table1  partition for(date ****)


ora601insert ( не дайрект пас )

Ммм?
...
Рейтинг: 0 / 0
05.07.2017, 14:51
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483223
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
andrey_anonymous,

Говорим про кейс partition exchange.

" Но само заполнение той самой таблицы с которой будет осуществляться обмен не очень быстрый"
...
Рейтинг: 0 / 0
05.07.2017, 15:01
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483226
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ora601" Но само заполнение той самой таблицы с которой будет осуществляться обмен не очень быстрый"
Нет ни одной разумной причины отказываться от direct insert при заполнении промежуточной таблицы - при условии выполнения всех ограничений.
...
Рейтинг: 0 / 0
05.07.2017, 15:07
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483228
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
andrey_anonymous,

Ну так я о том же. ТС - тоже вопрос, на промежуточной таблице индексы нологгинг?
...
Рейтинг: 0 / 0
05.07.2017, 15:10
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483229
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ora601Pavel_PV,

+ CTAS NOLOGGING должно работать way more faster > CTAS.

Если данные настолько малоценны, что ради производительности их можно гонять в nologging (привет стендбаям, репликами и всяким PITR) - то нет особого смысла пользовать для трансформации оракель. Возможно, достаточно будет продрать исходное файло awk/sed/питоном и использовать результат в БД как external table. Или в хадуп какой свалить.
...
Рейтинг: 0 / 0
05.07.2017, 15:12
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483233
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--Eugene--
Участник
Pavel_PVесли выбросить все индексы из таблицы то вставка выполняется на очень хорошем уровне, с индексами всё хуже. По распределению примерно так - 1/3 на голую вставку и 2/3 на всё остальное. Вариант с отключением индексов и их последующим пересчетом не должен дать профит ввиду использования ENABLE_PARALLEL_DML.А почему правда не вырубить индексы, вставить данные, и потом ALTER INDEX /*+PARALLEL*/ REBUILD PARTITION ?
(возможно, херню сморозил)
...
Рейтинг: 0 / 0
05.07.2017, 15:22
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483235
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--Eugene--
Участник
тьфу
тоесть ALTER INDEX REBUILD PARTITION PARALLEL [n]
...
Рейтинг: 0 / 0
05.07.2017, 15:26
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39483283
Evgeny2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Evgeny2
Гость
Pavel_PV сделай так...

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
begin 

execute immediate 'alter session enable parallel dml'; -- сессия должна быть закомичена, можно перед execute сделать commit;

insert --+ parallel(ins_table, 8)
         into ins_table
select --+ parallel(sel_table,8)
  from sel_table;
commit; -- обязательно

end;



https://www.akadia.com/services/ora_parallel_processing.html

Только учти, таблица будет расти прямо пропорционально объему вставленных данных.
...
Рейтинг: 0 / 0
05.07.2017, 16:26
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39484274
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
Коллеги, запутал вас видимо маленько.
Почему insert не direct-path? Может я что-то не понимаю, можешь пояснить по возможности? Ниже опишу всё как есть.
Давайте по пунктам, вот этот insert
insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML NO_GATHER_OPTIMIZER_STATISTICS*/
into table1 partition for(date ****)

именно и вставляет данные или в основную таблицу или в ту с которой будет потом произведён обмен партицией. Я говорю о хинтах, они сохраняются, общий формат(куда вставлять и т.д.) конечно немного видоизменяется.
На данный момент я вообще отказался от промежуточной таблицы и операции exchange partition, вышеуказанным insert-ом сразу вставляю данные из источника. Профита от заполнения сначала промежуточной таблицы и затем перезаписи в основную я не увидел.

andrey_anonymous по NOLOGGING тут свои особенности, твою мысль я понял. Считай, что ты просто перекладываешь данные и если что пойдет не так возьмешь и переложишь повторно.

--Eugene-- нет смысла отключать индексы, чтобы потом их пересчитать. Скорости от этого много не выйграть. В этом отчасти и заключается смысл использования ENABLE_PARALLEL_DML. Проверить просто, сделай вставку данных в большую таблицу с этим хинтом и без него, параллельно проследи на нагрузку на объекты во время выполнения запроса через ASH. Насколько я помню что-то в документации есть об этом.
Evgeny2, я и так использую ENABLE_PARALLEL_DML, но включаю через хинт.

Сейчас уже пришёл к итоговому коду который будет использован для вставки. Но проблема с распределением даных между потоками. Не могу сообразить как привести всё к нужному виду. Хинт "pq_distribute(A none)" не помогает так сказать ). Итак поехали:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
CREATE TABLE T1
(
  D1  DATE,
  N number
)
PARTITION BY RANGE (D1)
INTERVAL(NUMTODSINTERVAL(1, 'DAY'))
( PARTITION P_2010   VALUES LESS THAN (TO_DATE('2017-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')));


declare
 vDate date;
BEGIN
  FOR i IN 1..50
  LOOP
     vDate:= trunc(SYSDATE)+i;
     insert into T1(D1,N) select vDate, i from dual;
  END LOOP;
END;
/

create bitmap index test_index on T1(N) LOCAL;



Далее смотрим вот этот план:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
explain plan for
insert/*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/
into T1 A
(d1,N)
select date '2018-01-01',N
from T1
where d1=trunc(SYSDATE)+1;
SELECT * FROM table(DBMS_XPLAN.DISPLAY(format => 'alias outline'));



Код: 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.
Plan hash value: 409285163
 
-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                      |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR                       |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)                 | :TQ10002 |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,02 | P->S | QC (RAND)  |
|   3 |    INDEX MAINTENANCE                  | T1       |       |       |            |          |       |       |  Q1,02 | PCWP |            |
|   4 |     PX RECEIVE                        |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,02 | PCWP |            |
|   5 |      PX SEND RANGE                    | :TQ10001 |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,01 | P->P | RANGE      |
|   6 |       LOAD AS SELECT (HIGH WATER MARK)| T1       |       |       |            |          |       |       |  Q1,01 | PCWP |            |
|   7 |        OPTIMIZER STATISTICS GATHERING |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   8 |         PX RECEIVE                    |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   9 |          PX SEND PARTITION (KEY)      | :TQ10000 |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,00 | P->P | PART (KEY) |
|  10 |           PX BLOCK ITERATOR           |          |     1 |    22 |  1726   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWC |            |
|* 11 |            TABLE ACCESS FULL          | T1       |     1 |    22 |  1726   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
  11 - SEL$1 / T1@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      FULL(@"SEL$1" "T1"@"SEL$1")
      FULL(@"INS$1" "A"@"INS$1")
      [color=red]PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" PARTITION)[/color]
      OUTLINE_LEAF(@"INS$1")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('star_transformation_enabled' 'true')
      OPT_PARAM('_optimizer_table_expansion' 'false')
      OPT_PARAM('query_rewrite_enabled' 'false')
      DB_VERSION('12.1.0.2')
      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  11 - filter("D1"=TRUNC(SYSDATE@!)+1)
 
Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - Degree of Parallelism is 8 because of hint



Тот план который нужен:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
explain plan for
insert/*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/
into T1 [color=red]partition for(date '2018-01-01')[/color] A
(d1,N)
select date '2018-01-01',N
from T1
where d1=trunc(SYSDATE)+1;
SELECT * FROM table(DBMS_XPLAN.DISPLAY(format => 'alias outline'));



Код: 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.
Plan hash value: 3106122454
 
-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                      |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR                       |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)                 | :TQ10001 |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,01 | P->S | QC (RAND)  |
|   3 |    INDEX MAINTENANCE                  | T1       |       |       |            |          |       |       |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                        |          |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANGE                    | :TQ10000 |     1 |    22 |  1726   (0)| 00:00:01 |       |       |  Q1,00 | P->P | RANGE      |
|   6 |       LOAD AS SELECT (HYBRID TSM/HWMB)| T1       |       |       |            |          |       |       |  Q1,00 | PCWP |            |
|   7 |        PX BLOCK ITERATOR              |          |     1 |    22 |  1726   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWC |            |
|*  8 |         TABLE ACCESS FULL             | T1       |     1 |    22 |  1726   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
   8 - SEL$1 / T1@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      FULL(@"SEL$1" "T1"@"SEL$1")
      FULL(@"INS$1" "A"@"INS$1")
      [color=red]PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" NONE)[/color]
      OUTLINE_LEAF(@"INS$1")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('star_transformation_enabled' 'true')
      OPT_PARAM('_optimizer_table_expansion' 'false')
      OPT_PARAM('query_rewrite_enabled' 'false')
      DB_VERSION('12.1.0.2')
      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   8 - filter("D1"=TRUNC(SYSDATE@!)+1)
 
Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - Degree of Parallelism is 8 because of hint



Второй селект отрабатывает в два раза быстрее на моих данных и моих объемах. Исходя из EM обработка идёт в 8 потоков, первый же вытягивается в нитку и медленно+уныло пытается что-то сделать. Хочется к 1-му запросу хинтами прикрутить план второго, а не выходит.

P.S> Использовать конструкцию partition for/partition в самом запросе я не могу ввиду того, что в них нельзя передавать параметры. Пытался использовать функцию dataobj_to_mat_partition => oracle выдает ошибку. Опущу подробности, но в общем эта функция конечно предназначена для другого и что иногда она работает в подобных случаях скорее совпадение.
P.P.S> можно конечно засунуть весь запрос в sql_text и затем используя execute immediate....но что-то мне подсказывает, что можно решить проблему хинтами.
...
Рейтинг: 0 / 0
07.07.2017, 10:11
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39484366
Фотография --Eugene--
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--Eugene--
Участник
Pavel_PVобработка идёт в 8 потокова если ради интереса убрать DEGREE OF PARALLEL вообще (чтобы СУБД сама выставила) - пробовал?
...
Рейтинг: 0 / 0
07.07.2017, 11:39
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39484401
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
Если просто убрать хинт "parallel(8)" то параллели будут те которые были использованы при создании таблицы. Если убрать только 8-ку будет разрешенный максимум который =8.
Да и тут не в этом дело, тут скорее дело в строчке плана
Код: plsql
1.
PX SEND PARTITION (KEY)


и в этой радости:
Код: plsql
1.
PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" PARTITION)
...
Рейтинг: 0 / 0
07.07.2017, 12:08
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39484536
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Pavel_PV Да и тут не в этом дело, тут скорее дело в строчке плана
Код: plsql
1.
PX SEND PARTITION (KEY)


и в этой радости:
Код: plsql
1.
PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" PARTITION)



В (HYBRID TSM/HWMB) Скорее. Это новый метод direct-path pdml для 12с, который хорошо работает для сингл сегмент вставок. Но хинта на него нет.
...
Рейтинг: 0 / 0
07.07.2017, 13:59
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485430
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
ora601Pavel_PV Да и тут не в этом дело, тут скорее дело в строчке плана
Код: plsql
1.
PX SEND PARTITION (KEY)


и в этой радости:
Код: plsql
1.
PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" PARTITION)



В (HYBRID TSM/HWMB) Скорее. Это новый метод direct-path pdml для 12с, который хорошо работает для сингл сегмент вставок. Но хинта на него нет.

Да знаю про эту фишку новую "HYBRID TSM/HWMB". Если честно эти фичи 12-ки, ну вот честно слов нет. Это так сказать моё общее отношение к 12с, ждали большего от IM и прочего :). Ладно проверим твою гипотезу через отрубание новых фишек используя OPTIMIZER_FEATURES_ENABLE:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
explain plan for
insert/*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML pq_distribute(A none) OPTIMIZER_FEATURES_ENABLE('11.2.0.3')*/
into T1 A-- partition for(date '2018-01-01') A
(d1,N)
select date '2018-01-01',N
from T1
where d1=trunc(SYSDATE)+1;
SELECT * FROM table(DBMS_XPLAN.DISPLAY(format => 'alias outline'));



Код: 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.
Plan hash value: 409285163
 
-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                      |          |     1 |    22 |  1747   (0)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR                       |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)                 | :TQ10002 |     1 |    22 |  1747   (0)| 00:00:01 |       |       |  Q1,02 | P->S | QC (RAND)  |
|   3 |    INDEX MAINTENANCE                  | T1       |       |       |            |          |       |       |  Q1,02 | PCWP |            |
|   4 |     PX RECEIVE                        |          |     1 |    22 |  1747   (0)| 00:00:01 |       |       |  Q1,02 | PCWP |            |
|   5 |      PX SEND RANGE                    | :TQ10001 |     1 |    22 |  1747   (0)| 00:00:01 |       |       |  Q1,01 | P->P | RANGE      |
|   6 |       LOAD AS SELECT (HIGH WATER MARK)| T1       |       |       |            |          |       |       |  Q1,01 | PCWP |            |
|   7 |        PX RECEIVE                     |          |     1 |    22 |  1747   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   8 |         PX SEND PARTITION (KEY)       | :TQ10000 |     1 |    22 |  1747   (0)| 00:00:01 |       |       |  Q1,00 | P->P | PART (KEY) |
|   9 |          PX BLOCK ITERATOR            |          |     1 |    22 |  1747   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWC |            |
|* 10 |           TABLE ACCESS FULL           | T1       |     1 |    22 |  1747   (0)| 00:00:01 |   KEY |   KEY |  Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$1
  10 - SEL$1 / T1@SEL$1
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      FULL(@"SEL$1" "T1"@"SEL$1")
      FULL(@"INS$1" "A"@"INS$1")
      PQ_DISTRIBUTE(@"INS$1" "A"@"INS$1" PARTITION)
      OUTLINE_LEAF(@"INS$1")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('star_transformation_enabled' 'true')
      DB_VERSION('12.1.0.2')
      OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
  10 - filter("D1"=TRUNC(SYSDATE@!)+1)
 
Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - Degree of Parallelism is 8 because of hint



Собственно не вижу изменений. Причем знаешь в чем парадокс, стоит убить bitmap index и всё сразу начинает работать как положено, хинт pq_distribute помогает. Но если он оказывает такое влияние на потоки передачи данных, почему при использовании конструкции "partition(for)" это влияние сразу исчезает.
...
Рейтинг: 0 / 0
10.07.2017, 04:35
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485465
dba123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dba123
Участник
Pavel_PV,

egrep -i "deadlock|t1 a" *.trc

Может не заметил. Есть что-нибудь?
...
Рейтинг: 0 / 0
10.07.2017, 08:36
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485473
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
dba123 я привёл эти таблицы как пример, чтобы показать различие в планах точно такое как у меня происходит на боевых.
Повторюсь, речь именно о том как идёт распараллеливание. В одном случае всё работает в 8 потоков и отлично, в другом всё вытягивается в одну нитку. Стоит указать "partition for" и всё чудесным образом взлетает. Но в доке нет информации о "таком чуде". Но всё строится в базе своей на планах, поэтому ищем различия в планах и хинтах => приводим всё к тому который работает => получаем то, что нужно.
Я считаю, что строчка "PX SEND PARTITION (KEY)" каким-то образом тормозит весь процесс в данном случае. Почему сказать не могу, знаний не хватает имхо ).
...
Рейтинг: 0 / 0
10.07.2017, 08:57
| Ответить | Цитировать | Написать  
25 сообщений из 40, страница 1 из 2
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39482716&tid=1885622]:
 0ms
get settings:
 6ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 160ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 74ms
get tp. blocked users:
 2ms
others: 201ms
total:  477ms
созд. / загр.: 477ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]