We have a legacy application (ERP) that, because of technical issues, spawns a new OS process (.exe - ms windows clients) for each screen requested by the user. Also, each company branch (> 20) has its own schema, and the application deals using 1 connection for each. Since each user may open as many screens they deserve to, it is quite common that some users reach > 30 sessions.

That will result in opening many connections to Oracle. In last report, we got 861 sessions for 87 users (~10 sessions/user).

My customer's DBA is saying that this will knock the database performance down, and demand heaps (really huge amounts) from the server's RAM & CPU.

Does this statement make sense?


  • What are the side effects of raising the PROCESSES system parameter?
  • What is the cost of a open process (even if idle) in the server?
  • 2
    If the DB server has enough RAM, that shouldn't be a problem. But you might want to look into "shared servers" which is essentially a connection pool built into the Oracle core: docs.oracle.com/cd/E11882_01/server.112/e25494/…
    – user1822
    Nov 22, 2013 at 12:40
  • +1, @a_horse_with_no_name. This seems to me to be the classic case where shared servers will shine. Nov 22, 2013 at 12:52
  • @a_horse_with_no_name: Thank's for your direction. That link certainly will be useful.
    – J.Hudler
    Nov 22, 2013 at 20:02

1 Answer 1


At least it has you have to increase most of the OS kernel parameters(like number of file handles). Most of them have a formula where use PROCESSES is an input. Also each server process allocates some RAM - the about is not big, but when multiplied by one thousand ...

Idle processes do not have any major overhead, but when DB server starts swapping RAM it's over. All the performance is away.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.