Управление пространством и Oracle Direct Path Load (операции прямой загрузки) в Oracle 12c
Еще один перевод отличной статьи с blogs.oracle.com, теперь от Nigel Bayliss . На этот раз, особенности управления пространством при Direct Path Load операциях. Уделено внимание и новым фичам в этой области в 12с, релиза. 12.1.0.2.
Оригинал здесь https://blogs.oracle.com/optimizer/entry/space_management_and_oracle_direct
С 12.1.0.2 в explain plan появилась информация о том как оракл распределяет блоки данных внутри сегментов при direct loads.
Давайте разберемся, почему существуют разные методы управления пространством и единый не подходит для каждого случая.
Просто, учитывая, что direct path load может использоваться, наполняя секционированные и нет таблицы, наполняя один или множество сегментов, работать параллельно или в один поток, выполняться на одном инстансе либо быть распределенным по множеству инстансов RAC. Также следует учитывать некоторые нюансы, например, неравномерное распределение данных - некоторые секции могут содержать значительно больше данных, чем остальные. Успешное параллельное выполнение зависит от равномерности распределения нагрузки по процессам параллельной обработки.
Оракл использует различные стратегии для достижения хорошего масштабирования в самых разнообразных условиях, избегая неэффективной работы при неравномерном распределении данных.
Рассмотрим эти стратегии для 11gR2 и затем дополним их нововведениями из 12c.
High Water Mark (HWM) Loading
Возможно, самый простой механизм загрузки данных. Для примера он используется по-умолчанию, если вы загружаете данные в один поток, стандартным insert+append:
HWM загрузка может использоваться всякий раз, когда Oracle может получить эксклюзивный доступ к сегменту. Это справедливо для последовательной и параллельной загрузки, которая распределена по ключу секционирования (PKEY distribution) и экви-секционированных ("equi-partition") загрузок. Например, при "equi-partition" загрузке parallel execution servers будут обрабатывать соответствующие секции в целевой таблице и каждый parallel server будет отвечать за загрузку данных из соответствующей секции в исходную таблицу.
Equi-partition загрузка будет выбрана автоматически, если вы параллельно копируете данные между двумя "equi-partition" таблицами, но только если таблицы имеют относительно большое кол-во секций (по отношению к кол-ву параллелей).
Рис. ниже отображает последовательную загрузку на 2-х нодовом RAC. Новые данные изображены добавляющимися в конец HWM слева - направо, до commit'а, после которого сдвигается граница HWM, дабы вместить новые данные.
Temp Segment Merge (TSM) Loading
Этот тип загрузки был первым механизмом реализующим параллельную загрузку в один сегмент в Oracle 11gR2 (хотя AutoDOP использует кое-что другое, рассмотрим это ниже)
Для примера, следующие параллельные выражения приведут к TSM загрузке:
Следующая схемка иллюстрирует параллельную 4-х потоковую загрузку в 2-х нодовый RAC кластер:
Так же это способ по-умолчанию загрузки в один сегмент в 11g при использовании Auto DOP (т.е. при загрузках в не секционированную таблицу или в одну секцию таблицы).
Совмещая high water mark загрузку, новые данные добавляются непосредственно в сегмент, за границу high water mark. В зависимости от DOP и типа параллельного выполнения, выбранного оптимизатором нескольким PX обработчикам может потребоваться вставлять данные в один сегмент. В этой ситуации становится обязательным новую позицию high water mark распределить между множеством параллельных процессов. Это распределение реализуется с помощью использования HV очередей. Каждый сегмент имеет свою HV очередь, каждая очередь используется для записи позиции на которую должна быть сдвинута HWM в момент commit'а транзакции. Очередь гарантирует что многочисленные параллельные процессы не могут подвинуть HWM в одно и тоже время.
Следующая диаграмма представляет собой HWMB загрузку с DOP 4 на одиночном инстансе. Строки отображаются заполняющимися слева-направо и HWM отметка перемещается вправо, вмещая в новые данные.
В целом при HWMB загрузке добавляется меньше экстентов в сегмент таблицы или ее секции, чем при TSM (temp segment merging). Это преимущество важно для систем которые часто используют direct load с большим DOP.
Oracle Database 12c: Hybrid TSM/HWMB
Изменения, внесенные в Oracle 12c Database Release 12.1.0.1 призваны улучшить масштабируемость параллельной direct path load, особенно когда она используется для заполнения одиночных сегментов базы данных, то есть не секционированных таблиц или отдельных секций таблицы. Эти изменения особенно важны в высокопроизводительных системах, которые перемещают и трансформируют данные между не секционированными таблицами и отдельными секциями таблиц. Это также полезно в системах, которые используют загрузку с partition exchange, т.е. наполняют отдельную не секционированную таблицу, а затем встраивают ее в секционированную с помощью partition exchange.
Прежде чем мы рассмотрим, как работает новый подход, вот пример на Oracle 12c, который демонстрирует новое поведение:
12.1.0.1 использует такой план выполнения, но конструкцию не отображает.
Основная мотивация такого подхода в том, что high water mark brokering имеет недостаток при загрузке данных большим DOP в один сегмент. Единственной HV очереди нужно будет часто обновляться, и здесь, возникает потенциальное место конкуренции, которая становится более серьезной при распределении PX процессов по нодам RAC (Real Application Clusters) систем. Последовательный доступ к загруженной HV очереди может занять много времени, поэтому в Oracle Database 12c реализовано сочетание High Water Mark Brokering (HWMB) с Temp Segment Merge (TSM) для устранение конкуренции (в т.ч. между экземплярами RAC) за HV очередь, уменьшая при этом число новых экстентов, которые создадутся при операции загрузки.
Проиллюстрируем, как работает гибридный TSM / HWMB при параллельной загрузке данных в не секционированные таблицы или в единичный сегмент. Когда инициируется операция параллельной нагрузки, временный сегмент создается для каждого экземпляра, участвующего в загрузке (т.е. создастся 2 сегмента в 2 нодовом RAC, если параллельная загрузка распределяется по всему кластеру). В каждый временный сегмент могут писать несколько PX процессов, но главное, что в один временный сегмент пишут процессы только одного экземпляра. Таким образом, HV очередь, связанная с каждым временным сегментом, действует локально для каждого экземпляра БД, и не требует распределения по всему кластеру.
Следующая схема отражает Hybrid TSM/HWMB загрузку с DOP=4 на 2-х нодовый RAC кластер:
Итого, преимущества загрузки Hybrid TSM/HWMB в Oracle 12с:
Примеры к статье
Если вас интересуют примеры или Вы сами хотите поэкспериментировать с поведением - можете найти некоторые скрипты от автора (Nigel Bayliss) на Github.
Еще один перевод отличной статьи с blogs.oracle.com, теперь от Nigel Bayliss . На этот раз, особенности управления пространством при Direct Path Load операциях. Уделено внимание и новым фичам в этой области в 12с, релиза. 12.1.0.2.
Оригинал здесь https://blogs.oracle.com/optimizer/entry/space_management_and_oracle_direct
С 12.1.0.2 в explain plan появилась информация о том как оракл распределяет блоки данных внутри сегментов при direct loads.
Давайте разберемся, почему существуют разные методы управления пространством и единый не подходит для каждого случая.
Просто, учитывая, что direct path load может использоваться, наполняя секционированные и нет таблицы, наполняя один или множество сегментов, работать параллельно или в один поток, выполняться на одном инстансе либо быть распределенным по множеству инстансов RAC. Также следует учитывать некоторые нюансы, например, неравномерное распределение данных - некоторые секции могут содержать значительно больше данных, чем остальные. Успешное параллельное выполнение зависит от равномерности распределения нагрузки по процессам параллельной обработки.
Оракл использует различные стратегии для достижения хорошего масштабирования в самых разнообразных условиях, избегая неэффективной работы при неравномерном распределении данных.
Рассмотрим эти стратегии для 11gR2 и затем дополним их нововведениями из 12c.
High Water Mark (HWM) Loading
Возможно, самый простой механизм загрузки данных. Для примера он используется по-умолчанию, если вы загружаете данные в один поток, стандартным insert+append:
ALTER SESSION DISABLE PARALLEL DML; INSERT /*+ APPEND */ INTO sales_copy t1 SELECT ...;Новые данные вставляются в экстенты, распологаемые за отметкой high water mark (далее hwm) (https://docs.oracle.com/database/121/CNCPT/logical.htm#CNCPT89022) таблицы или ее секции. Данные за hwm не сканируются запросами, т.е. новые данные остаются невидимыми до того как транзакция будет "закоммичена", после чего hwm сдвигается и в состав сегмента включаются новые экстенты.
HWM загрузка может использоваться всякий раз, когда Oracle может получить эксклюзивный доступ к сегменту. Это справедливо для последовательной и параллельной загрузки, которая распределена по ключу секционирования (PKEY distribution) и экви-секционированных ("equi-partition") загрузок. Например, при "equi-partition" загрузке parallel execution servers будут обрабатывать соответствующие секции в целевой таблице и каждый parallel server будет отвечать за загрузку данных из соответствующей секции в исходную таблицу.
Equi-partition загрузка будет выбрана автоматически, если вы параллельно копируете данные между двумя "equi-partition" таблицами, но только если таблицы имеют относительно большое кол-во секций (по отношению к кол-ву параллелей).
Рис. ниже отображает последовательную загрузку на 2-х нодовом RAC. Новые данные изображены добавляющимися в конец HWM слева - направо, до commit'а, после которого сдвигается граница HWM, дабы вместить новые данные.
Temp Segment Merge (TSM) Loading
Этот тип загрузки был первым механизмом реализующим параллельную загрузку в один сегмент в Oracle 11gR2 (хотя AutoDOP использует кое-что другое, рассмотрим это ниже)
Для примера, следующие параллельные выражения приведут к TSM загрузке:
CREATE TABLE sales_copy PARALLEL 8 AS SELECT * FROM sales;
Parallel Insert Direct Load (PIDL) в не секционированнуб=table or a single partition:
INSERT /*+ APPEND PARALLEL(t1,8) */ INTO sales_copy_nonpart t1 SELECT ...;
INSERT /*+ APPEND PARALLEL(t1,8) */ INTO sales_copy partition (part_p1) t1 SELECT ...;
Когда параллельная загрузка стартует, каждый parallel execution server producer (процесс параллельной обработки извлекающий("производящий") данные ) выделяет один временный сегмент для загрузки. Временные сегменты будут находиться в одном табличном пространстве, с таблицей или секцией, в которую загружаются данные, и после commit'а временный сегменты будут слиты в основной сегмент при помощи изменения карты extent'ов, т.е. временные сегменты будут внедрены в основной без перемещения данных во второй раз.Следующая схемка иллюстрирует параллельную 4-х потоковую загрузку в 2-х нодовый RAC кластер:
TSM загрузка очень хорошо масштабируется со степенью параллелизма (degree of parallelism = DOP), потому что каждый параллельный процесс (PX server) работает со своим отдельным temp сегментом. Можно заметить что при увеличении DOP растет производительность, обычно, до предела ресурсов CPU или системы ввода-вывода. Тем не менее, существует потенциальный недостаток: каждый временный сегмент станет как минимум одним экстентом, когда вольется в сегмент таблицы или ее секции.Например если мы загрузим с DOP=16 в таблицу вольется, как минимум, 16 новых экстентов, даже если кол-во строк относительно мало. Это может иметь негативное значение по следующим причинам:
- Карты расположения экстентов в сегментах читаются координатором запроса при инициализации параллельного выполнения, т.е. если таблица или секция имеет чрезвычайно большое количество экстентов на ней могут дольше выполняться выборки или обновления, чем на такой же с меньшим количеством экстентов.
- Обрезка экстентов может оставлять достаточно малые промежутки для вставки новых экстентов, что влечет повышенную фрагментацию (обычно называемую "внешней").
- Если используется UNIFORM распределение экстентов, экстенты не обрезаются. В этом случае финальный экстент, созданный во временном сегменте будет частично пустым (кроме случая, когда кол-во строк как раз соответствовало полному заполнению). Статистически, получаем средние 50% пустого места в последнем экстенте каждого временного сегмента загрузки при ее окончании. Для примера если загружаем с DOP 8 в 1Mb UNIFORM экстенты, в среднем получаем 0,5Mb свободного места в каждом temp сегменте или 0,5*8 = 4Mb всего. Если в эту таблицу попадают данные исключительно с direct path load, это место всегда останется пустым ( и, очевидно, будет расти при следующих direct path load операциях).
Эти недостатки могут быть нивелированы при загрузке больших объемов данных относительно нечасто, а небольших объемов данных часто.
High Water Mark Brokering (HWMB)
High water mark brokering (HWMB) может использоваться, если несколько PX процессов могут заполнять один и тот же сегмент таблицы или ее секции. Способ часто используется при заполнении при выполнении direct path loads в несколько секций в 11g или 12c, например :
High Water Mark Brokering (HWMB)
High water mark brokering (HWMB) может использоваться, если несколько PX процессов могут заполнять один и тот же сегмент таблицы или ее секции. Способ часто используется при заполнении при выполнении direct path loads в несколько секций в 11g или 12c, например :
INSERT /*+ APPEND PARALLEL(t1,8) */ INTO sales_copy_partitioned t1 SELECT ...;
Так же это способ по-умолчанию загрузки в один сегмент в 11g при использовании Auto DOP (т.е. при загрузках в не секционированную таблицу или в одну секцию таблицы).
Совмещая high water mark загрузку, новые данные добавляются непосредственно в сегмент, за границу high water mark. В зависимости от DOP и типа параллельного выполнения, выбранного оптимизатором нескольким PX обработчикам может потребоваться вставлять данные в один сегмент. В этой ситуации становится обязательным новую позицию high water mark распределить между множеством параллельных процессов. Это распределение реализуется с помощью использования HV очередей. Каждый сегмент имеет свою HV очередь, каждая очередь используется для записи позиции на которую должна быть сдвинута HWM в момент commit'а транзакции. Очередь гарантирует что многочисленные параллельные процессы не могут подвинуть HWM в одно и тоже время.
Следующая диаграмма представляет собой HWMB загрузку с DOP 4 на одиночном инстансе. Строки отображаются заполняющимися слева-направо и HWM отметка перемещается вправо, вмещая в новые данные.
В целом при HWMB загрузке добавляется меньше экстентов в сегмент таблицы или ее секции, чем при TSM (temp segment merging). Это преимущество важно для систем которые часто используют direct load с большим DOP.
Oracle Database 12c: Hybrid TSM/HWMB
Изменения, внесенные в Oracle 12c Database Release 12.1.0.1 призваны улучшить масштабируемость параллельной direct path load, особенно когда она используется для заполнения одиночных сегментов базы данных, то есть не секционированных таблиц или отдельных секций таблицы. Эти изменения особенно важны в высокопроизводительных системах, которые перемещают и трансформируют данные между не секционированными таблицами и отдельными секциями таблиц. Это также полезно в системах, которые используют загрузку с partition exchange, т.е. наполняют отдельную не секционированную таблицу, а затем встраивают ее в секционированную с помощью partition exchange.
Прежде чем мы рассмотрим, как работает новый подход, вот пример на Oracle 12c, который демонстрирует новое поведение:
INSERT /*+ APPEND PARALLEL(t1,8) */
INTO sales_copy t1 /* sales_copy is not partitioned */
SELECT /*+ PARALLEL(t2,8) */ *
FROM sales t2;
План запроса в 12с будет следующий : ---------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ---------------------------------------------------------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | | | 74 (100)| | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10000 | 999K| 8789K| 74 (2)| 00:00:01 | Q1,00 | P->S | QC (RAND) | | 3 | LOAD AS SELECT (HYBRID TSM/HWMB)| | | | | | Q1,00 | PCWP | | | 4 | OPTIMIZER STATISTICS GATHERING | | 999K| 8789K| 74 (2)| 00:00:01 | Q1,00 | PCWP | | | 5 | PX BLOCK ITERATOR | | 999K| 8789K| 74 (2)| 00:00:01 | Q1,00 | PCWC | | |* 6 | TABLE ACCESS FULL | SALES | 999K| 8789K| 74 (2)| 00:00:01 | Q1,00 | PCWP | | ----------------------------------------------------------------------------------------------------------------------------В плане обратим внимание на конструкцию, которую не встретить до 12с: HYBRID TSM/HWMB. Как следует из названия, это гибридное решение, которое сочетает в себе выгоды temp segment merge и high water mark brokering. Обратите внимание, что Oracle версии
12.1.0.1 использует такой план выполнения, но конструкцию не отображает.
Основная мотивация такого подхода в том, что high water mark brokering имеет недостаток при загрузке данных большим DOP в один сегмент. Единственной HV очереди нужно будет часто обновляться, и здесь, возникает потенциальное место конкуренции, которая становится более серьезной при распределении PX процессов по нодам RAC (Real Application Clusters) систем. Последовательный доступ к загруженной HV очереди может занять много времени, поэтому в Oracle Database 12c реализовано сочетание High Water Mark Brokering (HWMB) с Temp Segment Merge (TSM) для устранение конкуренции (в т.ч. между экземплярами RAC) за HV очередь, уменьшая при этом число новых экстентов, которые создадутся при операции загрузки.
Проиллюстрируем, как работает гибридный TSM / HWMB при параллельной загрузке данных в не секционированные таблицы или в единичный сегмент. Когда инициируется операция параллельной нагрузки, временный сегмент создается для каждого экземпляра, участвующего в загрузке (т.е. создастся 2 сегмента в 2 нодовом RAC, если параллельная загрузка распределяется по всему кластеру). В каждый временный сегмент могут писать несколько PX процессов, но главное, что в один временный сегмент пишут процессы только одного экземпляра. Таким образом, HV очередь, связанная с каждым временным сегментом, действует локально для каждого экземпляра БД, и не требует распределения по всему кластеру.
Следующая схема отражает Hybrid TSM/HWMB загрузку с DOP=4 на 2-х нодовый RAC кластер:
- Высокая масштабируемость, особенно с большим DOP и в RAC окружении.
- Меньше табличных экстентов, создаваемых при загрузке, особенно важно при частой загрузке с большим DOP.
- Снижения риска "разбухания" табличных карт экстентов и, как следствие, снижения производительности PX процедур.
В Oracle 12c:
- Параллельные create table as select, INSERT, MERGE операции используют Hybrid TSM/HWMB вместо TSM загрузки в единичный сегмент. Это используется и при AutoDOP и с обычным DOP.
- TSM продолжает быть актуальным для секционированных таблиц создающихся с create table as select, так как этот подход хорошо масштабируется и операция выполняется единоразово, что позволяет избегать проблем с фрагментацией места и разбуханием экстентов.
- Hybrid TSM/HWMB также используется вместо TSM для некоторых сегментированных таблиц в create table as select операциях.
- Особенно распределения пространства в планах выполнения с Oracle 12.1.0.2 LOAD AS SELECT дополняется кляузами “TEMP SEGMENT MERGE”, “HIGH WATER MARK BROKERED”, “HIGH WATER MARK”, “HYBRID TSM/HWMB” или “EQUI-PARTITION”.
Если вас интересуют примеры или Вы сами хотите поэкспериментировать с поведением - можете найти некоторые скрипты от автора (Nigel Bayliss) на Github.
No comments :
Post a Comment