Быстрая вставка данных / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных

15 сообщений из 40, страница 2 из 2

все

Быстрая вставка данных

#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

Гость

Волшебные пузырькиВсе дело в волшебных пузырьках.
Если целевая таблица - 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__|

Участник

Сообщения: 2 776

Рейтинг: 0 / 0

Pavel_PV,

Столько воды, а в итоге все вылилось в "почему не параллелится".
Можешь сделать тест-кейс?

...

Рейтинг:

0 / 0

10.07.2017, 13:40

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485758

Kamael

Участник

Откуда: Алмата

Сообщения: 373

Рейтинг: 0 / 0

Волшебные пузырьки, вода сплошная.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.
Посмотрите статистики выполнения sql monitor отчета.

...

Рейтинг:

0 / 0

10.07.2017, 13:53

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485803

Kamael

Участник

Откуда: Алмата

Сообщения: 373

Рейтинг: 0 / 0

KamaelВолшебные пузырьки, вода сплошная.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.
Посмотрите статистики выполнения sql monitor отчета.
Пардон, это причина только для не партиционированной таблицы.
Но по статистикам выполнения, паралелится всё равно слабо.
pdml_reason : bitmap indexes are defined, причина не распаралеливания.

...

Рейтинг:

0 / 0

10.07.2017, 14:48

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485809

Kamael

Участник

Откуда: Алмата

Сообщения: 373

Рейтинг: 0 / 0

Но без индекса паралелится ровненько по всем PX.
как бы yне какой нибуть рестрикшн на pdml bitmap

...

Рейтинг:

0 / 0

10.07.2017, 15:03

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485819

dbpatch

Участник

Сообщения: 1 241

Рейтинг: 0 / 0

Да ну...ora601табличку там посмотри, ага) /Я не говорил, что это медленно - я говорил что NOLOGGING операции трудно представить уместным на рабочей базе. Не читайте между строк.

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

Кроме того, после INSERT /*+ NOLOGGING вполне достаточно сделать SELECT /*+ PARALLEL - это инициирует direct patch read, т.е. форсированный сброс грязных блоков на диск, все счастливы

...

Рейтинг:

0 / 0

10.07.2017, 15:14

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485821

dbpatch

Участник

Сообщения: 1 241

Рейтинг: 0 / 0

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

Участник

Сообщения: 1 241

Рейтинг: 0 / 0

KamaelНо без индекса паралелится ровненько по всем PX.
как бы yне какой нибуть рестрикшн на pdml bitmap
ну, структура у bitmap индекса такая, что его довольно проблематично построить методом split/merge

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

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

так почему бы его и не соблюдать в явном виде?

...

Рейтинг:

0 / 0

10.07.2017, 15:26

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39485827

dbpatch

Участник

Сообщения: 1 241

Рейтинг: 0 / 0

кстати, ТС - включение опции 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

Участник

Сообщения: 785

Рейтинг: 0 / 0

[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

Гость

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

Участник

Сообщения: 1 241

Рейтинг: 0 / 0

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

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

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

понятное дело, что тождественное субпартицирование желательно сделать и на источнике данных, чтоб не читало несколько раз одно и то-же

...

Рейтинг:

0 / 0

11.07.2017, 12:52

| Ответить | Цитировать | Написать

Быстрая вставка данных

#39487092

Pavel_PV

Гость

dbpatchPavel_PVпропущено...

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

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

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

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

Вчера перекопал море документации в надежде понять о чудодействии "partition for", но что-то ничего не нашёл. Думаю, может у Тома спросить, что они туда зашили такого "красивого". На выходных всё равно покопаю, если ответ найду отпишусь.

...

Рейтинг:

0 / 0

12.07.2017, 04:37

| Ответить | Цитировать | Написать

15 сообщений из 40, страница 2 из 2

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Быстрая вставка данных

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39485887&tid=1885622]:	0ms
get settings:	9ms
get forum list:	18ms
check forum access:	4ms
check topic access:	4ms
track hit:	83ms
get topic data:	10ms
get forum data:	3ms
get page messages:	51ms
get tp. blocked users:	2ms
others:	229ms

total:	413ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы