RE: Reg: ORA-04030

Mamta,

   It is not that simple.

   You cannot just limit the database to a few sessions. When other users try 
to connect they will get errors.

    You need to look into v$session to see where the connections are 
originating from and see if you can reduce the amount of sessions. For each 
origin you will have a different procedure.

    On the concurrent manager you can reduce the number of managers, some 
managers can be disabled if you are not using them.  For the self-service 
sessions, you can configure the AOL connection pool. The default is to create 
one connection per user. You can configure a maximum number of connections for 
the entire pool. For the forms sessions what you can do is to look if the forms 
sessions are being cleared when the users disconnect from the server. There are 
some timeouts you can configure (Forms heartbeat, operating system tcp 
timeouts) to clear these sessions faster. Also many dangling forms sessions on 
a specific form may indicate a problem with that particular form.

    This tunning will only alleviate the problem up to a certain point. 
Depending on the amount of users you have on your environment it wont be 
sufficient.

    The option 2 would be a easier thing to do. You can configure the 
parameters and reboot, and will have about 1Gb of extra memory to use. Also you 
can use PAE to keep the block buffer outside of the 4Gb address space, giving 
you some more leverage. See note 225349.1.

Regards,
Luis

--- On Thu, 2/26/09, NEELI-SC, Mamta <Mamta.NEELI@xxxxxxxxxxxxxx> wrote:
From: NEELI-SC, Mamta <Mamta.NEELI@xxxxxxxxxxxxxx>
Subject: RE: Reg: ORA-04030
To: ora-apps-dba@xxxxxxxxxxxxx
Date: Thursday, February 26, 2009, 9:18 PM




 
 

 







Hi Chunk, 

   

Migrating to 64bit will take time... 

   

So the quick turn around will be to go to
option1 right? 

   

If you were able to go through my pfile
please suggest me if some changes are required in it. 

   

Thanks a lot. 

   

Mamta 

   

   









From:
ora-apps-dba-bounce@xxxxxxxxxxxxx [mailto:ora-apps-dba-bounce@xxxxxxxxxxxxx] On 
Behalf Of Chuck Edwards

Sent: Friday, 27 February 2009
00:20

To: ora-apps-dba@xxxxxxxxxxxxx

Subject: Re: Reg: ORA-04030 



   



Since the problem is really a database issue, you could run the DB on a
separate 64-bit Windows server.  But according to the certification
section of Metalink, you are correct:  The E-Business Suite application
tier is not certified against any version of 64-bit Windows. 





   





   





Chuck Edwards 





Blue Gecko, Inc. 





http://www.bluegecko.net 





   







On Feb 25, 2009, at 10:33 PM, NEELI-SC, Mamta wrote: 







 

 







Hi Chunk, 





   





I was just going through the third option
suggested by you… 





   





Migrate to 64bit... 





   





But only database can migrated to 64bit
and not Application that is through split configuration…as per the doc 





http://blogs.oracle.com/stevenChan/2006/05/64bit_support_for_the_ebusines.html 





   





Or there is any other option?? 





   





Anyone has gone through such issues.
Please share the resolution you followed. 





   





Your valuable inputs are really
appreciable. 





   





Thanks, 





Mamta 





   





   





   













From: ora-apps-dba-bounce@xxxxxxxxxxxxx
[mailto:ora-apps-dba-bounce@xxxxxxxxxxxxx] On
Behalf Of Chuck
Edwards

Sent: Wednesday, 25 February 2009 23:00

To: ora-apps-dba@xxxxxxxxxxxxx

Subject: Re: Reg: ORA-04030 







   







On Windows, Oracle runs in a single
service called oracle.exe.  This service contains multiple threads that
represent the background and user processes.  Because Oracle is running as
a single service, all of the threads together can only address 2GB of physical
memory, which is the limit for a 32-bit operating system. 









   









On a 32-bit UNIX or Linux platform, the
SGA is still subject to the 2GB limit, but the user processes run in their own
process space and may address their own memory. 









   









Your error is caused by the 32-bit, 2GB
memory limitation; even though your SGA may be smaller than 2GB, every session
started against the database chips away at the addressable memory for the
oracle.exe service.  When the total memory addressed hits 2GB, you will
not be allowed to start another session and you will see ORA-04030. 









   









There are a few ways to combat this
problem: 









   









1.  Don't run so many user sessions.
 This is not always practical or possible. 









2.  There are ways to increase the
memory limit on 32-bit Windows to up to 4GB.  Check out Oracle's platform
guide for 32-bit Windows for more direction:  
http://download.oracle.com/docs/cd/B19306_01/win.102/b14304/architec.htm 









3.  Migrate to 64-bit Windows. 









4.  Migrate to UNIX or Linux for your
database OS.  









   









If you are committed to Oracle
on the Windows platform and cannot practically limit the number of user
sessions or substantially shrinking your SGA, explore option 2, then
option 3, in that order. 









   









You might check out Metalink
article 373602.1 as well.  It references other related articles you
might find helpful. 









   









Hope that helps. 









   













Chuck Edwards 









Blue Gecko, Inc. 









http://www.bluegecko.net 









   











   









On Feb 24, 2009, at 4:28 PM, NEELI-SC,
Mamta wrote: 













 



 









HI Chuck, 









   









Yes it’s 32-bit Windows. 









   









Regards, 









Mamta 









   

















   













 









  

















   









   







  

Other related posts: