Discussion :

[CoeurDeSQL]

Bonjour

Je souhaite transférer des schémas oracle 11 sur des schémas en oracle12
Avec exp du schéma et des droits ( grants et constraints à yes) ou expdp en full et imp du schéma (avec grants et constraints à yes) ou impdp (du schema)
Au moment de l'import sur Oracle12, j'ai des erreurs ORA-12889, de valeurs trop grandes dans une colonne ou des erreurs ORA-02298 (impossibilité de valider des contraintes). Quelque soit la méthode d'export/import choisie.
Je suis surpris d'avoir des données qui dépassent (pour l'erreur 12889) la limite de ma colonne, en attendant je n'ai pas d'erreur sur mes exports.
Existe-t-il une option, dans l'export ou l'import, me permettant de forcer les valeurs afin de pouvoir importer toutes les valeurs sans limite de taille ou toutes les contraintes ? Ou dois-je faire une sorte de comptabilité entre oracle 11 et oracle 12 ?

Merci

[vanagreg]

Bonjour,

Il ne faut pas utiliser "exp" ou "imp" qui sont dépréciés depuis longtemps. Il faudrait que tu nous montres un cas précis de l'erreur.
Peut-être que l'encodage de ta base 12c est différent de celui de ta base 11g et requiert plus d'octets pour le stockage?

[Ikebukuro]

Pour l'erreur ORA-02298 avec le pb de validation des contraintes, as-tu fais un expdp avec timestamp = yes?
Cela te permet de faire un export consistant : toutes les contraintes d'intégrité sont respectées.

Pour l'erreur ORA-12889, de valeurs trop grandes dans une colonne : que vaut nls_length_semantics sur les deux bases?

[CoeurDeSQL]

Merci pour vos premiers retours.
Non pour le timestamp dans l'export, mais je vais essayer merci du conseil.
je vais comparer le nls_length_semantics. De tête j'ai le même encodage mais on ne sait jamais

Pour l'exemple d'erreur sur les contraintes :

Traitement du type d'objet SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
ORA-39083: Echec de la crÚation du type d'objet REF_CONSTRAINT:"MONSCHEMA"."FK_R83" avec erreur :
ORA-02298: impossible de valider MONSCHEMA.FK_R83) - clÚs parents introuvables

SQL en Úchec :
ALTER TABLE "MONSCHEMA"."TABLE1" ADD CONSTRAINT "FK_R83" FOREIGN KEY ("ID") REFERENCES "MONSCHEMA"."TABLE2" ("ID") ENABLE


ORA-39083: Echec de la crÚation du type d'objet REF_CONSTRAINT:"MONSCHEMA"."FK_R113" avec erreur :
ORA-02298: impossible de valider (MONSCHEMA.FK_R113) - clÚs parents introuvables

J'en ai une ribambelle

Encore merci, je retente avec les conseils de ikebukuro et je vous redis

[CoeurDeSQL]

j'ai vérifié le paramètre nls_length_semantics il a la même valeur (byte) sur chaque serveur oracle
et j'en profite pour informer sur l'expdp (mis ça m'a mis sur la voie donc merci), ce n'est plus timestamp mais flashback_time=systimestamp

[vanagreg]

TU n'as pas mis d'exemple d'erreur ORA-12889

[CoeurDeSQL]

Pour l'erreur ORA-02298 avec le pb de validation des contraintes, as-tu fais un expdp avec timestamp = yes?
Cela te permet de faire un export consistant : toutes les contraintes d'intégrité sont respectées.

Toujours pareil au moment de l'import avec le paramètre flashback_time lors de l'export

[CoeurDeSQL]

TU n'as pas mis d'exemple d'erreur ORA-12889

Oui voici un exemple
ORA-02374: conversion error loading table "MONSCHEMA"."MATABLE"
ORA-12899: value too large for column MACOLONNE (actual: 102, maximum: 100)

[Ikebukuro]

Pour les erreurs du style suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Traitement du type d'objet SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
ORA-39083: Echec de la crÚation du type d'objet REF_CONSTRAINT:"MONSCHEMA"."FK_R83" avec erreur :
ORA-02298: impossible de valider MONSCHEMA.FK_R83) - clÚs parents introuvables
 
SQL en Úchec :
ALTER TABLE "MONSCHEMA"."TABLE1" ADD CONSTRAINT "FK_R83" FOREIGN KEY ("ID") REFERENCES "MONSCHEMA"."TABLE2" ("ID") ENABLE
 
ORA-39083: Echec de la crÚation du type d'objet REF_CONSTRAINT:"MONSCHEMA"."FK_R113" avec erreur :
ORA-02298: impossible de valider (MONSCHEMA.FK_R113) - clÚs parents introuvables

je te conseille de vérifier dans ton outil (SQL Developer ou autre) si ces contraintes ont bien été créées dans la base d'import. De mémoire, impdp peut essayer de créer des contraintes dans le mauvais ordre, par exemple la table T1 a une FK sur la table T2 mais T2 n'est pas créée quand Oracle crée T1 dans la base d'import : résultat ça plante puisque la FK ne peut pas référencer une table inexistante. MAIS peut-être que, une fois ces messages affichés, Oracle recrée les contraintes après la création de la table T2 mais il n'y a rien à l'écran donc on a l'impression qu'il y a des erreurs.
Autre explication : les deux tables T1 et T2 existent, la FK a été créée MAIS puisque tu fais un export inconsistant, la valeur que tu veux insérer dans T1 n'existe pas dans T2 lors de ton export donc lors de l'import il y a un bug.
Le pb du message d'erreur est qu'il y a "Echec de la crÚation du type d'objet" : donc je ne sais pas si c'est l'esplication 1 ou 2.

De la lecture ici : https://www.dba-village.com/village/...hreadIdA=35704


Sinon, pour l'autre erreur,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ORA-12899: value too large for column MACOLONNE (actual: 102, maximum: 100)

que renvoie le SELECT sur la table ayant la colonne de nom "MACOLONNE":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT max(lengthb(MACOLONNE)), max(length(MACOLONNE)) from T_MACOLONNE;

J'aimerais bien aussi avoir la définition des deux tables comportant MACOLONNE sur les deux bases :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
desc MATABLE sur base 1
desc MATABLE sur base 2

[CoeurDeSQL]

Si je regarde la 1ere contrainte listée, je la vois bien dans la table (et dans le sql du create table) mais elle est considérée comme non validée
Quant aux longueurs de colonnes et au desc, j'ai les mêmes valeurs sur mon ancienne et ma nouvelle base, qui correspondent à la taille de la colonne que je retrouve dans mon message d'erreur d'import

c'est un truc de fou

[CoeurDeSQL]

j'ai presque envie de prendre mes TBS de données et d'index de l'ancienne base et les mettre sur la nouvelle.
Mais je ne sais pas comment oracle va réagir

[skuatamad]

Et pour le NLS_CHARACTERSET des bases ?
https://laurentschneider.com/wordpre...-database.html

[Ikebukuro]

Si je regarde la 1ere contrainte listée, je la vois bien dans la table (et dans le sql du create table) mais elle est considérée comme non validée
Quant aux longueurs de colonnes et au desc, j'ai les mêmes valeurs sur mon ancienne et ma nouvelle base, qui correspondent à la taille de la colonne que je retrouve dans mon message d'erreur d'import

c'est un truc de fou

Et ça, sur les deux bases, ça donne quoi?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT DBMS_METADATA.GET_DDL('TABLE','MATABLE','OWNER_DE_LA_TABLE') from dual;

[CoeurDeSQL]

Et pour le NLS_CHARACTERSET des bases ?
https://laurentschneider.com/wordpre...-database.html

Bonjour en effet par défaut je n'ai pas la même valeur, je vais re essayer, merci
Je vais prendre les problèmes les uns après les autres

[CoeurDeSQL]

Bonjour bien vu
je suis un idiot de ne pas avoir vérifié
Par défaut je n'ai pas le même characteerset à l'installation de ma base
Merci