*** DUMP FILE SIZE IS LIMITED TO 0 BYTES *** 1

[nontrad]

*** DUMP FILE SIZE IS LIMITED TO 0 BYTES ***

I was cruising through my directory and found .log files that contain this message. As best as I can figure out, someone is trying to export from the database but there is no dump file set aside to allow this. No one claims any knowledge of these actions. I know I'm not doing it accidently because the times the .log files were created don't match up to my work hours.

1) I want to establish an audit trail to find out who's doing this. I though I had one established but I must have goofed. How do I establish an audit trail of connections/actions and how do I view that trail?

2) Is there any other action against the DB other than an export that would create this .log file & message?

3) My ORACLE_SID= is to one DB but these actions are against another DB. Do I have to set up an audit trail for each DB? How do I get from one to the other?

Thanks.

 

[karluk]

This is probably not caused by an export. The dump files in question are probably the trace files automatically created when certain database errors occur.

As far as why you are getting the "DUMP FILE SIZE IS LIMITED TO 0 BYTES" message, I checked Metalink and it appears that this is bug 934839 which was fixed in Oracle 8.1.7 and in some of the 8.1.6 patches. On Windows NT the documentations says the fix is in the 8.1.6.3.0 patchset, but I don't see it listed in any of the earlier patches.

If you are indeed hitting this bug it looks as if your only option is to upgrade. I didn't see any work around listed. Check with Oracle for details about your O/S. I don't think the patch is the same on all platforms.

 

[nontrad]

Thanks. Maybe that's the reason. We're using 8.1.6.

I'll look for a patch for our system. BTW, what is metalink?

 

[nontrad]

Found out the problem w/ Oracle tek help. We chaned 2 files, rebooted the server & relinked Oracle.

1) System file - increased shimmmni parameter to 300 - was set at 50. Previously we had changed semmns to 200

2) .profile file - changed PATH to add /etc and changed order of files.

added the following which affects linking
TMP=/tmp
TMPDIR=/tmp
LD_LIBRARY_PATH=$ORACLE_HOME/lib

We actually think that changind the parameter in system is what did the trick.

YAY! The messages went away! As the Db becomes closer to operational, the messages were multiplying faster than bacteria. It would have been a MAJOR problem if not corrected.