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

610
CHAPTER 13 ■ PARTITIONING
ops$tkyte@ORA10G> create index t_idx
2 on t(owner,object_type,object_name)
3 global
4 partition by hash(owner)
5 partitions 16
6 /
Index created.
Much like the hash partitioned tables we investigated earlier, Oracle will take the OWNER
value, hash it to a partition between 1 and 16, and place the index entry in there. Now when
we review the TKPROF information for these three queries again
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.00 0.00 0 4 0 1
total 5 0.00 0.00 0 19 0 16
total 5 0.01 0.00 0 28 0 25
we can see we are much closer to the worked performed by the nonpartitioned table earlier—
that is, we have not negatively impacted the work performed by our queries. It should be
noted, however, that a hash partitioned index cannot be range scanned. In general, it is most
suitable for exact equality (equals or in-lists). If you were to query WHERE OWNER > :X using the
preceding index, it would not be able to perform a simple range scan using partition elimination—you
would be back to inspecting all 16 hash partitions.
Does that mean that partitioning won’t have any positive impact on OLTP performance?
No, not entirely—you just have to look in a different place. In general, it will not positively
impact the performance of your data retrieval in OLTP; rather, care has to be taken to ensure
data retrieval isn’t affected negatively. But for data modification in highly concurrent environments,
partitioning may provide salient benefits.
Consider the preceding a rather simple example of a single table with a single index, and
add into the mix a primary key. Without partitioning, there is, in fact, a single table: all insertions
go into this single table. There is contention perhaps for the freelists on this table.
Additionally, the primary key index on the OBJECT_ID column would be a heavy right-handside
index, as we discussed in Chapter 11. Presumably it would be populated by a sequence;
hence, all inserts would go after the rightmost block leading to buffer busy waits. Also, there
would be a single index structure, T_IDX, for which people would be contending. So far, a lot of
“single” items.
Enter partitioning. You hash partition the table by OBJECT_ID into 16 partitions. There are
now 16 “tables” to contend for, and each table has one-sixteenth the number of users hitting it
simultaneously. You locally partition the primary key index on OBJECT_ID into 16 partitions.
You now have 16 “right-hand sides,” and each index structure will receive one-sixteenth the
workload it had before. And so on. That is, you can use partitioning in a highly concurrent
environment to reduce contention, much like we used a reverse key index in Chapter 11 to
reduce the buffer busy waits. However, you must be aware that the very process of partitioning
out the data consumes more CPU itself than not having partitioning. That is, it takes more
CPU to figure out where to put the data than it would if the data had but one place to go.