Можно ли использовать соединения с прямыми путями?

Question

Я попытался найти примеры, но все они просты с одним условием where.Здесь ситуация.У меня есть куча устаревших данных, перенесенных из другой базы данных.У меня также есть «хорошие» таблицы в той же базе данных.Мне нужно перенести (преобразование данных) данные из устаревших таблиц в таблицы.Поскольку это другой набор таблиц, для преобразования данных требуются сложные объединения, чтобы правильно поместить старые данные в новые таблицы.

Итак, старые данные старых таблиц.

Новые таблицы должны иметьстарые данные, но для правильной передачи этих старых данных в новые таблицы требуется много объединений.

Можно ли использовать прямой путь с таким количеством объединений?INSERT SELECT (много объединений) Применяется ли прямой путь к таблицам, которые уже находятся в одной базе данных (передача между таблицами)?Это только для загрузки таблиц из, скажем, текстового файла?

Спасибо.

Answer 1

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

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

Answer 2

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

Позвольте мне уточнить немного. Обычно, когда вы выполняете DML в Oracle, предыдущие изображения изменений, которые вы делаете, регистрируются в UNDO, и все изменения (включая изменения UNDO) сначала записываются в REDO. Так Oracle управляет транзакциями, восстановлением экземпляров и восстановлением баз данных. Если транзакция отменяется или откатывается, Oracle использует информацию в UNDO, чтобы отменить изменения, сделанные вашей транзакцией. Если экземпляр падает, то при перезапуске Oracle будет использовать информацию в REDO и UNDO для восстановления до последней совершенной транзакции. Сначала Oracle прочтет REDO и выполнит откат, затем с помощью UNDO откатит все транзакции, которые не были зафиксированы во время сбоя. Таким образом, Oracle может восстановить до последней зафиксированной транзакции.

Теперь, когда вы укажете подсказку APPEND для оператора вставки, Oracle выполнит INSERT с прямой загрузкой. Это означает, что данные загружаются в совершенно новые, никогда ранее не использовавшиеся блоки, выше отметки верхнего уровня. Поскольку загружаемые блоки являются совершенно новыми, «образа перед» не существует, поэтому Oracle может избежать написания UNDO, что повышает производительность. Если база данных находится в режиме NOARCHIVELOG, Oracle также не будет писать REDO. В базе данных в режиме ARCHIVELOG Oracle по-прежнему будет писать REDO, если, прежде чем вы добавите / * + добавление * /, вы не установите таблицу в NOLOGGING (т.е. измените таблицу tab_name nologging;). В этом случае ведение журнала REDO для таблицы отключено. Однако именно здесь вы можете столкнуться с последствиями резервного копирования / восстановления. Если вы выполняете прямую загрузку NOLOGGING, а затем у вас возникает сбой носителя, и файл данных, содержащий сегмент с операцией nologging, восстанавливается из резервной копии, созданной до загрузки nologging, тогда журнал повторов будет not содержит изменения, необходимые для восстановления этого сегмента. Итак, что происходит? Что ж, когда вы выполняете загрузку NOLOGGING, Oracle записывает записи отклонения экстента в журнал повторов вместо реальных изменений. Затем, если вы используете это восстановление в процессе восстановления, эти блоки данных будут помечены как логически поврежденные. Любые последующие запросы к этому сегменту получат ошибку ORA-26040.

Итак, как этого избежать? Что ж, вы всегда должны делать резервную копию сразу же после любой прямой загрузки NOLOGGING. Если вы восстановите / восстановитесь из резервной копии, взятой после основной загрузки, проблем не возникнет, поскольку данные будут находиться в блоках данных в файле, который был восстановлен.

Надеюсь, это понятно,

-Марк

Answer 3

Да, не должно быть никаких произвольных ограничений сложности запроса.

Если вы делаете вставить / * + APPEND * / в target_table select .... из источника1, источника2 ..., источникаN, где

Это должно работать нормально. Однако учтите, что производительность нагрузки будет ограничена производительностью этого запроса, поэтому убедитесь, что он хорошо настроен, если вы ожидаете хорошей производительности.

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

Надеюсь, это поможет,

1011 * -Марк *