Partitioning For Optimal Parallel Query Execution

Question

Hi All,
We are trying to design an architecture that benefits from partitioning and parallel query to obtain the best query response times for our system.
Let me start by describing the main table which has five columns:
Columns:
1) DocId ------- Numeric Primary Key Constraint (Unique)
2) Text ------- CLOB of XML Content
3) SCode ------- Varchar 12 ( service code Can be one of 200 values)
4) A_Date ------- Oracle Date ( The arrival date )
5) A_Month ------- Numeric partition key, the month number (1-12)
We insert 100,000 records daily so a month of data will contain 3,000,000 rows. The Text varies from 4k to 200k bytes and on average is around 30k bytes per document. A_Date is obtained when the C++ application receives a client connection. After document transmission is complete the DocId is obtained from an Oracle sequence. It is true that A_Date and DocId increase together. However because of varying document sizes and transmission rates, there is no guarantee that consistent order between the two columns exists.
For Example: If time (t) increases and the connection times are: t1, t2, t3, t4 and the document at t2 took long to transmit, we can have:
A_Date -------- DocId (From Oracle Sequence)
t2 -------------- 1004
t4 -------------- 1003
t3 -------------- 1002
t1 -------------- 1001
A_Month is simply the month number (1-12) extracted from the transmission entry timestamp. It is also our Partition Key (see below). When the year wraps around from 2006 to 2007, data for January will simpy fall into the 1st partition bucket, and so on..
QUERY NEEDS: Our queries are centered around a DateTime interval Where the left endpoint is current day/time. They can query the current day, current to 1 month back, current to 2 months back, .. current to 15 months back. We MUST RETURN a list of DocId's sorted in DESCENDING ORDER for screen display purposes.
In General we need to return sub-second for the 1st month. As we query further back in time longer response times between 1 and 4 seconds are acceptable.
PARTITIONING AND INDEXES:
The table is partitioned by A_Month as shown below:
Create Table IndexTable
PARTITION BY RANGE (A_Month)
( PARTITION p1 VALUES LESS THAN 1.1 ...
PARTITION p2 VALUES LESS THAN 2.1 ...
PARTITION p3 vALUES LESS THAN 3.1 ...
There are GLOBAL INDEXES on DocId, Text(Domain Index), and SCode.
A_Date is a LOCAL INDEX.
QUERY STRUCTURE:
My Query structure looks like this (for a 2 month query):
SELECT DocId from IndexTable WHERE
Contains (Text, 'BUSH and EARNINGS') > 0 AND
SCode in ('S1', 'S2', 'S3', 'S4') AND
A_Date Between '2006-01-15 11:00:00' AND '2006-03-15 11:00:00'
Order By DocId DESC;
QUESTIONS (THERE ARE THREE)
#### QUESTION 1 ####
As I examine various explain plans, the PSTART and PSTOP do not reflect consistency with my A_Date range. It seems to always display:
PStart PStop
RowId RowId
no matter what my A_Date range is.. I don't see it pruning my partitions. I cannot find documentation as to what RowId means or how it affects the optimizer's plan.
#### QUESTION 2 ####
I have tried parallelization hints on the table and indexes such as
/*+ PARALLEL( IndexTable, 4) */ and on the A_Date index
/*+ PARALLEL_INDEX( IndexTable, A_Date_Index, 4) */.
I can't really tell if the parallel hints make a difference.
However, the FIRST_ROWS hint makes a big difference if I nest the query inside a rownum clause as:
SELECT * from
( Select /+* first_rows */ ... WHERE CONTAINS... > 0 AND... )
Where ROWNUM <=20;
#### QUESTION 3 ####
I'm running close to the latest RedHat Linux and Oracle 10g2 and I have read about Parallel Slave Processes in Tom Kyte's Expert Oracle Architecture book in which he says you should see processes like:
ora...p000..
ora...p001..
ora...pnnn..
Which are the parallel slave processes. I have NEVER seen any oracle processes numbered as such running on my system when I run test queries. I have seen some q_ processes and others, but not the pnnn processes..
Can I benefit from parallel query without ever seeing these processes??
I Greatly Appreciate Any Advice To Any Of These Questions..
Joe

Answer 1

Well I can tell you this much. You will never get partition pruning if you don't have the partition key in the where clause.
I'm not sure about the parallel query. There was a time that this wasn't supported with Text indexes, but not sure if that still applies today.
In theory there are two levels of partitioning that can be defined that you may want to test out.
1st, range partition the base table and create a partitioned text index based on that. This is what you are currently doing.
2nd, in the storage preference for the $I table specify a range or hash partition (I've never tried this, but in theory it should work) on the token_text column. Try this out and see if it works.