Une des évolutions de la version 12C  de la base de données c’est la disparition des utilitaires CSSCAN,  LCSSCAN et du package csalter.plb qui nous étaient bien utiles pour préparer et réaliser les changements de jeu de caractère. Certaines entrées de ce blog comme “Migrer le characterset de la base avec CSSCAN et CSALTER” ou “Language and Character Set File Scanner (LSSCAN)”  vous ont permis de vous familiariser avec ces outils.  Comment fait-on maintenant ?  Oracle ne nous laisse pas démuni, mais nous propose un autre utilitaire , graphique cette fois –ci , qui agrège les fonctionnalités précédentes tout en se dotant d’analyse plus fine; beaucoup plus proche d’un assistant et proposant l’automatisation des taches de conversion : dmu pour Database Migration for Unicode.  Voyons comment le mettre en pratique,  non seulement avec la version 12C, mais aussi avec les versions 10.2, 11.1 et 11.2.
il faut d’abord localiser l’outil!  Avec la distribution des versions 12.1.0.1  et 12.1.0.2, il se trouve sous $ORACLE_HOME/rdbms/admin/dmu et se lance avec dmu.sh mais attention c’est une version ancienne qui est fournie, il sera plus intéressant de prendre la dernière version disponible actuellement la version 2.0 du 19 mars 2014 que l’on trouvera sur le site OTN à cette page dédiée DMU ou via My Oracle Support (MOS) « The Database Migration Assistant for Unicode (DMU) Tool (Doc ID 1272374.1) ».
Pour les changements apportés avec cette version 2.0 , reportez vous à la release note DMU release 2.0,  vous verrez qu’en plus de la prise en compte de l’architecture Multitenant , de nombreuses optimisations ont été apportées.
Pour les autres distributions et les plates formes sur lesquelles le faire fonctionner voir ici,  on se rend compte que l’on peut commencer dés les version 10.2.0.4.4 à condition d’appliquer le patch unitaire de référence #9825461  “DATABASE MIGRATION ASSISTANT FOR UNICODE (DMU) RDBMS SERVER-SIDE FUNCTIONS” .
Le téléchargement consiste en un fichier zip nommé dmu-2.0.zip qui contient la documentation et les exécutables java nécessaire. Il faut donc avoir déjà sur son poste ou sur son serveur un JDK compatible en version 6 ou en version 7 ,   si ce n’est pas la bonne version  vous aurez quelques soucis, du style impossible de modifier un champ après une saisie !
Pour le démarrer depuis un poste client sous Windows 8.1 64bits :

• Décompression du fichier dmu-2.0.zip  sous  D:\App\dmu
• Double clic sur le fichier dmu64W.exe sous D:\App\dmu\dmu

A la première ouverture il  me demande la localisation de l’exécutable java,  je lui donne celui fourni avec SQLDevelopper qui est déjà présent sur mon laptop  : C:\Program Files\Oracle\sqldeveloper\jdk\bin\java.exe. C’est une version 1.7.0_55 qui est plus récente que DMU et donc non certifiée; il m’avertit deux fois avant de s’’ouvrir enfin :

La première étape est de créer une connexion vers la base cible (celle que vous souhaitez convertir). Cliquer sur l’icone nouvelle connexion en haut à gauche ,  ou depuis le menu “File”   –> “Create new connection”   ou <ctrl> + N.  Il est nécessaire d’utiliser un compte avec le privilège SYSDBA.

une fois la connexion tester et valider, elle apparait dans la partie gauche, onglet « Navigator » de l’interface, il faut déployer l’information de la base en cliquant sur le signe « + »  à gauche de la connexion.  Cette première connexion génère souvent l’erreur :“SYS.DBMS_DMUA_INTERNAL Not found”  :

Un clic sur le lien « More » affiche la fenêtre d’aide qui nous dit qu’il est nécessaire de créer certains packages  dans la base grâce au script :  $ORACLE_HOME/rdbms/admin/prvtdumi.plb.  Librairie dmu_lib et package dbms_dmua_internal.
D’où connexion sur le serveur de la base cible et exécution du script :

SQL> connect / as sysdba
SQL> @?/rdbms/admin/prvtdumi.plb

Une fois cela fait, recliquer sur la croix de déploiement à gauche de la connexion à la base de données, ce qui déclenche la phase suivante :  la configuration du référentiel pour l’outil. C’est une obligation, Il ne peut pas travailler sans , le seul choix valide à ce moment  est “Install the repository in migration mode” , noter que le jeu de caractère de la base a bien été déterminé :

L’avantage de ce référentiel , c’est la possibilité de reprendre ce que l’on faisait même si l’interface graphique se perd  (ce qui n’est pas rare de nos jours). L’écran d’après vous donne les deux choix possible pour votre migration :  “AL32UTF8”  ou “UTF8” .

L’écran suivant demande dans quel tablespace possédant suffisament d’espace libre vous allez installer ce référentiel, je créé un espace dédié avec l’ordre SQL suivant  :

SQL>create tablespace TESTDMU datafile '/u01/oradata/ORCL/testdmu01.dbf' size 50M ;
SQL>alter database datafile '/u01/oradata/ORCL/testdmu01.dbf' autoextend on maxsize 500M ;

Avant de le sélectionner dans la liste déroulante, proposant l’ensemble des tablespaces de votre base de données cible.

Noter qu’ une taille initiale de 10 Mo suffit pour la vingtaine d’objets créés (14 tables , 7 indexes , une colonne de type LOB et son index)  , ils appartiennent tous au schéma SYSTEM.  Mettre le fichier en extension automatique s’évite les problèmes d’allocation futur.  Une fois l’opération terminée et l’apparition du  message « Repository has been installed successfully » . A l’affichage nous avons alors dans la partie droite de l’interface, dans l’onglet dédié “Migration Status”  toutes les étapes à dérouler pour aller au bout de notre migration :

Sur les quatre phases, seul le “step 1”  est coché en vert, c’est  l’étape qui est terminée.
La phase 2 consiste au scan complet de la base de données pour découvrir les éventuelles problématiques de migration,  cliquer sur le lien « Scan all Character data in the database to check… »  ,  ou depuis le menu « Migration » le choix « Scan Database » ou encore le même choix dans le menu contextuel associé à votre connexion,  vous ouvre la page de bienvenue de l’assistant spécifique :

Cliquer sur le bouton  “Next” pour la suite, la définition des différentes options pour ce scan   :

• Nombre de processus en parallèle sur le serveur de la base
• Taille du buffer utilisé
• Différentes options de collecte des numéros de lignes

Dans ce  scan nous conservons  toutes les valeurs par défaut :

Et dans le choix des objets à étudier, nous prendrons tous les objets de la base, dictionnaire et objets applicatifs (qui est aussi le positionnement par défaut ) :

Le dernier écran de l’assistant nous affiche le détail de chaque objet trouvé avec les informations sur leur taille et sur la propriété de collecte des lignes, que l’on peut modifié au choix pour chacun. Qui sont affichés dans le dernier écran avant le lancement avec un certain niveau de détail , comme leur taille ou la propriété de collecte des numéros de ligne (Toutes les lignes qui nécessitent une conversion « All to convert » ,  Aucune ligne « None » ,  Uniquement les lignes pour lesquelles des problèmes sont détectés) :

En cliquant sur le bouton « Finish » ,  le scan commence et on peut suivre sa progression dans l’onglet spécifique « Scan Progress”

Une fois terminé il  renvoie vers le rapport détaillé que l’on accède soit au travers du menu contextuel lié à la connexion (clic droit sur la connexion) , soit depuis la barre de menu “Migration”  , choix “ Database Scan Report”  :

Cette opération de scan consiste à parcourir chaque colonne des objets concernés et d’en déterminer le statut les valeurs pouvant être :

• « Invalid binary representation » ,  code non valide dans le jeu de caractère d’origine (données de type binaire par exemple).
• « Exceed data type limit » , le contenu de la colonne sera trop grand par rapport à son type après la conversion.
• « Exceed column limit », la donnée après conversion ne tiendra pas dans la colonne.
• « Need conversion », la donnée dans la cellule doit être convertie car sa représentation dans le jeu de caractère source est différente de celle dans le jeu de caractère source.
• « Need no conversion » , représentation identique de la donnée dans les deux jeux de caractères

Le nombre d’éléments nécessitant une conversion est clairement donné , on peut descendre jusque dans le détail de la colonne en cause, ici pour la colonne « VALUE » de la table MGMT_IP_ELEM_DEFAULT_PARAMS.VALUE :

La progression de la migration montre maintenant qu’il ne reste plus qu’a procéder à cette dernière phase,  les étapes 1 à 3 étant terminer :

Pour démarrer le processus de migration , deux choix:  menu contextuel avec la connexion sélectionnée ou depuis la barre de menu “Migration” , choix “Convert Database” .  Avant de déclencher, il peut être intéressant de se poser quelques questions sur les choix de traitement que l’on retrouve dans le paramétrage de la base, onglet dédié à la connexion , section « Converting » :

Parmi ces choix, la possibilité d’utiliser des commandes de type CTAS (CREATE TABLE AS SELECT)   pour la modification des objets au lieu de commandes de mise à jour (UPDATE) en autorisant ou non le déplacement de lignes dans les blocs (avec l’impact que cela peut avoir !) ou la gestion des vues matérialisées et le moment de leur rafraichissement.
Pour chacune des  étapes prévue pour la conversion, depuis l’onglet « Converting » on peut avoir précisément tous les détails, jusqu’aux ordres SQL exécutés. Ainsi pour la modification de la colonne VALUE de la table MGMT_IP_REPORT_ELEM_PARAMS du schéma SYSMAN nous avons la commande UPDATE correspondante :

Si vous êtes d’accord sur le plan, cliquer sur le bouton “Convert”  ,  mais n’oubliez de déconnecter toutes les autres sessions (particulièrement vos propres sessions de surveillance)  , sinon vous aurez l’avertissement suivant :

Après un dernier point d’attention , le processus va démarrer et vous pourrez suivre sa progression dans l’onglet “Progression Status”  jusqu’à sa terminaison:


La base a bien changé de jeu de caractère et on peut le vérifier :

SQL> select parameter,value from v$nls_parameters where parameter='NLS_CHARACTERSET' ;
PARAMETER            VALUE
-------------------- --------------------
NLS_CHARACTERSET     AL32UTF8

La dernière étape , comme conseillé est de fermer la connexion depuis  l’outil DMU et de redémarrer la base car elle est en mode restrict, comme on peut le voir :

SQL> select logins from v$instance ;
LOGINS
----------
RESTRICTED

Votre opération de migration est terminée avec succès!
Bien sur ça ne se passera pas aussi simplement dans votre cas , les causes des problèmes induits par la conversion peuvent être nombreuses, l’outil vous aidera à les traiter et les éliminer les une après les autres en travaillant précisément sur les objets récalcitrant ou on les bypassant. Cela se gère au travers des opérations de « Cleansing ». On peut accéder à l’éditeur depuis le menu contextuel d’une table dans le rapport de scan , avec le choix « Cleansing Editor » , pour modifier directement une donnée dans la colonne de la table par exemple. On peut aussi faire du traitement de masse avec la fonction « Bulk Cleansing » accessible depuis le menu principal ou contextuel de la connexion.
On s’aperçoit qu’à l’usage après avoir apprivoisée l’interface le nouvel outil est souple et complet. Si vous avez déjà trouver d’autres limitations ou anomalie que celles de bases ou il faut réaliser la conversion avant la migration vers les versions 12 :

• Seul le passage vers Unicode est pris en compte  (AL32UTF8 ou UTF8 pour compatibilité descendante et surtout pour Oracle Ebusiness Suite 11i qui le nécessite en pré-requis)
• la migration des données de type NCHAR n’est pas non plus intégré

N’hésitez pas à nous en faire part sur ce blog.

—

Vous souhaitez monter en compétences sur la version 12c de la base de données Oracle ? Alors découvrez nos prochaines dates de formation sur Paris et en région