RE: Accessing ASH is slow
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: "'Henry Poras'" <hrp@xxxxxxxxxx>
- Date: Tue, 23 Jul 2013 18:48:20 -0400
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@xxxxxxxxxx]
Sent: Tuesday, July 23, 2013 4:45 PM
To: Mark W. Farnham
Cc: usn@xxxxxxxxx; 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@xxxxxxxx> 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@xxxxxxxxxx]
Sent: Tuesday, July 23, 2013 3:13 PM
To: mwf@xxxxxxxx
Cc: usn@xxxxxxxxx; 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
