Création/restauration de dump avec TOUT.

Version imprimable

09/08/2019, 14h44
Kropernic

Création/restauration de dump avec TOUT.

Bonjour,

Je dois créer et restaurer un dump Oracle pour la première fois (je roule ma bosse sur Sql Server mais je n'ai encore jamais touché à Oracle).

Le souci est que personne chez nous ne sait vraiment comment faire. Alors y a bien quelqu'un (qui ne travaille plus ici entre temps:aie:) qui à force de test à réussi à établir une procédure qui fonctionne plus ou moins mais bien sûr quand je la suis, ça merde lors de l'import du dump avec l'erreur "Schema xxxx; was not found."

Le truc qui me semble bizarre c'est qu'avant de réimporter le dump, y a tout un tas de create user et de grant à faire. Et aussi la création de tablespace mais ça, même si je ne vois pas exactement ce que c'est, je peux comprendre que ce soit nécessaire à faire la première fois (j'imagine que ça sert à créer l'espace disque où il va pouvoir restaurer le dump).

Ce que je me dis, c'est qu'on utilise très mal le machin et qu'il y doit y avoir moyen de produire un dump qui contient TOUT. Mais vraiment tout. Les users, les grants, etc. Et de pouvoir restaurer ce dump sans avoir à faire 3 millions de choses préalablement.

Du coup, je viens chercher les lumières de la communauté car dans la doc d'oracle, j'vois plein de paramètre (notamment le full=y) mais rien n'y fait.

J'ai réussi à créer un dump avec full=y qui est effectivement bien plus volumineux que celui de la procédure que j'ai suivie qui, si j'ai bien compris, n'exporte qu'un schéma (vu qu'il y a le paramètre schéma=xxx lors de l'exécution de expdp). Mais quand j'ai voulu réimporter le dump créé avec full=y, ça a merdé. Pour info, voici les quelques premières lignes du fichier log de ma tentative de restauration du dump full.

Citation:

;;; Import: Release 18.0.0.0.0 - Production on Fri Aug 9 10:46:11 2019
Version 18.3.0.0.0

Copyright (c) 1982, 2018, Oracle and/or its affiliates. All rights reserved.
;;;
Connected to: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": sys/********@oracle18pluggable AS SYSDBA directory=DATA_PUMP_DIR dumpfile=AGITO_FULL_20190808.DMP logfile=AGITO_FULL_IMPORT.log
Processing object type DATABASE_EXPORT/TABLESPACE
ORA-31684: Object type TABLESPACE:"SYSAUX" already exists
ORA-31684: Object type TABLESPACE:"UNDOTBS1" already exists
ORA-31684: Object type TABLESPACE:"TEMP" already exists
ORA-31684: Object type TABLESPACE:"USERS" already exists
ORA-39083: Object type TABLESPACE:"GINIUS" failed to create with error:
ORA-01119: error in creating database file 'C:\ORACLE\ORADATA\AGITODEV\GINIUS.DBF'
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.

Failing sql is:
CREATE TABLESPACE "GINIUS" DATAFILE 'C:\ORACLE\ORADATA\AGITODEV\GINIUS.DBF' SIZE 4294967296 AUTOEXTEND ON NEXT 268435456 MAXSIZE 16384M LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT NOCOMPRESS SEGMENT SPACE MANAGEMENT AUTO
ORA-39083: Object type TABLESPACE:"INDX" failed to create with error:
ORA-01119: error in creating database file 'C:\ORACLE\ORADATA\AGITODEV\INDX.DBF'
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.

Failing sql is:
CREATE TABLESPACE "INDX" DATAFILE 'C:\ORACLE\ORADATA\AGITODEV\INDX.DBF' SIZE 536870912 AUTOEXTEND ON NEXT 134217728 MAXSIZE 4096M LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT NOCOMPRESS SEGMENT SPACE MANAGEMENT AUTO

ORA-39083: Object type TABLESPACE:"COBBT1010" failed to create with error:
ORA-01119: error in creating database file 'C:\ORACLE\ORADATA\AGITODEV\COBBT1010.DBF'
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.

Failing sql is:
CREATE TABLESPACE "COBBT1010" DATAFILE 'C:\ORACLE\ORADATA\AGITODEV\COBBT1010.DBF' SIZE 33554432 AUTOEXTEND ON NEXT 33554432 MAXSIZE 2048M LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT NOCOMPRESS SEGMENT SPACE MANAGEMENT AUTO

ORA-39083: Object type TABLESPACE:"SPTL_INDX" failed to create with error:
ORA-01119: error in creating database file 'C:\ORACLE\ORADATA\AGITODEV\SPTL_INDX.DBF'
ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 3) The system cannot find the path specified.

Y a beaucoup plus de log bien sûr (malgré que je l'ai killé dès que j'ai vu que ça merdait, il a eu le temps de tenter de faire un paquet de trucs).

Voilà je m'arrête là. Sorry pour ce message qui est probablement un peu décousu et merci d'avance à ceux qui prendront la peine d'y répondre.

EDIT : J'ai oublié de préciser que c'est pour migrer une db depuis une instance 11G vers une instance 18C.
09/08/2019, 15h28
Pomalaix

Alors en très bref :

Si vous faites un export FULL, et un import FULL également, l'opération se charge notamment de recréer les tablespaces à l'identique de la source.
Mais il faut pour ça que les chemins existent préalablement.
Une chose qu'on voit dans votre log, c'est que le chemin "C:\ORACLE\ORADATA\AGITODEV" n'existe pas.

Par ailleurs, il faut vous méfier quand vous parlez de killer l'import.
Avec Datapump, les opérations se poursuivent en tâche de fond sur le serveur, peu importe que vous ayez tué la session (fenêtre DOS) dans laquelle vous avez lancé impdp.
09/08/2019, 15h34
Kropernic

Déjà, merci pour la réponse.

Maintenant, comment obtenir la liste des chemins à créer ?

Entre temps, j'ai relancer l'import du dump de la procédure que j'ai suivi et qui n'exporte qu'un schéma. J'ai juste eu à retirer le paramètre SCHEMA de la comme de l'import.

Pourrai-je encore tenter de faire un import du dump full une fois celui-ci terminer ou bien cela va-t-il gêner oracle car des trucs existeront déjà ?
09/08/2019, 15h41
Pomalaix
Pour les chemins à créer, vous pouvez lancer la requête suivante sur la base initiale :
Code:

1 2 3 4 5 6 7 8 9 col name format A100 SELECT NAME FROM V$TEMPFILE UNION SELECT NAME FROM V$DATAFILE UNION SELECT MEMBER FROM V$LOGFILE UNION SELECT NAME FROM V$CONTROLFILE ORDER BY 1;
Et pour une nouvelle tentative d'import, effectivement il faudra faire du ménage préalablement.
09/08/2019, 16h04
Kropernic

2 pièce(s) jointe(s)

Ok ça donne bien un résultat mais je suis dubitatif.

Lorsque je suis connecté avec ce que je pense être le user ayant le plus de droit (équivalent de sysadmin en sql server), j'ai ceci :
Pièce jointe 496548
Je m'attendais à voir TOUT mais manifestement pas vu qu'il n'y a pas les chemins concernés par mon dump.

Du coup, je me suis connecté avec l'utilisateur GINIUS et j'ai ceci :
Pièce jointe 496552

Je me suis un moment demandé si le tns AGITODEV ne pointait pas sur un autre serveur mais non, c'est le même. Du coup, je ne comprends pas.

Auriez-vous des ressources claires concernant l'organisation d'oracle pour que je comprenne comment il gère ses users, ses db, etc ?
09/08/2019, 16h08
Pomalaix

Vous n'êtes manifestement pas dans la même base d'un côté et de l'autre !

Pour savoir où vous êtes, vous pouvez faire :

Code:

SELECT HOST_NAME, INSTANCE_NAME FROM V$INSTANCE;
09/08/2019, 16h13
Kropernic

Ok,

Il y a donc bien la notion d'instance comme dans sql server.

Et effectivement, c'est bien le même le même host mais pas la même instance.

Donc si je veux un dump full de la bonne instance (en l’occurrence agitodev), je dois, lors de la connexion fait sys@agitodev as sysdba.

Et effectivement, en étant comme ça, j'ai bien la bonne (la même que GINIUS) liste de folders.

Je commence à y voir plus clair.
09/08/2019, 16h23
Kropernic

Citation:

Envoyé par Pomalaix

Et pour une nouvelle tentative d'import, effectivement il faudra faire du ménage préalablement.

Je n'ai pas encore cherché mais n'existe-t-il pas une option pour lui dire qu'il peut écraser si jamais il tombe sur un truc qui existe déjà ?
Histoire de ne pas à voir faire du ménage.

Car lorsqu'on refresh un db d'acceptance/dev avec la db de production histoire de pouvoir des tests sur des données un peu à jour (parfois c'est important), s'il faut à chaque fois démarrer d'un truc clean avant de faire l'import du dump, cela me semble super contraignant...
09/08/2019, 16h30
Pomalaix

Il existe par exemple l'option d'import TABLE_EXISTS_ACTION=REPLACE, mais ça ne joue pas sur les procédures, qui ne seront alors pas rafraîchies.
C'est pour ça que la seule façon propre de pratiquer, c'est de faire le ménage auparavant.
12/08/2019, 09h19
Kropernic

Ok je vois.

Du coup, la question qui suit logiquement est : Comment faire le ménage efficacement ?
12/08/2019, 09h30
McM

Soit tu supprimes tous les schémas qui ne sont pas ceux du système

Code:

DROP USER xxxx CASCADE

Soit tu supprimes la bdd (supprimer physiquement les fichiers .dbf, archlog, etc..) et tu la recrées pour repartir d'une instance propre.
13/08/2019, 10h42
Kropernic

Est-ce normal que le

Code:

DROP USER XXX CASCADE

prenne des lustres ?
13/08/2019, 11h09
McM

Ca dépend, cela supprime le schéma, les tables, les procédures, etc... donc oui ça peut prendre du temps.
13/08/2019, 14h08
Kropernic

Ok merci.

Entre temps, on m'a montré comment supprimé une db via l'assistant de configuration (enfin un truc qui a l'air bien fait en oracle :aie:).

Sinon juste pour confirmation... J'essaie d'importer un dump d'une base en 11g dans une base en 18c. On me dit que ça doit être fait dans un pluggable database. Correct ?

J'ai googlé un peu pluggable database mais ce que j'ai trouvé reste assez flou.
14/08/2019, 11h07
Ikebukuro

Est-ce que ta base de données 18 a été créée en mode Multi-tenant (nouvelle architecture Oracle)?
Que donne

Code:

SELECT cdb FROM v$database;
14/08/2019, 11h29
Kropernic

Put*** je pige rien... L'import du dump full est fini et, après avoir résolu quelques problèmes de packages qui ne compilaient pas, je m'aperçois que je n'ai aucun trigger sur aucune table...

J'ai regardé dans le log d'export, ça a l'air d'être ok et dans celui de l'import, y a une erreur sur 1 trigger de mon schéma... Où sont donc tous les autres ?
14/08/2019, 12h40
Pomalaix

Impossible de vous aider sans avoir les commandes précises utilisées à l'export et à l'import.
De même, si on n'a pas les messages d'erreur...
14/08/2019, 13h07
Kropernic

Les commandes utilisées étaient :

Code:

expdp full=y ...

et

Code:

impdp full=y ...

... étant la directory et les noms des fichiers dump/log.

Quant aux messages d'erreurs, je viens de supprimer tous les dumps et log pour recommencer proprement une fois de plus donc je ne peux plus vous les donner mais il n'y avait aucune erreur indiquée lors du passage de la ligne

Citation:

Processing object type DATABASE_EXPORT/TABLE/TRIGGER

N.B. : Quelque chose du genre. Aussi à l'export qu'à l'import.
28/10/2020, 10h47
PaulNero

Bonjour,
si vous voulez faire de l'import dans un OS différent il faut:
-créer les tablespaces relatifs aux schémas
-mapper les datafiles dans les nouvelles destinations
-préciser schemas=gaga,gogo,... to avoid les messages bruyants (already exist...)

datapump se chargera de créer les schémas.
enjoy