A suggestion on hash partiton

Question

Hi All,
We have a history table which contains nearly 4 million data.
tab1(col1,col2,col3....col9)
We have hash partion on col3 which has only near about 900 distinct values.Now in future these values will increase but that is not sifficient as what needs to be the cardinality for a hash partition key column .
Now column col9 is a date column.
We have some purging modules which delete history data from this table day wise say at one go the purge module will delete 20 lakhs data and this data based one some say 300 days based on the col9 column .
In this situation what type of partition approach we should take to have maximum performance .
Perhaps i have explained my problem.Can you please suggest me what approach we need to take.
Thanks in advance.

Answer 1

bp wrote:
now as previously we have hash partition on col3 say this col is store and users usually access this store value from frontend which in terms hits tab1 table.So if we do partition on col9 column will it be a performance problem while user will access ?Unless the users can specify a date (col9) then, yes, there will be a penalty since the HASH partition will no longer be the primary partitioning mechanism, rather the records will be identified via a global index. You have two (conflicting) aims it would seem: OLTP on col3, and maintenance on col9. I'm not sure that if you have RANGE partitioning under the HASH partitioning you can actually exploit the range partitioning to advantage, and unless you have HASH partitioning as the UPPER most mechanism, OLTP will suffer.
bp wrote:
if we do range partition what will be the appropiate way to achieve this month wise?It would be somthing like:
...VALUES LESS THAN TO_DATE('01012009 00:00:00:', 'DDMMYYYY HH24:MI:SS)'There are examples on the forum.
Edited by: SeánMacGC on Jul 16, 2009 7:22 AM
And UPDATE INDEXES will not work on 9i, you'll need to rebuild explicitly.