Comments on: Index naming

By: Jonathan Lewis

Jonathan Lewis — Mon, 12 Mar 2012 12:24:03 +0000

Flado,

I also thought that object names were restricted to ASCII (7-bit) – but all I could find in the manuals was advice to stick to ASCII because that gives maximum transportability. There were also the comments about names being stored in uppercase only in the data dictionary unless quoted – so the introduces a few more restrictions on how easily you can use them. Perhaps the naming has to be restricting to the single byte characters of the database character set.

Your example is quite entertaining as a demo, because the order of output changes if you do:

alter session set nls_comp=linguistic;
alter session set nls_sort = binary_ci;

This sort of thing could make a real mess of peoples’ favourite admin scripts.

By: Flado

Flado — Fri, 02 Mar 2012 16:48:05 +0000

> US7ASCII…

Are you sure? This works :-)

create table t(id int,i1 int);
create index "Ä" on t(i1);
create index "ä" on t(id);
create index "a" on t(i1,id);
create index "A" on t(id,i1);
select index_name from user_indexes where table_name='T' order by index_name;

By: Pavol Babel

Pavol Babel — Tue, 07 Feb 2012 23:17:59 +0000

US7ASCII…

By: Pavol Babel

Pavol Babel — Tue, 07 Feb 2012 22:42:41 +0000

The basic formula for index range scan is OK. It goes like BLEVEL + ceiling(selectivity * leaf_blocks) . However, in Jonathan’s example the selectivity for product_id is approximately 1/500000. So CBO predicts only 3 LIO for both access paths (to change it, we would have to set leaf_blocks statistic for T1_I1 to at least 500 001 ).
It is not very common to have two indexes with same prefixed columns (especially such a selective one), but sometimes there could be reason for that.

Regards
Pavol Babel

By: lascoltodelvenerdi

lascoltodelvenerdi — Tue, 07 Feb 2012 22:25:50 +0000

“Because when you sort the index names alphabetically”

Uhm… does the NL parameters play a role here or not? (i.e.: different language settings = different sorting)
Or Oracle internally always use an “English sort”?

By: AMC

AMC — Tue, 07 Feb 2012 14:51:56 +0000

This is the MOS note
Handling of equally ranked (RBO) or costed (CBO) indexes (Doc ID 73167.1)

By: Narendra

Narendra — Tue, 07 Feb 2012 09:24:16 +0000

The two indexes produce the same cost
Does this not mean the costing itself has an issue here ? Should the cost of accessing index with larger width (due to more number of columns) be more than accessing index with smaller width, especially when both are being probed with range scans ?

By: Mauro

Mauro — Tue, 07 Feb 2012 04:12:55 +0000

Hi Jonathan,

do you mean Doc ID 73167.1?

Regards,
Mauro

By: Pavol Babel

Pavol Babel — Tue, 07 Feb 2012 02:02:14 +0000

Jonathan,

it is too late so unless I’m mistaken it seems simple increasing of BLEVEL statistic by one for T1_I1 worked on my site (11.2.0.1 DB). The cost for T1_I1 index has been increased from 3 to 4, which makes sense to my mind. As you suggested, we would have to increase leaf_blocks statistic dramatically to make T1_I1 expensive enough. However, fine blevel hacking could be smart solution (especially in 10g where SQL baselines can’t be used)
This tie-break situation is quite rare, but I have faced it several times, too. Oracle should fix the code, the alphabetical sort rule should be really used as the last resort (which obviously is not in this situation)

Regards
Pavol Babel