Si vous utilisez l'utilitaire "Datapump" pour exporter/importer des objets PL/SQL qui sont "wrapped", vous rencontrerez des erreurs de compilation de ses objets au moment de l'import.
La solution est forte simple par contre, si vous avez plusieurs objets PL/SQL, elle pourrait s'avérer longue et pénible. La façon de régler le problème est de tout simplement ajouter un retour chariot (ENTER) à la fin du bloc de code "wrapped" et de recompiler l'objet.
Par exemple, après l'import, vous aurez quelque chose de semblable :
9KT8wA45xNIx8UkKA2HePAukkjxautEZA46ttoRHaQKjPJh43giqUg==
/
Alors, il suffit d'ajouter un retour chariot avant la barre oblique :
9KT8wA45xNIx8UkKA2HePAukkjxautEZA46ttoRHaQKjPJh43giqUg==
/
J'ai rencontré ce problème sur une base de données Express Edition (XE).
Ce bug est connu chez Oracle et il a été observé sur une base de données 10gR2 :
Oracle Support : Impdp Returns ORA-39082 When Importing Wrapped Procedures [ID 460267.1]
Bienvenue sur mon blog ! Ce blog me sert principalement d'aide mémoire sur des commandes, des tâches journalières, des problèmes rencontrées, des trucs, des astuces, etc. De jours en jours, je l'alimente avec des sujets que je traite. En créant des articles, je m'offre la chance de pouvoir retrouver facilement ces informations et par le fait même, ça me permet de les partager avec vous.
Aucun message portant le libellé EXPORT. Afficher tous les messages
Aucun message portant le libellé EXPORT. Afficher tous les messages
jeudi 17 mars 2011
mercredi 16 février 2011
Impasse suite à une tentative d'export
Après avoir tenté un export d'un schéma sur une base de données avec l'outil EXPDP, j'ai obtenu une erreur, qui malheureusement, je ne me souviens pas. Suite à cette erreur, j'ai tenté à nouveau un export mais sans succès car rien n'aboutissait.
J'ai alors vérifié l'état de la session dans la vue « v$session » et, j'ai remarqué que ma session provenant de l'outil EXPDP était bloquée par une autre. La session bloquante correspondait à ma précédente session qui était tombée en erreur.
Pour me permettre de réaliser l'export, j'ai alors décidé de terminer la session avec la commande "Alter system kill session". À ma grande surprise, la base de données m'a retournée une erreur me disant que la session n'existe pas. Suite à cela, j'ai décidé d'être plus radicale puis de terminer la processus de la session directement sur le serveur. Encore là, je ne trouvais pas de processus correspondant à la session. Me voilà dans une impasse... Le seul moyen que j'ai pu faire pour m'en sortir a été de redémarrer l'instance de la base de données avec la commande "shutdown abort" car la commande "shutdown immediate" ne parvenait pas à arrêter les processus.
Si vous avez déjà rencontré ce genre de problème et que vous l’avez résolu autrement, merci de partager avec moi.
J'ai alors vérifié l'état de la session dans la vue « v$session » et, j'ai remarqué que ma session provenant de l'outil EXPDP était bloquée par une autre. La session bloquante correspondait à ma précédente session qui était tombée en erreur.
Pour me permettre de réaliser l'export, j'ai alors décidé de terminer la session avec la commande "Alter system kill session". À ma grande surprise, la base de données m'a retournée une erreur me disant que la session n'existe pas. Suite à cela, j'ai décidé d'être plus radicale puis de terminer la processus de la session directement sur le serveur. Encore là, je ne trouvais pas de processus correspondant à la session. Me voilà dans une impasse... Le seul moyen que j'ai pu faire pour m'en sortir a été de redémarrer l'instance de la base de données avec la commande "shutdown abort" car la commande "shutdown immediate" ne parvenait pas à arrêter les processus.
Si vous avez déjà rencontré ce genre de problème et que vous l’avez résolu autrement, merci de partager avec moi.
Libellés :
ALTER SYSTEM,
EXPDP,
EXPORT,
session,
V$SESSION
S'abonner à :
Messages (Atom)