Has anyone used transportable tablespaces as a special backup method? Periodically I get a request from our applications people to "backup these tables before we run this year-end program so if something goes wrong we can reset everything." And the attention-getter is "if we can't recover, you won't get paid again." - Usually nothing goes wrong (thankfully). - We do full backups, obviously, but there are unpleasant consequences for rolling back an enterprise-scale database. The system goes back for everyone. Obviously we can do a TSPITR over on a test system, but I don't like to rely on that alone. - Export works great for small to medium size tables. - Export of large tables is fine, but my experience says that importing a really large table can take a LOOONG time, a frightening prospect during an emergency. - It occurs to me that making the tablespace read-only and performing a transportable "export" should work great. These large tables are in their own tablespace. The application doesn't any RI in Oracle. - Recovery should be a matter of dropping the existing tablespace, copying the backup datafile off tape, running the import procedure, and making the tablespace read-write. Much faster than the true import.
Am I missing something? I plan to try this on a test system to make sure I have the right syntax. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
