RE: Accessing ASH is slow

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Tue, 23 Jul 2013 18:48:20 -0400
Message-ID: <045001ce87f6$bbc00030$33400090$_at_rsiz.com>

Because the NLS_COMP (comparison) value was set to LINGUISTIC, so Oracle translates the join condition for you to use linguistic equivalent rather than binary values. This allows for binary values that map to equivalent values in some language to evaluate as equals. For purposes of the values in NEED_SAMPLE this probably never makes a difference to the answer, but Oracle injects the change to processing views nonetheless.  

The Oracle Database Globalization Support Guide has some information about this, and the Oracle Database SQL Language Reference has information about how the NLSSORT function operates.  

mwf  

From: Henry Poras [mailto:hrp_at_google.com] Sent: Tuesday, July 23, 2013 4:45 PM
To: Mark W. Farnham
Cc: usn_at_usn-it.de; ORACLE-L
Subject: Re: Accessing ASH is slow  

but why should the join condition even apply the NLSSORT function?  

On Tue, Jul 23, 2013 at 4:36 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

It should not affect the answer (except possibly the ordering of the reported set), but it can affect whether or not an index can be used in projecting the join.  

From: Henry Poras [mailto:hrp_at_google.com] Sent: Tuesday, July 23, 2013 3:13 PM
To: mwf_at_rsiz.com
Cc: usn_at_usn-it.de; ORACLE-L

Subject: Re: Accessing ASH is slow  

Martin,  

Maybe I'm missing something here, but why would the NLSSORT setting impact the join condition? Wouldn't the outcome of the join equality be the same regardless of the sort setting?  

Henry    

--
http://www.freelists.org/webpage/oracle-l

Received on Wed Jul 24 2013 - 00:48:20 CEST