Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

444
CHAPTER 11 ■ INDEXES
The results against the index here were identical, which makes sense, as the data is stored in the index
is just the same regardless of how the table is organized. The logical I/O went from 1,374 for a single execution
of this query to 245, just as before. But overall the amount of logical I/O performed by this query did not
differ significantly: 21,357 versus 20,281. The reason? The amount of logical I/O performed against the table
did not differ at all—if you subtract the logical I/O against the index from the total logical I/O performed by
each query, you’ll find that both queries did 19,983 logical I/Os against the table. This is because every time
we wanted N rows from the database—the odds that any two of those rows would be on the same block
was very small—there was no opportunity to get multiple rows from a table block in a single call.
Every professional programming language I have seen that can interact with Oracle implements this
concept of array fetching. In PL/SQL, you may use BULK COLLECT or rely on the implicit array fetch of 100
that is performed for implicit cursor for loops. In Java/JDBC, there is a prefetch method on a connect or
statement object. Oracle Call Interface (OCI; a C API) allows you to programmatically set the prefetch size, as
does Pro*C. As you can see, this can have a material and measurable affect on the amount of logical I/O performed
by your query, and it deserves your attention.
Just to wrap up this example, let’s look at what happens when we full scan the
DISORGANIZED table:
select * from disorganized where x between 20000 and 40000
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 5 0.00 0.00 0 0 0 0
Execute 5 0.00 0.00 0 0 0 0
Fetch 6675 0.53 0.54 0 12565 0 100005
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 6685 0.53 0.54 0 12565 0 100005
Rows Row Source Operation
------- ---------------------------------------------------
20001 TABLE ACCESS FULL DISORGANIZED (cr=2513 pr=0 pw=0 time=60115 us)
That shows that in this particular case, the full scan is very appropriate due to the way
the data is physically stored on disk. This begs the question, “Why didn’t the optimizer full
scan in the first place for this query?” Well, it would have if left to its own design, but in the
first example query against DISORGANIZED I purposely hinted the query and told the optimizer
to construct a plan that used the index. In the second case, I let the optimizer pick the best
overall plan.
The Clustering Factor
Next, let’s look at some of the information Oracle will use. We are specifically going to look at
the CLUSTERING_FACTOR column found in the USER_INDEXES view. The Oracle Reference manual
tells us this column has the following meaning: