ORA 403 Shared_pool_reserved_size
Les escribo porque tengo una base de datos 8.1.7.4 y me esta arrjando este error. Cuando yo realizo la consulta:
select pool, name, bytes/1024/1024
from v$sgastat
where name = 'free memory' and pool = 'shared pool'
Me devuelve siempre más de 150M libres de memoria, y el ora - 4031 me lo tira por 7, 11 o 15 M; supongo, por lo que leí, que esto se debe a que busca un solo pedazo de memoria y no lo encuentra de este tamaño.
La aplicación que tiene la consulta que arroja este error esta hecha en VB 6 y no tenemos el código fuente, con un trace pude determinar cual es la consulta que se ejecuta antes del error y que no se puede alojar en memoria.
Mi pregunta es si puedo subir una query a la shared_pool_reserved para que siempre este en memoria y si esto me serviría de algo para solucionar el problema.
select pool, name, bytes/1024/1024
from v$sgastat
where name = 'free memory' and pool = 'shared pool'
Me devuelve siempre más de 150M libres de memoria, y el ora - 4031 me lo tira por 7, 11 o 15 M; supongo, por lo que leí, que esto se debe a que busca un solo pedazo de memoria y no lo encuentra de este tamaño.
La aplicación que tiene la consulta que arroja este error esta hecha en VB 6 y no tenemos el código fuente, con un trace pude determinar cual es la consulta que se ejecuta antes del error y que no se puede alojar en memoria.
Mi pregunta es si puedo subir una query a la shared_pool_reserved para que siempre este en memoria y si esto me serviría de algo para solucionar el problema.
1 respuesta
Respuesta de neosys
1
Este error se produce por la excesiva fragmentación de la memoria de la SHARED_POOL.
Y al tener que 'alocatar' espacio nuevo, no lo encuentra, (aunque normalmente se daba mucho en la carga de funciones, procedimientos y package, s) y se solventaba haciendo un FLUSH de la SHARED_POOL.
Fue incluso entonces detectado y tratado como BUG por Oracle, aunque en este momento cuando ya está corriendo la 11g, dudo muchísimo que puedas encontrar el 'patch'.
La forma de solucionarlo es :
- O incrementando la SHARED_POOL_SIZE.
- Entonces, la SHARED_POOL_RESERVED_SIZE mantenla en un valor sobre in 10% del
total de la SHARED_POOL. Aunque no la incrementes. Mira a ver si está sobre ese
porcentaje.
- PRUEBA TAMBIÉN CON ESTOS PARÁMETROS (es que de la 8i ya se me han olvidado
muchos, comprendelo ...) :
Si no puedes conseguir más memoria :
- Si NO tienes procedimientos en JAVA reduce al mínimo la JAVA_POOL_SIZE y
Traspasale lo liberado a los otros parámetros.
- En versiones pre-9i recuerdo que puedes establecer el valor de
OPTIMIZER_MAX_PERMUTATIONS a 2000 para que libere espacio de forma
Más rápida. Y así no tener tanta fragmentación.
Te queria proponer algo sobre el parámetro _SHARED_POOL_RESERVED_MIN_ALLOC,
pero creo que desde la 8i en adelante quedó obsoleto. Miralo de todas formas.
Respecto a lo que dices ... Tan solo puedes dejar permanentemente en memoria objetos de BB. DD. Como : TABLAS, INDICES, SEQUENCIAS con 'cache'. Luego los PROCEDIMIENTOS, FUNCIONES y PACKAGES lo puedes hacer indicando expresamente al levantar la BB. DD. O cuando desees el KEEP ...
Haz una prueba, mira a ver si cuando sale el error, lo detectas y haces un ALTER SYSTEM FLUSH SHARED POOL; Y vuélvelo a ejecutar.
Mira también a ver si tienes procedimientos, funciones o packages de gran tamaño. Convendría dividirlos en trozos más pequeños. Ya que si por ejemplo tienes un PACKAGE con 20 funciones y muchísimas lineas de código y tan sólo llamas a una función de ese package ... todo es cargado! Incluso las 19 funciones restantes. (Divide y vencerás).
Espero que haya sido un poco de orientación ...
Ya me contarás.
Un Saludo
Ramón
Spain
Y al tener que 'alocatar' espacio nuevo, no lo encuentra, (aunque normalmente se daba mucho en la carga de funciones, procedimientos y package, s) y se solventaba haciendo un FLUSH de la SHARED_POOL.
Fue incluso entonces detectado y tratado como BUG por Oracle, aunque en este momento cuando ya está corriendo la 11g, dudo muchísimo que puedas encontrar el 'patch'.
La forma de solucionarlo es :
- O incrementando la SHARED_POOL_SIZE.
- Entonces, la SHARED_POOL_RESERVED_SIZE mantenla en un valor sobre in 10% del
total de la SHARED_POOL. Aunque no la incrementes. Mira a ver si está sobre ese
porcentaje.
- PRUEBA TAMBIÉN CON ESTOS PARÁMETROS (es que de la 8i ya se me han olvidado
muchos, comprendelo ...) :
Si no puedes conseguir más memoria :
- Si NO tienes procedimientos en JAVA reduce al mínimo la JAVA_POOL_SIZE y
Traspasale lo liberado a los otros parámetros.
- En versiones pre-9i recuerdo que puedes establecer el valor de
OPTIMIZER_MAX_PERMUTATIONS a 2000 para que libere espacio de forma
Más rápida. Y así no tener tanta fragmentación.
Te queria proponer algo sobre el parámetro _SHARED_POOL_RESERVED_MIN_ALLOC,
pero creo que desde la 8i en adelante quedó obsoleto. Miralo de todas formas.
Respecto a lo que dices ... Tan solo puedes dejar permanentemente en memoria objetos de BB. DD. Como : TABLAS, INDICES, SEQUENCIAS con 'cache'. Luego los PROCEDIMIENTOS, FUNCIONES y PACKAGES lo puedes hacer indicando expresamente al levantar la BB. DD. O cuando desees el KEEP ...
Haz una prueba, mira a ver si cuando sale el error, lo detectas y haces un ALTER SYSTEM FLUSH SHARED POOL; Y vuélvelo a ejecutar.
Mira también a ver si tienes procedimientos, funciones o packages de gran tamaño. Convendría dividirlos en trozos más pequeños. Ya que si por ejemplo tienes un PACKAGE con 20 funciones y muchísimas lineas de código y tan sólo llamas a una función de ese package ... todo es cargado! Incluso las 19 funciones restantes. (Divide y vencerás).
Espero que haya sido un poco de orientación ...
Ya me contarás.
Un Saludo
Ramón
Spain
Muchas Gracias por la respuesta, te agradezco enormemente tu tiempo. En el caso particular de mi error se soluciono cuando indique explícitamente en el TNSNAMES la clausula SERVER DEDICATED. Con esto los servidores compartidos desaparecieron y el error dejo de ocurrir. Voy a analizar bien tu respuesta para aprender nuevas cosas.
