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

Введение

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

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

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

Необходимость создания данной, четвертой части статьи, возникла потому-что не был рассмотрен новый способ миграции с помощью транспортируемых табличных пространств. Эта технология появилась начиная с Oracle Database 12.2, и позволяет еще больше упростить миграцию.

Кросплатформенное копирование табличных пространств по сети

Начиная с версии Oracle Database 12.2 появилась новая технология: RMAN Cross Platform Tablespace Transport Over Network.
Описание данной технологии приведено в документе службы Oracle Support: «12.2 RMAN Cross Platform Tablespace Transport Over Network (Doc ID 2307383.1)».

Идея заключается в том, что файлы данных и инкрементальные резервные копии копируются на целевую БД напрямую по сети (по протоколу SQL*Net). Это исключает необходимость наличия промежуточной системы хранения для резервных копий, также поддерживается миграция в случае если целевая БД расположена на ASM.
В процессе копирования автоматически определяется Endian (порядок байтов в машинном слове) и, если он различается на исходной и целевой БД, автоматически
происходит конвертация блоков в другой Endian.

Для реализации такой миграции в утилите RMAN появились две новые команды:

«restore foreign datafile .. from service … » и «recover foreign datafilecopy … from«

Первая команда фактически копирует файлы данных с исходной БД на целевую с конвертацией Endian — аналог команд создания полной резервной копии в формате «image copy«, ее копирования на целевую БД и выполнение команды convert.

Вторая команда автоматически определяет с какого момента времени (SCN) нужно получить инкрементальную резервную копию на исходной БД, формирует эту резервную копию, копирует ее на целевой сервер, автоматически конвертирует Endian и применяет к файлу данных.

Применение на практике

Для начала, необходимо на целевой БД на платформе Linux, создать TNS-алиас для подключения к целевой БД на RISC-платформе.
В данном примере в файле tnsnames.ora на сервере с Linux x86 определяется TNS-алиас с «говорящим» названием для подключения к целевой БД на Solaris SPARC.

solaris =    (DESCRIPTION =      (ADDRESS_LIST =        (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.127)(PORT = 1521))      )      (CONNECT_DATA = (SERVICE_NAME = orcl))   ) 

Проверяем, что подключение с сервера на Linux x86 к БД на Solaris SPARC успешно работает:

[oracle@localhost ~]$ sqlplus system/oracle@solaris  SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 14 13:49:40 2024 Version 19.25.0.0.0  Copyright (c) 1982, 2024, Oracle.  All rights reserved.  Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production  SQL> SELECT                d.platform_name,                p.endian_format      FROM        v$transportable_platform p,           v$database d        WHERE           p.platform_id = d.platform_id;   PLATFORM_NAME             ENDIAN_FORMAT -----------------------   ------------- Solaris[tm] OE (64-bit)   Big  

Внимательный читатель обратил внимание, что исходная БД на платформе Solaris SPARC имеет версию 12.2, а целевая БД на платформе Linux x86 — версию 19.25. Это означает, что при миграции возможно неявно провести апгрейд БД до более высокой версии!

Определяем список файлов данных для миграции:

SQL> SELECT file#, name FROM v$datafile;  /u01/app/oracle/oradata/ibs/system01.dbf  3 /u01/app/oracle/oradata/ibs/sysaux01.dbf  4 /u01/app/oracle/oradata/ibs/undotbs01.dbf  7 /u01/app/oracle/oradata/ibs/users01.dbf 

Стоит напомнить, что переноситься на другую платформу и конвертироваться могут только файлы табличных пространств с пользовательскими данными.
Таким образом, нам нужно мигрировать только файл данных под номером 7, из которого состоит табличное пространство USERS.

Проверим табличное пространство USERS на замкнутость (self contained):

SQL> exec sys.dbms_tts.TRANSPORT_SET_CHECK('USERS',true,true);  PL/SQL procedure successfully completed.  SQL> SELECT * FROM SYS.TRANSPORT_SET_VIOLATIONS;  no rows selected

Табличное пространство USERS замкнуто: можно начинать его мигрировать на другую платформу.

Запускаем утилиту RMAN и подключаемся к целевой БД на платформе Linux x86 (Oracle Linux 9.4 на процессорах AMD):

[oracle@localhost ~]$ lscpu | grep Model Model name:                           AMD EPYC 7702P 64-Core Processor Model:                                49 [oracle@localhost ~]$  rman target sys/oracle@linux  Recovery Manager: Release 19.0.0.0.0 - Production on Sat Dec 14 15:23:02 2024 Version 19.25.0.0.0  Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.  connected to target database: ORCL (DBID=1703490175) 

Для копирования и конвертации файлов по сети, в утилите RMAN версии 12.2+ появилась новая команда «restore foreign datafile … from service«.
Копируем файл данных с БД на платформе Solaris for SPARC на БД на платформе Linux x86:

RMAN> restore foreign datafile 7 format '/oradata/ORCL/users01.dbf' from service solaris;  Starting restore at 14-DEC-24 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK  channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service solaris channel ORA_DISK_1: specifying datafile(s) to restore from backup set  channel ORA_DISK_1: restoring foreign file 7 to /oradata/ORCL/users01.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:04:15 Finished restore at 14-DEC-24 

Следует отметить, что копирование файла данных и его конвертации происходит без останова исходной БД и перевода табличного в режим «только для чтения»!
Если на целевой БД для управления файлами данных используется OMF (Oracle Management Files), то вместо фразы FORMAT следует использовать опцию NEW:

RMAN> restore foreign datafile 7 to new from service solaris; Starting restore at 14-DEC-24 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=21 device type=DISK  channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service solaris channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring foreign file 7 to /oradata/ORCL/datafile/o1_mf_users_mov1kc19_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:04:15 Finished restore at 14-DEC-24

Убедимся, что новый файл данных появился на файловой системе ОС Linux:

[oracle@localhost ~]$ ll /oradata/ORCL/users01.dbf -rw-r-----. 1 oracle oinstall 3102482432 Dec 14 15:31 /oradata/ORCL/users01.dbf [oracle@localhost ~]$

Поскольку, файл данных на целевой БД не согласован, а также за период копирования и конвертации файлов данных пользователи продолжали работу с исходной БД, в ней накопился определенный объем изменений.
Перенесем эти изменения в файлы данных на целевом сервере, с помощью новой команды утилиты RMAN «recover foreign datafilecopy … from service»:

RMAN> recover foreign datafilecopy '/oradata/ORCL/users01.dbf' from service solaris; recover foreign datafilecopy '/oradata/ORCL/users01.dbf' from service solaris; Starting recover at 14-DEC-24 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=25 device type=DISK channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: using network backup set from service solaris channel ORA_DISK_1: restoring foreign file 00007 to /oradata/ORCL/users01.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:01:45 Finished recover at 14-DEC-24

Утилита RMAN автоматически определяет с какого момента времени (SCN) нужно получить инкрементальную резервную копию на исходной БД, копирует эту резервную копию
на целевой сервер, автоматически конвертирует в Litle Endian и применяет к файлу данных.

Серией последовательных выполнений команды «recover foreign datafilecopy … from service» мы добиваемся минимального расхождения в данных на исходной и целевой БД.
Наконец в назначенное время, табличное пространство на исходной БД переводится в режим «только для чтения»:

[oracle@localhost ~]$ sqlplus system/oracle@solaris  SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 14 15:51:12 2024 Version 19.25.0.0.0  Copyright (c) 1982, 2024, Oracle.  All rights reserved.  Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production  SQL> alter tablespace  users read only;  Tablespace altered.

Получаем с исходной БД последнюю инкрементальную копию и применяем ее на целевой БД с автоматической конвертацией:

RMAN> recover foreign datafilecopy '/oradata/ORCL/users01.dbf' from service solaris; Starting recover at 14-DEC-24 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=25 device type=DISK channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: using network backup set from service solaris channel ORA_DISK_1: restoring foreign file 00007 to /oradata/ORCL/users01.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished recover at 14-DEC-24

Теперь все готово для подключения нового табличного пространства (соответствующих файлов данных) к целевой БД.
Для упрощения работы созданим db-линк с целевой БД на исходную:

SQL> create public database link solaris connect to system identified by oracle using 'solaris';  Database link created.

Подключаем новое табличное пространство к целевой БД. Для этого используется утилита impdp с параметрами transport_tablespaces и transport_datafiles.
Передача с целевой БД метаданного табличного пространства и их загрузка в целевую БД происходит прямо по сети (параметр network_link), без формирования промежуточного файла дампа:

[oracle@localhost ~]$ impdp system/oracle network_link=solaris transport_tablespaces=USERS transport_datafiles='/oradata/ORCL/users01.dbf'  Import: Release 19.0.0.0.0 - Production on Sat Dec 14 16:03:27 2024 Version 19.25.0.0.0  Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.  Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Starting "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01":  system/******** network_link=solaris transport_tablespaces=USERS transport_datafiles=/oradata/ORCL/users01.dbf Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK Processing object type TRANSPORTABLE_EXPORT/TABLE Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS Processing object type TRANSPORTABLE_EXPORT/STATISTICS/MARKER Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK Job "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully completed at Sat Dec 14 16:04:12 2024 elapsed 0 00:00:42

Миграция успешно завершена и новое табличное пространство и соответствующий файл данных доступны для работы на целевой платформе на Linux x86:

 SELECT    t.name as tablespace_name,    d.file#,     d.name  FROM     v$datafile   d,    v$tablespace t  WHERE   d.ts#  = t.ts# and   t.name = 'USERS';  TABLESPACE_NAME                     FILE# NAME ------------------------------ ---------- --------------------------- USERS                                   5 /oradata/ORCL/users01.dbf 

Автоматизация миграции с помощью скрипта M6

Для упрощения миграции больших баз данных, которые содержат большое число табличных пространств и файлов данных, автором был разработан скрипт M6.
Данный скрипт выполняется на исходной БД в среде утилиты SQL*Plus версии 22.4 и выше, и автоматически формирует все необходимые скрипты для
автоматизации миграции с помощью вышеописанного алгоритма.

SQL> @gen_restore help=y ===============================================================================  M6 Scripts: Release 1.0.0.0.1 - Production on 15.12.2024 17:46:53  gen_restore.sql - generate RMAN scripts for datafile conversion during migration  Copyright (c) 2024, Igor Melnikov.  All rights reserved.   You can control how gen_restore.sql runs by entering the "gen_restore" command followed by various arguments. To specify parameters, you use keywords:       Format:  @gen_restore.sql parameter1=value1 parameter2=value2       Example: @gen_restore.sql TABLESPACES=users,users_ind SOURCE_SERVICE=solaris SCRIPT_RESTORE=restore_x86.rcv               @gen_restore.sql SOURCE_SERVICE=ibm_power  Keyword             Description (Default) -------------------------------------------------------- SOURCE_SERVICE_NAME TNS alias for source database on destination server (source_db) TABLESPACES         tablespaces for migration, ALL-for all user-defined tablespaces (ALL) HELP                print this message: Y/N (N) SCRIPT_RESTORE      RMAN script for restore (restore.rcv) SCRIPT_RECOVER      RMAN script for recover (recover.rcv) SCRIPT_READ_ONLY    sql script for read only tablespaces (tbs_ro.sql) SCRIPT_READ_WRITE   sql script for read write tablespaces (tbs_rw.sql) IMPDP_CONFIG        config file for impdp - plug-in tablespaces (tts_plugin.cfg) SOURCE_DB_LINK      Database link on target database to source database (source_db) DEBUG               Debug mode: Y/N (N)

Скрипт автоматически генерирует следующие файлы для миграции с помощью вышеописанного алгоритма:

• скрипт для утилиты RMAN для копирования и восстановления файлов данные с конвертацией Endian на целевой платформе (имя скрипта задается параметром SCRIPT_RESTORE);

• скрипт для утилиты RMAN для копирования и применения инкрементальных резервных копий с конвертацией Endian на целевой платформе (имя скрипта задается параметром SCRIPT_RECOVER);

• скрипт для утилиты SQL*Plus/sqlcl для перевода табличных пространств на исходной БД в режим «только для чтения» (имя скрипта задается параметром SCRIPT_READ_ONLY);

• скрипт для утилиты SQL*Plus/sqlcl для перевода табличных пространств на исходной БД в режим «только чтения-записи (имя скрипта задается параметром SCRIPT_READ_WRITE);

• файл параметров для утилиты impdp, для подключения табличных пространств и файлов данных к целевой БД (имя файла задется параметром IMPDP_CONFIG).

Дополнительно в скрипт можно передать два опциональных параметра:

• имя TNS-алиаса на целевой БД, для подключения к исходной БД (параметр SOURCE_SERVICE_NAME);

• имя database link на целевой БД, который ссылается на исходную БД (необходим для параметра NETWORK_LINK утилиты impdp).

Заключение

Компания Oracle постоянно упрощает процесс миграции СУБД Oracle Database между платформами с разными Endian.
Новые команды утилиты RMAN «restore foreign datafile … from service» и «recover foreign datafilecopy … from service», которые появились в Oracle Database версии 12.2,
позволяют значительно упростить этот процесс.
Забегая вперед, следует отметить, что в новом релизе СУБД Oracle Database 23ai появились новые возможности которые еще больше упрощают этот процесс,
но это уже другая история …

Автор выражает благодарность компании ЭЛЬКАРО^{[ссылка удалена мод.]} за предоставленные для тестирования серверы на платформе Sun Solaris 11.4 for SPARC и Oracle Linux на AMD Epyc.

Скрипт M6 можно скачать по следующей ссылке.

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