On Wed, 19 Feb 2003 21:56:59 -0500, M2 wrote:
That's the way I do it. Partition by date. You can give the
partitions an upper boundary of < date ex:
PARTITION BY RANGE (newbie_date)
(
PARTITION p20030228 VALUES LESS THAN (TO_DATE(' 2003-03-28', 'SYYYY-MM-DD'))
> Paul,
> you know I hadn't thought of that. That just might do the trick. I shall
> ponder some more. Thanks for the idea!
>
> Matt.
>
> "Paul Dixon" <paul.gp.dixon_at_bttinnedham.com> wrote in message
> news:b302lt$b99$1_at_pheidippides.axion.bt.co.uk...
>>
>> "M2" <me_at_quietplaceiwithnospam.com> wrote in message
>> news:T8d4a.77$Aq3.14282_at_news.optus.net.au...
>> > I'm sorry (and possible embarrased) to say that actually was what I
>> > was suggesting. I work for an education institution and need to
>> > gracefully
>> move
>> > out old session data to keep sizes down. The sessions start and end
>> > on different dates each year and the systems provided for these often
>> > don't start on the start of session anyway. This didn't seem to fit
>> > any mold
> for
>> > identifying it's destination partition at the time of insert.
>> >
>> > So how do you efficiently deal with something like this where
> information
>> > needs to move from one partition to another post creation?
>> >
>> > Is partitioning maybe not the way to go? All I am really after is a
>> > way
> to
>> > flag a (large) group of rows to be archived using an external process
>> (it's
>> > complicated logic). After doing this I want to be able to move the
>> > data
>> off
>> > to the warehouse and recover the space in the production system with
>> > as little effect on the production system as possible.
>>
>> Matt,
>>
>> I don't know whether this fits in with the "complicated logic" you use
>> for archiving, but rather than moving data to a different partion when
>> it becomes "old" why not periodically create additional partitions to
>> receive "new" session data. Eventually at some point in time a previous
>> partition would only contain data that meets your "old" criteria and
>> could be processed accordingly.
>>
>> Paul Dixon
>>
>>
>>
>>
>>
Received on Thu Feb 20 2003 - 14:13:34 CST
