How to create and drop partitions automatically?

Question

How to create and drop partitions automatically?
The environment is Oracle 10g(10.2.0.3) on the RHEL4.0 system.
I want to partition the MESSAGE table by date (NUMTODSINTERVAL(1,'DAY') ). One partition per day. Because the table is huge, only 2 partitions (today and yesterday's data) are necessary to be kept online. All the partitions that earlier than the previous day will be backed up and then dropped. I want to make the partition creating and dropping jobs run automatically. How to do it?
Thank you

Answer 1

junez wrote:
How to create and drop partitions automatically?
The environment is Oracle 10g(10.2.0.3) on the RHEL4.0 system.
I want to partition the MESSAGE table by date (NUMTODSINTERVAL(1,'DAY') ). One partition per day. Because the table is huge, only 2 partitions (today and yesterday's data) are necessary to be kept online. All the partitions that earlier than the previous day will be backed up and then dropped. I want to make the partition creating and dropping jobs run automatically. How to do it?With 11g, new partitions can automatically be created.
With 10g, you need to do that yourself. I prefer to create a "buffer" of future partitions - in case the job whose task it is to add new partitions gets held up or stuck. Or the job queue is full due to some problem and it does not get the chance to execute in time.
I dislike your partitioning criteria. I prefer using the date directly and not mangling it to something else. If a specific day has a large volume of data, then another option is to use hourly date ranged partitions. With local partitioned indexes and the date time range used for querying, this can be quite effective performance wise.
As for partitioning maintenance - I use a custom written partitionManager PL/SQL package that provides an interface for adding daily and hourly partitions to a table. Input parameters are for example name of the table, start date and the number of partitions to add. Similarly it provides interfaces for aging partitions - again by specifying a table and a date-time to use as the starting point, back into time, for removing old partitions.
I typically call this code from the actual application code itself - so before a new partition will be used for example, the app code will first ensure that it has a partition to use. This is safer than a separate job as the dependency is resolved where and when it is needed - and not done as a separate task.
For example - you should have a procedure/package that provides an app the means to log a message into your MESSAGE table. As part of an autonomous transaction, this procedure can check if the required partition exists, before attempting to insert a message into the table.
Where this approach is not possible, a DBMS_JOB can be used to create future partitions - but as I mentioned, rather have it add a bunch of future (empty) partitions in case something goes pear shape with the job mechanism.