02 • 34 • 09 • 31 • 70
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 :
Modification des connexions du référentiel « DEV » pour les faire pointer sur le référentiel importé
On modifie l’URL JDBC pour pointer sur l’environnement local. On clique ensuite sur « Tester la connexion », en anglais « connection ».
On clique sur le bouton « Tester ».
Tout est OK :
Création des connexions sur les référentiels de travail
On se déconnecte.
On clique sur le « + » pour créer une nouvelle connexion au référentiel de travail (Développement).
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.
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 ».
La purge est terminée lorsque l’on obient ce message :
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) :
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.
En ligne de commande MS-Dos, on se positionne sur le répertoire bin :
..\diag_tools\bin
Et on lance le RCC.bat
On choisit l’option « 2 » pour une migration des référentiels vers n’importe quelle version de la 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.
On choisit le sample.propertie, soit l’option A.
On spécifie le mot de passe de la base de données relationnelle Oracle pour le user ODIM.
On analyse tout y compris la Topo, on choisit donc Y.
On va lancer l’analyse sur le Référentiel de DEV, donc on met Y.
Le mot de passe du user/schéma Oracle : ODID
Et son schéma (identique au user) = ODID
L’analyse est en cours :
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
L’analyse
L'analyse se fait dans le répertoire ..\diag_tools\logs
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.
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 :
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
On clique sur suivant :
On sélectionne «schémas sélectionnés individuellement ».
Puis on clique sur « Oracle Data Integration ».
À noter : Il est impératif à ce stade de bien avoir un backup des référentiels ODI nettoyés après le RCC.
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.
On coche toutes les cases et on clique sur « suivant ».
On renseigne le nom de l’utilisateur Supervisor et son mot de passe.
On enregistre la clef de mise à jour : « gAFAXc30Y6XymkOkLwOZ » puis « suivant ».
On clique sur « Suivant ».
Et on clique enfin sur « Mettre à niveau ».
La migration est en cours…
Et voilà, vous avez terminé la migration ODI 11g vers la version 12 c !
Les équipes de Next Decision sont expertes en Oracle Data Integrator vous accompagnent dans vos migrations ODI. Contactez-nous !
