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: Logical Backup for a large database

RE: Logical Backup for a large database

From: Christopher Spence <cspence_at_FuelSpot.com>
Date: Thu, 30 Aug 2001 05:57:15 -0700
Message-ID: <F001.0037CD1E.20010830060639@fatcity.com>

Exports you will have data loss from the time of export to the time of failure.
If that is acceptable, then exports are fine, otherwise you need to use hot/cold/rman type backups.

"Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes."

Christopher R. Spence
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275

Fuelspot
73 Princeton Street
North, Chelmsford 01863  

-----Original Message-----
Sent: Monday, August 27, 2001 6:59 PM
To: Multiple recipients of list ORACLE-L

Well, to play the Devil's advocate here, the big advantage of export/import is that it's faster than recovering from RMAN and takes much less disk space. Here we're contractually obliged to recover customers' data from a previous night's backup, not earlier. So, an export can work for us. We do exports every night here, along with RMAN backups.

But, our customer data is nowhere near 150gb.

However as Steve Orr mentioned in a separate post, we recovered from data loss using RMAN a couple of weeks ago. It really is a much, much better backup strategy in most cases.

--Walt Weaver
  Bozeman, Montana

-----Original Message-----
Sent: Monday, August 27, 2001 3:55 PM
To: Multiple recipients of list ORACLE-L

I think recommending regular exports for a 150Gb database is a mistake.

Instead, you should practice using RMAN to restore and recover to a separate location. You can limit the size and complexity of a single table restore by restoring only the table's tablespace, the SYSTEM and any tablespaces containing rollback segments.

Once you have restored and recovered the one tablespace you need, you can export the table and import it into the production system. This method provides protection that is superior to exports, because it allows the recovery of a single table to an arbitrary point in time.

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton

On Mon, 27 Aug 2001, Wong, Bing wrote:


> I would suggest to export schema by schema and schedule the jobs to
> run different time. In the export job, use pipe file at the unix
> level to compress the export file. The command is as follows:
>
> To export and compress at the unix level...
>
> mknod export_pipe p
> compress < export_pipe > export.dmp.Z
> exp ....... file=export_pipe
>
>
> To import and uncompress...
>
> uncompress < export.dmp.Z > export_pipe
> imp ....... file=export_pipe
>
>
> -----Original Message-----
> Sent: Monday, August 27, 2001 2:11 PM
> To: Multiple recipients of list ORACLE-L
>
> Last week one of my user dropped a table since we don't have any
> backup except for rman backup. It is not allowe me to do any recovery
> on 7/24 database. Anyway we recreate the table(we are lucky, this
> table hold
> parameters)
>
> This make me think of situation of lossing very important big table.
> We
have
> about 1000 tables with bigget one of 8GB .
>
> Is there any idea how to perform a logical backup on a database with
150GBs.
> Or take a TSPITR in case of those kind of thing happen again. From
> my case, imp/exp looks impossibe from point of view of timing and
> spacing.
The
> question will be the same for TSOITR on large database. Is there any
> other way to prepre those kind of situation.
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: jwilton_at_speakeasy.net 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: Weaver, Walt INET: wweaver_at_rightnow.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: Christopher Spence INET: cspence_at_FuelSpot.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).
Received on Thu Aug 30 2001 - 07:57:15 CDT

Original text of this message

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