Import se plante lors de l'activation de CONSTRAINTS [Résolu]

[Sabact]

Bonjour,
Je veux importer une base de donnees:
L'import se lance comme suit,
Delete le contenu du table d'une base de données existantes, ainsi lancer le commande(Pour une raison personnelle d'une application la suppression du SCHEMA USE est interdite)

Code :

 imp USE/USE@USE file=C:\IMPORT\Donnees.dmp log=C:\IMPORT\imp_Donnees.log full=y indexes=N IGNORE=Y commit=Y constraints=N

Problème rencontré:
les données sont bien importées mais l'import se plante lors de l'activation du constraints, que je doit faire pour l'annuler .
Merci.

[philcero]

Je pense que tu as mal analysé ton problème. a partir du moment où ton import utilise l'option "constraints=n" il n'y a pas d'import et/ou activation de celles-ci.

Si le log n'est pas trop gros, peux-tu le poster ici s.v.p.

[Sabact]

Envoyé par philcero

Je pense que tu as mal analysé ton problème. a partir du moment où ton import utilise l'option "constraints=n" il n'y a pas d'import et/ou activation de celles-ci.

Si le log n'est pas trop gros, peux-tu le poster ici s.v.p.

Dans le log il n'y a pas des spécials je vais esseyer d'emporter le bout du fichier log:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
Connecté à : Oracle DATABASE 10g Release 10.2.0.1.0 - Production
Fichier d'export créé par EXPORT:V10.01.00 via le chemin classique
import effectué dans le jeu de caractères WE8MSWIN1252 et le jeu NCHAR AL16UTF16
. . Import de la table                         "ACTUA"          0 lignes importées       <
. . Import de la table             "GMM_EXPORT_ACCESS"          0 lignes importées       <
. . Import de la table                         "GMMPI"         40 lignes importées       <
. . Import de la table                       "GMMPI_43"         43 lignes importées       <
. . Import de la table                        "DONNEES"      22816 lignes importées       <
. . Import de la table          "JESMIL_EXPORT_ACCESS"          0 lignes importées       <
. . Import de la table                  "BILAN_CLIENT"      10715 lignes importées       <
. . Import de la table                           "MAJ"          0 lignes importées       <
---------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
Préparation de l'activation des constraints...

[philcero]

Petit rectificatif, je pense qu'il faut partir dans l'autre sens. Combien dois-tu importer de schémas à l'arrivée ?

[Sabact]

Envoyé par philcero

Petit rectificatif, je pense qu'il faut partir dans l'autre sens. Combien dois-tu importer de schémas à l'arrivée ?

Normalement je dois importer 52 Tables, environs 5 min au maximum .

Ayant j'ai executé les commandes dans une autre version d'Oracle l'integration se déroule bien!
version 10.2.0.1.0 se plante
version 10.1.0.4.0 import se termine avec succès.
J'arrive pas à comprendre.

[philcero]

En ce cas, si ton import concerne un seul et unique schéma évite l'import FULL :

1. Purge TOUS les objets du schéma cible.
2. Importe à l'aide d'un "imp ... fromuser=... touser=..." et voie le résultat.

En ce qui concerne l'erreur de ton import il se peut qu'il y ait des tables parasites dans les schémas systèmes qui ne sont pas purgés lors de l'import FULL. D'où duplication d'objet peut être (Je sais c'est pas précis mais on fait ce qu'on peut).

L'import FULL est normalement réservé au montage d'une base FROM SCRATCH, autrement dit pour alimenter une base vierge.

[Sabact]

Envoyé par philcero

En ce cas, si ton import concerne un seul et unique schéma évite l'import FULL :

1. Purge TOUS les objets du schéma cible.
2. Importe à l'aide d'un "imp ... fromuser=... touser=..." et voie le résultat.

En ce qui concerne l'erreur de ton import il se peut qu'il y ait des tables parasites dans les schémas systèmes qui ne sont pas purgés lors de l'import FULL. D'où duplication d'objet peut être (Je sais c'est pas précis mais on fait ce qu'on peut).

L'import FULL est normalement réservé au montage d'une base FROM SCRATCH, autrement dit pour alimenter une base vierge.

Oui le problème survient à cause des objets parasites dans le schema.
Merci