La version 11g de Oracle Data Integrator ne sera plus supportée au 31 décembre 2021. Pourtant cet ETL constitue une brique indispensable de votre chaîne décisionnelle, de votre gestion des données (Data Management) ou de votre architecture Big Data.

Aussi, il est peut-être temps, et intéressant de penser migration vers la dernière version supportée, à savoir, la 12c.

La migration, en soit, n’est pas la partie la plus compliquée. En effet, l’outil de migration (UA pour Upgrade Assistant) fonctionne plutôt bien. L’utilitaire de migration « Technique » effectue une mise à niveau technique des référentiels de base de données (SGBD relationnelles) :

  • Master Repository
  • Work Repository

Cette mise à niveau est « globale » au sens des référentiels.

La partie la plus délicate est la correction du référentiel. C’est aussi la partie la plus chronophage et technique.

Next Decision vous fournit ces tutoriels de migration ODI.

Étapes fondamentales de la migration technique :

  • Export / Import Oracle de ODIM et ODID (Il sera peut-être nécessaire de créer une nouvelle base de données).
  • Travaux préparatoires AVANT upgrade
  • Upgrade
  • Travaux préparatoires au débugage POST upgrade

Toutes les étapes citées dans ce document ont été testées, validées et exécutées une à plusieurs fois, afin de lever le maximum des difficultés rencontrées. Cette publication ne constitue pas un engagement de la part de Next Decision. Si vous n’êtes pas serein pour faire votre migration, si vous avez des doutes sur vos architectures, les consultants et développeurs Next Decision experts en ODI sont à votre disposition pour que tout se passe au mieux.

Préparation à la migration ODI 11g vers la version 12c

Import des schémas à upgrader

Afin d’être dans un environnement « hermétique », il est conseillé de faire un export des schémas ODI existants et de les importer dans une base de données déconnectée du réseau.

ATTENTION : la migration se fait toujours sur une copie des référentiels ODI, jamais sur le référentiel ODI.

Changement des mires de connexion des référentiels

Modification des connexions dans l’éditeur de connexion ODI sur la topologie :

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Modification des connexions du référentiel « DEV » pour les faire pointer sur le référentiel importé

Migration ODI 11g vers la version 12C

On modifie l’URL JDBC pour pointer sur l’environnement local. On clique ensuite sur « Tester la connexion », en anglais « connection ».

Migration ODI 11g vers la version 12C

On clique sur le bouton « Tester ».

Migration ODI 11g vers la version 12C

Tout est OK :

Migration ODI 11g vers la version 12C

Création des connexions sur les référentiels de travail

On se déconnecte.

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

On clique sur le « + » pour créer une nouvelle connexion au référentiel de travail (Développement).

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Purge des journaux

La purge peut être très gourmande en ressource surtout si on a un gros niveau de log dans l’operator.

Plusieurs possibilités peuvent être combinées :

  • Purge du journal par l’outil de purge intégré
  • Suppression des scenarios et journaux associés

On peut évaluer le niveau de log en sachant déjà la date de la première session d’exécution d’un scénario.

select MIN(SESS_BEG) from ODID.SNP_SESSION;

On peut aussi regarder le nombre de scenario et leur nombre de version distincte :

select SCEN_NAME , count(*) from ODID.SNP_SCEN group by SCEN_NAME;

Dans les bonnes pratiques de développements ODI, on considèrera que l’on ne doit avoir que 2 versions maximum de scénario en cours. Celui actuellement en production et sa version précédente au cas où.

Pour rappel, le scénario est un exécutable que l’on ne peut modifier. Donc il est inutile de garder N versions.

Pour faciliter les suppressions de sessions, on peut regarder le nombre par année :

select to_char(sess_beg, 'YYYY') annee, count(*) from odid.snp_session group by to_char(sess_beg, 'YYYY');

Ou par mois :

select to_char(sess_beg, 'YYYYMM') annee_mois, count(*) from odid.snp_session group by to_char(sess_beg, 'YYYYMM');

Pour connaitre les sessions qui sont exécutées puis 1 an, on lancera la requête suivante qui nous donnera le nom du scenario et sa version :

select distinct scen_name, scen_version from odid.snp_session
where sess_beg >= sysdate - 365
order by 1 ,2;

On peut accéder à la purge du journal dans l’operator.

Migration ODI 11g vers la version 12C

On peut alors spécifier une date de début de purge et une date de fin pour faire de la suppression par tranche. Il est primordial de cocher la case « Purger les rapports de scénario ».

Migration ODI 11g vers la version 12C

La purge est terminée lorsque l’on obient ce message :

Migration ODI 11g vers la version 12C

Purge des sessions

Si malgré la purge, il subsiste des « exécutions » dans le journal au niveau « Statut », il conviendra de les supprimer à la main.

Vérifier s’il y a des sessions ouvertes (Running & Waiting) :

Migration ODI 11g vers la version 12C

Si oui, les supprimer (cela peut être très long).

Suppression de tous les scénarios

La suppression des scénarios se fera via l’operator. Pour notre migration, nous supprimerons tous les scénarios.

Dans le cas où vous voulez faire du nettoyage, on ne gardera que les 2 dernières versions des scénarios.

Objets « Lockés »

On vérifie qu’il n’y a pas d’objet locké dans les référentiels de travail via la requête suivante:

SELECT * FROM SNP_LOCK ;

Si oui, on purge la table :

truncate table SNP_LOCK ;

Contrôle des référentiels

Avant d’effectuer la migration des référentiels, il conviendra de valider que les référentiels sont « propres ».

Pour ce faire, nous allons utiliser un automate de diagnostic des référentiels : le RCC

Configuration du RCC

Dans le répertoire config :

..\diag_tools\config

Modifier le fichier sample.properties.

Pour spécifier les accès au référentiel MASTER :

MRepoDriver = oracle.jdbc.OracleDriver
MRepoURL = jdbc:oracle:thin:@localhost:1521:XE
MRepoUser = ODIM
MRepoCatalog =
MRepoSchema = ODIM

Dans le répertoire bin :

..\diag_tools\bin

Modifier le fichier rccparams.bat pour qu’il utilise une JVM existante sur le poste :

set RCC_JAVA_HOME=%ODI_JAVA_HOME%

if "%RCC_JAVA_HOME%" == "" set RCC_JAVA_HOME=C:\Applications\Java\jdk1.6.0_45

PS : dans un environnement UNIX, nous utiliserions les pendants en .sh

Lancement du RCC

Lancer le StartDialog du répertoire Bin :

start_diag.bat

Ce programme va permettre de lancer une base en mémoire (Base de données In Memory) qui va stocker les différents contrôles effectués par notre outil d’analyse.

Migration ODI 11g vers la version 12C

En ligne de commande MS-Dos, on se positionne sur le répertoire bin :

..\diag_tools\bin

Et on lance le RCC.bat

Migration ODI 11g vers la version 12C

On choisit l’option « 2 » pour une migration des référentiels vers n’importe quelle version de la 12c.

Migration ODI 11g vers la version 12C

On choisit la « totale », soit l’option 1 qui permet de vérifier l’ensemble des référentiels et tous les points de contrôle.

Migration ODI 11g vers la version 12C

On choisit le sample.propertie, soit l’option A.

Migration ODI 11g vers la version 12C

On spécifie le mot de passe de la base de données relationnelle Oracle pour le user ODIM.

Migration ODI 11g vers la version 12C

On analyse tout y compris la Topo, on choisit donc Y.

Migration ODI 11g vers la version 12C

On va lancer l’analyse sur le Référentiel de DEV, donc on met Y.

Migration ODI 11g vers la version 12C

Le mot de passe du user/schéma Oracle : ODID

Migration ODI 11g vers la version 12C

Et son schéma (identique au user) = ODID

Migration ODI 11g vers la version 12C

L’analyse est en cours :

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

Cela peut durer entre 1 et 5 heures suivant le nombre de référentiels de travail et la volumétrie de chaque environnement.

Lorsque l’analyse est terminée, on arrête le diagnostic en lançant un stop_diag.bat dans le répertoire : ..\diag_tools\bin

Migration ODI 11g vers la version 12C

L’analyse

L'analyse se fait dans le répertoire ..\diag_tools\logs

Migration ODI 11g vers la version 12C

Après le job du RCC, nous retrouverons un reporting issu de l’analyse des corrections à effectuer par environnement.

On retrouvera aussi les différentes erreurs dans la liste des tables suivantes dans votre référentiel Oracle. Cela peut s’avérer pratique pour faire des query (requêtes) SQL avec un outil tel que SQL Developer ou Microsoft SQL Server Management Studio.

Migration ODI 11g vers la version 12C

Le référentiel Maître

Toutes les erreurs types ne sont pas à prendre en compte.

Exemple :

[I n f o] Compared to ODI 12.1.2.0

Le référentiel MASTER ne contient que ce type d’erreur donc le Master est OK.

Le référentiel ODID

Pour les erreurs de type :

[I n f o] Compared to ODI 12.1.2.0 expected Repository structure,

Il ne faut pas les prendre en compte car elles sont justes là pour prévenir des différences de structures entre la version 11 et la version 12. Lors de la migration à proprement parlé ces différences de structures seront corrigées.

[I n f o] 2246 orphan records have been found in the SNP_EXP_TXT_HEADER table.

[W a r n i n g] 69 interactions between ODI Objects in Projects and/or Models require your attention

[S e v e r e] You have 4 duplicate text entries referred by distinct Objects.

Le reste des erreurs devront être corrigées, soit par des requêtes de delete ou update dans le référentiel.
Il conviendra d’être très prudent lors de la correction des erreurs. Cela nécessite en général de faire appel à un expert en migration ODI.

Démarche de correction

La démarche consiste donc à :

  • Corriger les erreurs (cela peut être très long)
  • Relancer le RCC
  • Corriger à nouveau le référentiel si nécessaire

Une bonne pratique consiste à préparer une sauvegarde de notre base de données en vue d’une possible restauration en cas de mauvaise requête de correction.

Ensuite, nous procédons de manière « Agile » :

  • Je corrige
  • Sauvegarde
  • RCC
  • Validation
  • Je passe à l’erreur suivante

Pensez à vous faire une documentation au fur et à mesure. C’est-à-dire que pour chaque erreur corrigée, notez la correction associée afin de pouvoir la réutiliser sur d’autres référentiels et/ou environnements.

Migration des référentiels

Copier les fichiers « SANITY »

L’exécution du RCC a, entre autre, produit 3 fichiers xml :

Migration ODI 11g vers la version 12C

Ces fichiers Debug contiennent les définitions de la base existante pour que lors de la migration, l’assistant à la migration puisse modifier la structure des tables en faisant le delta entre l’existant et la nouvelle version.

Ces 3 fichiers doivent être copiés dans :

C:\apps\ODI12c\odi\sdk\lib\scripts\ORACLE\patches

Lancement de l’updgrade

On se positionne dans le répertoire C:\apps\ODI12c\oracle_common\upgrade\bin. On vérifie qu’une machine virtuelle java a bien été déclarée sinon, on complète le fichier ua.bat ainsi :

REM ##########################################################
REM Execute WebLogic script to define WL_HOME and JAVA_HOME if need be.
REM ##########################################################
set WL_SCRIPT1=%MW_HOME%\oracle_common\common\bin\setHomeDirs.cmd

set JAVA_HOME=C:\Applications\Java\jdk1.8.0_101
if exist %WL_SCRIPT1% CALL %WL_SCRIPT1%

if "%JAVA_HOME%" == "" goto :nojavahome

set PATH=%BASE_DIR%\bin;%PATH%

On lance le ua.bat

Migration ODI 11g vers la version 12C

On clique sur suivant :

Migration ODI 11g vers la version 12C

On sélectionne «schémas sélectionnés individuellement ».

Migration ODI 11g vers la version 12C

Puis on clique sur « Oracle Data Integration ».

Migration ODI 11g vers la version 12C

Migration ODI 11g vers la version 12C

À noter : Il est impératif à ce stade de bien avoir un backup des référentiels ODI nettoyés après le RCC.

Migration ODI 11g vers la version 12C

On spécifie la connexion au référentiel Maitre (MASTER) :

  • Chaine de connexion à la base de données : URL, port et SID (pour une base Oracle) ou Database Name pour Ms Sql-Server
  • On renseigne un utilisateur Administrateur de base de données nécessaire à la modification de la structure des tables
  • L’utilisateur du référentiel Master et son mot de passe

On valide le schéma et ODI, si tout est OK, on clique sur suivant.

Migration ODI 11g vers la version 12C

On coche toutes les cases et on clique sur « suivant ».

Migration ODI 11g vers la version 12C

On renseigne le nom de l’utilisateur Supervisor et son mot de passe.

Migration ODI 11g vers la version 12C

On enregistre la clef de mise à jour : « gAFAXc30Y6XymkOkLwOZ » puis « suivant ».

Migration ODI 11g vers la version 12C

On clique sur « Suivant ».

Migration ODI 11g vers la version 12C

Et on clique enfin sur « Mettre à niveau ».

Migration ODI 11g vers la version 12C

La migration est en cours…

Migration ODI 11g vers la version 12C

Et voilà, vous avez terminé la migration ODI 11g vers la version 12 c ! 

Migration ODI 11g vers la version 12C

Les équipes de Next Decision sont expertes en Oracle Data Integrator vous accompagnent dans vos migrations ODI. Contactez-nous !