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

442
CHAPTER 11 ■ INDEXES
In my database using an 8KB blocksize, these tables had the following number of total
blocks apiece:
ops$tkyte@ORA10G> select table_name, blocks
2 from user_tables
3 where table_name in ( 'COLOCATED', 'DISORGANIZED' );
TABLE_NAME
BLOCKS
------------------------------ ----------
COLOCATED 1252
DISORGANIZED 1219
The query against the disorganized table bears out the simple math we did earlier: we did
20,000+ logical I/Os (100,000 total blocks queried and five runs of the query). We processed
each and every block 20 times! On the other hand, the physically COLOCATED data took the
logical I/Os way down. Here is the perfect illustration of why rules of thumb are so hard to
provide—in one case, using the index works great, and in the other case it doesn’t. Consider
this the next time you dump data from your production system and load it into development,
as it may very well provide at least part of the answer to the question, “Why is it running differently
on this machine—aren’t they identical?” They are not identical.
■Note Recall from Chapter 6 that increased logical I/O is the tip of the iceberg here. Each logical I/O
involves one or more latches into the buffer cache. In a multiuser/CPU situation, the CPU used by the second
query would have undoubtedly gone up many times faster than the first as we spin and wait for latches. The
second example query not only performs more work, but also will not scale as well as the first.
THE EFFECT OF ARRAYSIZE ON LOGICAL I/O
It is interesting to note the effect of the ARRAYSIZE on logical I/O performed. ARRAYSIZE is the number of
rows Oracle returns to a client when they ask for the next row. The client will then buffer these rows and use
them before asking the database for the next set of rows. The ARRAYSIZE may have a very material affect
on the logical I/O performed by a query, resulting from the fact that if you have to access the same block over
and over again across calls (across fetch calls specifically in this case) to the database, Oracle must retrieve
that block again from the buffer cache. Therefore, if you ask for 100 rows from the database in a single call,
Oracle might be able to fully process a database block and not need to retrieve that block again. If you ask for
15 rows at a time, Oracle might well have to get the same block over and over again to retrieve the same set
of rows.
In the example earlier in this section, we were using SQL*Plus’s default array fetch size of 15 rows (if
you divide the total rows fetched by the number of fetch calls, the result is very close to 15). If we were to
compare the execution of the previous queries using 15 rows per fetch versus 100 rows per fetch, we would
observe the following for the COLOCATED table: