Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Compressing Export Dumps|

RE: Compressing Export Dumps|

From: MacGregor, Ian A. <ian_at_SLAC.Stanford.EDU>
Date: Thu, 16 May 2002 10:48:57 -0800
Message-ID: <F001.00462B94.20020516104857@fatcity.com>


I was just about to post a message asking the same thing. Many of us have seen databases produce dumps which at first were much smaller than 2 GB, then we had to pipe them through the native compress utility on UNIX to keep them that way, then we used gzip which does a better job of compression, finally when this wasn't enough we combined gzip with split. For the above, assume the backup system cannot handle files over 2GB.

But why export routinely in the first place. They are not a good recovery mechanism. Using an export almost always means loss of data. If a table is lost we can recover, that tablespace, the system tablespace, and the rollback tablespace, to a point-in-time just before the table was lost from our hot backups, and then export the "lost" table fom this "mini" database and import it into the one from which it was dropped. If an overzealous user ran some incorrect DML, we can run the undo statement from log miner.

One can argue that if for some reason the physical backups are damaged, restoring from an export with some loss of data is better than no recovery at all. It also protects against errors in the physical backup script which may result in incomplete backups. Export can aid in identifying bad table blocks as it selects every row from every non "sys" table.

However, as your database grows larger selecting every row becomes more and more expensive. Even if your exports are "inconsistent" they have an impact on rollback segments. No, they do not produce any undo, however they do expect that the schemas being exported stay the same. Schema changes while an export is underway can produce snapshot too old errors and stop the export. Although now schema changes usally, always? result in a failure to export just the table involved. The problem with setting "optimal" for rollback segments is very likely to be exposed by an export.

I am curious about the number of people who have stopped using them as part of their daily backup strategy, and if you have. what are you doing to check for block corruption. Assume the database is 24 X 7.

Ian MacGregor
Stanford Linear Acclerator Center
ian_at_SLAC.Stanford.edu

-----Original Message-----
Sent: Thursday, May 16, 2002 10:28 AM
To: Multiple recipients of list ORACLE-L

Simon,

I'm curious as to why you're creating exports that large.

Are you doing this as a backup method?

Have you ever restored an export that large?

The largest export I've ever restored is about 10 gig, and it took far too long.

Jared

"Simon Waibale" <waibals_at_mtn.co.ug>
Sent by: root_at_fatcity.com
05/16/2002 02:38 AM
Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        Compressing Export Dumps


Hi all,
My export dumps are too big (80 GB) for my filesystem and I'm looking for a
way
to compress them on the fly -ie without taking *.dmp to disk first but straight *.dmp.gz
Anybody with an idea on how to archive this ? Thanking you,

---
CSW




--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: INET: Jared.Still_at_radisys.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: MacGregor, Ian A. INET: ian_at_SLAC.Stanford.EDU Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
Received on Thu May 16 2002 - 13:48:57 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US