Weirdness on Export

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.

Any clues? Scripts is below.

(1) exp_dpr1.sh
sundb01:/lvo295/dpr1/scripts >more exp_dpr1.sh
#!/usr/bin/ksh
#
#Revisions
DATE=$(date +%Y%m%d%H%M)
. ./.profile
cd /arlogs
exp userid=***** buffer=500000 full=y compress=y indexes=y \
file=/lvo195/dpr1/exp/exp_dpr1$DATE.dmp \
log=/lvo195/dpr1/exp/exp_dpr1$DATE.log \
rows=y grants=y direct=y consistent=y
gzip /lvo195/dpr1/exp/exp_dpr1$DATE.dmp

Is this a cron job?
Can you run it manually using the same parfile? If so does it fail or write to the wrong dir?

Try it with rows=N, that should only take a few seconds.

MH

Maybe gzip uses your /lvo10 as a temporary space while compressing your .dmp file ?

check where your oracle tmpdir is.

echo $TMPDIR

my $tmpdir is tmp. a few minutes after i kill the export job the space that is used(in bad location), gets freed.

I took out compress parameter=y and still occurs. its doesn't event get to gzip command, but will remove and retry. I am running manually to recreate incident. no longer in cron

Does it when I do exp interactively and not with the script also.

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

Hi
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.

Guys, please correct me if i'm wrong.


Thanks


(1) exp_dpr1.sh
sundb01:/lvo295/dpr1/scripts >more exp_dpr1.sh
#!/usr/bin/ksh
#
#Revisions
DATE=$(date +%Y%m%d%H%M)
. ./.profile
cd /arlogs
exp userid=***** buffer=500000 full=y compress=y indexes=y \
file=/lvo195/dpr1/exp/exp_dpr1$DATE.dmp \
log=/lvo195/dpr1/exp/exp_dpr1$DATE.log \
rows=y grants=y direct=y consistent=y
cd /lvo195/dpr1/exp
gzip exp_dpr1$DATE.dmp

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.

Is lvo195 actually a symbolic link to lvo100?

What i feel is when ever u copy or write a file into a file system, the OS make a temporary copy in the /tmp folder before finally writing it into the specified file system and during the process of writing in the /tmp folder if the OS does not find enough space it aborts the process.Please increase the size in the tmp folder or the root folder.

regards
anandkl