Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
LAMI DBA
LAMI DBA

Articles autour des SGBD Oracle, SQL Server & PostgreSQL

oracle 12c, Rman, TTS

Oracle 12c : Utiliser RMAN pour faire du Cross Platform Transport tablespace - XTTS

16 Mai 2018

Rédigé par LAMI-DBA et publié depuis Overblog

Dans un environnement multi systèmes, il peut arriver d'avoir à déplacer une base de données oracle entre 2 systèmes différents (par exemple HP UX vers Linux Red Hat), auquel cas plusieurs solutions seraient possibles pour réaliser cette opération.

La première qui vient à l'esprit serait de créer une enveloppe (ie base de données vide) sur le serveur cible et de réaliser un import classique des données via notre ami Datapump.

Cependant, dans le cas d'une base à forte volumétrie, le temps de traitement peut être assez long.

Pour gagner en temps d’exécution il y a une seconde solution, celle de réaliser un export / import datapump avec Transport Tablespace incluant une conversion, au format attendu par le système CIBLE, du datafile lié au tablespace.

Cette méthode se nomme XTTS, ou encore Cross Platform Transport tablespace.

La notion de transport tablespace existe depuis la version 8i, laquelle a considérablement évoluée en version 10g avec la possibilité de réaliser du Cross Platform pour permettre de déplacer des tablespaces sur des systèmes hétérogènes.

 

En release 12.1, la nouveauté réside dans l'utilisation de RMAN à la place de Datapump, ce qui peut avoir un impact très intéressant ET en temps de traitement ET en simplification de commandes, car jusque là il fallait utiliser les deux technologies : Datapump + RMAN.

En effet, auparavant il fallait réaliser les actions suivantes pour arriver au bout du déplacement de notre tablespace :

1 - Placer le tablespace de ma base SOURCE en read-only,
2 - Vérifier que le tablespace ne possède pas d'objets qui seraient dépendants d'un autre tablespace,
3 - Exporter les metadatas du tablespace SOURCE en utilisant datapump (EXPDP),
4-  Convertir le ou les datafile(s) du tablespace SOURCE dans le format de la plate forme CIBLE en utilisant RMAN, soit sur le serveur SOURCE ou soit sur le serveur CIBLE,
5 - Copier le dump contenant les metadatas ainsi que le backupset RMAN (contenant le datafile converti) vers le serveur CIBLE,
6 - Importer les metadatas depuis le dump de la SOURCE sur la base CIBLE en utilisant datapump (IMPDP) avec le paramètre TRANSPORT_TABLESPACE qui pointera alors sur le datafile qui aura été au préalable restauré via RMAN,
7 - Une fois l'import terminé, placer le tablespace de la base CIBLE en Read Write.

Nous allons donc voir à travers cet article comment réaliser un déplacement de tablespace entre une machine HP-UX et un Linux, en utilisant uniquement RMAN pour l'ensemble des actions..

Petit prérequis mais pas des moindres :  Le character set des bases se doit d'être ISO, sinon la restauration RMAN ne fonctionnera pas. C'est d’ailleurs un prérequis en version 11G lorsque datapump est utilisé pour faire du transport tablespace.

En ce qui concerne mon contexte technique :

Base SOURCE nommée ORCL en release 12.1 sur un système HP UX (nom de machine "Joker") et base cible nommée MRSTEST sur un système Oracle Linux 6 (nom de machine "HARLEY") évidemment en release 12.1 également.

Première action, je vais me créer un jeu de test sur ma base source afin de pouvoir vérifier au final sur ma base cible que j'ai bien récupéré mes données.

SQL> create tablespace TEST_XTTS datafile '/applis/list/oracle/ORCL/data1/TEST_XTTS.dbf' size 1G autoextend off ;

Tablespace created.

SQL> create user batman identified by robin profile default account unlock;

User created.

SQL> grant connect,create session to batman;

Grant succeeded.

SQL> alter user batman quota unlimited on TEST_XTTS;

User altered.

SQL> create table batman.flag (dataref number) tablespace TEST_XTTS;

Table created.

SQL> insert into batman.flag select 100 from dual connect by level <=500000;

500000 rows created.

SQL> commit;
Commit complete.

SQL> select count(*) from batman.flag;

  COUNT(*)
----------
   500000

   
Maintenant que j'ai mon jeu de test, je vais identifier les informations des différentes plates formes sur lesquelles il est possible de réaliser un XTTS en interrogeant ma base SOURCE :

SQL> SELECT tp.platform_id, tp.PLATFORM_NAME, ENDIAN_FORMAT,d.name
FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME(+)
ORDER BY name, endian_format, platform_id;  


PLATFORM_ID PLATFORM_NAME                            ENDIAN_FORMAT  NAME
----------- ---------------------------------------- -------------- ---------
          3 HP-UX (64-bit)                           Big            ORCL
          1 Solaris[tm] OE (32-bit)                  Big
          2 Solaris[tm] OE (64-bit)                  Big
          4 HP-UX IA (64-bit)                        Big
          6 AIX-Based Systems (64-bit)               Big
          9 IBM zSeries Based Linux                  Big
         16 Apple Mac OS                             Big
         18 IBM Power Based Linux                    Big
         13 Linux x86 64-bit                         Little
          5 HP Tru64 UNIX                            Little
          7 Microsoft Windows IA (32-bit)            Little
          8 Microsoft Windows IA (64-bit)            Little
         10 Linux IA (32-bit)                        Little
         11 Linux IA (64-bit)                        Little
         12 Microsoft Windows x86 64-bit             Little
         15 HP Open VMS                              Little
         17 Solaris Operating System (x86)           Little
         19 HP IA Open VMS                           Little
         20 Solaris Operating System (x86-64)        Little
         21 Apple Mac OS (x86-64)                    Little


Ma plate forme cible sera "Linux x86 64-bit".

Pour pouvoir débuter les opérations il faut placer le Tablespace TEST_XTTS en READ ONLY :

SQL> alter tablespace TEST_XTTS read only;
Tablespace altered.

Bien, je peux maintenant passer à RMAN pour réaliser un BACKUP de mon datafile dans un format qui sera pris en compte sur ma plate forme cible.

Pour cela deux options : Soit l'on réalise un BACKUP TO PLATFORM ou soit l'on utilise BACKUP FOR TRANSPORT.

La différence entre ces deux commandes est simple, soit la conversion du datafile sera réalisée DEPUIS LA SOURCE (BACKUP TO PLATFORM), soit la conversion du datafile sera réalisée SUR LA CIBLE (BACKUP FOR TRANSPORT).

Dans un cas de production, mieux vaut effectuer la conversion sur la CIBLE pour éviter de monopoliser de la CPU au détriment du workload transactionnel / batch.

Dans cet exemple je vais convertir mon datafile sur la SOURCE puisque c'est du bac à sable, et donc utiliser RMAN avec "BACKUP TO PLATFORM". Par la suite RMAN va réaliser deux actions ou plutôt deux backups, à savoir le backup du datafile qui sera converti pour un système LINUX et le backup des METADATAS, auparavant réalisé par datapump EXPDP.

C'est parti pour la démo !

Depuis ma base SOURCE je lance notre ami RMAN et lance le backup de mon datafile qui sera converti pour une plate forme "Linux x86 64-bit", et ensuite le backup des metadatas :

$ rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Tue May 15 12:08:31 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: OMIDG (DBID=3149487371)

RMAN> backup to platform 'Linux x86 64-bit' as compressed backupset
tablespace TEST_XTTS format '/tmp/tbs_TEST_XTTS.bck'
datapump format '/tmp/metadata_TEST_XTTS.bck';

Starting backup at 15-MAY-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=606 device type=DISK
Running TRANSPORT_SET_CHECK on specified tablespaces
TRANSPORT_SET_CHECK completed successfully

Performing export of metadata for specified tablespaces...
   EXPDP> Starting "SYS"."TRANSPORT_EXP_ORCL_hjus":
   EXPDP> Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
   EXPDP> Processing object type TRANSPORTABLE_EXPORT/TABLE
   EXPDP> Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
   EXPDP> Processing object type TRANSPORTABLE_EXPORT/STATISTICS/MARKER
   EXPDP> Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
   EXPDP> Master table "SYS"."TRANSPORT_EXP_ORCL_hjus" successfully loaded/unloaded
   EXPDP> ******************************************************************************
   EXPDP> Dump file set for SYS.TRANSPORT_EXP_ORCL_hjus is:
   EXPDP>   /applis/list/oracle/product/rdbms/12.1.0.2/dbhome_1/dbs/backup_tts_ORCL_75480.dmp
   EXPDP> ******************************************************************************
   EXPDP> Datafiles required for transportable tablespace TEST_XTTS:
   EXPDP>   /applis/list/oracle/ORCL/data1/TEST_XTTS.dbf
   EXPDP> Job "SYS"."TRANSPORT_EXP_ORCL_hjus" successfully completed at Tue May 15 12:11:28 2018 elapsed 0 00:00:52
Export completed

channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00014 name=/applis/list/oracle/ORCL/data1/TEST_XTTS.dbf
channel ORA_DISK_1: starting piece 1 at 15-MAY-18
channel ORA_DISK_1: finished piece 1 at 15-MAY-18
piece handle=/tmp/tbs_TEST_XTTS.bck tag=TAG20180515T121023 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting compressed full datafile backup set
input Data Pump dump file=/applis/list/oracle/product/rdbms/12.1.0.2/dbhome_1/dbs/backup_tts_ORCL_75480.dmp
channel ORA_DISK_1: starting piece 1 at 15-MAY-18
channel ORA_DISK_1: finished piece 1 at 15-MAY-18
piece handle=/tmp/metadata_TEST_XTTS.bck tag=TAG20180515T121023 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 15-MAY-18


Bien, j'ai donc maintenant 2 backupsets, l'un pour mon datafile converti, et l'autre pour les metadatas :

-rw-r-----. 1 oracle  oinstall 2367488 May 15 12:11 tbs_TEST_XTTS.bck
-rw-r-----. 1 oracle  oinstall  163840 May 15 12:11 metadata_TEST_XTTS.bck

 

On peut d'ailleurs visualiser que notre ami RMAN réalise bien la vérification des potentielles dépendances des objets contenus dans mon tablespace, en appelant la procédure TRANSPORT_SET_CHECK du package DBMS_TTS. Et oui, plus besoin de lancer soit même la vérification !!

A partir de ce moment, nous pouvons copier les deux backupset sur le serveur CIBLE "HARLEY", pour ensuite les restaurer :

Un petit SCP de ces 2 fichiers entre mes 2 machines :

$ scp tbs_TEST_XTTS.bck oracle@harley:/tmp/.
oracle@harley's password:
tbs_TEST_XTTS.bck                                                                                                                              100% 2312KB   2.3MB/s   00:00

$ scp metadata_TEST_XTTS.bck oracle@harley:/tmp/.
oracle@harley's password:
metadata_TEST_XTTS.bck                                                                                                                         100%  160KB 160.0KB/s   00:00

 

Et je peux maintenant lancer directement RMAN depuis mon serveur CIBLE pour restaurer les backupsets.

Notez bien que je spécifie la plate forme SOURCE dans ma ligne de commande de RESTORE.

Attention : il peut arriver que cela plante si toutefois le paramètre DB_CREATE_FILE_DEST ne serait pas positionné. Penser donc à le modifier (en MEMORY) avant de lancer la restauration:

SQL> alter system set DB_CREATE_FILE_DEST='/applis/list/oracle/HARLEY/data1' scope=memory;
System altered.

[oracle@harley tmp]$ rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Tue May 15 12:23:24 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: MRSTEST (DBID=3107102009)

RMAN> restore from platform 'HP-UX (64-bit)'
2> foreign tablespace TEST_XTTS to new
3> from backupset '/tmp/tbs_TEST_XTTS.bck'
4> dump file from backupset '/tmp/metadata_TEST_XTTS.bck';

Starting restore at 15-MAY-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=260 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=33 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring all files in foreign tablespace TEST_XTTS
channel ORA_DISK_1: reading from backup piece /tmp/tbs_TEST_XTTS.bck
channel ORA_DISK_1: restoring foreign file 14 to /applis/list/oracle/HARLEY/data1/HARLEY/datafile/o1_mf_test_xtt_fhoftz2t_.dbf
channel ORA_DISK_1: foreign piece handle=/tmp/tbs_TEST_XTTS.bck
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:16
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring Data Pump dump file to /applis/list/oracle/product/rdbms/12.1.0.2/dbhome_1/dbs/backup_tts_MRSTEST_65249.dmp
channel ORA_DISK_1: reading from backup piece /tmp/metadata_TEST_XTTS.bck
channel ORA_DISK_1: foreign piece handle=/tmp/metadata_TEST_XTTS.bck
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

Performing import of metadata...
   IMPDP> Master table "SYS"."TSPITR_IMP_MRSTEST_Fjkh" successfully loaded/unloaded
   IMPDP> Starting "SYS"."TSPITR_IMP_MRSTEST_Fjkh":
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
   IMPDP> ORA-39123: Data Pump transportable tablespace job aborted
ORA-29342: user BATMAN does not exist in the database

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 05/15/2018 12:33:26
RMAN-06963: Error received during import of metadata
RMAN-06965: Datapump job has stopped
RMAN-06961:    IMPDP> Job "SYS"."TSPITR_IMP_MRSTEST_Fjkh" stopped due to fatal error at Tue May 15 12:33:23 2018 elapsed 0 00:00:02

 

C'est là qu'est l'os ... le USER propriétaire de mes objets hebergés dans mon tablespace (dans mon cas le user "batman"), doit également être présent sur la CIBLE.

Je crée donc mon user BATMAN sur ma base CIBLE et relance ma restauration :

SQL> create user batman identified by robin profile default account unlock;
User created.

SQL> grant connect,create session to batman;
Grant succeeded.

RMAN> restore from platform 'HP-UX (64-bit)'
foreign tablespace TEST_XTTS to new
from backupset '/tmp/tbs_TEST_XTTS.bck'
dump file from backupset '/tmp/metadata_TEST_XTTS.bck';

Starting restore at 15-MAY-18
using channel ORA_DISK_1
using channel ORA_DISK_2

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring all files in foreign tablespace TEST_XTTS
channel ORA_DISK_1: reading from backup piece /tmp/tbs_TEST_XTTS.bck
channel ORA_DISK_1: restoring foreign file 14 to /applis/list/oracle/HARLEY/data1/HARLEY/datafile/o1_mf_test_xtt_fhogc06s_.dbf
channel ORA_DISK_1: foreign piece handle=/tmp/tbs_TEST_XTTS.bck
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:16
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring Data Pump dump file to /applis/list/oracle/product/rdbms/12.1.0.2/dbhome_1/dbs/backup_tts_MRSTEST_84012.dmp
channel ORA_DISK_1: reading from backup piece /tmp/metadata_TEST_XTTS.bck
channel ORA_DISK_1: foreign piece handle=/tmp/metadata_TEST_XTTS.bck
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

Performing import of metadata...
   IMPDP> Master table "SYS"."TSPITR_IMP_MRSTEST_EbjE" successfully loaded/unloaded
   IMPDP> Starting "SYS"."TSPITR_IMP_MRSTEST_EbjE":
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/TABLE
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/STATISTICS/MARKER
   IMPDP> Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
   IMPDP> Job "SYS"."TSPITR_IMP_MRSTEST_EbjE" successfully completed at Tue May 15 12:42:09 2018 elapsed 0 00:00:14
Import completed

Finished restore at 15-MAY-18

On peut voir que le datafile restauré est en format OMF contrairement à ce qui était sur la base SOURCE. Si l'on souhaite rester en mode manuel SANS OMF il faudrait utiliser un catalog RMAN.

Vérifions si nous retrouvons bien notre table BATMAN.FLAG :

SQL> select count(*) from batman.flag;

  COUNT(*)
----------
   1000000

Parfait ! Je sais pas pour vous, mais je pense que même sans avoir calculé à la minute près j'ai gagné du temps par rapport à l'ancienne méthode en 11G, et j'ai bien simplifié les actions !

Enjoy ;-)

Partager cet article
Repost0
Pour être informé des derniers articles, inscrivez vous :
Vous aimerez aussi :
DBA_HIST_DATABASE_INSTANCE - Historique des versions et démarrage d'instance.
DBA_HIST_DATABASE_INSTANCE - Historique des versions et démarrage d'instance.
STANDBY_FILE_MANAGEMENT - ORA-01276 - ORA-01274
STANDBY_FILE_MANAGEMENT - ORA-01276 - ORA-01274
Dataguard - Configuration
Dataguard - Configuration
DATAGUARD - CREATE STANDBY DATABASE -dbca
DATAGUARD - CREATE STANDBY DATABASE -dbca
IMPDP - PARTITION_OPTIONS
impdp - ORA-00439 - feature not enabled: Basic Compression
Commenter cet article
Thème Magazine - Hébergé par Overblog