Введение

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

Было отмечено, что для упрощения межплатформенной миграции с помощью транспортируемых табличных пространств с инкрементальными резервными копиями, компания Oracle предоставляет набор готовых perl-скриптов - в документе "V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)”.

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

Переход с RISC-платформ на Linux x86 c помощью скриптов миграции M5

Для упрощения миграции БД с сменой Endian, компания Oracle предоставляет новый набор скриптов M5:M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)

Данные скрипты включают в себя все последние улучшения в технологии Oracle FTEX.

Стоит отметить, что скрипты M5 реализованы на языке программирования bash schell, без использования скриптов на perl. Объем M5-скриптов (в строках кода) в несколько раз меньше, чем вариант perl-скриптов для V4.

M5-скрипты поддерживают:

• encrypted табличные пространства;

• мультисекционные бакапы;

• миграцию множества БД в одну CDB одновременно;

• компрессию в backup sets;

• улучшенный паралеллизм;

• БД-источник может быть как Non-CDB так и PDB;

• БД-приемник также может быть как Non-CDB, так и PDB.

Дополнительно, для миграции с помощью скриптов M5, целевая БД должна иметь включенный режим Oracle Managed Files (OMF) - должен быть выставлен параметр DB_CREATE_FILE_DEST.

Шаги миграции с использованием скриптов-M5

Набор скриптов M5 состоит из следующих файлов:

• dbmig_driver_m5.sh – основной скрипт;

• impdp.sh – скрипт, выполняющий подключение табличных пространств к целевой БД;

• dbmig_ts_list.txt – файл конфигурации с списком переносимых табличных пространств, так как используется FTEX, то здесь должны быть включены все табличные пространства, кроме системных;

• dbmig_driver.properties - файл конфигурации, в котором прописываются все необходимые для работы скриптов настройки

Использование скрипта M5 состоит из следующих этапов:

1. Подготовка к миграции;

2. Получение полной резервной копии пользовательских табличных пространства, их копирование и конвертация на целевой БД;

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

4. Подключение новых табличных пространств к целевой БД и импортом всех метаданных;

5. Финальные пост-миграционные операции на целевой БД.

Подготовка

1. подключение NFS-диска к хосту с БД-источником и к хосту с БД- приемником, можно обойтись без NFS-диска, но в этом случае придеться вручную копировать резервные копии и конфигурационные файлы между серверами;

2. oтредактировать файл конфигурации dbmig_driver.properties;

3. на сервере Linux x86 создать и подготовить пустую БД;

Получение и восстановление “горячей” полной резервной копии

Основные действия начинаются с запуска скрипта dbmig_driver_m5.sh на исходном RISC-сервере

$> dbmig_driver_m5.sh L0  

Данный скрипт, согласно настройкам в файле dbmig_driver.properties, создает полную резервную копию БД, а также создает скрипт restore_L0_<source_sid>_<timestamp>.cmd для утилиты RMAN, для последующего восстановления и конвертации файлов данных на сервере с Linux x86.

При выполнения скрипта dbmig_driver_m5.sh, выдает детальная информация о создании резервной копии, в том числе, показывается итоговая статистика создания резервной копии: время выполнения, объем обработанных данных.

SCN, на который была создана полноя резервная копия (RMAN Level 0 backup), записывается в специальный файл .next_scn. Данный SCN будет использоваться для последующих итерационных созданий инкрементальных резервных копий (RMAN Level 1 backup).

Если NFS-диск не используется, то потребуется перенести на целевой сервер файлы резервной копии и сформированный скрипт для RMAN restore_L0__.cmd Далее, используя данный скрипт, следует выполнить воcстановление БД на целевом сервере Linux x86.

  $> rman target / @restore_L0_orcl_2040415224825.cmd

После выполнения скрипта RMAN, требуется проконтролировать восстановление по логам команды RMAN.

Следует обратить внимание, что в управляющем скрипте утилиты RMAN явно отсутствует команда CONVERT, а всего лишь присутствует команда восстановления полной резервной копии:

# target database
RUN
{
ALLOCATE CHANNEL DISK1 DEVICE TYPE DISK FORMAT '...';
ALLOCATE CHANNEL DISK2 DEVICE TYPE DISK FORMAT '...';
RESTORE ALL FOREIGN DATAFILES TO NEW FROM BACKUPSET
'<backup-set-1>',
'<backup-set-2>',
...
'<backup-set-n>'
};

Поскольку конвертация файлов данных c Big Endian на Little Endian производится автоматически.

Получение инкрементальный резервной копии на исходной БД

Запуск создания инкрементальной резервной копии на RISC-сервере также производится через выполнение скрипта dbmig_driver_m5.sh:

  $> dbmig_driver_m5.sh L1

Аналогично, как и при создании полной резервной копии, при создании инкрементальной резервной копии создается управляющий скрипт с именем вида restore_L1_<source_sid>_<timestamp>.cmd для утилиты RMAN.

Вновь созданную инкрементальную резервную копию требуется скопировать и применить на целевой БД на Linux x86:

  $> rman target / @restore_L1_orcl_240416003010.cmd

По окончании восстановления, требуется убедиться в отсутствии ошибок, анализируя журналы выполнения утилиты RMAN.

Точно также, как и в ходе восстановления полной резервной копии, производится автоматическая конвертация блоков инкрементальной резервной копии в Little Endian, перед тем как применять ее к новым табличным пространствам на целевой платформе Linux x86.

Итераций с созданием инкрементальной резервной копии можно выполнить несколько раз, в зависимости от объема изменений в БД-источнике и допустимого времени простоя (downtime). В последний день перед переключением на новую БД, создание инкрементальных резервных копий выполняется несколько раз, чтобы последняя резервная копия получилась минимального размера и, соответственно, ее конвертация и применение выполнятся за минимальное время.

Переключение и время простоя (downtime)

В час “Х” назначается время простоя БД (downtime). В этот период табличные пространства в исходной БД будут переведены в режим Read-Only. Сессии приложения могут использовать исходуню БД на RISC-сервере, но только в режиме Read-Only.

Для выполнения переключения на целевую БД на сервере Linux x86, производится финальный запуск скрипта dbmig_driver_m5.sh на RISC-cервере:

  $> dbmig_driver_m5.sh L1F

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

• Перевод всех табличных пространств, указанных в конфигурационном файле dbmig_ts_list.txt, в режим Read-Only;

• Получение финальной инкрементальной резервной копии - cоздается управляющий файл RMAN для восстановления restore_L1F_<source_sid>_<timestamp>.cmd

• Выгрузка всех метаданных с целевой БД, в том числе и для перемещаемых табличных пространств.

Далее, на целевой БД восстанавливаем последний инкрементальный бакап, используя управляющий файл RMAN.

  $> rman target \ @restore_L1F_orcl_240418005511.cmd

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

• ORACLE_HOME – каталог ORACLE_HOME целевой БД на сервере Linux x86;

• ORACLE_SID – SID целевой БД;

• ORACLE_CONNECT_STRING – строка подсоединения;

• DATA_PUMP_DIR=DATA_PUMP_DIR - Data Pump directory

При запуске скрипта impdp.sh указываются 3 параметра:

1. Дамп файл, полученный в ходе выполнения expdp на исходном сервере

2. Лог последнего востановления на целевой БД (используется для получения списка файлов данных, которые будут подключаться)

3. Константа test или run. Если указать test, то просто будет создан файл параметр для утилиты Datapump Import (impdp). При указании run , файл параметров для утилиты Datapump Import также будет сгенерирован, и затем произойдет вызов утилиты impdp с этим параметром.

Следует обязательно проверить результат в лог-файле.

По окончанию, метаданные в целевую БД перенесены, новые табличные пространства подключены и доступны. Целевая БД готова к использованию!

Финальные пост-миграционные операции на целевой БД на Linux x86

1. Вручную удалить точку восстановления (restore point) в целевой БД после миграции (эта точка автоматически создается в самом начале работы скрипта impdp.sh);

2. Собрать статистику (Table, Index,Column Usage), так как она исключается в M5-скрипте по умолчанию, либо загрузить статистику из stage-таблицы, если статистика была скопирована в stage-таблицу на БД источнике;

3. Создать полную резервную копию БД на сервере с Linux x86, и удалить резервные копии, которые использовались в ходе миграции, лучше это выполнять через утилиту RMAN, чтобы этой информации не осталось в каталоге RMAN.

Для удаления резервных копий на сервере Linux x86 используются следующие команды RMAN:

• DELETE

• CHANGE ... UNCATALOG

Cкрипты M5 в сочетании с технологией Full Transportable Export/Import позволяют значительно упростить миграцию БД Oracle с RISC на Linux x86. Несмотря на это, особенно при миграции крупных БД, содержащих сотни тысяч объектов, возникает ряд проблем.

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