SUMMARY: ulimit question

Lisa Hafner (hafner@syrinx.com)
Tue, 13 May 1997 10:08:54 -0400

Original question was:

> Our Oracle admin is trying to install oracle 7.3.3 on our sparc
> 20 (running 2.5.1). When she runs the final script (at least I hope it's
> the last one) it comes up with the following error:
>
> Please raise the ORACLE owner's ulimit as per the IUG.
>
> Oracle hasn't been any help. My question is -- since the oracle
> owner's ulimit is set for unlimited except for:
>
> data(kbytes) 2097148
> stack(kbytes) 2097148
> nofiles(descriptors) 1024
>
> How do I raise the other 3 to unlimited for this user? I've
> tried a handful of things, but to no avail. I've heard that I may be
> able to change them in /etc/system, but I haven't been able to find any
> references to syntax of the entries. Help!
>

General consensus seemed to be that the error can be IGNORED.
(Scary thought.) Our DBA says that "so far, so good" so it seems
that you guys were right. It's been up and running since the 4th of May.
Thanks -- you all saved me from banging my head on the sparc's monitor!

Here's a few excerpts:

Don't worry. I got the same error when I installed Oracle and it
works just fine. The Oracle-L mailing list also talked about this -
the consensus is that it is a non-issue. The install is OK,
Oracle is OK.
_________________________
The DBA's I've asked have said "ignore it" and my Oracle database has been
running for 2 years without problems.

The Oracle install scripts are very buggy and broken (heh, they break down
and die if you use NIS+). Reading the code, it's a meaningless message.

Just make sure your shared memory is big enough for the SGA and things will
work fine.
_________________________
this warning has been part of oracles installation messages for
a long time - I think I saw it as long ago as ORACLE-5 !

I have always ignored it ( except on SCO unix ) and have never had a problem.
nearly two gigabyte of stack and data is easily big enough for oracle, and
1024 file descriptors is the hard limit and cannot be
exceeded.

Thanks to:

Bismark Espinoza <bismark@alta.Jpl.Nasa.Gov>
erin o'neill <erin@factory.net>
Brion Leary <brion@dia.state.ma.us>
Glenn Satchell - Uniq Professional Services
<Glenn.Satchell@uniq.com.au>
Stephen Harris <sweh@mpn.com>
Peter Bestel <peter.bestel@uniq.com.au>
Gonzo Bushman <gonzo@icon.net>
Ray Trzaska <rtrzaska@uk.mdis.com>
"Andy J. Stefancik 237-2164" <ajs6143@eerpf001.ca.boeing.com>
Peter M Allan <peter.allan@aeat.co.uk>