Build Table Within CPU Cycle Limits ::

Question

I have a table that looks like this:
:Example Table:
customer_trail
database_update_date cust_activity cust_name
02/11/08 09:00 01/11/08 09:34 Bob
02/11/08 09:00 23/10/08 09:34 James
02/12/08 09:00 05/11/08 09:34 John
02/12/08 09:00 12/12/08 09:34 Mike
: Definitions:
The database_update_date is the primary key and is the date when everything gets loaded into the database.
The cust_activitity is when the customer came in and requested some work done.
The cust_name is the customers name.
:SQL:
SELECT TO_CHAR(cust.cust_activity ,'DD/MM/YY') AS Date_Raised,
TO_CHAR(cust.cust_activity,'HH24')||':00' AS 24HR_TIME,
cust.*
FROM customer_trail cust
WHERE database_update_date BETWEEN '01-nov-2008' AND '02-nov-2008'
AND cust_activity BETWEEN '01-nov-2008' AND '01-dec-2008'
AND cust_name IN ( 'Bob', 'Mike', 'Pete')
:PROBLEM:
My problem is this, due to the fact that the table is so large and we have so many customers. My query times out if I search for a months worth of data using the database_update_date attribute, so I am having to search 1 day at a time to build up a months worth of data in my new table called output. However this is a manual process of me changing the values within database_update_date and saving it to the output table.
Also there is no way to optimise my query and the table can not be changed easily.
So what I need to do is get it to update the database_update_date daily from the 01-nov-2008 to the 01-dec-2008 and store everything that matches the other two conditions without exceeding my CPU Cycle limit.
Any ideas?

Answer 1

Rob van Wijk wrote:
Davey,
The design of the table has to be such that it supports its use the best way. If the query you showed is the query that it needs to be optimized for, you'll want to look into partitioning and indexing this table. Range partitioning on cust_activity and a local index on (cust_name,database_update_date) maybe?
But there is really too little information here. Is this the main query and a typical one? How many rows are you typically retrieving here? How large is large? Can you show an explain plan and a tkprof file snippet?
Regards,
Rob.Plan
CREATE TABLE STATEMENT ALL_ROWSCost: 374 Bytes: 151 Cardinality: 1                               
     6 LOAD AS SELECT NOV                          
          5 PX COORDINATOR                     
               4 PX SEND QC (RANDOM) SYS.:TQ10000 Cost: 373 Bytes: 151 Cardinality: 1                
                    3 PX PARTITION RANGE ITERATOR Cost: 373 Bytes: 151 Cardinality: 1 Partition #: 4 Partitions accessed #83 - #88          
                         2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE customer_trail Cost: 373 Bytes: 151 Cardinality: 1 Partition #: 4 Partitions accessed #83 - #88     
                              1 INDEX SKIP SCAN INDEX .I_customer_trail_1 Cost: 187 Cardinality: 262 Partition #: 4 Partitions accessed #83 - #88
Here is the plan, I hope that helps as this actually makes nosense to me at all.