Re: Newbie Question on Partitions

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.

"Jusung Yang" <JusungYang_at_yahoo.com> wrote in message news:130ba93a.0302171037.1a76e4e1_at_posting.google.com...
> There is no such requirement that partitions should be placed in
> different tablespaces. Though it may help sometime by distributing IO.
>
> I certainly hope that you are not trying to partition the production
> table by the archive flag, which seems to be what you were suggesting.
> Updating the partition key will cause physical row movement which I
> would try to avoid. It is best that you build the partition key so
> that when a new record is created it already knows which partition it
> belongs and move into that partition automatically.
>
>
> - Jusung Yang
>
>
> "M2" <me_at_quietplaceiwithnospam.com> wrote in message
news:<ke_3a.65$Aq3.12506_at_news.optus.net.au>...
> > Hi,
> > just a quick newbie question on partitions. I have a very large table
(40
> > million rows) that I want to move into partitions. The plan here is to
> > create two partitions one for "archive" rows and the other for
production
> > rows. I will then periodically update rows to set the archive flag
(causing
> > a change in partition) and move the data off to a warehouse. The
partition
> > will then be dropped to recover the space.
> >
> > So, my question is, will this be efficient if both the archive and
> > production partitions are in the same tablespace? Everything I read
seems to
> > mention partitions synonymously with different tablespaces but is it
> > possible to do it in the same space? What would I lose out on?
> >
> > Matt.
Received on Mon Feb 17 2003 - 16:14:11 CST