Je dois donc inspecter le fichier .dmp et répertorier tous les schémas qu'il contient. Comment puis-je le faire?
Mise à jour (2008-09-18 13:02) - Informations plus détaillées:
La commande impdp que j'utilise actuellement est la suivante:
impdp user/password@database directory=DPUMP_DIR
dumpfile=EXPORT.DMP logfile=IMPORT.LOG
Et le DPUMP_DIR est correctement configuré.
SQL> SELECT directory_path
2 FROM dba_directories
3 WHERE directory_name = 'DPUMP_DIR';
DIRECTORY_PATH
-------------------------
D:\directory_path\dpump_dir\
Et oui, le fichier EXPORT.DMP est infact dans ce dossier.
Le message d'erreur que je reçois lorsque j'exécute la commande impdp est le suivant:
Connected to: Oracle Database 10g Enterprise Edition ...
ORA-31655: no data or metadata objects selected for job
ORA-39154: Objects from foreign schemas have been removed from import
Ce message d'erreur est généralement attendu. J'ai besoin que la commande impdp soit:
impdp user/password@database directory=DPUMP_DIR dumpfile=EXPORT.DMP
SCHEMAS=SOURCE_SCHEMA REMAP_SCHEMA=SOURCE_SCHEMA:MY_SCHEMA
Mais pour ce faire, j'ai besoin du schéma source.
Si vous ouvrez le fichier DMP avec un éditeur capable de gérer des fichiers volumineux, vous pourrez peut-être localiser les zones où les noms de schéma sont mentionnés. Veillez simplement à ne rien changer. Il serait préférable que vous ouvriez une copie du dump original.
impdp
exporte le DDL d'une sauvegarde dmp
dans un fichier si vous utilisez le paramètre SQLFILE
. Par exemple, mettez ceci dans un fichier texte
impdp '/ as sysdba' dumpfile=<your .dmp file> logfile=import_log.txt sqlfile=ddl_dump.txt
Puis, vérifiez ddl_dump.txt
pour les espaces de table, les utilisateurs et les schémas de la sauvegarde.
Selon la documentation, cela ne modifie pas réellement la base de données:
Le code SQL n'est pas réellement exécuté et le système cible reste inchangé.
Mise à jour (2008-09-19 10:05) - Solution:
Ma solution: Ingénierie sociale, j'ai creusé très fort et j'ai trouvé quelqu'un qui connaissait le nom du schéma.
Solution technique: La recherche dans le fichier .dmp a fait a donné le nom du schéma.
Une fois que j'ai connu le nom du schéma, j'ai effectué une recherche dans le fichier de vidage et j'ai appris où le trouver.
Le nom des schémas a été vu dans le fichier .dmp:
<OWNER_NAME>SOURCE_SCHEMA</OWNER_NAME>
.__ Cela a été vu avant chaque nom de table/définition.
SCHEMA_LIST 'SOURCE_SCHEMA'
Cela a été vu vers la fin du fichier .dmp.
Il est intéressant de noter que la section SCHEMA_LIST 'SOURCE_SCHEMA'
contenait également la ligne de commande utilisée pour créer le dump, les répertoires utilisés, les fichiers de référence utilisés, la version de Windows sur laquelle il était exécuté et les paramètres de session d'exportation (langue, formats de date).
Alors, problème résolu :)
En supposant que vous ne disposiez pas du fichier journal du travail expdp qui l’avait généré, l’option la plus simple serait probablement d’utiliser le paramètre SQLFILE pour que impdp génère un fichier DDL (basé sur un fichier complet). importation). Ensuite, vous pouvez récupérer les noms de schéma de ce fichier. Ce n’est pas idéal, bien sûr, car impdp doit lire l’ensemble du fichier de vidage pour extraire le DDL, puis à nouveau pour accéder au schéma qui vous intéresse, et vous devez faire un peu de texte pour rechercher les différentes instructions CREATE USER. , mais cela devrait être faisable.
Lorsque vous exécutez la commande impdp pour générer un fichier sql, vous devez l'exécuter en tant qu'utilisateur doté du rôle DATAPUMP_IMP_FULL_DATABASE.
Ou ... exécutez-le en tant qu'utilisateur avec des privilèges faibles et utilisez l'option MASTER_ONLY = YES, puis inspectez la table principale. par exemple.
select value_t
from SYS_IMPORT_TABLE_01
where name = 'CLIENT_COMMAND'
and process_order = -59;
col object_name for a30
col processing_status head STATUS for a6
col processing_state head STATE for a5
select distinct
object_schema,
object_name,
object_type,
object_tablespace,
process_order,
duplicate,
processing_status,
processing_state
from sys_import_table_01
where process_order > 0
and object_name is not null
order by object_schema, object_name
/
Étape 1: Voici un exemple simple. Vous devez créer un fichier SQL à partir du fichier de vidage à l'aide de l'option SQLFILE
.
Étape 2: Grep pour CREATE USER
dans le fichier SQL généré (ici tables.sql)
Exemple ici:
$ impdp directory=exp_dir dumpfile=exp_user1_all_tab.dmp logfile=imp_exp_user1_tab sqlfile=tables.sql
Importation: Sortie 11.2.0.3.0 - Production le ven. 26 avr. 08:29:06 2013
Copyright (c) 1982, 2011, Oracle et/ou ses filiales. Tous les droits sont réservés.
Nom d'utilisateur:/as sysdba
Type d'objet de traitement SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA Le travail "SYS". "SYS_SQL_FILE_FULL_01" s'est terminé avec succès à 08:29:12.
$ grep "CREATE USER" tables.sql
CREATE USER "USER1" IDENTIFIÉ PAR LES VALEURS: 270D559F9B97C05EA50F78507CD6EAC6AD63969E5E; BBE7786A5F9103 '
Beaucoup d'options de datapump expliquées ici http://www.acehints.com/p/site-map.html
Ma solution (similaire à la réponse de KyleLanser) (sur une boîte Unix):
strings dumpfile.dmp | grep SCHEMA_LIST
Vous devez rechercher OWNER_NAME.
cat -v dumpfile.dmp | grep -o '<OWNER_NAME>.*</OWNER_NAME>' | uniq -u
cat -v transforme le fichier de vidage en texte visible.
grep -o ne montre que le match, on ne voit donc pas de longues lignes
uniq -u supprime les lignes en double, ce qui réduit les résultats
Cela fonctionne plutôt bien, même sur des fichiers de sauvegarde volumineux, et pourrait être modifié pour une utilisation dans un script.