Введение

В последнее время наблюдается рост интереса заказчиков к миграции СУБД Oracle Database с RISC-платформ (прежде всего это платформы Oracle SPARC и IBM Power) на Linux x86.

Этому способствует много причин. Oracle прекратил развитие SPARC-архитектуры, RISC-сервера в несколько раз дороже x86-серверов, комплектующие к ним стоят в несколько раз дороже, чем для x86-серверов. В то же время, платформа x86, благодаря стараниям компании AMD, за последние годы получила бурное развитие: на рынке стали доступны относительно недорогие 2-х сокетные системы с 128 процессорными ядрами, что суммарно дает 256 ядер на сервер (512 потоков с включенной технологией AMD SMT).

Также унификация аппаратного обеспечения инфраструктуры ПО (баз данных и серверов приложений) с помощью широко распространенной платформы Linux x86, значительно упрощает ее сопровождение и стоимость. Также устраняется зависимость от одного вендора, то есть от производителя RISC-серверов.

В данной статье будет подробна описана миграция СУБД Oracle Database с
RISC-платформ на Linux x86 с минимальным временем простоя с помощью
кроссплатформенных переносимых табличных пространств (Crossplatform
Transportable Tablespaces).

Различие в форматах хранения на x86 и на распространенных RISC-платформах

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

Рис. 1 Различие хранения данных на платформах RISC и x86
Рис. 1 Различие хранения данных на платформах RISC и x86

Аналогичным образом данные хранятся на диске и в памяти - в блоках данных СУБД Oracle Database.

Таким образом, для миграции БД Oracle с RISC-платформы на Linux x86, просто скопировать файлы данных недостаточно – необходима конвертация блоков в файлах данных, то есть нужно “переставить” байты в обратном порядке.

Узнать порядок байтов в БД Oracle Database, можно с помощью следующего SQL-запроса:

SELECT 
   p.endian_format
 FROM 
   v$transportable_platform p,
   v$database                       d
 WHERE
   p.platform_id = d.platform_id;

Миграция с помощью транспортируемых табличных пространств

Технология транспортируемых табличных пространств хорошо и давно известна администраторам баз данных Oracle. Ее суть заключается в возможности просто скопировать файлы данных табличных пространств с одного сервера на другой, с дальнейшим подключением этих файлов к другой БД.

В ходе перемещения табличных пространств в рамках одного и того же Endian, например, с Windows на Linux или  c Solaris x86 на Linux x86 производятся следующие операции:

  1. Предварительно создается пустая БД (не содержит пользовательских табличных пространств) на целевой платформе;

  2. Табличные пространства для переноса на исходной БД переводятся в режим “только для чтения” (read only);

  3. Экспортируются метаданные сегментов в этих табличных пространствах с помощью утилиты Datapump Export;

  4. Файлы данных и дамп-файл с метаданными, сформированный на предыдущем шаге, копируются на целевой сервер;

  5. Производится импорт метаданных в целевую БД с помощью утилиты Datapump Import – табличные пространства подключаются к целевой БД;

  6. Табличные пространства переводятся в режим “read write”.

Рис. 2 Миграция БД на платформу с одинаковым Endian
Рис. 2 Миграция БД на платформу с одинаковым Endian

На вышеприведенном Рис. 2, транспортируемые табличные пространства используются для миграции БД с платформы Windows x86 на Linux x86 c одновременным апгрейдом версии СУБД Oracle Database с 11.2.0.4 до 19.23.

Необходимо отметить, что множество перемещаемых табличных пространств должно быть замкнуто (self-contained). Предполагается что перемещаются все пользовательские табличные пространства, и в табличных пространствах SYSTEM и SYSAUX НЕТ пользовательских сегментов.

При миграции БД c RISC-платформы на Linux x86 добавляется шаг конвертация файлов данных, поскольку эти платформы имеют разный Endian.

При копировании файлов данных, все они должны быть согласованными с помощью перевода табличных пространств в режим Read-only. Копирование файлов данных можно сделать несколькими способами: RMAN backup (Image Copy), утилитами копирования операционной системы или с помощью встроенного системного PL/SQL-пакета DBMS_FILE_TRANSFER.

Необходимо отметить следующие особенности использования технологии транспортируемых табличных пространств для миграции БД между платформами:

  1. До Oracle Database 19c существовало несколько ограничений по типам данных в таблицах для переноса, например не поддерживался перенос таблиц с столбом типа XMLType;

  2. Если перенос осуществляется между БД с разными Endian, например: с IBM AIX на Linux x86, то необходима конвертация файлов данных с помощью команды CONVERT утилиты Oracle RMAN, либо с помощью встроенного системного пакета DBMS_FILE_TRANSFER, который производит конвертирование блоков на “лету” в момент копирования файла на целевую БД;

  3. Переносятся только сегменты (таблицы, индексы, мат. представления, и их секции), все остальные метаданные, которые находятся в системном табличном пространстве SYSTEM, НЕ переносятся (например: пакеты PL/SQL, последовательности, представления, определения пользователей и ролей и т.д.); эти метаданные нужно переносить на целевую БД другим способом, например с помощью утилиты Datapump Export с параметром content=metadata_only.

Из всего вышеизложенного, следует, что для миграции с RISC-платформ на Linux x86 с помощью транспортируемых табличных пространств, требуется очень большое время простоя (downtime).

Рис. 3 Полный цикл миграции БД с IBM AIX for Power на Oracle Linux for x86 с конвертацией Endian
Рис. 3 Полный цикл миграции БД с IBM AIX for Power на Oracle Linux for x86 с конвертацией Endian

На Рис. 3 приведен полный цикл миграции, включая перенос метаданных и конвертацию файлов БД с помощью RMAN, базы данных с IBM AIX for Power на Oracle Linux x86. Дополнительно производится обновлении версии Oracle Database Release Update с 19.9 на 19.23.

Миграция с помощью транспортируемых табличных пространств и кроссплатформенных резервных копий

C целью уменьшения времени простоя при миграции БД c одной платформы на другую, корпорация Oracle, в версии СУБД Oracle Database 11.2.0.4 добавила новую технологию: Cross Platform Incremental Backup. Речь идет о том, что стало возможно конвертировать не только полные копии файлов БД, а также инкрементальные резервные копии.

Это позволяет получить "горячую" полную резервную копию табличных пространств (backup as image copy) на RISC-платформе, сконвертировать и восстановить его на Linux x86. Затем получить "дельту" изменений на RISC-платформе (инкрементальную резервную копию), и сконвертировав ее, применить к табличным пространствам на Linux x86. Данная технология позволяет очень сильно сократить время простоя БД на миграцию.

Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока конвертация инкрементальной резервной копии не начнет умещаться в заданное бизнесом технологическое окно простоя.

Подробно весь процесс миграции с RISC-платформ на Linux x86 с помощью кроссплатформенных инкрементальных резервных копий подробно описан в документе “V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)” службы Oracle Support.

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

Миграция с помощью Full Transportable Export/Import (FTEX)

При миграции с помощью транспортируемых табличных пространств и кроссплатформенных резервных копий было серьезное ограничение: метаданные из табличного пространства SYSTEM нужно было переносить вручную. Еще в Oracle Database 12.1.0.2 была представлена технология Full Transportable Export/Import (FTEX), которая позволяет мигрировать пользовательские табличные пространства и метаданные за один шаг. Практически за один шаг мигрирует целиком вся БД. Но было существенное ограничение: целевая БД должна была иметь тот же Endian, что и исходная БД.

И вот, наконец, в Oracle Database 19c это ограничение было снято – миграцию с помощью Full Transportable Export/Import можно теперь делать между базами с разными Endian.

Миграция с помощью технологии Full Transportable Export/Import (FTEX), имеет следующие преимущества по сравнению с традиционным перемещением табличных пространств с инкрементальными резервными копиями:

  • Переносятся все метаданные БД целиком:

    • профили

    • публичные dblink и синонимы

    • directories

    • triggers, кроме принадлежащих SYS

    • SQL Management Base (SQL plan baselines, plan directives)

  • Полностью автоматическое создание метаданных;

  • Легко в использовании, например: не нужно явно выполнять команду конвертации файлов в RMAN (CONVERT), при восстановлении полной резервной копии или применении инкрементального бэкапа, конвертация блоков на целевой платформе будет выполнена автоматически.

Рис. 4 Упрощение миграции с помощью FTEX
Рис. 4 Упрощение миграции с помощью FTEX

Помимо миграции с RISC-платформ на Linux x86, FTEX может использоваться и для решения других задач:

  • апгрейд на новый релиз или Release Update СУБД Oracle Database;

  • миграцию между non-CDB и PDB;

  • миграцию между платформами с одинаковыми Endian (Например Windows -> Linux).

Для использовании технологии FTEX, для миграции с RISC на x86, необходимо, чтобы исходная и целевая базы данных удовлетворяли следующим требованиям по установленным версиям ПО:

  • установлен Oracle Database Release Update 19.18 и выше;

  • также установлен соответствующий Datapump Bundle Patch.

Помимо требований к версии БД, для использования FTEX, также должны выполняться следующие условия:

  • Целевая БД должна иметь значение COMPATIBLE тот же или выше, что и исходная БД;

  • Целевая БД должна иметь тот же Character Set что и исходная;

  • В целевой БД рекомендуется иметь TimeZone-файл той же версии, что и в исходной БД;

  • При наличии типов TIMESTAMP WITH LOCAL TIME ZONE, параметр DBTIMEZONE должен быть одинаковым.

В второй части статьи будет подробно рассмотрена миграция БД Oracle Database с RISC на x86 с помощью скриптов нового поколения от Oracle (M5).

Игорь Мельников

Независимый консультант

Комментарии (11)


  1. Dmitri-D
    03.08.2024 23:54
    +2

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

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

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

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


    1. IgorM23 Автор
      03.08.2024 23:54

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

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

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


  1. adrozhzhov
    03.08.2024 23:54

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


    1. IgorM23 Автор
      03.08.2024 23:54

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

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

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

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

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


  1. IgorM23 Автор
    03.08.2024 23:54

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

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

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


    1. Maerzd
      03.08.2024 23:54

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

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


  1. alexmib
    03.08.2024 23:54

    Ап! ;-)

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


    1. IgorM23 Автор
      03.08.2024 23:54

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

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

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


  1. unreal_undead2
    03.08.2024 23:54

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


  1. Kumotori
    03.08.2024 23:54

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


    1. IgorM23 Автор
      03.08.2024 23:54

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

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

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