RE: Problem with many (160 - 170) sessions in the database on NT

Actually, I would just try and shrink the sga a little bit and make sure that your swap file is on it's own platter. I have run into a lot of problems with swap file crap on NT, even thought the machine has a gig of ram. Try to keep it just a little below that 1.7 threshold. Also, I read somewhere that the Win2k will allow you to install more ram than NT's limit right now, so the future might be looking a little bit better.

-----Original Message-----
Sent: Tuesday, May 29, 2001 3:11 PM
To: Multiple recipients of list ORACLE-L NT

Jonas,

In addition to Dick's comments about a real Os ( with which I concur ) you need to do that math. You are running 170 sessions on the database.

You can count on each session eating up 5 meg of RAM with 7.3. If you go to 8i, you can at least double that figure. This is all dependant on your
SORT_AREA_SIZE of course and YMMV.

So your box is using 1 gig of RAM for user sessions. That leaves you with 700M, and we don't know how big your SGA is. I don't know how much RAM NT wants, maybe someone else can help out here.

You need more RAM IMO, but I'm operating on assumptions here and not too many facts.

You probably can't upgrade to 8.1.7 with your current RAM. I would wonder about 4 processors for 170 users as well.

And of course, there's the 1.7 Gig mem bug you mention, afraid I don't know anything about that.

Bottom line, this box seems to be pushing it's resources, but you're in a better position to make that call.

Jared

On Tuesday 29 May 2001 09:50, Jonas A Wetterberg wrote:
> Hello
>
> We are running into a little problem with an Oracle installation. The
> server OS is Windows NT, SP6, and the version of Oracle is 7.3.4.5.0. The
> server have 4 processes, we have about 1,7 G primary memory and about 2 G
> of memory on swap disk. We have 4 processes in the machine. One of these
is
> reserved for the OS, and Oracle uses the other 3.
>
> We we reach around 170 sessions in the database, the database sometimes
> goes down and we have to perform a restart. The 3 process Oracle use are
> all at about 100% in task manager. The memory use is somewhere around 1,3
> G. Then we can run the database for aboout 4 more hours, then we have to
> restart. Sometimes we have to restart around lunch everyday.
>
> Now I have heard the Windows NT have a limit of how much memory one
process
> might use, and that limit is somewhere around 1,7 G, and that that might
be
> our problem.
>
> We are planing to upgrade to Oracle 8.1.7 and to Windows NT 4 Enterprise
> Edition or to Windows 2000 Advanced Server. Does anyone know if this can
> help? Should we put more memory or more processes in the machine?
>
> Any help is appreacheated
>
> Regards
>
> /Jonas

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Kevin Kostyszyn
  INET: kevin_at_dulcian.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).