It sounds like an issue with the JDBC Thin Client connections that are established from the JServs used by Oracle Self Service. We have found that the default settings within the App will allow ridiculous amounts of JDBC connections to the database with very little reuse.
With some tweaking of your JDBC settings (in the DBC File), you should be able to ensure that JDBC connections which are not required are released from the system. Check your v$session and confirm how many JDBC Thin Client connections you have over time.
Regards,
Paul
*********** ORIGINAL MESSAGE ***********
On 7/04/2005 at 9:05 AM Cohn Grant wrote:
Hello All!
Wanting to know if any of you have had any experience of the following:
We are running Oracle Apps 11.5.9 on a two-tier Windows 2000 platform.
The one server runs the OAS (& Apache) and all the forms. The other
server has the D/base (Oracle 8.1.7.4) and the concurrent manager.
Almost since installation of the system (18 months ago) we seem to have
a continual memory problem. The memory used by the oracle.exe process
grows and grows as does the count of the non-paged pool.
This goes on for about 4 days and then results in a system crash (on the
DB Tier server) with OS SRV error 2019 : "The server was unable to
allocate from the system nonpaged pool because the pool was empty"
We have put in the /3GB switch in the boot.ini which will allow for a
large increase in memory for oracle.exe (this also reduces the amount of
memory available for NP pool) - The server has 4GB RAM.
ALSO - (but maybe totally unrelated to the SRV errors) ....... The
number of sessions in the database (select count * from v$session),
grows and grows and grows. It appears that old sessions never log-out.
HOWEVER, if I do a quick restart of the APACHE service on the APPS-Tier
server, a lot of the sessions disappear and at the same time the memory
used by oracle.exe falls. (NP pool stays the same)
Confusing enough??? :-) This may be two unrelated problems.
I have had a TAR open with Oracle for almost 10 month now - with no
resolution. They have suggested some patches to apply to try resolve the
session problem. We applied these on a test system (which does not have
the same load and does not give the same problem). Before applying these
on Production, I'd like to have any comment any of you may have.
Regards
Grant Cohn
Shell & BP Oil Refinery
DURBAN
South Africa.
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
Oracle LazyDBA home page