La migration d'une instance Oracle 11g R2 64 bits d'une plateforme Sun SPARC Solaris 10 64 bits vers une plateforme SunOS X86 Solaris 10 64 bits n'est pas anodine car dans ce contexte les fichiers de données Oracle doivent subir une conversion, le poids (ou endian en anglais) étant différent entre ces deux plateformes (big endian pour Sun SPARC, little endian pour SunOS x86).
La fonctionnalité des tablespaces transportables d'Oracle (transportable tablespaces) inclut de façon très simple et efficace depuis la version 10g, même si il existe quelques restrictions, la conversion des fichiers Oracle lors d'un changement de plateforme et de poids.
Cet article rappelle très brièvement la notion de poids et propose un exemple de conversion d'une instance Oracle 11g R2 de Sun SPARC Solaris 10 vers SunOS X86 Solaris 10.
Le terme "endian" se rapporte à l’ordre de numérotation des octets d’un type de données (entier, caractères…). Les architectures d’ordinateur divergent dans la façon dont elles numérotent les octets d’un type de données de gauche à droite ou de droite à gauche (un peu comme l’écriture). Dans le schéma ci-dessous, les architectures 32 bits « Big Endian » et « Little Endian » sont illustrées pour le stockage d’un entier 0XA0B70708 en notation héxadécimale.
Chaque octet équivaut à 8 bits :
Le passage d'une plateforme à une autre lorsque les poids diffèrent pour les bases de données, et ceci quelque soit le moteur (Oracle, Sybase,...), nécessite impérativement une conversion, le schéma ci-dessous résume les poids par plateformes et dans quel contexte des conversions sont nécessaires :
Sybase propose depuis la version 12.5.3 la conversion cross plateforme par dump/load (Sybase 12.5.3 - Dump/Load cross plateforme » ), pour Oracle la méthode des transportable tablespaces inclut la fonctionnalité de conversion. Cet article présente un cas concret pour Oracle.
L'instance à migrer s'appelle UBXU1ORA, il s'agit d'une version 11.2.0.1 64 bits comprenant 3 tablespaces non systèmes : UBIX_TABLES, UBIX_INDEX et UBIX_ADMIN.
Pour retrouver les tablespaces utilisateurs à migrer à partir de la vue dba_tablespaces :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select tablespace_name from dba_tablespaces
where contents not in ('UNDO','TEMPORARY')
and tablespace_name not in ('SYSTEM','SYSAUX');
TABLESPACE_NAME ------------------------------ UBIX_TABLES UBIX_INDEX UBIX_ADMIN
Pour retrouver les fichiers de données des tablespaces utilisateurs à migrer à partir de la vue dba_data_files :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select tablespace_name,file_name from dba_data_files
where tablespace_name in (select tablespace_name
from dba_tablespaces
where contents not in ('UNDO','TEMPORARY')
and tablespace_name not in ('SYSTEM','SYSAUX'))
order by 1,2;
TABLESPACE_NAME FILE_NAME ------------------- ----------------------------------------- UBIX_ADMIN /ubix/oracle/UBXU1ORA/UBIX_ADMIN_01.dbf UBIX_INDEX /ubix/oracle/UBXU1ORA/UBIX_INDEX_01.dbf UBIX_INDEX /ubix/oracle/UBXU1ORA/UBIX_INDEX_02.dbf UBIX_INDEX /ubix/oracle/UBXU1ORA/UBIX_INDEX_03.dbf UBIX_INDEX /ubix/oracle/UBXU1ORA/UBIX_INDEX_04.dbf UBIX_INDEX /ubix/oracle/UBXU1ORA/UBIX_INDEX_05.dbf UBIX_TABLES /ubix/oracle/UBXU1ORA/UBIX_TABLES_01.dbf UBIX_TABLES /ubix/oracle/UBXU1ORA/UBIX_TABLES_02.dbf UBIX_TABLES /ubix/oracle/UBXU1ORA/UBIX_TABLES_03.dbf UBIX_TABLES /ubix/oracle/UBXU1ORA/UBIX_TABLES_04.dbf UBIX_TABLES /ubix/oracle/UBXU1ORA/UBIX_TABLES_05.dbf 11 rows selected.
Quelques restrictions existent pour pouvoir utiliser les tablespaces transportables. La procédure transport_set_check du package DBMS_TTS permet de vérifier si une incompatibilité avec les tablespaces transportables est détectée.
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> begin
dbms_tts.transport_set_check('UBIX_TABLES',true);
end;
/
L'exécution de cette procédure pour un tablespace remplit la vue système TRANSPORT_SET_VIOLATIONS, vue qui va remonter toutes les incompatibilités avec la technologie des tablespaces transportables.
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> select * from TRANSPORT_SET_VIOLATIONS;
no rows selected
La procédure transport_set_check est exécutée pour chaque tablespace à transporter et les résultats remontés dans la vue TRANSPORT_SET_VIOLATIONS sont analysés après chaque exécution.
Des violations peuvent survenir lorsque des objets référencés ne sont pas dans le jeu de tablespaces à transporter, c'est notamment le cas de l'erreur ORA-39907. Voici le résultat de la procédure transport_set_check sur le tablespace UBIX_INDEX qui ne contient que les indexes des tables, tables qui sont en revanche stockées dans le tablespace UBIX_TABLES :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> begin
dbms_tts.transport_set_check('UBIX_INDEX',true);
end;
/
select * from TRANSPORT_SET_VIOLATIONS;
VIOLATIONS ----------------------------------------------------------- ORA-39907: Index OPS$BRU.MODNEG2 in tablespace UBIX_INDEX points to table OPS$BRU.MODNEG in tablespace UBIX_TABLES.
Les violations indiquent que l'index s'applique sur une table contenue dans un autre tablespace, il s'agit d'un simple avertissement sans gravité. La procédure transport_set_check permet d'inclure un jeu de tablespaces pour vérifier un transport de plusieurs tablespaces en même temps, ce qui sera la cas :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> begin
dbms_tts.transport_set_check('UBIX_TABLES,UBIX_INDEX,UBIX_ADMIN',true);
end;
/
select * from TRANSPORT_SET_VIOLATIONS;
no rows selected
Le référencement vers des objets systèmes SYS, des tables externes (external tables) etc... n'est pas pris en charge. Ces types d'objet doivent être préparés dans l'instance cible, par export ou toute autre méthode (script SQL...).
Quelques précautions à prendre :
La vue DBA_TAB_COLUMNS et notamment la colonne DATA_TYPE permet de retrouver ces types de colonnes exotiques.
oracle@UBXU1ORA sqlplus " /as sysdba"
SQL> select owner,table_name, column_name, data_type
from dba_tab_columns
where owner in ('OPS$BRU','UBXADMIN','UBXREF')
and data_type='RAW'
OWNER TABLE_NAME COLUMN_NAME DATA_TYPE --------------- -------------------- ----------------- ------------- OPS$BRU ORA_STATS R1 RAW OPS$BRU ORA_STATS R2 RAW
Les étapes de la migration peuvent être résumées avec le diagramme ci-dessous :
La vue v$transportable_plaform rassemble toutes les plateformes supportées par Oracle ainsi que leurs poids. Pour les plateformes Solaris :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL > select platform_name, endian_format
from V$TRANSPORTABLE_PLATFORM
where upper(platform_name) like '%SOLARIS%'
PLATFORM_NAME ENDIAN_FORMAT ---------------------------------- ------------- Solaris[tm] OE (32-bit) Big Solaris[tm] OE (64-bit) Big Solaris Operating System (x86) Little Solaris Operating System (x86-64) Little
Dans cet exemple pratique, la plateforme source est Solaris [tm] OE (64-bit) et la plateforme cible est Solaris Operating System (x86-64) : les poids sont différents (Big/Little), donc une conversion avec RMAN est nécessaire. Le libellé "Solaris Operating System (x86-64)" va être très important dans la conversion des tablespaces avec RMAN.
La plateforme d'une instance est disponible dans la colonne platform_name de la vue v$database :
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> select platform_name from v$database
PLATFORM_NAME ------------------------- Solaris[tm] OE (64-bit)
Les tablespaces UBIX_TABLES, UBIX_INDEX et UBIX_ADMIN à migrer sont mis en lecture seule (read only) avec la commande ALTER TABLESPACE.
alter tablespace ubix_tables read only; Tablespace altered. alter tablespace ubix_index read only; Tablespace altered. alter tablespace ubix_admin read only; Tablespace altered.
L'export des meta données des trois tablespaces à migrer est réalisé depuis l'instance source avec l'utilitaire expdp (export data pump). 2 exports vont être réalisés :
Le répertoire pour l'export data pump est au préalable créé avec la commande CREATE DIRECTORY :
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> create directory dpump_tts as '/ubix/oracle/export/metadata';
Directory created.
Un fichier de paramètres export_metadata_tts.par pour l'export data pump des meta données des tablespaces transportables est préparé :
oracle@UBXU1ORA> cat export_metadata_tts.par
userid="/ as sysdba" directory=dpump_tts dumpfile=ubix_metadata_tts.dmp logfile=export_metadata_tts.log transport_full_check=y transport_tablespaces=(UBIX_ADMIN,UBIX_TABLES,UBIX_INDEX)
L'option transport_tablespaces liste les tablespaces à transporter, l'option transport_full_check=y déclenche la vérification de la cohérence des références entre objets dans les tablespaces.
L'export data pump est ensuite appelé avec ce fichier de paramètrage :
oracle@UBXU1ORA> expdp parfile=export_metadata_tts.par
... Starting "SYS"."SYS_EXPORT_TRANSPORTABLE_01": /******** AS SYSDBA parfile=export_metadata_tts.par Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK Processing object type TRANSPORTABLE_EXPORT/TABLE ... Master table "SYS"."SYS_EXPORT_TRANSPORTABLE_01" successfully loaded/unloaded ****************************************************************************** Dump file set for SYS.SYS_EXPORT_TRANSPORTABLE_01 is: /ubix/oracle/export/metadata/ubix_metadata_tts.dmp ****************************************************************************** Datafiles required for transportable tablespace UBIX_ADMIN: /ubix/oracle/UBXU1ORA/UBIX_ADMIN_01.dbf Datafiles required for transportable tablespace UBIX_INDEX: /ubix/oracle/UBXU1ORA/UBIX_INDEX_01.dbf /ubix/oracle/UBXU1ORA/UBIX_INDEX_02.dbf /ubix/oracle/UBXU1ORA/UBIX_INDEX_03.dbf /ubix/oracle/UBXU1ORA/UBIX_INDEX_04.dbf /ubix/oracle/UBXU1ORA/UBIX_INDEX_05.dbf Datafiles required for transportable tablespace UBIX_TABLES: /ubix/oracle/UBXU1ORA/UBIX_TABLES_01.dbf /ubix/oracle/UBXU1ORA/UBIX_TABLES_02.dbf /ubix/oracle/UBXU1ORA/UBIX_TABLES_03.dbf /ubix/oracle/UBXU1ORA/UBIX_TABLES_04.dbf /ubix/oracle/UBXU1ORA/UBIX_TABLES_05.dbf
La sortie liste les fichiers de données qui seront nécessaires à l'import.
Le fichier de paramètres export_metadata_objects.par est créé pour l'export data pump des objets non pris en charge par les tablespaces transportables :
oracle@UBXU1ORA> cat export_metadata_objects.par
userid="/ as sysdba" directory=dpump_tts dumpfile=ubix_metadata_objects.dmp logfile=export_metadata_objects.log full=y content=metadata_only
Les options FULL=y et CONTENT=metadata_only garantissent l'export des meta données de tous les objets (tables, indexes, vues, packages, procédures, fonctions, packages, package body, vues matérialisées...) sans exporter les données des tables.
L'export data pump est ensuite appelé avec ce fichier de paramètrage :
oracle@UBXU1ORA> expdp parfile=export_metadata_objects.par
Export: Release 11.2.0.1.0 - Production on Mon Nov 8 16:10:40 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Starting "SYS"."SYS_EXPORT_FULL_01": /******** AS SYSDBA parfile=export_metadata.par Processing object type DATABASE_EXPORT/TABLESPACE Processing object type DATABASE_EXPORT/PROFILE ... Processing object type DATABASE_EXPORT/SCHEMA/FUNCTION/FUNCTION Processing object type DATABASE_EXPORT/SCHEMA/PROCEDURE/PROCEDURE Processing object type DATABASE_EXPORT/SCHEMA/FUNCTION/ALTER_FUNCTION Processing object type DATABASE_EXPORT/SCHEMA/PROCEDURE/ALTER_PROCEDURE Processing object type DATABASE_EXPORT/SCHEMA/VIEW/VIEW Processing object type DATABASE_EXPORT/SCHEMA/VIEW/GRANT/OWNER_GRANT/OBJECT_GRANT Processing object type DATABASE_EXPORT/SCHEMA/VIEW/GRANT/CROSS_SCHEMA/OBJECT_GRANT Processing object type DATABASE_EXPORT/SCHEMA/VIEW/COMMENT Processing object type DATABASE_EXPORT/SCHEMA/TABLE/CONSTRAINT/REF_CONSTRAINT Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY ... Dump file set for SYS.SYS_EXPORT_FULL_01 is: /ubix/oracle/export/metadata/ubix_metadata_objects.dmp Job "SYS"."SYS_EXPORT_FULL_01" successfully completed at 16:14:55
Le fichier de log de l'export data pump ne doit pas contenir d'erreurs, sauf si il existe des schémas XMLObjects qui ne sont pas supportés par l'export data pump, dans ce contexte l'utilitaire d'export classique exp doit être utilisé.
Vérifier le dimensionnement du tablespace SYSTEM afin que celui-ci contienne assez d'espace disponible lors de l'export data pump : 200 Mb est une bonne marge.
Les fichiers de données des tablespaces sont convertis tablespace par tablespace pour être compatible avec la plateforme cible - Solaris Operating System (x86-64) - grâce à la commande convert tablespace de l'utilitaire RMAN, les fichiers de données convertis sont stockés dans le répertoire /ubix/oracle/export de la machine source :
oracle@UBXU1ORA> rman target / nocatalog connected to target database: UBXU1 (DBID=3277469180) using target database control file instead of recovery catalog RMAN> convert tablespace 'UBIX_INDEX' to platform="Solaris Operating System (x86-64)" db_file_name_convert '/ubix/oracle/UBXU1ORA/UBIX_INDEX_01.dbf','/ubix/oracle/export/UBIX_INDEX_01.dbf' '/ubix/oracle/UBXU1ORA/UBIX_INDEX_02.dbf','/ubix/oracle/export/UBIX_INDEX_02.dbf', '/ubix/oracle/UBXU1ORA/UBIX_INDEX_03.dbf','/ubix/oracle/export/UBIX_INDEX_03.dbf', '/ubix/oracle/UBXU1ORA/UBIX_INDEX_04.dbf','/ubix/oracle/export/UBIX_INDEX_04.dbf', '/ubix/oracle/UBXU1ORA/UBIX_INDEX_05.dbf','/ubix/oracle/export/UBIX_INDEX_05.dbf';
Starting conversion at source at 19/10/10 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input datafile file number=00006 name=/ubix/oracle/UBXU1ORA/UBIX_INDEX_01.dbf converted datafile=/ubix/oracle/export/UBIX_INDEX_01.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:01:25 channel ORA_DISK_1: starting datafile conversion input datafile file number=00014 name=/ubix/oracle/UBXU1ORA/UBIX_INDEX_03.dbf converted datafile=/ubix/oracle/export/UBIX_INDEX_03.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:01:15 channel ORA_DISK_1: starting datafile conversion input datafile file number=00015 name=/ubix/oracle/UBXU1ORA/UBIX_INDEX_05.dbf converted datafile=/ubix/oracle/export/UBIX_INDEX_05.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:01:15 channel ORA_DISK_1: starting datafile conversion input datafile file number=00007 name=/ubix/oracle/UBXU1ORA/UBIX_INDEX_02.dbf converted datafile=/ubix/oracle/export/UBIX_INDEX_02.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:45 channel ORA_DISK_1: starting datafile conversion input datafile file number=00010 name=/ubix/oracle/UBXU1ORA/UBIX_INDEX_04.dbf converted datafile=/ubix/oracle/export/UBIX_INDEX_04.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:45 Finished conversion at source at 19/10/10
Les temps de conversion sont très rapides : moins de 2 minutes pour des fichiers de données ayant une taille de 3 à 4 Gb. Le temps va dépendre toutefois de la CPU.
Les fichiers de données des tablespaces UBIX_TABLES, UBIX_INDEX et UBIX_ADMIN convertis et localisés dans le répertoire /ubix/oracle/export sont envoyés avec le binaire ftp (mode binaire) vers la machine cible Sun X86 64 bits directement dans l'arborescence de l'instance qui va accueillir ces fichiers de données (/ubix/oracle/UBXU1ORA).
Les fichier d'exports ubix_metadata_tts.dmp et ubix_metadata_objects.dmp contenant les meta données sont également envoyés par ftp (mode binaire) vers la machine cible dans le répertoire /ubix/oracle/export/metadata.
Une restriction très importante : l'instance cible doit avoir les mêmes jeux de caractères que l'instance source. Lorsque les jeux de caractères sont différents, l'import des tablespaces transportés est en échec avec l'erreur ORA-19736:
IMP-00003: ORACLE error 19736 encountered ORA-19736: can not plug a tablespace into a database using a different national character set ORA-06512: at "SYS.DBMS_PLUGTS", line 1797 ORA-06512: at "SYS.DBMS_PLUGTS", line 1636 ORA-06512: at line 1 IMP-00000: Import terminated unsuccessfully
Pour retrouver les jeux de caractères de l'instance source, interroger la vue nls_database_parameters de l'instance source :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select parameter, value
from nls_database_parameters
where parameter in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET')
PARAMETER VALUE -------------------------- --------------------------- NLS_CHARACTERSET WE8PC850 NLS_NCHAR_CHARACTERSET AL16UTF16
Ces jeux de caractères sont paramatrés dans la commande CREATE DATABASE de l'instance cible :
CREATE DATABASE UBXU1 .... character set WE8PC850 national character set AL16UTF16 ...;
Dans le cas des tablespaces transportables, la version des fuseaux horaires doit être strictement la même pour les instances source et cible. Pour retrouver la version des fuseaux horaires dans l'instance source :
oracle@UBXU1ORA (source 11.2.0.1)> sqlplus "/ as sysdba" SQL> select * from v$timezone_file;
FILENAME VERSION -------------------- ---------- timezlrg_11.dat 11
La version 11 correspond à la dernière version des fuseaux horaires de la version Oracle 11.2.0.1. Si l'instance cible est créée avec la version 11.2.0.2, sans prendre garde, la version des fuseaux horaires est à une version supérieure (version 14) :
oracle@UBXU1ORA (cible 11.2.0.2)> sqlplus "/ as sysdba" SQL> select * from v$timezone_file;
FILENAME VERSION -------------------- ---------- timezlrg_14.dat 14
Lors de l'import des tablespaces transportables, l'erreur ORA-39322 sera levée si il existe un delta dans la version des fuseaux horaires
ORA-39002: invalid operation ORA-39322: Cannot use transportable tablespace with timestamp with timezone columns and different timezone version.
L'instance cible doit être créée avec une version des fuseaux horaires identique à celle de l'instance source. Pour cela, la variable $ORA_TZFILE est forcée à la version 11 dans la session qui créé la base de données cible afin que la version 14 ne soit pas appliquée automatiquement par le moteur Oracle :
oracle@UBXU1ORA (cible 11.2.0.2)> export ORA_TZFILE=$ORACLE_BASE/$ORACLE_HOME/oracore/zoneinfo/timezlrg_11.dat oracle@UBXU1ORA (cible 11.2.0.2)> sqlplus "/ as sysdba" SQL > CREATE DATABASE UBXU1 ...
Dans la norme appliquée aux instances de cet article, la variable ORA_TZFILE pointe sur /Software/oracle/app/product/11.2.0/oracore/zoneinfo/timezlrg_11.dat. Vérifier ensuite que la bonne version des fuseaux horaires est appliquée dans l'instance cible en interrogeant v$timezone_file après la création de la base de données cible.
Les comptes et rôles sont préparés dans l'instance cible. Leur existence est indispensable pour l'import des tablespaces tansportables. Pour les comptes, aucun tablespace de données par défaut n'est précisé puisqu'ils ne sont pas encore importés.
oracle@UBXU1ORA (cible)> sqlplus "/ as sysdba" SQL> create user ops$bru identified by *******; SQL> create user ubxref identified by *******; SQL> create user ubxadmin identified by *******; SQL> create user modele_ops$bru identified by *******; SQL> create role useubix_ops$bru identified by *******;
Aucun privilège particulier n'est donné aux comptes (create session etc...), les privilèges sont attribués lors de l'import.
Pour retrouver dans l'instance source les comptes, rôles, proflls etc... en interrogeant les vues du dictionnaire : Reverse Engineering Oracle 10g pour les imports ».
L'import des tablespaces et fichiers de données est réalisé à l'aide du fichier ubix_metadata_tts.dmp réalisé à l'étape 5-2-1.
Le répertoire pour l'import data pump est au préalable créé avec la commande CREATE DIRECTORY dans l'instance cible, il s'agit du répertoire contenant les fichiers ubix_metadata* :
oracle@UBXU1ORA> sqlplus "/ as sysdba" SQL> create directory dpump_tts as '/ubix/oracle/export/metadata';
Directory created.
Un fichier de paramètres import_metadata_tts.par pour l'import data pump des tablespaces transportés et des meta données est créé :
oracle@UBXU1ORA> cat import_metadata_tts.par
userid="/ as sysdba"
directory=dpump_tts
dumpfile=ubix_metadata_tts.dmp
logfile=import_metadata_tts.log
transport_datafiles=('/ubix/oracle/UBXU1ORA/UBIX_ADMIN_01.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_TABLES_01.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_TABLES_02.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_TABLES_03.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_TABLES_04.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_TABLES_05.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_INDEX_01.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_INDEX_02.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_INDEX_03.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_INDEX_04.dbf',
'/ubix/oracle/UBXU1ORA/UBIX_INDEX_05.dbf')
Le fichier de dump donné en paramètre (dumpfile) correspond au fichier d'export des meta données des tablespaces réalisé à l'étape 5-2-1 (ubix_metadata_tts.dmp).
L'option transport_datafiles liste tous les fichiers de données des tablespaces convertis et transportés.
L'import data pump est alors appelé avec ce fichier de paramètrage :
oracle@UBXU1ORA> impdp parfile=import_metadata_tts.par
Master table "SYS"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded Starting "SYS"."SYS_IMPORT_TRANSPORTABLE_01": /******** AS SYSDBA parfile=import_metadata_tts.par Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK Processing object type TRANSPORTABLE_EXPORT/TABLE Processing object type TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT ... Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK Job "SYS"."SYS_IMPORT_TRANSPORTABLE_01" completed with 1129 error(s) at 18:38:25
Cet import met à jour le catalogue de l'instance Oracle cible pour les tables, indexes, contraintes, déclencheurs (triggers). L'import des meta données des tablespaces transportés est très rapide.
Des avertissements sont probablement consignés dans le fichier de log si des triggers sont par exemple invalides, ces avertissements ne sont pas bien graves car il est fort probable que ces triggers dépendent d'autres objets comme par exemple des fonctions ou des procédures etc..., objets qui ne sont pas encore importés. Ces objets complémentaires sont importés dans une prochaine étape.
Par conséquent, vérifier à cette étape que toutes les erreurs remontées ne sont pas liées directement à l'import des tablespaces transportables et qu'elles sont uniquement liées à des problèmes de droits ou de dépendances d'objets, problèmes qui seront corrigés avec l'import des objets complémentaires ultérieurement.
Dans le cas de cet article, seulement des problèmes de validité de triggers sont détectés, aucun problème pour l'import des tablespaces. Voici une commande simple pour extraire les erreurs ORA- dans le fichier de log de l'import :
oracle@UBXU1ORA> cat /ubix/oracle/export/metadata/import_metadata_tts.log \
| grep 'ORA-' | awk -F":" '{print $1}' | sort -u
ORA-39082
Les tablespaces UBIX_TABLES, UBIX_INDEX et UBIX_ADMIN sont en mode lecture seule à l'issue de l'import TTS. Ils sont remis en mode lecture/écriture (read write) avec la commande ALTER TABLESPACE.
alter tablespace ubix_tables read write; Tablespace altered. alter tablespace ubix_index read write; Tablespace altered. alter tablespace ubix_admin read write; Tablespace altered.
La mise en mode lecture/écriture est indispensable pour l'import des objets complémentaires (procédures, packages...).
Les tablespaces utilisateurs sont à présent importés dans l'instance cible, les tablespaces par défaut et temporaire des schémas dans l'instance cible sont alors rétablis. Les commandes ALTER USER à appliquer dans la cible peuvent être générées dynamiquement depuis l'instance source avec la requête ci-dessous :
oracle@UBXU1ORA (source)> sqlplus "/ as sysdba"
SQL> set pagesize 1000;
SQL> set linesize 800;
SQL> select 'alter user '||username||' default tablespace '||default_tablespace||' temporary tablespace '||temporary_tablespace||';' from dba_users where username in (select distinct owner from dba_segments where tablespace_name not in ('SYSTEM','SYSAUX'));
alter user UBXREF default tablespace UBIX_ADMIN temporary tablespace TEMP; alter user OPS$BRU default tablespace UBIX_TABLES temporary tablespace TEMP; alter user UBXADMIN default tablespace UBIX_ADMIN temporary tablespace TEMP;
L'import des objets complémentaires (vues, procédures, fonctions, packages...), objets qui ne sont pas pris en charge par l'export des tablespaces transportables, est ensuite exécuté en utilisant le fichier d'export réalisé à l'étape 5-2-2.
Un fichier de paramètres import_metadata_objects.par pour l'import des objets est préparé :
oracle@UBXU1ORA> cat import_metadata_objects.par
userid="/ as sysdba" directory=dpump_tts dumpfile=ubix_metadata_objects.dmp logfile=import_metadata_objects.log full=y content=metadata_only table_exists_action=skip
Le fichier de dump donné en paramètre (dumpfile) correspond au fichier d'export des objets réalisé à l'étape 5-2-2- (ubix_metadata_objects.dmp).
L'option content=metadata_only indique un import des définitions sans les données (rows=n).
L'option table_exists_action=skip écarte les tables qui existent déjà. Par voie de conséquence, avec cette option, les meta données des tables comme les contraintes, indexes et triggers seront également écartées, meta données déjà importées dans le catalogue lors du premier import.
L'import data pump est alors appelé avec ce fichier de paramètrage :
oracle@UBXU1ORA> impdp parfile=import_metadata_objects.par
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": /******** AS SYSDBA parfile=import_metadata_objec
ts.par
Processing object type DATABASE_EXPORT/TABLESPACE
...
ORA-31684: Object type TABLESPACE:"UBIX_TABLES" already exists
...
ORA-31684: Object type USER:"OPS$BRU" already exists
...
Table "OPS$BRU"."AXACOS" exists. All dependent metadata and data will be skipped due to
table_exists_action of skip
Processing object type DATABASE_EXPORT/SCHEMA/JOB
Processing object type DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCACT_SCHEMA
Job "SYS"."SYS_IMPORT_FULL_01" completed with 142 error(s) at 18:54:29
De très nombreuses erreurs ORA-31684 sont rencontrées, ce qui est tout à fait normal car l'option FULL=y est donnée. Inutile de les vérifier une par une, il est préférable de passer à l'étape qui suit immédiatement.
Le plus important est de retrouver les messages "All dependent metadata and data will be skipped due to table_exists_action" pour les tables qui existent déjà dans les tablespaces. Ce message indique que les contraintes, indexes, triggers... qui dépendent des tables existantes sont écartés.
À l'issue de l'import, rejouer le script $ORACLE_HOME/rdbms/admin/utlrp.sql pour recompiler tous les objets passés au statut invalide dans l'instance cible. Si des objets demeurent au statut invalide, vérifier si la préparation des comptes, rôles, profils etc... a été correctement faite (cf Reverse Engineering Oracle 10g pour les imports »).
Même si c'est fortement déconseillé, il se peut que des objets applicatifs soient créés avec le compte système oracle SYS, or l'import ne prend pas en compte ce cas de figure, ce qui est la cas également des tables externes. Dans cet article le package applicatif UBIX_SYSSTATS appartient à SYS : le code source de cet objet est généré depuis l'instance source avec la procédure get_ddl du package dbms_metadata, code source qui est ensuite compilé dans l'instance cible.
oracle@UBXU1ORA (source)> sqlplus "/ as sysdba"
SQL> set long 200000 pages 0;
SQL> select dbms_metadata.get_ddl('PACKAGE','UBIX_SYSSTATS','SYS') from dual;
CREATE OR REPLACE PACKAGE "SYS"."UBIX_SYSSTATS" is
procedure gather_sys_stats;
procedure delete_sys_stats;
end;
CREATE OR REPLACE PACKAGE BODY "SYS"."UBIX_SYSSTATS" is
procedure gather_sys_stats is begin sys.dbms_stats.gather_schema_stats('SYS');
end;
procedure delete_sys_stats is begin sys.dbms_stats.delete_schema_stats('SYS');
end;
end;
Autre point important, l'octroi de droits aux comptes applicatifs sur des objets systèmes oracle SYS et SYSTEM (vues du dictionnaire, packages DBMS% ...) peut également être la source d'objets applicatifs invalides. Utiliser l'instance source pour retrouver les éventuels droits à donner sur les objets systèmes aux comptes applicatifs dans l'instance cible :
oracle@UBXU1ORA (source)> sqlplus "/ as sysdba"
SQL> select 'GRANT '||privilege||' ON "'||owner||'"."'||table_name||'" TO "'||grantee||'"'||decode(grantable, 'YES', ' WITH GRANT OPTION')||';'
from dba_tab_privs
where owner in ('SYS','SYSTEM')
and grantee in ('OPS$BRU','UBXADMIN','UBXREF');
GRANT SELECT ON "SYS"."DBA_TAB_PRIVS" TO "OPS$BRU" GRANT EXECUTE ON "SYS"."DBMS_ALERT" TO "OPS$BRU" GRANT EXECUTE ON "SYS"."DBMS_PIPE" TO "OPS$BRU" GRANT EXECUTE ON "SYS"."DBMS_LOCK" TO "OPS$BRU" GRANT SELECT ON "SYS"."DBA_SYNONYMS" TO "OPS$BRU" GRANT SELECT ON "SYS"."V_$SESSION" TO "OPS$BRU" WITH GRANT OPTION GRANT SELECT ON "SYS"."DBA_DATA_FILES" TO "UBXADMIN" WITH GRANT OPTION GRANT SELECT ON "SYS"."DBA_TEMP_FILES" TO "UBXADMIN" WITH GRANT OPTION ...
Pour retrouver tous les objets au statut invalide dans l'instance cible :
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select owner, object_type, object_name
from dba_objects
where status='INVALID'
and owner not in ('SYS','SYSTEM');
OWNER OBJECT_TYPE OBJECT_NAME ------------ ------------------- ---------------------- OPS$BRU PACKAGE BODY UFO_RISK
Un seul package est invalide dans l'exemple de cet article, mais il s'agit d'une erreur applicative "normale".
Dernière vérification d'usage indispensable avant la mise à disposition aux équipes applicatives, comparer le nombre d'objets par type dans l'instance cible et l'instance source, aucun delta ne doit apparaître :
| Instance source | Instance cible |
|---|---|
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select distinct object_type,
count(1)
from dba_objects
where owner in ('OPS$BRU','UBXADMIN
','UBXREF')
group by object_type
order by object_type
OBJECT_TYPE COUNT(1) ------------------- ---------- FUNCTION 3 INDEX 2546 LOB 3 PACKAGE 224 PACKAGE BODY 224 PROCEDURE 32 SEQUENCE 189 SYNONYM 152 TABLE 2905 TRIGGER 589 TYPE 22 VIEW 2930 |
oracle@UBXU1ORA> sqlplus "/ as sysdba"
SQL> select distinct object_type,
count(1)
from dba_objects
where owner in ('OPS$BRU','UBXADMIN
','UBXREF')
group by object_type
order by object_type
OBJECT_TYPE COUNT(1) ------------------- ---------- FUNCTION 3 INDEX 2546 LOB 3 PACKAGE 224 PACKAGE BODY 224 PROCEDURE 32 SEQUENCE 189 SYNONYM 152 TABLE 2905 TRIGGER 589 TYPE 22 VIEW 2930 |
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 10/2010 | Version initiale |
| 2.0 | 11/2010 | Export et import des meta données par export data pump / import data pump. Prise en charge des objets non supportés par les exports TTS. Avertissement sur le fichier de fuseau horaire timezone lors de la création de la base de données d'accueil. Vérifications complémentaires |
Oracle 11g R1 BOL : About
transporting Tablespaces across platforms
Wikipedia : Endianess (poids
forts, poids faibles)
SQLPAC : Reverse Engineering
Oracle 10g pour les imports