Generally if while running an export you see this error
ORA-39095: Dump file space has been exhausted: Unable to allocate 8192 bytes
You would probably think - filesystem full, i'll free up some space and try again. However that's not always the cause as i found out today.
In my case the filesystem i was using had nearly 1TB free (and loads of inodes before you ask) but i still got the error after about 5 minutes - very odd.
So i tried the export again just to see what it would do a second time and it failed again - but this time much more quickly. I though perhaps there is some weird filesystem quota thing going on - so i copied a few large file to see what would happen. That it turned out was fine so what was going on?
Well here is my command line - see if you can spot the mistake
expdp / directory=scratch parallel=4 keep_master=y full=y reuse_dumpfiles=y
Spotted it?
Well if you look closely I'm specifying parallel 4 but not actually listing a dumpfile with a wilcarded name (in fact i don't specify a name at all so i just get one file call expdat.dmp) - so all the slaves will want to use the same file.
You'd think might just cause contention on the file (and of course it does) - but some of the locks it creates cause datapump to throw the error that it can't allocate any space - which i guess it can;t as it can;t get a lock but it throws a different error.
Anyway it's a known feature - and the workaround is obvious don;t use parallel without multiple dumpfiles!
MOS ref note below
https://support.oracle.com/epmos/faces/DocumentDisplay?id=433391.1
very good...
ReplyDeleteSaved my night tonight :-). Thanks a lot.
ReplyDeleteI just had exactly the same thing. Copy/Paste of another command. Added parallel and was mystified why it wouldn't work. Couldn't see the wood for the trees! :)
ReplyDeleteThanks.
Tim...
I am not using PARALLEL parameter and specified DATAFILE=file.dmp still I am getting the error. My understanding is it should create a single dump if I am not specifying anything.
ReplyDelete