Is there a way to specify columns to be excluded from the NLSSORT function

Question

Hi, in order to enable case-insensitive searches in oracle without making significant app changes, we've added a login trigger that enables linguistic sorting by setting the session params:
alter session set nls_comp=LINGUISTIC;
alter session set nls_sort=BINARY_CI;
While this gives us exactly the desired behavior for all our actual linguistic data, 90% of our primary key fields are typed as varchar2 fields that contain GUIDs. This is a problem because the primary key index is a binary index but when we query for a row by its primary key, we're getting table scans because the query is being translated to using the NLSSORT function because of our session setup.
Here's a specific example of what we're seeing:
SQL> create table t1 (c1 varchar2(255) not null, c2 varchar2(255) null, primary key (c1));
Table created.
SQL> set autotrace traceonly explain;
SQL> select * from t1 where c1='t';
Execution Plan
Plan hash value: 3617692013
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 258 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1 | 1 | 258 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(NLSSORT("C1",'nls_sort=''BINARY_CI''')=HEXTORAW('7400') )
Note
- dynamic sampling used for this statement
I understand why this is occurring and I know that if I add an NLSSORT based index to the primary key columns on each of our tables (in addition to the existing unique index used by the PK constraint) that second index will cause my query to perform an index range scan. However, for various reasons this is something of a daunting task in our app and we'd like to avoid the double indexes for performance reasons as well. So what I'd prefer to do is find a way to tell the session to NOT apply the NLSSORT function when it sees these columns in incoming SQL, but I haven't read anything that leads me to believe that such blacklisting is a feature of the NLS libraries. If anyone knows whether this is possible or not or if you have an alternate approach, I'd really appreciate your feedback.
Thanks!
Message was edited by:
user616116

Answer 1

Unfortunately, there is no way to avoid this problem globally. We are aware of this deficiency and we will look for a solution for some future release. In the meantime, you will need, unfortunately, to code the workaround you mentioned.
-- Sergiusz