Oracle NLS_SORT not working on system level - oracle

Question

I am using oracle 11g r2, and trying to configure DB to sort order using linguistic sort.
I did
alter system set NLS_SORT='RUSSIAN' SCOPE=SPFILE;
alter system set NLS_COMP='LINUGUISTIC' SCOPE=SPFILE;
after i've restarter oracle i checked these params:
show parameters NLS_SORT;
show parameters NLS_COMP;
it show me the right values.
But when I make sort
select name from test order by name;
it show me results in not correct order, ie digits first, then letters.
but if i will do
alter session set nls_sort='RUSSIAN';
alter session set nls_comp='LINGUISTIC';
select name from test order by name;
it show me the right order.
anyone know why sysem changes not showing me right results ?

Answer 1

The priority for globalisation settings is shown in the documentation. You're setting priority 4 in that list, 'Specified in the initialization parameter file'. You are not setting priority 1 ('Explicitly set in SQL functions') and you get the results you want when you do set priority 2 ('Set by an ALTER SESSION statement'). By a process of elimination that indicates that your 'not correct' order is being influenced by priority 3, 'Set as an environment variable'.
You can check the values actually being used by your session with select * from nls_session_parameters.
The NLS_SORT environment variable is probably not being set directly; I suspect it's being derived from NLS_LANGUAGE, which is derived from NLS_LANG. If you aren't explicitly setting that in your operating system environment then the client will set it based on the operating system locale, generally, though the exact client you use may make a significant difference. You might need to explicitly set an NLS_COMP environment variable, if the database default for that is really being overridden.
SQL Developer, for example, allows you to specify the NLS settings in the preferences (accessed from Tools->Preferences->Database->NLS); the defaults appear to be based on operating system settings, in Windows anyway. For SQL*Plus you'd need to set operating system environment variables.
This also means that if you get it working in one place - the queries give the right order when run from SQL Developer, say - they might not work when used elsewhere, say over JDBC which has its own locale settings. Just something to watch out for.
A brute-force approach might be to add the alter session commands to a login trigger, but that doesn't sound ideal as it just masks the environment configuration.

Answer 2

You can set NLS parameters at different levels
As initialization parameters on the instance/server.
SQL> alter system set V$NLS_PARAMETER = 'XXX' scope = both;
As environment variables on the client.
% setenv NLS_SORT FRENCH
As ALTER SESSION parameters.
SQL> ALTER SESSION SET V$NLS_PARAMETER = = 'XXX'
Any setting overrides the setting on a higher level. So setting it server side does not guarantee that the setting is used by all clients connecting.
If you want to make sure it is set for every client connecting use a logon trigger. Even then a user can explicitly override the 'default' setting

Answer 3

You've got a typo in your second "ALTER SYSTEM" command (LINUGUISTIC instead of LINGUISTIC).
If your real command doesn't contain this error, I'd check whether your client sets the NLS session parameters to something else.

Answer 4

Regardless of the system settings, I would make every effort to ensure that your applications completely specify the NLS environment that they require. It's much more robust, particularly when you need to point the application code at different environments that may be newly setup, or shared with other systems.
In fact, I'd go as far as to say that you might be better not using setting system-level environment settings.