Fw: Data Purging Strategy

Sorry, forgot to "reply-all"...

• Original Message ----- To: <Jared.Still_at_radisys.com> Sent: Wednesday, November 06, 2002 4:51 PM

> The SAMFS and Legato "DiskExtender" HSM file-systems are based on the idea
> of "migration". Just like on mainframes, a file has a "header" that stays
> resident on disk-based storage. If the file is accessed, the necessary
> pieces will be retrieved from tape (or some other media such as CD-RW or
> magneto-optical) to disk-based storage, as needed. The whole file is not
> necessarily retrieved; consider it very similar to a paging algorithm.
The
> disk-based storage is managed as a cache, so after a time the retrieved
file
> data is aged out, either to be flushed back to tape (if modified) or
simply
> dropped (if read only). All of this is kept transparent from end-users
> (i.e. applications like Oracle, etc), so they only see the file residing
in
> the normal-looking file-system, albeit not quite as peppy as other
> file-systems...
>
> Works surprisingly well and Oracle treats it like any other datafile, so
for
> archiving your application doesn't really have to be changed in any way.
> It's just out there, just like the "current" data, only on a slower
> datafile...
>
> ----- Original Message -----
> From: <Jared.Still_at_radisys.com>
> To: <ORACLE-L_at_fatcity.com>
> Cc: <Tim_at_SageLogix.com>
> Sent: Wednesday, November 06, 2002 4:26 PM
> Subject: Re: Data Purging Strategy
>
>
> > Tim,
> >
> > I missed the part earlier where you mentioned HSM. Though somewhat
> > familiar with it, I've never used it. Pretty common in mainframe
> > environments.
> >
> > Do you have experience with it? Drawbacks other than performance?
> >
> > This seems like a much better solution to me than archiving onto tape
and
> > hoping you can use it later.
> >
> > Jared
> >
> >
> >
> >
> >
> > "Tim Gorman" <Tim_at_SageLogix.com>
> > Sent by: root_at_fatcity.com
> > 11/06/2002 03:08 PM
> > Please respond to ORACLE-L
> >
> >
> > To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> > cc:
> > Subject: Re: Data Purging Strategy
> >
> >
> > Agreed. The current Oracle datafile format (7.3, 8.0, 8.1, 9.0, or 9.2)
> > may not survive 10i -- who the heck know?
> >
> > However, the tape-based file-systems (i.e. SAMFS, Legato DiskExtender,
> > etc) can be treated like a file-system in all respects (only slower).
In
> > other words, convert the datafiles in place just as you would if they
are
> > on disk. After all, they are still active parts of an active Oracle
> > database, even if they are in READ ONLY. The last time such a
conversion
> > was necessary was between Oracle7 and Oracle8; I think that it is valid
> > to assume that Oracle will provide a similar migration utility should
> > another such conversion become necessary. Whatever needs to be
performed
> > for one tablespace in converting file formats should be done for all, so
> > this is not a problem specific to the strategy I mentioned...
> > ----- Original Message -----
> > From: Mercadante, Thomas F
> > To: Multiple recipients of list ORACLE-L
> > Sent: Wednesday, November 06, 2002 7:18 AM
> > Subject: RE: Data Purging Strategy
> >
> > Tim,
> >
> > my problem with moving data to tape is as follows:
> >
> > Your one strategy involved moving read-only tablespaces to tape. what
if
> > you upgrade Oracle versions. will these read-only files still be valid?
> > will they still be able to be put back on-line, or will they need to be
> > converted along with the rest of the files to the newer version and then
> > copied back to tape. if this is the case, is there disk space to put
all
> > of these back? if there is disk space, then why copy them to tape at
all?
> > they could always be available and on-line.
> >
> > Having a plan to save data to tape in hopes of resurrecting it later on
> > has more challenges than anything I've come across lately. It just
> > doesn't seem to make sense to do this anymore. With disk space at an
> > all-time low-cost, why put ourselves thru this? the logistics are just
> > too expensive, as well as the risk of never being able to get the data
> > back because of software compatibility issues.
> > Tom Mercadante
> > Oracle Certified Professional
> > -----Original Message-----
> > From: Tim Gorman [mailto:Tim_at_SageLogix.com]
> > Sent: Wednesday, November 06, 2002 8:49 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Re: Data Purging Strategy
> >
> > This is a data-archival requirement, not a data-purge requirement. It
> > only resembles a purge requirement based on the
> > multiple-database-migration strategy you outlined. There are
> > alternatives...
> >
> > Depending on the volume of data in your database and your availability
> > requirements, implementing table- and index-partitioning will likely be
> > crucial. One strategy is to have the most-active tables partitioned by
a
> > date column and have different sets of these partitions reside in
> > time-variant tablespaces. With this arrangement, you can archive data
to
> > tape by simply setting the archived tablespaces to READ ONLY and then
> > migrating them to tape-based (instead of disk-based) file-systems and
> > bringing them back online. Legato has this file-system technology
> > (recently purchased) and there is a share-ware product called SAMFS
which
> > is an HSM (hierarchical storage mgmt) filesystem used by some vendors
> > (i.e. StorageTek, etc). By setting tablespaces to READ ONLY it becomes
> > very easy to move them from disk to tape while retaining them within the
> > same original database, simplifying the task of later retrieval (which
is
> > really important).
> >
> > Of course, Oracle's partitioning option is enormously expensive, but in
> > this case it is a matter of the upfront license costs (with reduced
> > downstream implementation costs due to simplicity) versus a large
> > downstream application-development cost. In this situation, I think
> > roughly offsets everything. Since I'm not spending the money, I can
> > afford such a calculation... :-)
> >
> > With the various storage technologies available, a single database can
> > straddle several simultaneously, optimizing performance or cost as
needed.
> > Some files might reside on solid-state NVRAM "disk", some on SAN-based
> > disk, some on NAS-based storage, and then finally reside in archive
media
> > file-systems such as tape or magneto-optical based HSM file-systems.
> > ----- Original Message -----
> > From: prem_at_ibsplc.com
> > To: Multiple recipients of list ORACLE-L
> > Sent: Wednesday, November 06, 2002 2:13 AM
> > Subject: Data Purging Strategy
> >
> >
> > Dear List,
> >
> > I need some inputs from you all regarding purging data from the
database.
> >
> > This is the requirement
> >
> >
> > We define a retention period for all the data in the system.
> > When the retention period is reached, the data should be deleted, but
> > then at a later time, some user might request for this purged data. So
it
> > must be possible to retrieve this data.
> >
> > This is the strategy we have designed for this.
> >
> > When the retention period is reached, move the data from the main
database
> > to an offline database. Then delete the data from the main database.
> >
> > In the offline database, we cannot again keep it from long, so it has to
> > moved to tapes. Now my question, how can we move this data to tapes and
at
> > the same time retrieve data from the tapes based on dates.
> > i.e, the user will ask for the data on a particular date, so it must be
> > possible to retrieve data from the tapes based on a date and load it to
> > the database tables.
> >
> > Regards
> > Prem
> >
> >
> >
> >
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tim Gorman
  INET: Tim_at_SageLogix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).