Expdp/impdp en échec lors de l'import des tablespaces

Nous étudions la possibilité d'exporter / importer nos données pour regagner l'espace dans les tables.
L'interet est important car nous approchons des 2 To physique et par exemple en faisant cette manipulation sur 5 de nos grosses tables nous gagnons quasiment 400Go d'espace dans notre tablespace de 1,8 To.

L'opération ne peut se faire dans un weekend complet, lié à notre activité (jobs, magasins ouvert le weekend, entrepôts travaillant le samedi etc.)

Est il possible de faire un export le vendredi soir en effectuant un timestamp à chaque export de table.
Import sur une base à part rattaché à un environnement cloné.
Le dimanche après avoir attaché la nouvelle base "light", la meilleure option est j'imagine de rejouer les logs ?

Qu'en pensez vous ?

Je rajoute d'ailleurs une question, lors d'un expdp full=y puis de l'import, peut on "supprimer" des datafiles rendus inutiles par le regroupement des données.
Même si refragmenter la base n'est pas forcément souhaitable avec l'ajout de datafiles etc. Partir avec 50% d'espace vide et 1,8To même si le stockage coute moins cher, c'est quand même des disques à mirorrer ou avec une standbuy etc.

Au lieu de faire un export full, pourquoi ne réalises tu pas un export/import des 5 tables, une par une. Cela te prendrai moin de temps.

Sont'elles liées avec une clée étrangère ?

Les 5 tables peuvent être faites, il n'y pas de problèmes la dessus. C'est pour les 3995 autres que je me fais aussi du soucis :).
Mais même pour l'une des 5 le problème se pose puisque l'import prend énormément de temps (7h)

Bonjour,
Pour répondre à la première question: non il n'est pas possible de rejouer les logs d'une base exportée sur une base importée.
Les logs s'appliquent au niveau physique (les datafiles) et tou ton but c'est justement de ne pas avoir la même structure physique pour gagner de la place.
Et pour la deuxième question, oui si tu importes dans une autre tablespace, alors les datafiles de la première peuvent être supprimés et la nouvelle tu l'aura définie plus petite. Mieux que expdp/impdp: alter table move.

Maintenant, si ce que tu veux faire c'est une réorg online, ils faut voir du côté de DBMS_REDEFINITION.

cordialement,
Franck.

J'avoue bien m'embrouiller lors de l'import/export des tablespaces.

Voici la commande utilisée pour l'expdp :

Citation:

---

expdp system/MDPdirectory=datapump2 parallel=4 dumpfile=SAPQAS_PSAPPRD640_P4_%U.dmp tablespaces=PSAPPRD640 logfile=expdp_PSAPPRD640_P4.log

---

L'import par contre ne fonctionne pas comme souhaité, je m'explique, un peu comme pour l'impdp sur des tables déjà existantes je souhaite réimporter sur le même système le tablespace version réorganisé.
J'ai eu pas mal d'erreur malheureusement ... oracle droppant ma connexion avant la fin de l'exécution, au moment de l'import du table_data.
J'ai donc drop mon tablespace puis recréé, même constat et suite à ces manipulations ma base a plus que du mal à s'ouvrir, le processus d'ouverture de la base ne se termine pour ainsi dire pas.

J'ai regardé à droite à gauche@"google est mon ami" et pas mal d'options sont utilisés qui ne sont pas suffisamment expliquée (pour moi) et dont je ne vois pas forcément l'intérêt (puisque non expliquée).

Pourriez vous me décrire les commandes que vous utiliseriez pour :
exporter un tablespace dans son ensemble (si la parallélisation est possible/conseillée ça m'interesse)
Puis réimporter dans la même base les données du tablespace (cela nécessite t'il de droper le tablespace existant ?)
Ou réimporter dans un nouveau tablespace du même nom avec de nouveaux datafiles créés au même endroit et dans un moindre nombre (puisque les trous dans les tables n'ont pas été exportés).

L'erreur lors de l'import est la suivante :
ORA 3113 et 3114

Ci dessous le log de l'import :

Citation:

---

;;;
Import: Release 10.2.0.2.0 - 64bit Production on Thursday, 06 August, 2009 15:36:53

Copyright (c) 2003, 2005, Oracle. All rights reserved.
;;;
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
Master table "SYSTEM"."SYS_IMPORT_TABLESPACE_08" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_TABLESPACE_08": system/******** tablespaces=PSAPPRD640 TABLE_EXISTS_ACTION=REPLACE directory=datapump2 parallel=1 dumpfile=SAPQAS_PSAPPRD640_P1_%U.DMP logfile=impdp_PSAPPRD640_P1.log
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

---

Ce dernier plante (toujours) au moment de l'import du table_data

Visuellement, v lorsqu'il atteint sa limite au niveau du sga_max_size 2Go le processus Oracle.exe s'arrête.
Nous avons alloué 6Go à la sga_max_size même problème.

Si je prends le même fichier dump et que j'importe 10 tables tout fonctionne.
Par contre lorsqu'il tente de charger l'ensemble des tables, il effectue son "commit" qu'après avoir chargé l'ensemble des DATAS (c'est ce à quoi cela me fait penser) et dans ce cas là il a besoin de bcp bcp bcp de RAM pour effectuer cela.

Du coup sur un FULL comment cela peut il marcher ?
Ce tablespace est plutôt léger (20 Go), sur celui contenant les datas (1,5 To) que va t'il se passer ?

Bonsoir,
la commande est bonne pour exporter le tablespace.
lors de l'import avec le mode replace, les tables seront droppées avant d'être recrées, donc il est inutile de dropper le tablespace lui-même, sauf s'il est vraiment trop large. l'option estimate={BLOCKS | STATISTICS} d'impdp permet d'évaluer le volume de données qui sera généré.
pour le parallel, ça permet de gagner du temps mais c'est plus gourmand en ressources. il n'est pas conseillé d'en mettre plus que 2 fois le nombre de processeurs. attentions aux possibles contentions I/O si oracle écrit et lit sur le même disque avec plusieurs workers en parallèle...
quelle a été l'erreur exactement lors de l'import?

En fait lors de l'import la RAM grimpe jusqu'a atteindre le maximum alloué à Oracle.
Une fois cette limite atteinte, il crash, stoppant "brutalement" la base oracle.
Pas plus de log que ça malheureusement généré par le job d'import !

Bonjour,

ORA-3113 c'est une erreur interne.
Il doit y avoir un message côté serveur dans alert.log et un fichier de trace dans udump. Si tu as observé que celà se produit lorsque la mémoire attteint 2GB, alors peut être que c'est une limite de ton OS et tu dois aussi avoir un message système quelque part.
Oracle n'a pas besoin de 2GB pour exporter tes tables. Mais si tu alloue 2GB (ou 6B) à la SGA, alors il va les utiliser pour garder en cache des blocs de données.
Donc:
- soit tu vois comment avoir plus de 2GB au niveau de l'OS
- soit tu diminue la SGA

Cordialement,
Franck.

Bonjour,
l'import/export par tranche peut être géré par Oracle job scheduler . Une autre soluion pourrait être RMAN