Re: ORA-04030: out of process memory

From: <jdsysadm_at_yahoo.com>
Date: Fri, 22 Feb 2002 14:47:09 GMT
Message-ID: <3c7658d2.196136285_at_news.uncensorednewsfeed.com>


On Fri, 22 Feb 2002 13:41:39 +0100, "Rex" <rg_at_online.no> wrote:

>...when trying to allocate x bytes.
>
>Have created a database on 8.1.7.2 EE on HP-UX (11.0).
>Adding JVM to new db and job crashes when it runs a JVM script called
>jisja.sql (which turns on JAccelerator (ncomp) for JIS). Comment out this
>script and rerun job and I get the same error (ORA-04030) at several other
>points along the JVM job resulting in an
>unsuccessful install of JVM against the db.
>
>Searched Oracle Metalink and most refs found were for the initjvm.sql
>scripts producing the
>same error. Metalink solution was to check ulimit and up the memory
>allocated to the
>user. Have checked (as root) with ulimit -a and received the following
>output:
>time(seconds) unlimited
>file(blocks) unlimited
>data(kbytes) 65536
>stack(kbytes) 8192
>memory(kbytes) unlimited
>coredump(blocks) 4194303
>nofiles(descriptors) 2048
>However I am running the job as the Oracle user (oracle), who is a user on
>the NIS, and try
>to get the same info with ulimit -a and it gives me "ksh: ulimit: bad
>option(s)". When I try
>'ulimit' (with no args) I get "4194303" which I take to be the
>coredump(blocks) output similar
>to what was given for roots' ulimit -a. All docs found give advice to
>increase the memory
>for this user (oracle). How is this done? I have tried "ulimit -m unlimited"
>as the oracle user
>with the error "ksh: ulimit: bad option(s)".
>
>Or am I totally in the wrong direction and its something other than the
>ulimit thing?
>
>Any help with this appreciated from either the Oracle or HP-UX groups.
>
>Thanx in advance.
>Rex
>
>
>

Metalink document Note:120613.1 does show a few ORA-4030 bugs get fixed in the 8.1.7.3 patch, but the first thing I'd check on any out of memory errors would be your maxdsiz kernel parameter. Maxdsiz should be set to a bare minimum of 256 MB with 1 GB being better. Received on Fri Feb 22 2002 - 15:47:09 CET

Original text of this message