J’ai eu récemment à migrer un environnement Oracle Warehouse Builder 11.1 x vers la version 11.2. Après quelques essais cette opération est en réalité moins fastidieuse qu’on pourrait le croire à condition d’utiliser la dernière version 11.2.0.4.
Il faut savoir tout d’abord qu’il n’est pas possible de simplement exporter et importer le schéma OWBSYS et de lancer l’upgrade. La seule méthode supportée est de recréer le schéma OWB et d’y importer les mappings et workspaces.
Cet article vous présente les grandes étapes de cette opération, dans le cas présent il s’agissait de migrer un OWB 11..1 dans une base 10gR2 vers un OWB 11.2 dans une base 11gR2. La version de la base source n’a pas d’importance dans le processus décrit ici.
Principe général
Les étapes sont les suivantes :
- Création du repository OWBSYS dans la base 11gR2
- Export MDL des mappings 11.1 avec l’outil de la version 11.2
- Conversion et import du référentiel de la version 11.1 à la version 11.2
Conditions préalables
Pour réussir la migration l faut tout d’abord s’assurer que le repository Owb à migrer est sain et si nécessaire il faut supprimer les mappings et procédures orphelins. Pour cela les scripts owbhealthcheck11gr1.sql et owbcollect11g.sql que l’on télécharger sur MOS sont très utiles. Recompiler également tous les objets invalides avec le script utlrp.sql
De plus , il faut avoir vidé la corbeille OWB (dans le Design Center) avant d’exporter le référentiel.
Du côté de la base cible, tous les objets et schémas utilisés dans les mappings devront déjà avoir été crées et importés. Il faut faire attention en particulier aux database links et alias TNS qui doivent aussi pouvoir être résolus.
Quelques bugs peuvent surgir durant la migration et l’import, il faut passer les patchs cumulatifs correspondant à votre version d’OWB 11.2 avant de débuter la migration ( List of Patches Available for OWB 11.2 (Doc ID 1271208.1).
Je vous recommande d’ailleurs d’utiliser la version OWB 11.2.0.4, la 11.2.0.1 étant entachée de bugs concernant l’export/import, il suffit de rechercher « owb hang » dans My Oracle Support pour s’en convaincre.
Deux exemples cependant :
Pour éviter un des bugs (java.lang.OutOfMemoryError: PermGen space à 18% durant l’export) il faut modifier les paramètres de la jvm dans le script reposinst.sh qui permet de lancer l’assistant d’export/import:
Éditer le fichier de la version 11.2 : vi $ORACLE_HOME/owb/bin/unix/reposinst.sh
Dans ce script,augmenter la valeur du paramètre -XX:MaxPermSize sur la ligne d’exécution de java.
NDLR : Ce paramètre ne semble plus être présent dans le script en version 11.2.0.4
De même pour éviter un blocage à 96%, il faut modifier la ligne AddVMOption -Xmx768m en -Xmx1024m dans le fichier $ORACLE_HOME/owb/bin/owb.conf
Création du repository OWB dans la base 11.2
Pour créer le schéma OWBSYS, il suffit dans lancer les script cat_owb.sql présent dans le répertoire $ORACLE_HOME/owb/UnifiedRepos de la version 11.2.
Il faut avoir créé auparavant un tablespace dédié (500 Mo extensibles) , par exemple OWBSYS_DATA
Le script prendre en arguments le nom du tablespace et le mot de passe du schéma OWBSYS
sqlplus / as sysdba
@?/owb/UnifiedRepos/cat_owb.sql OWBSYS_DATA owbsys
Une fois le référentiel créé, il reste à déverrouiller le le compte owbsys avec le script unlock_owbsys.sql présent dans le même répertoire.
Si la base dans laquelle vous avez créé le référentiel est dans un Oracle_home différent de celui d’OWB il faut également exécuter le script reset_owbcc_home.sql
Export du référentiel OWB 11.1
La version 11.2 d’OWB permet d’exporter entièrement un référentiel (mappings + workspaces + locations) d’une version précédente avec l’utilitiaire graphique reposinst
Lancer reposinst.sh qui se trouve dans $ORACLE_HOME/owb/bin/unix dans une session X11 (Xming, console VNC ou autre).
su - oracle
/u01/app/oracle/product/11.2.0/db1/owb/bin/unix/reposinst.sh
Entrer les information de connexion à la base contenant le référentiel à migrer:
Se connecter au référentiel avec le user owbsys
Choisir l’option « Upgrade repository to current version » puis « Export entire repository to a file »
Saisir ensuite les noms et emplacements où seront créés le fichier d’export .mdl et le log de l’export.
Voilà, vous avez maintenant un export complet de votre référentiel OWB 11.1, il reste à l’importer dans le référentiel 11.2 qu nous avons crée.
Migration et import du référentiel en 11.2
L’import du référentiel se déroule en 2 phases :
- Les mappings en version 11.1 contenu dans le fichier MDL donné en entrée sont d’abord convertis en version 11.2 et un nouveau fichier .mdl est crée
- Le fichier converti est importé dans le référentiel
Avant de lancer la migration , il d’abord vérifier les options OWB pour s’assurer de la conformité à la licence.
Dans l’Oracle 11.2 cible, relancez l’outil reposinst.sh , connectez vous cette fois à la base cible où a été créé le référentiel vide et sur le 1er écran sélectionnez le dernier choix « Manage optional features ». Dans l’écran suivant, décochez toutes les options (celles ci sont activées par défaut) si vous n’avez pas de licence ODI Enterprise et bien sûr n’utilisez aucune fonctionnalité nécessitant cette licence.
Revenez ensuite au choix « Ugrade repository to current version » puis « Import entire repository from a file » et choisissez le fichier .mdl créé à l »étape précédente.
Si tout se passe bien, l’import est lancé automatiquement après migration en 11.2 des mappings du fichier d’entrée, ce fichier version 11.2 est créé dans le même répertoire , porte le même nom plus suffixe « _11_2 »
Si tout se déroule correctement, on obtient ce résultat :
Un peu de troubleshooting …
Il peut y avoir de multiples causes à l’échec de la migration et / ou de l’import.
RTC-5161 : Vous avez certainement des mappings utilisant des fonctions soumises à licence (multitarget, pluggable mappings, etc .. ) , vous en saurez plus dans cet article.
Pour les autres erreurs de type MDL1261 « Error importing mapping NULL », il faut rechercher la cause dans le fichier de log de l’import. Celui ci donne en principe le nom de l’objet provoquant l’erreur. Le plus souvent il s’agit d’un mapping orphelin qui n’a pas été correctement supprimé, des packages sont encore présents ou au contraire manquants. Un peu de ménage dans le référentiel source devrait permettre de corriger le problème.
Il ne reste plus maintenant qu’à faire une passe pour vérifier que les LOCATIONS sont correctement définies et pointent vers des destinations valides et vous pouvez redéployer vos mappings.
