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

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

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

24.12.2024 21:23

IgorM23 2 737 Источник

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД 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 можно скачать по следующей ссылке.

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

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

heccrbq
26.12.2024 06:28
#27715072
У вас тут очепятка:

SELECT * SYS.FROM
1. IgorM23 Автор
  26.12.2024 06:28
  #27715074
  Спасибо.
  
  Поправил!