Cet article a pour vocation de compléter l’excellent article d’Eric L. sur la Conversion de Character Set d’une base avec l’outil Oracle DMU, en abordant des cas particuliers que vous êtes susceptibles de rencontrer et qui sont bloquants et non gérés par l’utilitaire graphique.
Erreurs sur la table SYS.COM$
Ces erreurs sont relatives aux métadonnées (commentaires) sur les tables ou colonnes contenant des caractères non convertibles.
Oracle recommande vivement de ne pas faire d’update sur cette table.
Après avoir effectué un premier scan, les tables de DMU ont été remplies. En les interrogeant, il est possible d’identifier les objets concernés grâce à la requête suivante :
|
1 2 3 4 5 6 7 8 9 10 |
SELECT owner, object_name, object_type FROM dba_objects WHERE object_id IN ( SELECT UNIQUE obj# FROM sys.com$ WHERE rowid IN ( SELECT row_id FROM system.dum$exceptions WHERE obj# = ( SELECT OBJECT_ID FROM dba_objects WHERE owner= 'SYS' AND object_name = 'COM$' ) AND type = '8' )) ORDER BY owner, object_name; |
Vous pouvez alors modifier les commentaires posant problème à l’aide de la syntaxe suivante, en modifiant bien sûr les caractères empêchant la conversion :
|
1 |
COMMENT ON [TABLE/COLUMN] schema.table(.column) IS '[Nouveau commentaire]'; |
Un simple rescan de la base devrait confirmer que vous avez résolu le problème.
Erreurs sur la table SYS.SOURCE$
Ces erreurs surviennent quand vos packages PL/SQL contiennent des caractères non convertibles.
DMU n’est pas mesure de faire les corrections de manière automatique.
A l’instar des commentaires posant problème, il est possible de retrouver les packages en cause grâce à cette requête :
|
1 2 3 4 5 6 7 8 9 10 |
SELECT owner, object_name, object_type FROM dba_objects WHERE OBJECT_ID IN( SELECT UNIQUE obj# FROM sys.source$ WHERE rowid IN( SELECT row_id FROM system.dum$exceptions WHERE obj# =( SELECT OBJECT_ID FROM dba_objects WHERE owner = 'SYS' AND object_name = 'SOURCE$' ) AND type = '8' )) ; |
Une fois identifiés, le plus simple reste de droper ces packages avant la conversion et bien sûr de ne pas oublier de les recréer par la suite.
Assurez vous d’avoir le code de ceux-là, ou générez-le en amont grâce à la fonction suivante :
|
1 |
SELECT dbms_metadata.get_ddl('PACKAGE_BODY', '[Nom_du_package]') FROM dual; |
Erreurs sur la table AUDSYS.AUD$UNIFIED
Enfin, malgré tous vos efforts, il se peut que durant la conversion, vous rencontriez des erreurs sur l’objet AUDSYS.AUD$UNIFIED.
En effet, en mode open ou restrict, même en sys, DMU n’a pas l’autorisation de modifier cet objet.
L’astuce est alors d’ouvrir la base en mode upgrade durant la conversion.
|
1 2 |
shutdown immediate; startup upgrade; |
Base avec physical standby (Dataguard)
Enfin, si votre base à convertir a une standby physique, sachez que malgré les alertes de DMU (Concernant le mode Force Logging et l’existence d’une standby database), il est tout à fait possible de convertir la base primaire et sa Standby sans avoir à recréer la Standby. Mais ce point fera sans doute le sujet d’un prochain article détaillé.
Autres cas bloquants
Si vous rencontrez d’autres cas bloquants ne figurant pas dans cet article, sachez qu’il existe une note Oracle sur le sujet : Tips For and Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 2.2 (Doc ID 2018250.1)
—
| Vous souhaitez monter en compétences sur la base de données Oracle ? Alors découvrez nos prochaines dates de formation sur Paris et en région |
