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 -----------------------------------------------------------------