ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных
40 сообщений из 40, показаны все 2 страниц
  все  
Быстрая вставка данных
    #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
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485513
Волшебные пузырьки
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Волшебные пузырьки
Гость
Все дело в волшебных пузырьках.
Если целевая таблица - partitioned, то оптимизатор не может строить предположений, куда конкретно залягут вставляемые денные (кроме случаев эквисекционирования, но и там, подозреваю, сработает ровно так же).
Поэтому распараллеливание производится следующим образом: каждый рабочий сервер обслуживает свою секцию целевой таблицы.
Соответственно, сервера, читающие источник, раскидывают свои рекордсеты по серверам-приемникам согласно partition key (PX SEND PARTITION (KEY)).
Это разумно и правильно, кроме одного ньюанса: в случае ТС де-факто весь поток данных должен свалиться в одну секцию целевой таблицы. Отсюда спецэффект: на запись работает только один сервер из восьми, все "вытягивается в нитку", читатели напрасно греют процессоры вычислением partition key - он все время один и тот же получается :)

Если целевая таблица - не partitioned (включая случай, когда оптимизатор может определить, что приемником является единственная секция целевой таблицы - например, если указан partition for), то никакой необходимости вычисления partition key нет ввиду того, что писатели пишут в один общий сегмент.
...
Рейтинг: 0 / 0
10.07.2017, 10:08
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485524
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
Волшебные пузырькиВсе дело в волшебных пузырьках.
Если целевая таблица - partitioned, то оптимизатор не может строить предположений, куда конкретно залягут вставляемые денные (кроме случаев эквисекционирования, но и там, подозреваю, сработает ровно так же).
Поэтому распараллеливание производится следующим образом: каждый рабочий сервер обслуживает свою секцию целевой таблицы.
Соответственно, сервера, читающие источник, раскидывают свои рекордсеты по серверам-приемникам согласно partition key (PX SEND PARTITION (KEY)).
Это разумно и правильно, кроме одного ньюанса: в случае ТС де-факто весь поток данных должен свалиться в одну секцию целевой таблицы. Отсюда спецэффект: на запись работает только один сервер из восьми, все "вытягивается в нитку", читатели напрасно греют процессоры вычислением partition key - он все время один и тот же получается :)

Если целевая таблица - не partitioned (включая случай, когда оптимизатор может определить, что приемником является единственная секция целевой таблицы - например, если указан partition for), то никакой необходимости вычисления partition key нет ввиду того, что писатели пишут в один общий сегмент.
Было такое предположение, но остаётся объяснить пару "нюансов". Почему если из целевой таблицы удалить bitmap индекс, то оракл вполне может обходится без передачи partition key(через хинт) и не вытягивается в нитку?

И вторая штука которую при этом я не смог себе объяснить. Если следовать этой логике, то сколько максимум партиций сможет
обслужить сервер при таком подходе? Предположим что в запросе дано 2 параллели, а нужно вставить данные в 200 партиций. Каком будет алгоритм работы PX процессов в этом случае?
...
Рейтинг: 0 / 0
10.07.2017, 10:17
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485535
Пузырь-волшебник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пузырь-волшебник
Гость
Pavel_PVПочему если из целевой таблицы удалить bitmap индекс, то оракл вполне может обходится без передачи partition key(через хинт) и не вытягивается в нитку?
Покажи что имеешь ввиду.
Pavel_PV И вторая штука которую при этом я не смог себе объяснить. Если следовать этой логике, то сколько максимум партиций сможет обслужить сервер при таком подходе?
Логически - сколько угодно.
Если не PWCP (как в твоем "идеальном" плане), то лишнее тупо буферизуется между PX SEND/PX RECEIVE пока не забьет доступную PGA, затем вываливается в temp.
...
Рейтинг: 0 / 0
10.07.2017, 10:25
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485747
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexFF__|
Участник
Pavel_PV,

Столько воды, а в итоге все вылилось в "почему не параллелится".
Можешь сделать тест-кейс?
...
Рейтинг: 0 / 0
10.07.2017, 13:40
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485758
Kamael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kamael
Участник
Волшебные пузырьки, вода сплошная.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.
Посмотрите статистики выполнения sql monitor отчета.
...
Рейтинг: 0 / 0
10.07.2017, 13:53
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485803
Kamael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kamael
Участник
KamaelВолшебные пузырьки, вода сплошная.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.
Посмотрите статистики выполнения sql monitor отчета.
Пардон, это причина только для не партиционированной таблицы.
Но по статистикам выполнения, паралелится всё равно слабо.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.
...
Рейтинг: 0 / 0
10.07.2017, 14:48
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485809
Kamael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kamael
Участник
Но без индекса паралелится ровненько по всем PX.
как бы yне какой нибуть рестрикшн на pdml bitmap
...
Рейтинг: 0 / 0
10.07.2017, 15:03
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485819
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Да ну...ora601табличку там посмотри, ага) /Я не говорил, что это медленно - я говорил что NOLOGGING операции трудно представить уместным на рабочей базе. Не читайте между строк.

Детский сад, штаны на лямках.
И в чем проблема NOLOGGING на продукционной базе? Тем более, или это ETL/DWH, и исходные данные в любом случае сохранены?

Кроме того, после INSERT /*+ NOLOGGING вполне достаточно сделать SELECT /*+ PARALLEL - это инициирует direct patch read, т.е. форсированный сброс грязных блоков на диск, все счастливы
...
Рейтинг: 0 / 0
10.07.2017, 15:14
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485821
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
andrey_anonymousora601Pavel_PV,

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

Если данные настолько малоценны, что ради производительности их можно гонять в nologging (привет стендбаям, репликами и всяким PITR) - то нет особого смысла пользовать для трансформации оракель. Возможно, достаточно будет продрать исходное файло awk/sed/питоном и использовать результат в БД как external table. Или в хадуп какой свалить.

а мужики говорят что хадуп уже не актуален: https://habrahabr.ru/post/303802/


и, кстати, в Oracle давно запилили потоковую пред-обработку external table/file http://www.oracle.com/technetwork/issue-archive/2011/11-mar/o21nanda-312277.html

можно "результаты продирания" вообще нигде не хранить :)
...
Рейтинг: 0 / 0
10.07.2017, 15:19
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485823
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
KamaelНо без индекса паралелится ровненько по всем PX.
как бы yне какой нибуть рестрикшн на pdml bitmap
ну, структура у bitmap индекса такая, что его довольно проблематично построить методом split/merge

вообще говоря для подобных случаев как раз и придумано субпартицирование - Oracle не провидец, и
разработчик волен сам задать необходимый ему уровень изоляции (читай распараллеливания) данных.

в т.ч. волен сам запускать параллельные сессии, в явном виде, а не через PQ хинты - на direct path insert налагаются
ведь простые ограничения - каждая сессия/процесс должна вставлять строго в свой сегмент

так почему бы его и не соблюдать в явном виде?
...
Рейтинг: 0 / 0
10.07.2017, 15:26
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485827
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
кстати, ТС - включение опции COMPRESS на таблице назначении, как ни странно - может увеличить скорость вставки.
там не LZW компрессия, скорее разновидность RLE, тем не менее - она уменьшает число байт на запись, в т.ч. уменьшает объем сгенерированного redo


CREATE TABLE test1 NOCOMPRESS AS SELECT * FROM dba_objects;

vs

CREATE TABLE test2 COMPRESS AS SELECT * FROM dba_objects;

дает уменьшение размера redo в ~ два раза. а так как время I/O это чуть менее, чем 90% от total elapsed...
...
Рейтинг: 0 / 0
10.07.2017, 15:36
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39485887
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
[quot Pavel_PV]ora601пропущено...


В (HYBRID TSM/HWMB) Скорее.

Собственно не вижу изменений. Причем знаешь в чем парадокс, стоит убить bitmap index и всё сразу начинает работать как положено, хинт pq_distribute помогает. Но если он оказывает такое влияние на потоки передачи данных, почему при использовании конструкции "partition(for)" это влияние сразу исчезает.

"(HYBRID TSM/HWMB)" Я не получил при тестах (что впрочем не суть), но возвращаясь к кейсу партишен ексчендж vs пдмл (Обьем 12 млн) :

 


Код: 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.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
SQL> SELECT COUNT(*) FROM T1 partition for (date '2018-01-01') ;

  COUNT(*)
----------
  12812544

Elapsed: 00:00:00.75
SQL>
SQL> DROP TABLE T3;

Table dropped.

Elapsed: 00:00:00.20
SQL>
SQL>
SQL> CREATE TABLE T3 NOLOGGING PARALLEL 8 AS SELECT * FROM  T1 partition for (date '2018-01-01');

Table created.

Elapsed: 00:00:12.54
SQL>
SQL>
SQL> CREATE BITMAP INDEX  test_index_int ON t3(N) PARALLEL 8;

Index created.

Elapsed: 00:00:30.87
SQL>
SQL>
SQL> ALTER TABLE T1 EXCHANGE PARTITION SYS_P585 WITH TABLE T3 INCLUDING INDEXES WITHOUT VALIDATION;

Table altered.

Elapsed: 00:00:00.10
SQL>
SQL> SELECT COUNT(*) FROM T1 partition for (date '2018-01-01');

  COUNT(*)
----------
  12812544

Elapsed: 00:00:00.72
SQL>
SQL>
SQL>
SQL> explain plan for
  2  insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

Explained.

Elapsed: 00:00:03.51
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY(format => 'alias outline'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3616759440

--------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
 TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                       |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |
     |      |            |
|   1 |  PX COORDINATOR                        |            |       |       |            |          |       |       |
     |      |            |
|   2 |   PX SEND QC (RANDOM)                  | :TQ10002   |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,02 | P->S | QC (RAND)  |
|   3 |    INDEX MAINTENANCE                   | T1         |       |       |            |          |       |       |  Q1,02 | PCWP |            |
|   4 |     PX RECEIVE                         |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,02 | PCWP |            |
|   5 |      PX SEND RANGE                     | :TQ10001   |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,01 | P->P | RANGE      |
|   6 |       LOAD AS SELECT (HIGH WATER MARK) | T1         |       |       |            |          |       |       |  Q1,01 | PCWP |            |
|   7 |        OPTIMIZER STATISTICS GATHERING  |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   8 |         PX RECEIVE                     |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   9 |          PX SEND PARTITION (KEY)       | :TQ10000   |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,00 | P->P | PART (KEY) |
|  10 |           PX BLOCK ITERATOR            |            |    12M|    61M|   783   (0)| 00:00:01 |   186 |   186 |  Q1,00 | PCWC |            |
|  11 |            BITMAP CONVERSION TO ROWIDS |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,00 | PCWP |            |
|  12 |             BITMAP INDEX FAST FULL SCAN| TEST_INDEX |       |       |            |          |   186 |   186 |  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
      INDEX_FFS(@"SEL$1" "T1"@"SEL$1" ("T1"."N"))
      FULL(@"INS$1" "T1"@"INS$1")
      PQ_DISTRIBUTE(@"INS$1" "T1"@"INS$1" PARTITION)
      OUTLINE_LEAF(@"INS$1")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('optimizer_dynamic_sampling' 11)
      DB_VERSION('12.1.0.2')
      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

Note
-----
   - Degree of Parallelism is 8 because of hint

47 rows selected.

Elapsed: 00:00:00.37
SQL>
SQL> insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

12812544 rows created.

Elapsed: 00:02:12.35
SQL> ROLLBACK;

Rollback complete.

Elapsed: 00:00:01.31
SQL>
SQL> explain plan for
  2  insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 partition for(date '2018-01-01') (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

Explained.

Elapsed: 00:00:03.75
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY(format => 'alias outline'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2920565513

----------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                         |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR                          |            |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)                    | :TQ10001   |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,01 | P->S | QC (RAND)  |
|   3 |    INDEX MAINTENANCE                     | T1         |       |       |            |          |       |       |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                           |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANGE                       | :TQ10000   |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,00 | P->P | RANGE      |
|   6 |       LOAD AS SELECT (TEMP SEGMENT MERGE)| T1         |       |       |            |          |       |       |  Q1,00 | PCWP |            |
|   7 |        OPTIMIZER STATISTICS GATHERING    |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,00 | PCWP |            |
|   8 |         PX BLOCK ITERATOR                |            |    12M|    61M|   783   (0)| 00:00:01 |   186 |   186 |  Q1,00 | PCWC |            |
|   9 |          BITMAP CONVERSION TO ROWIDS     |            |    12M|    61M|   783   (0)| 00:00:01 |       |       |  Q1,00 | PCWP |            |
|  10 |           BITMAP INDEX FAST FULL SCAN    | TEST_INDEX |       |       |            |          |   186 |   186 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1
   9 - SEL$1 / T1@SEL$1

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      INDEX_FFS(@"SEL$1" "T1"@"SEL$1" ("T1"."N"))
      FULL(@"INS$1" "T1"@"INS$1")
      PQ_DISTRIBUTE(@"INS$1" "T1"@"INS$1" NONE)
      OUTLINE_LEAF(@"INS$1")
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      OPT_PARAM('optimizer_dynamic_sampling' 11)
      DB_VERSION('12.1.0.2')
      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

Note
-----
   - Degree of Parallelism is 8 because of hint

45 rows selected.

Elapsed: 00:00:00.91
SQL>
SQL> insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 partition for(date '2018-01-01') (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

12812544 rows created.

Elapsed: 00:01:25.51
SQL> ROLLBACK;



...
Рейтинг: 0 / 0
10.07.2017, 16:21
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39486194
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
dbpatchKamaelНо без индекса паралелится ровненько по всем PX.
как бы yне какой нибуть рестрикшн на pdml bitmap
ну, структура у bitmap индекса такая, что его довольно проблематично построить методом split/merge

вообще говоря для подобных случаев как раз и придумано субпартицирование - Oracle не провидец, и
разработчик волен сам задать необходимый ему уровень изоляции (читай распараллеливания) данных.

в т.ч. волен сам запускать параллельные сессии, в явном виде, а не через PQ хинты - на direct path insert налагаются
ведь простые ограничения - каждая сессия/процесс должна вставлять строго в свой сегмент
так почему бы его и не соблюдать в явном виде?
Не уловил идею, каким образом самому запускать параллельные сессии? Речь о пакете dbms_parallel_execute или о чем-то ином? Про COMPRESS спасибо. Он уже есть правда, но изначально был задуман не для этой цели, а куда более банальной - место.

ora601, хороший тест-кейс. Но думаю этот перекос во времени ctas VS insert PDML связан с разной длиной строки в моем случае + разным количеством индексов. В моем случае индекса три, я только что провёл тест на своей тестовой таблице(аналог бою) и итог: на создание 3-х индексов я потратил 298sek, при этом строка index maintenance исходя из EM выполнялась 212sek.
В твоем тест кейсе мне понравилось наглядно отличие времени вставки с указанием "partition for" и без него, я о последних двух insert-ах. Ниже кину вырезку:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SQL> insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

12812544 rows created.

Elapsed: 00:02:12.35

SQL> insert /*+ PARALLEL(8) APPEND ENABLE_PARALLEL_DML*/ into T1 partition for(date '2018-01-01') (d1,N) select date '2018-01-01',N from T1 partition for (date '2018-01-01');

12812544 rows created.

Elapsed: 00:01:25.51


Повторюсь. Грубо говоря, на данный момент, это в точности то, что я хочу победить. Или хотя бы понять почему план 1-го нельзя привести к плану 2-го. Что загадочного в этой конструкции partition for, что такого она подсказывает ораклу чего он не может понять хинтами и штатными средствами(аля DS). Ну т.е. что подсказывает понятно, но неужели нет других вариантов подсказать тоже самое.
Что касается ctas. Если необходимо я могу подготовить тест кейс с аналогом моих данных. Но можно поверить, что при определенном кол-ве индексов и определенной длине строки разница между ctas => созданием индексом и insert /*+ APPEND ENABLE_PARALLEL_DML*/ нивелируется. Я хотел сделать тесткейс, но 20 минут ждал заполнения данных в табличку и вырубил - подумал шипко долго ) вставлял всего 10КК.

P.S> А помню где-то читал, что оракл собирается в partition for сделать возможность использования переменных.
...
Рейтинг: 0 / 0
11.07.2017, 06:13
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39486455
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Pavel_PVdbpatchтак почему бы его и не соблюдать в явном виде?
Не уловил идею, каким образом самому запускать параллельные сессии? Речь о пакете dbms_parallel_execute или о чем-то ином?
да как угодно можно запускать, в т.ч. и через этот пакет.

я говорил больше о сути - ты через субпартиции максимально изолируешь параллельные сессии друг от друга, чтоб они там не бодались за всякие латчи на ASSM header blocks или free lists какие в т.ч., и не упирались конкуренцией во всякие глобальные и битмап индексы, а workerов запускаешь сам, не надеясь на всякие мутные экристики или предположения от PQ

в простейшем случае - на клиенте (чем ты там запускаешь) делаешь несколько соединений и вперед

понятное дело, что тождественное субпартицирование желательно сделать и на источнике данных, чтоб не читало несколько раз одно и то-же
...
Рейтинг: 0 / 0
11.07.2017, 12:52
| Ответить | Цитировать | Написать  
Быстрая вставка данных
    #39487092
Pavel_PV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pavel_PV
Гость
dbpatchPavel_PVпропущено...

Не уловил идею, каким образом самому запускать параллельные сессии? Речь о пакете dbms_parallel_execute или о чем-то ином?
да как угодно можно запускать, в т.ч. и через этот пакет.

я говорил больше о сути - ты через субпартиции максимально изолируешь параллельные сессии друг от друга, чтоб они там не бодались за всякие латчи на ASSM header blocks или free lists какие в т.ч., и не упирались конкуренцией во всякие глобальные и битмап индексы, а workerов запускаешь сам, не надеясь на всякие мутные экристики или предположения от PQ

в простейшем случае - на клиенте (чем ты там запускаешь) делаешь несколько соединений и вперед

понятное дело, что тождественное субпартицирование желательно сделать и на источнике данных, чтоб не читало несколько раз одно и то-же
Понял о чем ты. Это конечно хорошее глобальное решение именно на уровне разработки, но тут не выйдет таким образом поступить. Есть структура и под неё пляшем.

Вчера перекопал море документации в надежде понять о чудодействии "partition for", но что-то ничего не нашёл. Думаю, может у Тома спросить, что они туда зашили такого "красивого". На выходных всё равно покопаю, если ответ найду отпишусь.
...
Рейтинг: 0 / 0
12.07.2017, 04:37
| Ответить | Цитировать | Написать  
40 сообщений из 40, показаны все 2 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1885622]:
 0ms
get settings:
 5ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 162ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 214ms
total:  466ms
созд. / загр.: 466ms
x
x
Закрыть


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