Re: ORA-04030 beating
- From: "Paul G Parker" <parkerpg@xxxxxxxxx>
- To: "<oracle-l@xxxxxxxxxxxxx>" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 21 Nov 2008 23:19:26 -0500
I don't think this made it to the list. Trying again
Darrell,
Since this appears to be related to those sessions connected through
the listener, was the listener started by Oracle when the ulimit was
set to unlimited? The spawned listener processes inherits the
settings which were in effect at the time when the listener was
started, so if the ulimit settings were modified subsequently to the
listener start, the old limits are still in effect. Maybe worth a
check?
Paul
On Fri, Nov 21, 2008 at 3:53 PM, Darrell Landrum <dl1tech@xxxxxxxxx> wrote:
> Hey Mark, thanks for your input.
> I've been able to duplicate the error on various windows clients as well as
> in sessions on the database server connecting user@sid. So the client
> version is different in some cases, the same in others. So far this only
> runs successfully from a session on the database server connected locally.
> I just finished an hour conference with Oracle support, gathering info from
> v$ views, truss, etc. I'm just glad I'm not stumped alone. Although, I
> fully expect the solution, when and from wherever it comes, to be something
> I should have thought of already.
> Thanks!
> Darrell
> Sent from my iPhone
> On Nov 21, 2008, at 12:54, "Powell, Mark D" <mark.powell@xxxxxxx> wrote:
>
> The maximum size of a pl/sql table (array) used to be OS dependent. I can
> remember when we tested and found the limit was only around 10M on a Pyramid
> on 7.0 or maybe 7.1.
>
> I image that the amount of available free real memory on the client may also
> be important.
>
> Is the client where the task is failing at 111M a Windows or UNIX box? Is
> the client version the same as the database version?
>
> Interested in what others can add.
>
> -- Mark D Powell --
> Phone (313) 592-5148
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
