Détermination du paramètre NLS_LANG pour un fichier de vidage de base de données Oracle existant

Question

Nous avons reçu un fichier de vidage d'une autre équipe qui est parti pour le reste de l'année. Lorsque nous essayons d'importer la sauvegarde dans notre propre base de données, nous obtenons l'erreur suivante:

IMP-00038: Could not convert to environment character set's handle

À quelques recherches, notre spéculation est que nous avons un décalage entre le paramètre NLS_LANG de la machine source et notre machine locale. Nous n'avons actuellement aucun moyen de vérifier quelle est la valeur de NLS_LANG sur la machine source. Donc, ayant juste un fichier de vidage dans nos mains, est-il un moyen de comprendre la valeur NLS_LANG avec laquelle l'exportation a été faite? D'après son apparence, nous devrions être en mesure de surcharger la variable d'environnement NLS_LANG avant d'exécuter le client d'importation (imp).

Une autre chose est, le cliché a été fait à partir d'une instance de 11g et notre version d'importation est 10. J'ai lu que l'imp n'est pas compatible avant. Cela pourrait-il être le problème ici (au lieu de la discordance NLS_LANG)?

Answer 1

façon la plus facile sur unix est:

#>imp username/password file=test.dmp show=y 

Import: Release 10.2.0.3.0 - Production on Fri Nov 26 08:38:47 2010 

Copyright (c) 1982, 2005, Oracle. All rights reserved. 


Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production 
With the Partitioning, OLAP and Data Mining options 

Export file created by EXPORT:V10.02.01 via conventional path 
import done in US7ASCII character set and AL16UTF16 NCHAR character set 
import server uses WE8ISO8859P1 character set (possible charset conversion) 

Version exp/imp est un problème: J'utilise habituellement le V10 programme d'exportation et le faire se connecter à la base de données V11. Assurez-vous d'avoir un alias pour dev11 dans votre tnsnames.ora dans dev10's oracle_home.

hostname{oracle}# . oraenv 
ORACLE_SID = [oracle] ? dev10 
hostname{oracle}# 
hostname{oracle}#>exp username/password@dev11 full=y dumpfile=dump.exp 

Answer 2

Même si le fichier est un fichier binaire, il existe des extraits de texte lisibles par l'utilisateur. J'ai vu les chaînes suivantes là-dedans, et je pense que cela répond à ma question:

 
<CHARSET>AL32UTF8</CHARSET><NCHARSET>AL16UTF16</NCHARSET> 
... 
NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA' 

Answer 3

Ates, essayez impdp - qui pourrait parfois aider :-)

Answer 4

Another thing is, the dump was done from an 11g instance and our imp version is 10. I read that imp is not forward compatible. Could this be the issue here (instead of the NLS_LANG mismatch)?

A: Vous avez raison; Vous ne pouvez pas importer un fichier de vidage créé avec un client Oracle donné, car le client Oracle de votre base de données Oracle cible est plus ancien.

Bien que il n'est pas recommandé, vous pouvez exporter une plus récente Source Oracle Database (à savoir 10g +) avec un plus Oracle Client (c.-à-10g), puisque vous utilisez la même version client Oracle à importer dans votre ancien Base de données Oracle (c.-à-d. 10g).

Hypothèse: La version Oracle Client de votre base de données source est la même que la version de votre base de données cible Oracle. Notez que les outils de mélange Datapump (11g) et imp (-10g) l'utilitaire d'importation ne fonctionne pas.

lien Interessant Using Different Releases and Versions of Export

Answer 5

Peut-être exporté à l'aide expdp .... essayer impdp .... c'est-ce que j'ai vu lors de la recherche Google, et vraiment cela a fonctionné pour moi cette même question.