Re: Session memory usage

"Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message news:<410809d8$0$6451$cc9e4d1f_at_news-text.dial.pipex.com>...
> <sybrandb_at_yahoo.com> wrote in message
> news:a1d154f4.0407280618.41443c93_at_posting.google.com...
> > The rest of your question is platform dependent.
> > On Winblows you usually run into problems with 4G with about 200
> > sessions
> > (speaking from experience), when not using Multithreaded Server.
>
> Windows process space for Oracle (on indeed any other process) is limited to
> circa 1.7gb. allocate 1.6gb to SGA and the limit is a lot less, set it at
> 24mb and you can probably have an awful lot of very slow sessions.
>
> > Connection pooling is dependent on MTS, you would need to enable MTS
> > first.
>
> unless a mid-tier does it for you, in which case MTS would be somewhat daft
> (and therefore is almost certainly implemented somewhere).

Hi Niall.

If you get off of 8.1.7.x and onto 9.2.x, "large" memory support works on w2k adv svr, or w2k3 std. (I know that you run => 9.2.0.3 from your prior emails)

SO -
if one were to use pga_aggregate_target
along with /3GB in ye old boot.ini
one could run the oracle.exe process at around 3,000,000,000 bytes. this does not mean that one could run it at 3 GB, far from it.

we have a site running 9.2.0.4 Std Ed on w2k adv svr, running 300+ dedicated concurrent sessions, with quite a hefty db_cache_size, a large keep cache, with only a 512M pga_aggregate_target with a 320M shared pool to kick in the child latches.

it can be done.
its pretty stable.
whether or not that is what you WANT to do ... is open for debate.

omletsux_at_himself> show parameter cache
&#9792;NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM

------------------------------ ---------------
------------------------------
db_2k_cache_size               big integer     8388608
db_cache_size                  big integer     805306368
db_keep_cache_size             big integer     738197504
db_recycle_cache_size          big integer     16777216
object_cache_max_size_percent  integer         10
object_cache_optimal_size      integer         102400
session_cached_cursors         integer         100

keep is large due to FTS induced by app code that will hopefully soon change.

-bdbafh Received on Wed Jul 28 2004 - 21:55:51 CDT