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

CHAPTER 13 ■ PARTITIONING 611
So, as with everything, before applying partitioning to a system to “increase performance,”
make sure you understand what that system needs. If your system is currently CPU
bound, but that CPU usage is not due to contention and latch waits, introducing partitioning
could make the problem worse, not better!
USING ORDER BY
This example brought to mind an unrelated but very important fact. When looking at hash partitioned indexes,
we are faced with another case where the use of a index to retrieve data would not automatically retrieve the
data sorted. Many people assume that if the query plan shows an index is used to retrieve the data, the data
will be retrieved sorted. This has never been true. The only way we can retrieve data in any sort of sorted
order is to use ORDER BY on the query. If your query does not contain an ORDER BY statement, you cannot
make any assumptions about the sorted order of the data.
A quick example demonstrates this. We create a small table as a copy of ALL_USERS and create a hash
partitioned index with four partitions on the USER_ID column:
ops$tkyte@ORA10G> create table t
2 as
3 select *
4 from all_users
5 /
Table created.
ops$tkyte@ORA10G> create index t_idx
2 on t(user_id)
3 global
4 partition by hash(user_id)
5 partitions 4
6 /
Index created.
Now, we will query that table and use a hint to have Oracle use the index. Notice the ordering (actually,
the lack of ordering) of the data:
ops$tkyte@ORA10G> set autotrace on explain
ops$tkyte@ORA10G> select /*+ index( t t_idx ) */ user_id
2 from t
3 where user_id > 0
4 /
USER_ID
----------
11
34
...
81
157