RE: Database Archive
- From: "Powell, Mark D" <mark.powell@xxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 13 Apr 2004 09:54:51 -0400
Jaromir, at least through IMS version 7 HSAM still exists. I suspect it
will exist for as long as IMSDB exists.
to thread --
The inclusion of purge/archive processes to an application during the design
phase is in my experience neither that difficult or expensive as some
previous posters implied. Nor is it always necessary that such retrieval be
on demand. Often a few hours to an overnight delay is fully acceptable for
retrieving archived data. Each case of what is being archived, how likely
it is ever to be retrieved, and how it needs to be viewed has to be
considered to determine cost/benefit for the project. But archival is a
valid consideration for performance, security, and legal reasons. The need
for archival depends on the application, the data, and what management
wants! The design should fit the business requirements and if the
requirements call for archival then you need to find a way to handle the
requirement in a cost efficient manner.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of jaromir nemec
Sent: Tuesday, April 13, 2004 2:48 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Database Archive
H,
> For instance, one of the databases referred to is 100G is size.
1) The size is only one side of this problem. The growth (=velocity) is the
important issue in both OLTP and (more) in DSS.
2) The discussed problem can be limited to the comparison of the cost of
disc storage on one side with the cost of archiving (=should be much less)
along with archiving and restoring overhead. (= more than compensating, as
the integration and support is low)
As I know Bill Inmon propagated the "alternative storage" idea with some
strong cost arguments. But I guess this is far from mainstream now. The main
problem is the lack of support of transparent archiving in the database.
Today archiving solutions are
a) customised as part of the application (with high development costs)
b) using standard tools e.g. tape backups (in most cases the data could be
restored to the application but at high cost)
The problem is not new, some 30 years ago in DL/1 you could store part of
the database on tapes (HSAM = hierarchical sequential access method). But
I'm not sure if this feature is still supported:)
3) Of course there are lot of ill designed solutions (non partitioned tables
with "delete" archiving etc.) that could be tuned, but this is not the
point.
Thanks,
J.Nem
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
