UGA and PGA checks:

(1) You can do this to check UGA and PGA allocations for a given session:

select a.name,b.value,b.sid,username
from v$statname a,v$sesstat b,v$session
where a.statistic#=b.statistic# and b.sid = v$session.sid
and b.sid=&sidvalue and a.name like '%ga%memory%'

or

(2) To just check PGA allocations for a given session:

select PGA_USED_MEM,PGA_ALLOC_MEM,PGA_FREEABLE_MEM,PGA_MAX_MEM from v$process,v$session where sid = &sidvalue and addr=paddr

Also to keep in mind is the fact that database sessions that do direct path reads due to Sort IO (when a sort does not fit in memory) or uses parallel Query slaves or performs I/O to LOB segments (which are not cached in the Buffer Cache), add to the PGA's growth which in turn can affect the process size.

"I also noticed that there are 25 shared servers allocated and all of these start up with the instance, is there a gain in reducing the number to shared servers?"

I guess it depends on the load / concurrent connections to your database. You could always control initial shared server process startup Vs. the total number through the use of shared_servers and max_shared_servers parameters.

This is oracle's recommendation for the number of dispatchers:

"The value of MAX_DISPATCHERS should at least equal the maximum number of concurrent sessions divided by the number of connections for each dispatcher. For most systems, a value of 250 connections for each dispatcher provides good performance. "

You might also want to take a look at 10g's Automatic Shared Server Configuration feature (metalink note 265931.1).

Good luck......

http://www.dbaxchange.com