Я хочу вставить данные в таблицу unique2 из таблицы unique1 в том же порядке, что и в таблице unique1.Могу ли я указать порядок при вставке данных в оракул?
insert /*+ append */ into unique2
select * from unique1 A where not exists (select 1 from match1 B where A. promolog_key = B. promolog_key) order by rowid asc;
делает вышеуказанный запрос вставляет квалифицированные данные в том же порядке, что и в уникальном1?
благодаря
Oracle позволяет указать ORDER BY пункт в вашем INSERT заявлении и documentation states:
- Что касается пункта
ORDER BYподзапроса вDML_table_expression_clause, заказ гарантируется только для вставляемые строки и только в пределах каждой длины таблицы. Заказ новых строк по отношению к существующим строкам не гарантируется.
Так новые строки будут вставлены в таблицу копирования в том же порядке, как вы укажете в своей статье ORDER BY. Это не влияет на старые строки, которые уже находятся в таблице.
Ограничение по степени может не касаться вас, потому что вы используете подсказку /*+ append */ и поэтому должны вставлять только водяной знак (последовательно, если не параллельную вставку).
Я думаю, что документы правильны только в отношении вставок прямого пути, и даже тогда ссылка на экстенты не совсем правильна. Параллельные вставки прямого пути определяют новые экстенты для каждого ведомого PQ, но вставки последовательного прямого пути нет. Я отправил комментарий читателя на страницу. –
@DavidAldridge Я тоже заинтригован этим ограничением. Он может применяться к стандартным вставкам, где вставленные данные будут заказываться только в каждом вставленном объеме. Я думаю, что вставки последовательного прямого пути безопасны (по крайней мере, это был мой опыт). –
означает ли это, что если я использую прямые вставки пути или вставки прямого пути с параллельной, порядок не будет заимствован? – subash
Да, в общем случае упорядочение физических строк будет одинаковым.
Строка заказа на вставку основана на использовании прямого пути, и это довольно распространенная техника в хранилищах данных или других системах, которые полагаются на нее, чтобы получить выгодные коэффициенты сжатия и/или низкие коэффициенты кластеризации для определенных индексов (которые могут быть сильный драйвер для уменьшения размера индекса растрового изображения).
Функционально, однако, упорядочение по rowid кажется немного сомнительным. Если исходная таблица уже упорядочена по желанию, то продвижение полного сканирования таблицы на origin1 будет выполнять эту работу. В противном случае я бы заказал столбцы (столбцы), которые вы хотите улучшить с помощью кластеризации/сжатия.
Хотя индексированные таблицы или хеш-кластеры дают аналогичный эффект в отношении фактора кластеризации, они имеют ограничения, которые могут оказаться нецелесообразными. В случае с IOT часто бывает полезно с большими вставками упорядочить строки как часть выбора, чтобы получить более эффективное обслуживание в целевой таблице.
Что бы это значило для данных, которые нужно вставить в определенном порядке? Учитывая, что куча организованной таблицы по своей сути неупорядочен, физический порядок строк обычно не имеет смысла. Единственное исключение, о котором я могу думать, было бы, если бы 'unique2' был сжат, и вы пытались получить строки с повторяющимися значениями в одном блоке. Но ваш «порядок по rowid» сильно означает, что это не так. –
«Заказ» не имеет значения, как строки хранятся в таблице, и это разумное усилие, когда вы вводите порядок в свой оператор select для извлечения строк. – Wolf
@JustinCave Порядок строк может существенно повлиять на производительность сканирования индекса, что может оказать значительное влияние на оптимизатор. Я полагаю, что если бы вы захотели скопировать таблицу для целей тестирования, было бы лучше, если бы исходная таблица и ее копия имели одинаковый порядок (конечно, это не только * важный фактор =) –