Tim, besides not forgetting to set the new boundaries for partition key when
data is moved to the online storage, there is another thing to be careful.
Namely, DDL changes to the original table, like adding columns and/or changing
data types (extending column size is a classical example) can render partition
impossible to bring back online. As the original article from CW would have it,
these things have to be carefully planned, documented and treated as projects.
My suggestion is to first exchange partition with an empty table, then export
that table, so that the result is an entity which doesn't depend on the structure
of the original table for being restored. With tables having 100+ GB in size,
archiving is a very serious project which shouldn't be taken lightly. Also, a
mandatory part of a successful archiving project is bragging about it on this
list.
On 04/12/2004 10:18:39 PM, Tim Gorman wrote:
> Zhu,
>
> If its OK to actually remove data from a table to an offline archive store,
> then why isn't it OK to restrict on the partitioning key column in order to
> restrict the volume of data being queried?
>
> True enough that people will forget to restrict on the partition key; human
> nature and all that. But if they think it through, then what they are
> really complaining about is having access to all the data that otherwise
> would have been offlined. If they do not want to query that data, then they
> should't query that data. If they really want to query the data that would
> otherwise have been archived and removed, then they should appreciate it.
>
--
Mladen Gogala
Oracle DBA
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Mon Apr 12 2004 - 21:47:24 CDT
