SQLDeveloper usando más de 100MB de PGA

Question

Quizás esto sea normal, pero en mi base de datos Oracle 11g veo que los programadores que usan el SQL Developer de Oracle consumen regularmente más de 100MB de memoria combinada UGA y PGA. Me gustaría saber si esto es normal y qué se puede hacer al respecto. Nuestra base de datos se encuentra en la versión de 32 bits de Windows 2008, por lo que las limitaciones de memoria se están convirtiendo en una preocupación cada vez mayor. Estoy utilizando la siguiente consulta para mostrar el uso de memoria:

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; 

Parece que el uso de los recursos sube cada vez que se abre una tabla en SQLDeveloper, pero incluso cuando está cerrada la memoria no desaparece. El problema es peor si la tabla está ordenada mientras estaba abierta ya que parece usar aún más memoria. Entiendo cómo esto usaría la memoria mientras está ordenando, y tal vez incluso cuando aún está abierta, pero usar memoria después de que esté cerrada me parece incorrecta. ¿Alguien puede confirmar esto?

Actualización: Descubrí que mis números estaban apagados debido a no entender que the UGA is stored in the PGA under dedicated server mode. Esto hace que los números sean más bajos de lo que eran, pero el problema sigue siendo que SQL Developer parece usar un PGA excesivo.

Answer 1

Quizás SQL Developer no cierre los cursores que había abierto. Por lo tanto, si ejecuta una consulta que ordena un millón de filas y SQL Developer obtiene solo las primeras 20 filas de allí, necesita mantener el cursor abierto si desea desplazarse hacia abajo y obtener más.

Por lo tanto, necesita mantener parte de la memoria PGA asociada con el área de clasificación del cursor todavía asignada (se llama área de clasificación retenida) mientras el cursor esté abierto y no haya alcanzado EOF (fin de captura) .

Escoja una sesión y ejecutar:

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

Esto debería mostrar si algunos cursores todavía se mantienen abiertas con su memoria ...

Answer 2

¿Está utilizando la gestión automática de memoria? En caso afirmativo, no me preocuparía la memoria PGA utilizada.

Ver documentos:

de gestión automática de memoria: http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/memory003.htm#ADMIN11011

MEMORY_TARGET: http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams133.htm

¿Hay una razón por la que está utilizando Oracle de 32 bits? El hardware más reciente admite 64 bits.

Answer 3

Oracle, especialmente con AMM, utilizará cada bit de memoria en la máquina que le proporcione. Si no tiene una razón para desasignar la memoria, no lo hará. Lo mismo ocurre con el espacio de almacenamiento: si elimina 20 GB de datos de usuario, ese espacio no se devuelve al sistema operativo. Oracle se aferrará a él a menos que compacte explícitamente los espacios de tabla.

Creo que una simple prueba debería aliviar sus preocupaciones. Si es de 32 bits, y cada sesión de SQL Developer está usando 100MB + de RAM, entonces solo necesitaría unos cientos de sesiones abiertas para causar un problema de poca memoria ... si realmente hay uno.