views:

509

answers:

3

Perhaps this is normal, but in my Oracle 11g database I am seeing programmers using Oracle's SQL Developer regularly consume more than 100MB of combined UGA and PGA memory. I'd like to know if this is normal and what can be done about it. Our database is on the 32 bit version of Windows 2008, so memory limitations are becoming an increasing concern. I am using the following query to show the memory usage:

SELECT e.SID, e.username, e.status, b.PGA_MEMORY
FROM v$session e
LEFT JOIN 
   (select y.SID, y.value pga, 
      TO_CHAR(ROUND(y.value/1024/1024),99999999) || ' MB' PGA_MEMORY 
   from v$sesstat y, v$statname z 
   where y.STATISTIC# = z.STATISTIC# and NAME = 'session pga memory') b
ON e.sid=b.sid
WHERE (PGA)/1024/1024 > 20
ORDER BY 4 DESC;

It seems that the resource usage goes up any time a table is opened in SQLDeveloper, but even when it is closed the memory does not go away. The problem is worse if the table is sorted while it was open as that seems to use even more memory. I understand how this would use memory while it is sorting, and perhaps even while it is still open, but to use memory after it is closed seems wrong to me. Can anyone confirm this?

Update: I discovered that my numbers were off due to not understanding that the UGA is stored in the PGA under dedicated server mode. This makes the numbers lower than they were, but the problem still remains that SQL Developer seems to use excessive PGA.

A: 

Are you using Automatic Memory Management? If yes, I would not worry about the PGA memory used.

See docs:

Automatic Memory Management: http://download.oracle.com/docs/cd/B28359%5F01/server.111/b28310/memory003.htm#ADMIN11011

MEMORY_TARGET: http://download.oracle.com/docs/cd/B28359%5F01/server.111/b28320/initparams133.htm

Is there a reason you are using 32 bit Oracle? Most recent hardware supports 64 bit.

Angelo Marcotullio
Yes, we are using Automatic Memory Management, but I don't see why that would cause PGA usage not to be a concern. Sure the system can resize the SGA to give the PGA more memory if need be, however if the buffer cache, shared pool or other areas get too small it will cause performance problems.
Leigh Riffel
Our hardware supports 64 bit and we recently tried to migrate to Windows 2008 64 Bit with 11g, but discovered in testing that Oracle no longer supports Heterogeneous services in 11g and the replacement dg4odbc only works on the 32 bit version. Supposedly support is coming in 11.2. See 361676.1 on Metalink which explains this and gives an unacceptable workaround.
Leigh Riffel
>> however if the buffer cache, shared pool or other areas get too small it will cause performance problems.If you are using AMM, then you should trust Oracle to manage the memory. When you have an actual performance problem, you can use the various tools in Oracle to investigate.If you are curious, you can trace the developer session and get an idea what they are doing that is using the PGA memory. Hopefully, 11gR2 will fix your HS issue. Running Oracle on 32 bits is painful.
Angelo Marcotullio
I've looked at what these developers are doing and it isn't anything special. Even if I were on 64 bit developer sessions consuming over 100MB would still be a concern as I want as much memory as possible going to the buffer cache and sql_area.
Leigh Riffel
A: 

Oracle, especially with AMM, will use every bit of memory on the machine you give it. If it doesn't have a reason to de-allocate memory it will not do so. It is the same with storage space: if you delete 20 GB of user data that space is not returned to the OS. Oracle will hold on to it unless you explicitly compact the tablespaces.

I believe a simple test should relieve your concerns. If it's 32 bit, and each SQL Developer session is using 100MB+ of RAM, then you'd only need a few hundred sessions open to cause a low-memory problem...if there really is one.

Adam Hawkes
I tested as you suggested creating sessions and using up memory until I got out of process memory errors. For my first session in SQLDeveloper I opened the data tab of a table and sorted the table. The connection was then using 65MB of memory. I then closed the table, but the connection continued to hold 65 MB. I started creating other sessions and using memory until I received an ORA-04030 Out of Process memory. My original session was still using 65MB and did so until I closed it.
Leigh Riffel
+2  A: 

Perhaps SQL Developer doesn't close the cursors it had opened. So if you run a query which sorts a million rows and SQL Developer fetches only first 20 rows from there, it needs to keep the cursor open should you want to scroll down and fetch more.

So, it needs to keep some of the PGA memory associated with the cursor's sort area still allocated (it's called retained sort area) as long as the cursor is open and hasn't reached EOF (end-of-fetch).

Pick a session and run:

select sql_id,operation_type,actual_mem_used,max_mem_used,tempseg_size
from v$sql_workarea_active
where sid = &SID_OF_INTEREST

This should show whether some cursors are still kept open with their memory...

Tanel Poder
+1 You are correct. It seems to be keeping these in memory even after the table is closed in SQLDeveloper. Since version three is expected to be released soon I'll probably wait to see if it has a problem then and open an SR if it does. We are less concerned about the issue now because we have upgraded to 64 Bit and tripled the memory.
Leigh Riffel