11g/12c : import full tablespace transportable
- Détails
- Catégorie : Migration
- Publié le lundi 2 novembre 2015 20:07
- Écrit par Administrator
- Affichages : 11741
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
|
Système source |
Système cible |
|
Oracle Database 11.2.0.4 Entreprise Edition |
Oracle Database 12.1.0.2 Entreprise Edition |
|
Nom de la base : SHAKA |
Nom de la pluggable database : PONK |
|
Architecture : standalone |
Architecture : standalone CDB |
|
Nom du serveur : oradbm02 |
Nom du serveur : ora12cdb |
|
OS : Oracle Linux 6.4 64bit |
OS : Oracle Linux 6.7 64bit |
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}