[INSIGHT OUT 2011] B24 effective indexing(tom kyte)

<Insert Picture Here>
Effective Indexing
Thomas Kyte
http://asktom.oracle.com/

Who am I
• Been with Oracle since 1993
• User of Oracle since 1987
• The “Tom” behind AskTom in
Oracle Magazine
www.oracle.com/oramag
• Expert Oracle Database• Expert Oracle Database
Architecture
• Effective Oracle by Design
• Expert One on One Oracle
• Beginning Oracle

B*Tree
• What I call ‘conventional’ indexes
• Most common, some people might have only used this type
and nothing else
• Similar in implementation to a binary search tree
– Only not “binary” – they are N-ary, branches don’t go just left or
rightright
• Goal: minimize time to find small amounts of data
– Go ahead, define small
• Structurally they look like

0..50
51..100
101..150
….
10000.. 10050
0..10 51..58 10000.. 10009
Create index I on T(numColumn)
Lowest level
blocks are called
Leaf blocks
Contain every
indexed key and a
rowid
Interior blocks are
known as branch
blocks,
navigational
Leaf Nodes are
actually a doubly
linked list – once
we find where to
start – range
scanning is easyIt all starts with a
0..10
11..19
20..25
….
47.. 50
51..58
59..63
64..75
….
98.. 100
10000.. 10009
10010.. 10020
10021..10028
…
10046..10050
0,rowid
0,rowid
1,rowid
….
10,rowid
11,rowid
11,rowid
12,rowid
….
19,rowid
10046,rowid
10048,rowid
10048,rowid
….
10050,rowid
….
….
10021,rowid
10022,rowid
10023,rowid
….
10028,rowid ….
Leaf blocksrowid scanning is easyIt all starts with a
root block, root
could be all there
is

B*Tree Facts
• No such thing as a non-unique index under the covers
– Create index I on T(x,y) is sort of like Create UNIQUE index I on
T(x,y,rowid)
• All leaf blocks are at the same level
– Level is also known as the HEIGHT, BLEVEL (another metric
reported frequently) differs from height by one (does not count leafreported frequently) differs from height by one (does not count leaf
blocks)
– Any traversal from root to leaf takes the same number of IO’s
• Select indexed_col from T where indexed_col = :x will
take same number of IO’s regardless of the value of :x at
runtime.
– Most B*Trees will have a height of 2 or 3, even for millions of
records, for example

B*Tree Facts
ops$tkyte%ORA11GR1> create table t
2 as
3 select level x, level y
4 from dual
5 connect by level <= 10000000;
Table created.
ops$tkyte%ORA11GR1> alter table t add constraint t_pk primary key(x);
Table altered.
ops$tkyte%ORA11GR1> select index_name, blevel, num_rows
2 from user_indexes
3 where index_name = 'T_PK';
INDEX_NAME BLEVEL NUM_ROWS
------------------------------ ---------- ----------
T_PK 2 10000000

B*Tree Facts
ops$tkyte%ORA11GR1> set autotrace traceonly statistics
ops$tkyte%ORA11GR1> select x from t where x = 1;
3 consistent gets
ops$tkyte%ORA11GR1> select * from t where x = 1;
4 consistent gets
3 consistent gets
4 consistent gets
3 consistent gets
4 consistent gets

B*Tree Facts
• Index_stats is an important “V$” table
– Only one row
– Result of last validate structure
– Validate structure is an OFFLINE (blocking) operation
• Excellent General Purpose Indexing Mechanism
• Works well for small tables• Works well for small tables
• Works well for large tables
• Experiences little, if any, degradation in retrieval
performance as the size of the underlying table grows
• We’ll investigate when to use them shortly
– But first, compression and reverse key
Index_stats.sql

Index Key Compression
• Remove redundant leading edge values in index
keys
– Break key into “prefix” and “suffix”
– Repeating prefix values are not stored on leaf block –
only stored once
– Each leaf block is self contained– Each leaf block is self contained
– For example

• Index on t(owner,object_type,object_name)
(OPS$TKYTE, PROCEDURE, MAINTAIN_T, AAATM8AAEAAABV0AAP)(OPS$TKYTE, PROCEDURE,
P, AAATM8AAEAAABV0AAQ)(OPS$TKYTE, PROCEDURE, P1, AAATM8AAEAAABV0AAR)
(OPS$TKYTE, PROCEDURE, P2, AAATM8AAEAAABV0AAS) (OPS$TKYTE, PROCEDURE,
SHOW_SPACE, AAATM8AAEAAABV0AAT) (OPS$TKYTE, PROCEDURE, Y, AAATM8AAEAAABV0AAU)
(OPS$TKYTE, SEQUENCE, S, AAATM8AAEAAABV0AAV) (OPS$TKYTE, TABLE, ALL_DATA,
AAATM8AAEAAABV0AAW) (OPS$TKYTE, TABLE, AUDIT_TRAIL, AAATM8AAEAAABV0AAX)
(OPS$TKYTE, TABLE, BIND_DATA, AAATM8AAEAAABV0AAY) (OPS$TKYTE, TABLE, C,
AAATM8AAEAAABV0AAZ) (OPS$TKYTE, TABLE, CHAINED_ROWS, AAATM8AAEAAABV0AAa)
OPS$TKYTE, PROCEDURE (MAINTAIN_T, AAATM8AAEAAABV0AAP)(P,
AAATM8AAEAAABV0AAQ)(P1, AAATM8AAEAAABV0AAR) (P2, AAATM8AAEAAABV0AAS)
(SHOW_SPACE, AAATM8AAEAAABV0AAT) (Y, AAATM8AAEAAABV0AAU) OPS$TKYTE, SEQUENCE
(S, AAATM8AAEAAABV0AAV) OPS$TKYTE, TABLE (ALL_DATA, AAATM8AAEAAABV0AAW)
( AUDIT_TRAIL, AAATM8AAEAAABV0AAX) ( BIND_DATA, AAATM8AAEAAABV0AAY) ( C,
AAATM8AAEAAABV0AAZ) ( CHAINED_ROWS, AAATM8AAEAAABV0AAa) ( DBA_DATA,
AAATM8AAEAAABV0AAb) ( DEPARTMENTS_OBJ_T, AAATM8AAEAAABV0AAc) ( EMP,
AAATM8AAEAAABV0AAd) ( EMPLOYEES, AAATM8AAEAAABV0AAe) ( GTT,
• Index on t(owner,object_type,object_name) compress 2
(OPS$TKYTE, TABLE, DBA_DATA, AAATM8AAEAAABV0AAb) (OPS$TKYTE, TABLE,
DEPARTMENTS_OBJ_T, AAATM8AAEAAABV0AAc) (OPS$TKYTE, TABLE, EMP,
AAATM8AAEAAABV0AAd) (OPS$TKYTE, TABLE, EMPLOYEES, AAATM8AAEAAABV0AAe)
(OPS$TKYTE, TABLE, GTT, AAATM8AAEAAABV0AAf) (OPS$TKYTE, TABLE, IOT,
AAATM8AAEAAABV0AAg) (OPS$TKYTE, TABLE, LINEITEMS, AAATM8AAEAAABV0AAh)
(OPS$TKYTE, TABLE, MV, AAATM8AAEAAABV0AAi) (OPS$TKYTE, TABLE, ORDERS,
AAATM8AAEAAABV0AAj) (OPS$TKYTE, TABLE, SELECT, AAATM8AAEAAABV0AAk)
(OPS$TKYTE, TABLE, T, AAATM8AAEAAABV0AAl) (OPS$TKYTE, TABLE, T1,
AAATM8AAEAAABV0AAm) (OPS$TKYTE, TABLE, T2, AAATM8AAEAAABV0AAn) (OPS$TKYTE,
TABLE, T3, AAATM8AAEAAABV0AAo) (OPS$TKYTE, TABLE, TEST_FA,
AAATM8AAEAAABV0AAp) (OPS$TKYTE, TABLE, TEST_LONG, AAATM8AAEAAABV0AAq)
(OPS$TKYTE, TABLE, USER_DATA, AAATM8AAEAAABV0AAr)
AAATM8AAEAAABV0AAj) (OPS$TKYTE, TABLE, SELECT, AAATM8AAEAAABV0AAk) (OPS$TKYTE,
TABLE, T, AAATM8AAEAAABV0AAl) (OPS$TKYTE, TABLE, T1, AAATM8AAEAAABV0AAm)
(OPS$TKYTE, TABLE, T2, AAATM8AAEAAABV0AAn) (OPS$TKYTE, TABLE, T3,
AAATM8AAEAAABV0AAo) (OPS$TKYTE, TABLE, TEST_FA, AAATM8AAEAAABV0AAp)
(OPS$TKYTE, TABLE, TEST_LONG, AAATM8AAEAAABV0AAq) (OPS$TKYTE, TABLE,
USER_DATA, AAATM8AAEAAABV0AAr)
AAATM8AAEAAABV0AAj) (OPS$TKYTE, TABLE, SELECT, AAATM8AAEAAABV0AAk)
(OPS$TKYTE, TABLE, T, AAATM8AAEAAABV0AAl) (OPS$TKYTE, TABLE, T1,
AAATM8AAEAAABV0AAm) (OPS$TKYTE, TABLE, T2, AAATM8AAEAAABV0AAn) (OPS$TKYTE,
TABLE, T3, AAATM8AAEAAABV0AAo) (OPS$TKYTE, TABLE, TEST_FA,
AAATM8AAEAAABV0AAp) (OPS$TKYTE, TABLE, TEST_LONG, AAATM8AAEAAABV0AAq)
(OPS$TKYTE, TABLE, USER_DATA, AAATM8AAEAAABV0AAr)
AAATM8AAEAAABV0AAd) ( EMPLOYEES, AAATM8AAEAAABV0AAe) ( GTT,
AAATM8AAEAAABV0AAf) ( IOT, AAATM8AAEAAABV0AAg) ( LINEITEMS,
AAATM8AAEAAABV0AAh) ( MV, AAATM8AAEAAABV0AAi) ( ORDERS, AAATM8AAEAAABV0AAj)
( SELECT, AAATM8AAEAAABV0AAk) ( T, AAATM8AAEAAABV0AAl) ( T1,
AAATM8AAEAAABV0AAm) ( T2, AAATM8AAEAAABV0AAn) ( T3, AAATM8AAEAAABV0AAo)
( TEST_FA, AAATM8AAEAAABV0AAp) ( TEST_LONG, AAATM8AAEAAABV0AAq) (USER_DATA,
AAATM8AAEAAABV0AAr)

• Some Facts
– Available with Oracle8i R1 (version 8.1.5) and above
– Index probably consumes less disk space
– Can reduce I/Os on the system -- both physical and
logical
– Can improve buffer cache efficiency, there is less to– Can improve buffer cache efficiency, there is less to
cache
– May increase contention as there are now more rows
per leaf block
– May require increased CPU to access
Indc.sql
Indc2.sql

B*Tree When to use
• I do not like rules of thumb (ROT)
• Why? Consider these two – both are valid:
– Use a B*Tree index to index columns if you are going to access a
very small number of the rows in the table via the index.
– Use a B*Tree index if you are going to process many/most/all of
the rows in a table via the index
– They conflict – but they are both valid– They conflict – but they are both valid
– Discuss
• What is small
• What is initial response versus total throughput about
• What about when the index can be used instead of the table
• I like to understand how something works – and use that to
decide

B*Tree When to use
• So, the ‘rules are’
– As the means to access rows in a table: You will read the index
to get to a row in the table. Here you want to access a very small
number of the rows in the table.
– As the means to answer a query: The index contains enough
information to answer the entire query—we will not have to go to
the table at all. The index will be used as a “thinner” version of thethe table at all. The index will be used as a “thinner” version of the
table.
– As the means to optimize for initial response time: You want to
retrieve all of the rows in a table, including columns that are not in
the index itself – in some sorted order – the index will possibly
allow for immediate response (but slower overall throughput).

B*Tree When to use
• Organization counts
– Index on primary key populated by sequence/SYSDATE.
• Data in table is mostly sorted by sequence/SYSDATE
• Data in index is sorted by sequence/SYSDATE.
• Index very efficient for range scans
• But, how often do you range scan on a primary key populated
by sequence?by sequence?
• How often by date range?
– Index on LAST_NAME
• Data in table is randomly organized (your don’t hire everyone
with a last name of ‘A%’ on the same day)
• Data in index is sorted
• Index is not efficient for large range scans
o It would skip all around in the table

B*Tree When to use
• Enter the CLUSTERING FACTOR
– A measure of how sorted the table is by the key in the
index
– It measures how many IO’s it would take to read the
entire table via the index – row after row after row
– If table is sorted by key, clustering factor near number
of blocks in the table.
– If table is not sorted by key, clustering factor nearer
number of ROWS in table.
– Please ask yourself, how many ways can the table be
sorted on disk?
cf.sql

2 total IO’S
Against the
Table
0..50
51..100
101..150
….
10000.. 10050
0..10
11..19
20..25
….
47.. 50
51..58
59..63
64..75
….
98.. 100
10000.. 10009
10010.. 10020
10021..10028
…
10046..10050
….
Create index nm_idx on name)
Select * from t where pk between 1 and 8
1,Alice
2,Bob
3,Candy
4,Doug
5,Ellen
6,Frank
7,George
8,Hank
….
….
….
….
….
… …
…
…
…
….
Pk Name
1 Alice
2 Sue
3 Victor
4 Will
Pk Name
5 Irene
6 Kelly
7 Melanie
8 Oliver
Pk Name
9 George
10 Candy
11 Uwe
12 Wally
Pk Name
13 Ellen
14 Tom
15 Rick
16 Paul
Pk Name
17 Doug
18 Irene
19 Lance
20 Jack
Pk Name
21 Hank
22 Frank
23 Nicole
24 Bob

0..50
51..100
101..150
….
10000.. 10050
0..10
11..19
20..25
….
47.. 50
51..58
59..63
64..75
….
98.. 100
10000.. 10009
10010.. 10020
10021..10028
…
10046..10050
….
Create index nm_idx on name)
Select * from t where Name between ‘Alice’ and ‘Hank’
8 total IO’S
Against the
Table
cf.sql
1,Alice
2,Bob
3,Candy
4,Doug
5,Ellen
6,Frank
7,George
8,Hank
….
….
….
….
….
… …
…
…
…
….
Pk Name
1 Alice
2 Sue
3 Victor
4 Will
Pk Name
5 Irene
6 Kelly
7 Melanie
8 Oliver
Pk Name
9 George
10 Candy
11 Uwe
12 Wally
Pk Name
13 Ellen
14 Tom
15 Rick
16 Paul
Pk Name
17 Doug
18 Irene
19 Lance
20 Jack
Pk Name
21 Hank
22 Frank
23 Nicole
24 Bob

B*Tree in summary
• Most common
• Well understood (and mis-understood!)
• Very scalable access times
– To return a row from a 1,000 row index takes about as
much work as from a 10,000,000 row indexmuch work as from a 10,000,000 row index
• Indexing should be thought of as a design time
thing
• You might index to retrieve a few rows, all rows, or
to avoid the table in the first place

Bitmap Index
• Introduced in version 7.3, EE
• Designed for read mostly or read only application
• Specifically not designed or usable with OLTP
tables
– Tables undergoing concurrent modification– Tables undergoing concurrent modification
– Tables undergoing single row modifications
• A single bitmap key entry points to many rows
– In contrast to b*tree where there is a 1:1 relation
between keys in the index and rows in the table
bm1.sql

Bitmap Index – bitwise operations
JOB BITS
--------- ------------------------------
ANALYST 0-0-0-0-0-0-0-1-0-0-0-0-1-0
CLERK 1-0-0-0-0-0-0-0-0-0-1-1-0-1
MANAGER 0-0-0-1-0-1-1-0-0-0-0-0-0-0
PRESIDENT 0-0-0-0-0-0-0-0-1-0-0-0-0-0PRESIDENT 0-0-0-0-0-0-0-0-1-0-0-0-0-0
SALESMAN 0-1-1-0-1-0-0-0-0-1-0-0-0-0
CLERK OR 1-0-0-1-0-1-1-0-0-0-1-1-0-1
MANAGER
CLERK AND 0-0-0-0-0-0-0-0-0-0-0-0-0-0
MANAGER

Bitmap Index – structure
JOB LO-ROWID HI-ROWID BITS
--------- -------- -------- --------------------------
ANALYST AAAR4AAA AAABEEAAH 0-0-0-0-0-0-0-1-0-0-0-0-1-0
ANALYST AAAR4AAB AAABEEAAM 1-0-0-0-0-0-0-0-0-0-1-1-0-1
ANALYST AAAR4AAC AAABEEAAN 0-0-0-1-0-1-1
PRESIDENT AAAR4AAA AAABEEAAI 0-0-0-0-0-0-0-0-1-0-0-0-0-0
PRESIDENT AAAR4AAX AAABEEAAC 0-1-1-0-1-0-0-0-0-1-0-0-0-0
PRESIDENT AAAR4AAY AAABEEAAJ 1-0-1-0-0-1-1
• Key + Lo Rowid – Hi Rowid + Bitmap
• 0’s and 1’s map to rowids in that range
• If we know max number of rows/block – simple math
• alter table emp minimize records_per_block;
• Note the multiple entries per JOB!

Bitmap Index
• Can answer questions like:
– How many of this match (count 0’s and 1’s)
– How many of this that or the other thing match
• Bitwise and/or bitmaps
• Count 0’s and 1’s• Count 0’s and 1’s
– Good for accessing a few rows (just like B*Tree)
– Good for counting, identifying many, all, some of the
rows (just like B*Tree)

Bitmap Index - when
• Most common rule of thumb going is “low distinct
cardinality”
• Now, I defy you to define “low distinct cardinality”
– Is 2 “low distinct cardinality”?
– Yes it is
– No it isn’t
– It depends
• In pure ad-hoc, even high distinct cardinality
columns could/should be considered for bitmaps
• Consider

Bitmap Index - when
• How many men in regions 1, 10 and 30 are there in the 41
and over age group?
• How many men in region 20 or women in region 22 are 18
and under?
• How many people are in regions 11, 20 or 30
• How many over 41 year olds are there that are women?• How many over 41 year olds are there that are women?
• Etc etc etc
• Now, come up with an indexing scheme using B*Trees for
that
• And then maintain it as the questions change (and change
and change)
bm2.sql

Function Based Indexes
• Added in Oracle 8i release 1 (8.1.5) as a feature of
EE and PE
• In 9i, a feature of SE, EE and PE
• Great for
– Case insensitive searches/sorts– Case insensitive searches/sorts
– Searching on derived attributes -- complex formulas
• Provide immediate, transparent value to the
application
• Function you index must be “pure” - deterministic
pure.sql

• Thinking outside the box with FBI's
– Two facts
• B*Tree indexes will never have an entirely NULL
entry. If the entire key is NULL, it will not be placed
in the B*Tree
• We have function based indexes that allow us to
• We have function based indexes that allow us to
incorporate complex, procedural logic in them
– We can solve common problems
• Indexing only some of the rows in a table (like
indexing a where clause)
• Enforcing complex integrity in the database
• Using an index for “where column is null”

• Selective Indexing
– You have a table with a flag column
– You want to index this column when the flag = 'x'
– A small % of the table is accessed by this values
– Sounds like what you've read about bitmap indexes but
• This table is modified all day long
• This table is modified all day long
• Bitmaps would kill concurrency
• The bitmap would grow to outrageous sizes quickly
– The answer -- a function based index
• Or a better model
• Or a better structure (AQ) fbi.sql

• Selective Uniqueness
– You have a table with versioned information in it
• A project table with status "ACTIVE" and
"INACTIVE"
– When status is "ACTIVE", some set of columns must be
unique
unique
– When status is "INACTIVE", those columns may
contain any values -- any number of duplicates
– How can you do it?
selind.sql

• Where column is NULL
– Nulls are not indexed right?
– Wrong – entirely NULL key entries are not, but if *any*
bit of a concatenated index is not null Entry is made.
• Fear no longer the NULL value!
null.sql

Mythology
And other interestingAnd other interesting
anti-facts and facts

• Do nulls and indexes work together?
– Obviously, we’ve seen an example with FBI’s
– Bitmap indexes – always index nulls.
– B*Tree cluster indexes – always index nulls.
– Conventional B*Tree indexes do not if and only if the
entire key is null (all of the columns)
Mythology
entire key is null (all of the columns)
• Why is that? See null2.sql
null2.sql

• Do I need to index foreign keys?
– Probably
– If you
• Update the parent table primary key OR
• Delete from parent OR
• Merge into parent
– 9i and later – lock taken on child table for duration of update or
Mythology
– 9i and later – lock taken on child table for duration of update or
delete
• Which could take long since the table lock gets blocked,
blocking others
• Which could take long due to full scan of child, since there is no
index!
– 8i and before – lock taken for duration of transaction
fkey.sql

• Maybe we are not using the leading edge?
• Create index I on T(x,y)
– Where y = value will tend to not use the index
– Unless
• We index skip scan
• We select x,y from t where y = value – and we use
Mythology – why isn’t it using my index
• We select x,y from t where y = value – and we use
the index I as a skinny table to full scan
case1.sql

• Select count(*) from t
• Full scanning table, not using any existing index
• Two causes
– You are still using the RBO
– None of the columns indexed was defined “NOT NULL”

• Select * from table where indexed_column = value
• Indexed column is on the leading edge
• No index being used
• Likely an implicit conversion
case2.sql

• This is my favorite one
• Because if the index were to be used, the query
would run incredibly slow.
• Remember:
– Loop
• Say indexes are not all goodness
• Say full scans are not evil
• Exit when (you really believe it)
– End loop
• Following example from asktom..

So, joe (or josephine) sql coder needs to run the following query:
select t1.object_name, t2.object_name
from t t1, t t2
where t1.object_id = t2.object_id
and t1.owner = 'WMSYS'
Rows Row Source Operation
------- ---------------------------------------------------
528384 HASH JOIN
8256 TABLE ACCESS FULL T
suppose they ran it or explain planned it -- and saw that plan. "Stupid
stupid CBO" they say -- "I have indexes, why won't it use them. We all know
that indexes mean fast=true! Ok, let me use the faithful RBO and see what
happens"

select /*+ RULE */ t1.object_name, t2.object_name
from t t1, t t2
where t1.object_id = t2.object_id
and t1.owner = 'WMSYS'
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T'
2 1 NESTED LOOPS
3 2 TABLE ACCESS (FULL) OF 'T'
4 2 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE)
See, now that’s what I’m talking about – indexes are good…
Or are they?

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 35227 5.63 9.32 23380 59350 0 528384
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 35229 5.63 9.33 23380 59350 0 528384
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Optimizer goal: CHOOSE
Parsing user id: 80
------- ---------------------------------------------------
528384 HASH JOIN

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 35227 912.07 3440.70 1154555 121367981 0 528384
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 35229 912.07 3440.70 1154555 121367981 0 528384
Misses in library cache during parse: 0
Optimizer goal: RULE
Optimizer goal: RULE
Parsing user id: 80
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE
2 1 NESTED LOOPS
3 2 TABLE ACCESS (FULL) OF 'T'
4 2 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE)

1 SELECT phy.value,
2 cur.value,
3 con.value,
4 1-((phy.value)/((cur.value)+(con.value))) "Cache hit ratio"
5 FROM v$sysstat cur, v$sysstat con, v$sysstat phy
6 WHERE cur.name='db block gets'
7 AND con.name='consistent gets'
8* AND phy.name='physical reads'
VALUE VALUE VALUE Cache hit ratio
-------- ---------- ---------- ---------------
1277377 58486 121661490 .989505609
98.9% cache hit, not bad eh?

• Space is never reused in an index
– Indexes are a complex data structures
– Data has a location
• If you insert monotonically increasing values
(1,2,3, )
• And you delete many – not all, many – of the older
values over time (1,3,5,7, .)
Mythology
values over time (1,3,5,7, .)
• Then, since the value 123456 does not fit “near” the
value 2 – that space won’t be reused (the block that
2 is on)
• But indexes on say “last name” or a reverse key
index

• Most discriminating elements should go first
– Say you have copy of all objects
– You ask
• What does scott own?
• What tables does scott own?
• What about that EMP table scott owns?
Mythology
• What about that EMP table scott owns?
– The only sensible index would be on
(owner,object_type,object_name).
– Object_name is the most ‘discriminating’
– Object_name would be the worst thing to put first
– How you query the data dictates the ordering
order.sql

• NOSEGMENT
– What would happen to my plan if I created this index?
– Would the optimizer likely choose to use it?
– ALTER SESSION SET “_use_nosegment_indexes” =
true;
– Dbms_stats.set_index_stats with your best guess might
Interesting
– Dbms_stats.set_index_stats with your best guess might
be necessary
nosegment.sql

• INVISIBLE
– What would happen to my plan if I created this index?
– Would the optimizer likely choose to use it?
– Invisible indexes actually
• Create the index
• Maintain the index
Interesting – but wait, there’s more!
• Maintain the index
• But keep the index from the optimizers view!
• alter session set
OPTIMIZER_USE_INVISIBLE_INDEXES =true;
invisible.sql

• Where string like ‘%stuff’
– B*tree – nope
– Bitmap – nope
– Text – yes
• Indexes the substrings
• Case insensitive even
Interesting – and inclosing
• Case insensitive even
• Everyone has it
leading.sql

[INSIGHT OUT 2011] B24 effective indexing(tom kyte)

Recommended

Recommended

More Related Content

What's hot

What's hot (11)

Viewers also liked

Viewers also liked (16)

Similar to [INSIGHT OUT 2011] B24 effective indexing(tom kyte)

Similar to [INSIGHT OUT 2011] B24 effective indexing(tom kyte) (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (20)

[INSIGHT OUT 2011] B24 effective indexing(tom kyte)