В первой части статьи была рассмотрена основная проблема при миграции СУБД 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 состоит из следующих этапов:
- Подготовка к миграции;
- Получение полной резервной копии пользовательских табличных пространства, их копирование и конвертация на целевой БД;
- Получение инкрементальной резервной копии пользовательских табличных пространства, его копирование, конвертация и применение на целевой БД (выполняется несколько раз для снижения времени простоя);
- Подключение новых табличных пространств к целевой БД;
- Финальные пост-миграционные операции на целевой БД.
Подготовка
- Подключение NFS-диска к хосту с БД-источником и к хосту с БД- приемником, можно обойтись без NFS-диска, но в этом случае придеться вручную копировать резервные копии и конфигурационные файлы между серверами;
- oтредактировать файл конфигурации dbmig_driver.properties;
- на сервере 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_
$> 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.
Вновь созданную инкрементальную резервную копию требуется скопировать и применить на целевой БД:
$> 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 параметра:
- Дамп файл, полученный в ходе выполнения expdp на исходном сервере
- Лог последнего востановления на целевой БД (используется для получения списка файлов данных, которые будут подключаться)
- Константа test или run. Если указать test, то просто будет создан файл параметр для утилиты Datapump Import (impdp). При указании run , файл параметров для утилиты Datapump Import также будет сгенерирован, и затем произойдет вызов утилиты impdp с этим параметром.
Следует обязательно проверить результат в лог-файле.
По окончанию, метаданные в целевую БД перенесены, новые табличные пространства подключены и доступны. Целевая БД готова к использованию!
>Финальные пост-миграционные операции на целевой БД
- Вручную удалить точку восстановления (restore point) в целевой БД после миграции (эта точка автоматически создается в самом начале работы скрипта impdp.sh);
- Собрать статистику (Table, Index,Column Usage), так как она исключается в M5-скрипте по умолчанию, либо загрузить статистику из stage-таблицы, если статистика была скопирована в stage-таблицу на БД источнике;
- Создать полную резервную копию БД на сервере с Linux x86, и удалить резервные копии, которые использовались в ходе миграции, лучше это выполнять через утилиту RMAN, чтобы этой информации не осталось в каталоге RMAN.
Для удаления резервных копий на сервере Linux x86 используются следующие команды RMAN:
- DELETE
- CHANGE ... UNCATALOG
Cкрипты M5 в сочетании с технологией Full Transportable Export/Import позволяют значительно упростить миграцию БД Oracle с RISC на Linux x86. Несмотря на это, особенно при миграции крупных БД, содержащих сотни тысяч объектов, возникает ряд проблем.
В заключительной, третьей части статьи, будут описаны проблемы, которые возникли на многочисленных реальных проектах, и приведены способы их решения.
Игорь привет!!! Очень рад, что ты начал опять писать!
ОтветитьУдалитьГена