Миграция СУБД Oracle с RISC на Linux-x86 с помощью кроссплатформенных переносимых табличных пространств — Часть 1

[Dmitri-D]

На RISC-платформах байты упорядочены от старшего к младшему (Big Endian)

BigEndian - далеко не на всех RISC платформах. На SPARC и IBM - да, а не ARM - совсем не обязательно и почти везде Little endian. На RISC-V - только Little endian.

Существуют CISC (оппоненты RISC) у которых Big Endian - например Motorola 68K.

В общем Endianness - ортогональна RISC/CISC. Может быть и так и так.

[IgorM23]

В статье речь идет о RISC-платформах в контексте миграции БД Oracle на x86. Самые распространенные для Oracle на RISC - это SPARC и IBM Power. Эти платформы имеют формат Big Endian.

Спасибо за замечание!

Я поправил текст: "На большинстве RISC-платформ, прежде всего на самых распространенных, таких как SPARC и IBM Power, байты упорядочены от старшего к младшему (Big Endian), а на Linux x86 — наоборот, от младшего к старшему (Little Endian)."

[adrozhzhov]

А в реальности перенос идет через goldengate...

[IgorM23]

По моему опыту, в абсолютном большинстве случаев, для миграции с RISC на x86, применяется именно транспортируемые табличные пространства. - Если важно уменьшить время простоя.

Если время простоя позволяет, то используется Datapump Export/Import.

Да, GoldenGate применяется, но гораздо реже - с ним много заморочек и много ограничений.

Также требуется наличие отдельной лицензии (если заказчик сейчас за этим следит).

Одно неоспоримое преимущество GG - он позволяет обеспечить практически нулевое время простоя при такой миграции.

[IgorM23]

Да. Я читал эту хорошую статью Алексея Струченко.

Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.

Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.

[Maerzd]

Скриптом М5 поделитесь=)? У меня есть скрипт версии 4.7, когда тех.поддержка была успел скачать , он не рабочий=)) пришлось самому писать для миграции.

Если есть необходимость например для теста или создания копии продуктивной БД, то БД можно не переводить на последнем шаге в режим read only, но на первом шаге нужно делать бэкап с параметрами "backup for transport allow inconsistent incremental level 0 format...."

[alexmib]

Ап! ;-)

https://habr.com/ru/companies/jetinfosystems/articles/523326/

[IgorM23]

Да. Я читал эту хорошую статью Алексея Струченко.

Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.

Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.

[unreal_undead2]

Сначала прочитал в заголовке про миграцию с x86 на RISC V, потом понял, что немного опередил время )

[Kumotori]

Допустим, мы хотим объединить две задачи - смигрировать между платформами и разделить базу данных на несколько независимых по функционалу, на основе отдельных схем (schema).
Правильно я понимаю, что в этом случае FTEX (F=Full) нам будет только мешать, пытаясь перенести сущности из табличного пространства SYSTEM, не связанные с целевой схемой или набором схем?
Или вся цепочка зависимостей полностью отслеживаются по каждой конкретной схеме?
... хотя в это случае могут быть зацикливания, которые кроме как "руками" не решить.

[IgorM23]

Технология FTEX для этой задачи не подойдет, поскольку при ее использовании переносится вся БД целиком с всеми схемами. Я бы разделил Вашу задачу на два этапа:

1. Миграция всей БД с RISC на Linux 86

2. Разделение базы на несколько с помощью, например, технологии Oracle Datapump Export/Import.