Export jobs are filling a volume that is NOT referenced in the script anywhere. The scripts reside on /lvo295 but when they run they are "mysteriously" filling up /lvo100. There is no physical export files written to /lvo100 at all.
The jobs use the space (/lvo100) like tmp, before it was not noticed because i guess the size was sufficient to hold whatever it was writing, but now it is not, so it fills the volume and the jobs have to be cancelled thereby causing nightly exports to fail.
ticket opened with oracle and Sun, no resolution as yet, will try to initiate full backup from second node in OPS to see if that is a work around. initiating full export from first node is causing weirdness
I think u r running gzip from /lvo295. Try executing this script running gzip from /lo195/dpr1/exp directory.
B'coz, gzip won't accept other than your PWD. This might solve your problem.
I just now tried on my system with the same, it worked out in this way.
i broke it down to the command line export and eliminated the gzip altogether and it still happened... then i changed it to initiate the full export from the second node (second server) in our OPS environment. it doesn't fill up the file system when initiated from second node. neither Sun nor Oracle can explain so far.