From jwilton@speakeasy.net Mon, 27 Aug 2001 13:35:14 -0700 From: Jeremiah Wilton Date: Mon, 27 Aug 2001 13:35:14 -0700 Subject: RE: Logical Backup for a large database Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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@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@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).