Re: Why export is not a good archiving tool

From: Mark D Powell <Mark.Powell2_at_hp.com>
Date: Tue, 18 May 2010 06:26:25 -0700 (PDT)
Message-ID: <db43b771-416f-4288-82fd-459ccdbd5069_at_d12g2000vbr.googlegroups.com>



On May 17, 6:43 pm, "keith.micha..._at_gmail.com" <keith.micha..._at_gmail.com> wrote:
> I need to know why exporting a database periodically is not a suitable
> method for preserve access to historical data.  A customer with 10-20
> year retentions is using this to "preserve access" for compliance
> reasons.  I would like to push them towards IBM Optim, Outerbay,
> Solix, etc. but I don't know how to explain the shortcomings of their
> method.  Apparently the existing records don't have a nice date field
> to identify old data and leaving it in place doesn't protect it from
> damage or loss.

Export is a great tool for making logical backups that may be needed with the existing or next release of the database. However, there is no guarantee that an export dump file created today will be readable 20 years from today.

On the other hand a delimited or fixed position text extract file will almost surely be readable. Using delimited files also supports importing the data into a different database vendor product environment. After all can you be sure that business conditions will not have warranted conversion. The DDL for the target table and sqlldr control cards can be generated as part of the extract and used guide conversion if necessary.

Once extracted into delimited text files the data can be encrypted and/ or compressed using standard OS utilities. In the event of a noncompatible  platform change the files can easily be extracted and uncompressed/decrypted on the existing platform, copied to the new one, and then re-compressed/encrypted as necessary.

For long-term archival where you may need to access the data nothing beets pain text.

IMHO -- Mark D Powell -- Received on Tue May 18 2010 - 08:26:25 CDT

Original text of this message