There are usually two reasons for NLS character set problems:

There’s a mismatch between the NLS character set of the client and that of the database server.
You have an NLS-related operating system variable that has been set incorrectly.

To determine whether there is an NLS character set mismatch, compare your target database
character set to your client character set. To display your target database character set, issue the
following SQL statement:

SQL> select value from v$nls_parameters where parameter = 'NLS_CHARACTERSET';

VALUE
----------------------
WE8ISO8859P1

Compare that to the operating system NLS_LANG setting on your client. In Linux/Unix, use the
echo command to display the relevant NLS parameters:
$ echo $NLS_LANG
In Windows, search the Registry Editor for the value of NLS_LANG as shown here: Start
images un images regedit images Edit images Find images NLS_LANG.
If you find that there is an NLS_LANG mismatch, then you can override the OS variable
manually. For example, in a Linux/Unix C shell environment, use the setenv OS command:
$ setenv NLS_LANG american_america.we8iso8859p1
In a Linux/Unix Korn or Bash shell environment, use the OS export command as follows:
$ export NLS_LANG=american_america.we8iso8859p1
In a Windows environment, use the set command, as shown here:
c:\> set NLS_LANG=american_america.we8iso8859p1
If you set NLS_LANG to a value that RMAN doesn’t recognize, then you may receive an error
like this:
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-12705: Cannot access NLS data files or invalid environment specified
If you receive an error like that, ensure that your NLS_LANG operating system parameter is set
to a valid value.
image Tip To view valid NLS values, query the V$NLS_VALID_VALUES view.

How It Works
When faced with potential NLS character set issues, first verify the settings on both your target
server and your client. The value of NLS_LANG should match between the client OS and the
target database server. To troubleshoot this, you can manually override the client setting and
force it to match your target database NLS_LANG setting.
When troubleshooting NLS issues, it can sometimes be difficult to pin down where the NLS
values are being set. This is because you can have variables set at the database, instance, session,
and client OS. Table 17-1 describes useful NLS views that can help verify at what level the NLS
parameters have been set.

WE8MSWIN1252 is a character set which supports West European languages

Data Pump jobs will use the NLS_CHARACTERSET parameter, but non-English parameter
files will use NLS_LANG, so setting this variable correctly is important for character set
conversions.

>export NLS_LANG=AMERICAN_AMERICA.US7ASCII
>exp FULL=Y file=Exp_test.dmp log=Exp_test.log
Export done in US7ASCII character set and AL16UTF16 NCHAR character set server uses
WE8MSWIN1252 character set (possible charset conversion) ...
#Using NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 will avoid the charset
conversion

Changing the Character Set

--------------------------
Even with the best planning, you might need to change the character set after the database has
been created. This is possible, but there are some hoops to go through. There is no simple “alter
database” command for changing the character set.

One approach is to just start over and create a new database, export out the current one, and
import that data into the new database with a new character set. However, that might not be
possible, so you might need to instead use a tool to do the character set conversion.

The csscan utility is one tool you can use for character set conversion. It will list areas that are
issues and also create a script to change the character set after the issues are handled. Exporting a
couple of tables and importing them back in might be easier than re-creating the database. The
following example shows the steps involved in changing the character set and gives an idea of
what will need to be planned.
>csscan FULL=Y TONCHAR=UTF8 LOG=check CAPTURE=Y ARRAY=1000000
PROCESS=2
csscan> sys as sysdba
--Use the sys password to login and get the output of the scan
-- Now log into the database via sqlplus and shutdown database
-- and startup in restrict mode
SQL>shutdown immediate;
SQL>startup restrict
SQL> alter system set aq_tm_processes=0;
SQL> alter system set job_queue_processes=0;
SQL> alter database CHARACTER SET new_characterset;
-- National character can be set here
SQL> %ORACLE_HOME%/rdbms/admin/csalter.plb
--set the aq_tm_processes and job_queue_processes back
to their initial settings and restart the database

This example demonstrates some of the issues that will need to be resolved to change the
character set. For more details, see the Oracle documentation on csscan.