Введение
В последнее время наблюдается рост интереса заказчиков к миграции СУБД 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).
Аналогичным образом данные хранятся на диске и в памяти - в блоках данных СУБД 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 производятся следующие операции:
Предварительно создается пустая БД (не содержит пользовательских табличных пространств) на целевой платформе;
Табличные пространства для переноса на исходной БД переводятся в режим “только для чтения” (read only);
Экспортируются метаданные сегментов в этих табличных пространствах с помощью утилиты Datapump Export;
Файлы данных и дамп-файл с метаданными, сформированный на предыдущем шаге, копируются на целевой сервер;
Производится импорт метаданных в целевую БД с помощью утилиты Datapump Import – табличные пространства подключаются к целевой БД;
Табличные пространства переводятся в режим “read write”.
На вышеприведенном Рис. 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.
Необходимо отметить следующие особенности использования технологии транспортируемых табличных пространств для миграции БД между платформами:
До Oracle Database 19c существовало несколько ограничений по типам данных в таблицах для переноса, например не поддерживался перенос таблиц с столбом типа XMLType;
Если перенос осуществляется между БД с разными Endian, например: с IBM AIX на Linux x86, то необходима конвертация файлов данных с помощью команды CONVERT утилиты Oracle RMAN, либо с помощью встроенного системного пакета DBMS_FILE_TRANSFER, который производит конвертирование блоков на “лету” в момент копирования файла на целевую БД;
Переносятся только сегменты (таблицы, индексы, мат. представления, и их секции), все остальные метаданные, которые находятся в системном табличном пространстве SYSTEM, НЕ переносятся (например: пакеты PL/SQL, последовательности, представления, определения пользователей и ролей и т.д.); эти метаданные нужно переносить на целевую БД другим способом, например с помощью утилиты Datapump Export с параметром content=metadata_only.
Из всего вышеизложенного, следует, что для миграции с RISC-платформ на Linux x86 с помощью транспортируемых табличных пространств, требуется очень большое время простоя (downtime).
На Рис. 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), при восстановлении полной резервной копии или применении инкрементального бэкапа, конвертация блоков на целевой платформе будет выполнена автоматически.
Помимо миграции с 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).
Игорь Мельников
Независимый консультант