Re: How to detach/archive data

Hi Rick,

My recommendation would be to partition the tables you wish to historically archive. Once suitably partitioned, you can either exchange the partitions you no longer wish to remain "live" and export or export directly the partitions (you can do this). These 'saved' partitions can then be dropped and re-created if required. If you equal partition dependent tables, this makes the whole process a little easier. You then also have the additional performance benefits that partitioned tables provide.

Another option you could consider is to simply export the table(s) using the QUERY option and export only those rows of (no longer) interest (and import when required).

How you would automatic with a robotic tape system through an application I know not. I'll leave the easy bit to someone else :)

My thoughts

Richard

"Rick Denoire" <100.17706_at_germanynet.de> wrote in message news:0skrjuoemv7bv78jn5s51aupo1c11d92v7_at_4ax.com...
> Hello
>
> We have limited space for live DB files, which contain a considerable
> amount of seldom used data. At the same time, we have a tape robot
> which could save virtually any amount of data.
>
> What is the method to detach portions of the data to be archived in a
> way that one could consistently attach them again when needed? Perhaps
> using partitions?
>
> Preferably, I would not delete records since this renders the DB in a
> devastated state and one would have to reorganize data. Using
> export/import is not a solution either since it applies to complete
> objects. And I would avoid a method that would imply complex reloads
> and index recreation etc. when restoring archived data.
>
> Since our tape robot is under HSM control (hierarchical file system),
> would it be feasable to automate the process of reattaching detached
> data when required by an Oracle application? That is, without any
> human intervention, Oracle would look for the archived file, which
> would then be staged to disk from tape by the HSM, and Oracle would
> resume operations after reintegrating the file into the DB. But I
> suspect a timeout problem there, since tape robots are relatively slow
> from the Oracle viewpoint.
>
> Please give me some hints so I can move in the right direction.
>
> Thanks
> Rick
>
Received on Wed Jul 24 2002 - 03:34:27 CDT