Lack of Java Pool Can Also Cause ORA-4031 I've been fighting this failed database export for a few days. I'm confident this time it's fixed. What happened is that this database, as well as the production llnk, has an on-database-startup trigger, which executes sys.dbms_java.server_startup procedure. I don't know what this procedure does for lack of source code. But I can tell from LLNKDEV alert.log, ORA-4031 is thrown every time the database is started: Errors in file /f00/app/oracle/admin/LLNKDEV/udump/llnkdev_ora_16551.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-04031: unable to allocate 4032 bytes of shared memory ("shared pool","oracle /jdbc/kprb/KprbDBAcces...","joxlod: in ehe","ioc_allocate_pal") ORA-06512: at "SYS.DBMS_JAVA", line 0 ORA-06512: at line 2 which fortunately doesn't prevent the database startup. This is exactly the error we get when the database export is run. I can also duplicate it once the database is started and manually run this procedure. Common strategy to remedy ORA-4031 is increasing shared_pool_size and pin frequently used objects, mostly packages. I tried that. It still didn't work. I even increased shared_pool_size to 400MB, while LLNK (the corresponding production) only has 200MB. I finally tried increasing java_pool_size from 2M to 10M, in spite of the error saying it can't allocate memory from shared pool instead of java pool. And this did the trick, even with shared_pool_size set to 50M! The next database startup did not throw this error any more. A manual export is in progress right now. Yong SEE ALSO Metalink thread 241775.999, message from Oracle, Rowena Serna at 22-Jun-01 06:24 2006 note about ORA-4031: It seems the 3rd argument (the 2nd last) in ORA-4031 tells you which section of shared (or java or large) pool is short of memory. It matches x$ksmss.ksmssnam or v$sgastat.name. If in 9i, you could have multiple shared pool subpools. This SQL select sum(ksmsslen), ksmdsidx from x$ksmss where ksmssnam = 'free memory' group by ksmdsidx; shows how unbalanced free memory is in each subpool. Most likely the one with the least free memory threw ORA-4031 (with subpool, the 3rd arg of ORA-4031 looks like e.g., "sga heap(5,0)"). See which type of memory was allocated in the most unbalanced way. You can influence the distribution for some types. For instance, if it's "sql area", you may match library cache latches (_kgl_latch_count) with number of subpools (_kghdsidx_count) to balance it.