11g/12c : import full tablespace transportable

Détails

Catégorie : Migration

Publié le lundi 2 novembre 2015 20:07

Écrit par Administrator

Affichages : 14341

Cet article fait suite à Migration 11g/12c. Il décrit la méthode Migration 11g-12c CDB par Export/Import full par tablespace transportable.

Cet article décrit donc la migration d’une base de données nommée SHAKA en 11.2.0.4 Entreprise Edition sur un serveur en Oracle Linux 64bit vers une 12.1.0.2 Entreprise Edition

Avant de commencer à proprement parler de migration, il faut préparer la base cible. Nous voulons migrer directement dans un CDB, il faut donc créer la base container. Pour cela le plus simple est d’utiliser dbca. Rien de bien particulier, bien choisir « Advanced Mode » à l’étape Creation Mode, et à l’étape Database Identification bien cocher « Create As Container Database » et « Create an Empty Container Database » .

(MYCDB dans la capture d'écran, mais BIGDB dans l'article)

Maintenant que nous avons une CDB « vide » nommée ici BIGDB, nous pouvons crée une pluggable database vide dans ce container. Rien de plus simple par clonage de la pseudo pluggable database  PDB$SEED.

[oracle@ora12cdb oradata]$ sqlplus / as sysdba
SQL> show pdbs

    CON_ID CON_NAME                                  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
                 2 PDB$SEED                                        READ ONLY  NO

SQL> show parameter pdb_file_name_convert
NAME                                                       TYPE VALUE
------------------------------------ ----------- ------------------------------
pdb_file_name_convert                                  string

SQL> alter session set pdb_file_name_convert='/oracle/oradata/BIGDB/pdbseed','/oracle/oradata/BIGDB/PONK';
Session altered.

SQL> create pluggable database PONK admin user goz identified by goz;
Pluggable database created.

La nouvelle base PONK est maintenant créée mais pour l’instant elle est vide, elle attend impatiemment les données à migrer.

Il nous faut préparer la communication sqlnet entre PONK 12c et SHAKA en 11g. Car ici nous allons directement générer le fichier d’export des metadata de SHAKA à travers un dblink et les importer dans le « pipe » sur PONK. Mais cela pourrait être fait en deux étapes :  export full métadata transportable tablespace puis transfert du fichier metadata exporté et des datafiles.

Donc sur le serveur ora12cdb, nous éditons  le tnsname.ora pour y rajouter le chemin vers la 11g :

[oracle@ora12cdb admin]$ vi tnsnames.ora
SHAKA =
(DESCRIPTION =
   (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(Host = oradbm2)(Port = 1521))
   )
(CONNECT_DATA =
   (SERVICE_NAME = SHAKA)
)
)

Ensuite il faut créer le dblink vers SHAKA à partir de PONK ainsi que le directory oracle où va être généré le fichier d’export full et des metadata des tablespaces transportables par datapump :

SQL> alter session set container=PONK;
SQL> alter pluggable database PONK open;

SQL> ! mkdir /oracle/dumpmig
SQL> create directory dir_dump_mig as '/oracle/dumpmig';
SQL> grant read, write on directory dir_dump_mig to system;
SQL> create public database link SHAKA_LINK connect to system identified by oracle using 'SHAKA';
SQL> select * from dual@SHAKA_LINK;

D
-
X

Préparation côté 12c c’est fini. Les choses sérieuses peuvent commencer c'est-à-dire downtime de la production sur la base SHAKA.

Dans notre cas  de test il n’y a qu’un schéma à migrer : U_TEST. Il est réparti sur 3 tablespaces TBS_IMAGE, TBS_TEST_DATA et TBS_TEST_IDX.

SQL> select owner, tablespace_name , sum(bytes)/1024/1024 from dba_segments group by owner, tablespace_name order by  1,2
OWNER                   TABLESPACE_NAME                SUM(BYTES)/1024/1024
------------------------------ --------------------
APPQOSSYS              SYSAUX                               .25
DBSNMP                    SYSAUX                              1.5
OUTLN                      SYSTEM                              .5625
SYS                          SYSAUX                               62.375
SYS                          SYSTEM                               255.0625
SYS                          UNDOTBS1                           562.6875
SYSTEM                    SYSAUX                               14.8125
SYSTEM                    SYSTEM                              15.875
U_TEST                    TBS_IMAGE                          88.9375
U_TEST                    TBS_TEST_DATA                  118
U_TEST                    TBS_TEST_IDX                      272.1875
WMSYS                     SYSAUX                               7.5

SQL> alter tablespace TBS_IMAGE read only;
SQL> alter tablespace TBS_TEST_DATA read only;
SQL> alter tablespace TBS_TEST_IDX read only;
SQL> alter tablespace USERS read only;

En fait tous les tablespaces sont passés en read-only sauf les tablespaces purement système : SYSTEM, SYSAUX, UNDO.

Maintenant qu’ils sont en read only pas de temps à perdre il faut les copier. Cette partie peut durer longtemps si les datafiles sont volumineux, c’est sans doute le point faible de la méthode de migration.

select 'scp '||file_name||' oracle@ora12cdb:/oracle/oradata/BIGDB/PONK' from dba_data_files where TABLESPACE_NAME in ('TBS_IMAGE','TBS_TEST_DATA','TBS_TEST_IDX','USERS');

'SCP'||FILE_NAME||'ORACLE@ORA12CDB:/ORACLE/ORADATA/BIGDB/PONK'
------------------------------------------------------------------------------------------------------------------------------------
scp /oradata/SHAKA/users01.dbf oracle@ora12cdb:/oracle/oradata/BIGDB/PONK
scp /oradata/SHAKA/tbs_test_data_01.dbf oracle@ora12cdb:/oracle/oradata/BIGDB/PONK
scp /oradata/SHAKA/tbs_test_data_02.dbf oracle@ora12cdb:/oracle/oradata/BIGDB/PONK
scp /oradata/SHAKA/tbs_test_idx_01.dbf oracle@ora12cdb:/oracle/oradata/BIGDB/PONK
scp /oradata/SHAKA/tbs_image_01.dbf oracle@ora12cdb:/oracle/oradata/BIGDB/PONK

Ils sont donc copiés du serveur oradbm02 vers ora12c. Mais il faut maintenant importer les metadata pour qu’ils soient reconnus par la base PONK du container BIGDB. C’est là que rentre en jeux l’export/import datapump trasportable tablespace (donc il faut que la base source soit un Entreprise Edition sinon… pas possible). Et ici comme dit précédemment c’est directement un import qui est lancé, l’export est généré implicitement grâce à l’option network_link (utilisation du dblink). La ligne de commande est un peu longue, donc dans ce cas, le plus simple est de passer par un parfile :

[oracle@ora12cdb ~]$ vi migration.par
network_link=SHAKA_LINK
version=12
full=y
transportable=always
metrics=y
exclude=statistics
logfile=dir_dump_mig:migration.log
transport_datafiles='/oracle/oradata/BIGDB/PONK/users01.dbf','/oracle/oradata/BIGDB/PONK/tbs_test_data_01.dbf','/oracle/oradata/BIGDB/PONK/tbs_test_data_02.dbf','/oracle/oradata/BIGDB/PONK/tbs_test_idx_01.dbf','/oracle/oradata/BIGDB/PONK/tbs_image_01.dbf'


[oracle@ora12cdb ~]$ impdp system/oracle@PONK parfile=migration.par
Import: Release 12.1.0.2.0 - Production on Sun Oct 11 21:15:50 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@PONK parfile=migration.par
Startup took 2 seconds
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/PLUGTS_FULL/FULL/PLUGTS_TABLESPACE
Processing object type DATABASE_EXPORT/PLUGTS_FULL/PLUGTS_BLK
     Completed 1 PLUGTS_BLK objects in 1 seconds
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
[…]
     Completed 4 DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA objects in 28 seconds
     Completed 3 DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA objects in 1 seconds
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 26 error(s) at Sun Oct 11 21:18:58 2015 elapsed 0 00:03:05

Il y a des erreurs mais comme bien souvent dans un import il faut lire et analyser les erreurs car elles ne sont  pas forcément génante comme ici.

La migration est finie, les applications peuvent maintenant se connecter sur PONK.

[oracle@ora12cdb ~]$ sqlplus system/oracle@PONK
SQL> select owner, tablespace_name , sum(bytes)/1024/1024 from dba_segments where owner='U_TEST' group by owner, tablespace_name order by  1,2;
OWNER             TABLESPACE_NAME                     SUM(BYTES)/1024/1024
-------------------- ------------------------------ --------------------
U_TEST             TBS_IMAGE                                88.9375
U_TEST             TBS_TEST_DATA                        118
U_TEST              TBS_TEST_IDX                          272.1875

Voilà c’est tout pour ce premier exemple de migration. Il est assez simple à appréhender. Il est sans doute un peu plus complexe qu’un export/import classique (schéma par exemple) mais il est sans doute plus rapide car il n’y a pas la phase d’export de données dans un dumpfile,  éventuel transfert du dumpfile et injection du dumpfile dans la base, juste un « copier/coller » des datafiles… mais on peut améliorer ce downtime en introduisant une dataguard: 11g/12c : dataguard - import full tablespace transportable

 {jcomments on}

• < Précédent