One of the limitations we hit in our NT environment was that NT would not allow any application to exceed 2.5gig or so of memory AND NT would only deal with 4gig or RMA. No way around, it was a known issue. So, to ensure users could get their dedicated connections, we had to trim SGA and such to ensure that Oracle never tried to exceed the limit. The advice given was to make the move to W2000, which supposedly eliminated the 4gig barrier, as well as the 2.5+ gig barrier for a single application.
Now, up on 2000 on a new box with 4gigs of ram. Getting those pesky TNS-12500 errors. Again, Metalink shows that on W2k for 4gig, the OS grabs half the memory for itself. Each new connection causes a new thread at the os level, which takes a 1mb chuck out of the memory that ORACLE has available. The quick formula they show for determing how many active concurrent users you have is (2gig - SGA)/1mb. So, if you sga is 1.8gig, you can have 200 users with dedicated sessions. 201 causes the error.
But, have been unable to confirm if 1) W2K will definitly deal with more than 4gigs and 2) if I put 8gigs of ram in, will OS grab 4gig fo that for itself and 3) will it let oracle grab more than the old barrier of 2.5+ or so gig.
Anyone out there using a >4gig ram config on w2k? I am thinking I can just add ram to the box and this issue will go away. ALso thinking that MTS might be the way to go, since I need to support about 400-500 users beating at the door at any given time..
W2k is a good os but if you want better performance goto unix - if affordable. You can throw more memory to NT and it will chew it up. I am not sure about the limits but I don believe you will get stuck at 2.5Gb
Maybe you should think about load balancing with OPS if you can have 2 servers. This will help you with performance - I have done this type of implimentation. You will have problems with connections but there are some things you can do like:
1. disconnect users who are not active after 25 minutes no no activity etc..
2. ensure all bad connections are cleaned up via sqlnet.expire_time