Re: off the wall ideas welcomed

From: Tim Gorman <>
Date: Wed, 04 Feb 2009 15:40:41 -0700
Message-ID: <>


Use an "exp" and "imp" job joined together with a
UNIX "fifo" or "pipe"?  That way, both the "exp" and "imp"
processes can run as long as necessary without using any disk space for
a dump file at all?  Of course, I guess you'll have to import it into
the same table name but different schema, which I guess is what you
were planning anyway?

For example...
$ mknod /tmp/pipe.pipe p (or "mkpipe /tmp/pipe.pipe" on certain *NIXs)
$ nohup exp userid=system/
pwd tables=xyz file=/tmp/pipe.pipe ... > exp.out 2> exp.err &
$ nohup imp userid=system/
pwd fromuser=abc touser=def file=/tmp/pipe.pipe ... > imp.out 2> imp.err &
Then, just let 'er rip...

Niall Litchfield wrote:
I have an old 9i database with a table that appears to have been used as a test bed for as many oracle features as possible! In particular this table has
a fine grained access control policy
a long raw column
a blob column
The lob index is now corrupt. The recommended action is to export the table, drop the table and reimport - however the export file for this 12mb table grows to at least 2.4gb at which point disk space is exhausted. 
the date of corruption is unknown, so PIT recovery will be tricky of possible! 
alter table move lob... doesn't work because it also tries to rebuild the table segment which is not allowed because of the long raw. 
SQLPLUS copy doesn't work because of the 'object types' - presumably the BLOB. 
I'm pretty much out of (cheap) ideas for dealing with this corruption right now, so would welcome some.  

Niall Litchfield
Oracle DBA
-- Received on Wed Feb 04 2009 - 16:40:41 CST

Original text of this message