Можно ли использовать соединения с прямыми путями?
Я пытался найти примеры, но все они просты с одним предложением где. Здесь ситуация. У меня есть куча устаревших данных, перенесенных из другой базы данных. У меня также есть "хорошие" таблицы в той же базе данных. Мне нужно перенести (преобразование данных) данные из устаревших таблиц в таблицы. Поскольку это другой набор таблиц, для преобразования данных требуются сложные объединения, чтобы правильно поместить старые данные в новые таблицы.
Итак, старые таблицы старых данных.
В новых таблицах должны быть старые данные, но для правильной передачи этих старых данных в новые таблицы требуется много объединений.
Могу ли я использовать прямой путь с таким количеством соединений? INSERT SELECT (много объединений) Применяется ли прямой путь к таблицам, которые уже находятся в одной базе данных (передача между таблицами)? Это только для загрузки таблиц из, скажем, текстового файла?
Спасибо.
3 ответа
Нет, наоборот, это означает, что вам нужно сделать резервную копию после загрузки 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, если, прежде чем вы добавите /*+ append */, вы не установите таблицу в NOLOGGING (т.е. измените таблицу tab_name nologging;). В этом случае ведение журнала REDO для таблицы отключено. Однако именно здесь вы можете столкнуться с последствиями резервного копирования / восстановления. Если вы выполняете прямую загрузку NOLOGGING, а затем у вас происходит сбой носителя, и файл данных, содержащий сегмент с операцией nologging, восстанавливается из резервной копии, созданной до загрузки nologging, тогда журнал повторов не будет содержать изменений, необходимых для восстановления этого файла. сегмент. Итак, что происходит? Что ж, когда вы выполняете загрузку NOLOGGING, Oracle записывает записи отклонения экстента в журнал повторов вместо реальных изменений. Затем, если вы используете это восстановление в процессе восстановления, эти блоки данных будут помечены как логически поврежденные. Любые последующие запросы к этому сегменту получат ошибку ORA-26040.
Итак, как этого избежать? Ну, вы всегда должны делать резервную копию сразу же после любой прямой загрузки NOLOGGING. Если вы восстанавливаете / восстанавливаете из резервной копии, созданной после основной загрузки, проблем не возникнет, поскольку данные будут находиться в блоках данных в файле, который был восстановлен.
Надеюсь, это понятно,
-Отметка
Запрос в вашем SELECT может быть настолько сложным, насколько вы хотите с прямой вставкой. Прямой путь относится только к таблице назначения. Это не имеет никакого отношения к способу чтения или обработки данных.
Если вы выполняете прямую вставку, вы просите Oracle вставить новые данные выше верхней отметки таблицы, чтобы обойти обычный код, который повторно использует пространство в существующих блоках для вставки новых строк. Он также должен блокировать другие вставки, так как вы не можете изменить высшую отметку таблицы при вставке с прямым путем. Это, вероятно, не имеет большого значения, если у вас есть окно простоя, в котором выполняется загрузка, но было бы весьма проблематично, если бы вы хотели, чтобы существующие таблицы были доступны для других приложений во время загрузки.
Да, не должно быть никаких произвольных ограничений на сложность запроса.
Если вы вставите /*+ APPEND */ в target_table, выберите.... из source1, source2..., sourceN где
Это должно работать нормально. Однако учтите, что производительность нагрузки будет ограничена производительностью этого запроса, поэтому убедитесь, что он хорошо настроен, если вы ожидаете хорошей производительности.
Наконец, подумайте, может ли установка NOLOGGING на целевой таблице значительно улучшить производительность. Но также учтите последствия восстановления из резервной копии, если вы решите внедрить NOLOGGING.
Надеюсь, это поможет,
-Отметка