Optimización SGA y PGA

SGA
Los trabajos de optimización de un gestor de base de datos Oracle pasan siempre por
el estudio de las tablas de estadísticas propias del motor. Estas tablas dan información
relativa a lo sucedido desde el último arranque, es decir, con cada reinicio de la
instancia de base de datos se vacían. Oracle utiliza dos estructuras de memoria
principales para su trabajo: el Área Global del Sistema, SGA (System Global Area o
también Shared Global Area) y el Área Global de Programa, (Program Global Area),
PGA. En la SGA Oracle guarda información sobre su estado de manera compartida. Está
disponible para todos los procesos, por eso se dice que está compartida. La SGA consta
del

 Database Buffer Cache

 Redo Log Buffer
 Shared Pool
 Large Pool
 Java Pool
 Streams Pool

Empezando por la SGA los valores a estudiar son: La cantidad de memoria libre en la
Shared Pool
SELECT *
FROM v$sgastat
WHERE name='free memory';

El porcentaje de aciertos de caché, según esta fórmula:

Cache Hit Ratio = 1 - (physical reads / (db block gets + consistent gets))

SELECT name, value

FROM v$sysstat
WHERE name IN ('db block gets', 'consistent gets', 'physical reads')

También con

SELECT physical_reads, db_block_gets, consistent_gets, name

FROM v$buffer_pool_statistics

Con un valor inferior a 90% es recomendable aumentar la database buffer cache.

La relación entre paradas para acceder al redo log y accesos en caché.
SELECT name, value
FROM v$sysstat
WHERE name = 'redo entries'
OR name = 'redo log space requests'
Con una relación superior a 1:5.000 es necesario ampliar el tamaño del buffer de redo.
Los aciertos de Library Cache
SELECT SUM (pins - reloads) / SUM (pins)
FROM v$librarycache

Con un valor menor a 95% se recomienda aumentar el tamaño de la Shared Pool.

Los aciertos en el diccionario de datos

SELECT SUM(gets) , SUM( getmisses), (SUM( getmisses)/SUM(gets))*100

FROM v$rowcache
Con un porcentaje de fallos (getmisses) frente al de aciertos (gets) mayor de 10-15% es
necesario aumentar la Shared Pool y estudiar las consultas lanzadas para asegurarse
de que usan parámetros.

PGA

La PGA, Program Global Area, es la zona de memoria de cada proceso Oracle. No está
compartida y contiene datos e información de control de un único proceso.

La PGA consta del

 Área de ordenación
 Resto de memoria privada del proceso

Siguiendo por la PGA los valores a estudiar son:

La proporción de ordenaciones que se realizan en memoria frente a las realizadas en
disco.
SELECT a.value "Ordenaciones Disco",
b.value "Ordenaciones Memoria",
ROUND((100 * b.value) /
DECODE((a.value + b.value), 0, 1, (a.value + b.value)),
2) "Porcent"
FROM v$sysstat a, v$sysstat b
WHERE a.name = 'sorts (disk)'
and b.name = 'sorts (memory)';

Si el porcentaje de ordenaciones realizadas en memoria es menor del 98% el área de

ordenación está mal dimensionada.
Es necesario modificar ese espacio mediante el parámetro SORT_AREA_SIZE.
A partir de este momento se centra el estudio en las consultas ejecutadas.

Table Scan. Las consultas pueden desencadenar operaciones de table scan, hay que
controlar que las operaciones de este tipo no deben ser full table scan, las más
pesadas.
En cualquier caso, las operaciones de este último tipo sobre tablas pequeñas, de
diccionario, no generan carga.
SELECT name,value FROM v$sysstat WHERE name LIKE '%table scans%'
Bloqueos. Una de las situaciones que más puede afectar al rendimiento de la base de
datos es la existencia de bloqueos en el servidor.
SELECT s.sid, s.serial#, p.spid FROM v$session s, v$process p WHERE s.paddr = p.addr
AND s.sid in (SELECT session_id FROM v$locked_object)

Anulaciones. El mismo caso que el anterior.

SELECT r.name "RB Segment", NVL(s.username, 'no transaction') "Username", s.osuser

"OS User", s.terminal "Terminal" FROM v$lock l, v$session s, v$rollname r WHERE
l.sid=s.sid(+) AND TRUNC(l.id1/65536) = r.usn AND l.type='TX' AND l.lmode=6 ORDER
BY r.name

Una vez comprobada toda la configuración y la situación actual de la instancia, queda

observar el uso que se está haciendo del motor: las consultas.
Las consultas lanzadas aparecen en la vista V$SQL. Al igual que el resto se vacía con el
arranque de la instancia.
Estas consultas se pueden ordenar por cualquiera de sus campos, pero los más útiles
son: EXECUTIONS (número de ejecuciones), CPU_TIME (tiempo de CPU) y
APPLICATION_WAIT_TIME (tiempo de espera).

Configurar la memoria de Oracle tras la instalación.

1. Objetivo:
Se muestra, a modo de ejemplo, una forma de distribuir la memoria del sistema en
una nueva instalación de ORACLE.

2. La memoria de ORACLE
El total disponible de memoria en un sistema tiene que estar configurado de forma
que todos los componentes de ese sistema funcionen óptimamente. Una pauta a
seguir para que el sistema quede bien configurado podría ser el siguiente:
Componentes del sistema Memoria del Sistema

Oracle SGA Componentes ~ 50\% del total

Sistema operativo + Otros componentes ~15\% del total

Memoria de usuario ~ 35\% del total

Esta es la primera pauta que podemos seguir a la hora de reservar o ver la memoria
que se necesita o que se puede poner cómo máximo en un sistema para que Oracle
funcione correctamente y los demás componentes del sistema puedan hacerlo
también. (Habría que tener en cuenta también el número de usuarios que accederán
concurrentemente al sistema).
Una vez que hemos decidido que la SGA de nuestra base de datos ORACLE va a ser el
50\% de la memoria total del sistema. Esta memoria la tenemos que dividir entre los
componentes que la forman. (Database buffer cache, shared_pool_area, fixed size,
redo log buffer)
Componentes de la SGA Memoria SGA

Database Buffer Cache ~80\% de la SGA

Shared Pool Area ~12\% de la SGA

Fixed Size ~1\% de la SGA

Redo Log Buffer ~0.1\% de la SGA

La distribución puede venir bien para comenzar a establecer un sistema, aunque

posteriormente podrán variar (y habrá que realizar tuning de ellos) cuando se conozca
o varíen el tipo de acceso a la base de datos, los patrones de acceso, usuarios
concurrentes en el sistema etc. Para entender mejor estas tablas proponemos el
siguiente ejemplo:
Tengo un sistema configurado con 2 GB de memoria y con una estimación de 100
sesiones concurrentes. La aplicación requiere responder en pocos segundos. Es una
base de datos que tiene muchas transacciones.
Componentes del sistema Memoria asignada (en Mb)

SGA para ORACLE ~1024

Sistema operativo + Otros componentes ~306

Memoria de usuario ~694

Los 694 MB estarán disponibles para la PGA y todos los procesos servidores de Oracle.
Teniendo en cuenta que en el ejemplo hemos dicho que teníamos 100 sesiones
concurrentes nos daría un promedio de unos 7 Megas (aproximadamente) para el
consumo de cada usuario. (Tenemos que tener en cuenta que el SORT_AREA_SIZE
forma parte de la PGA) Por ultimo habría que distribuir la memoria que hemos dado a
la SGA entre todos sus componentes.
Componentes de la SGA Memoria asignada (en Mb)

Database Buffer Cache ~800

Shared Pool Area ~128 – 188

Fixed Size + Misc ~8

Redo Log Buffer ~ 1 (promedio 512K)

Gestión de memoria para Oracle 10g y >=Oracle 11g

En las versiones 10g y 11g de Oracle Database, se ha simplificado la configuración de
las estructuras de memoria tanto para el SGA como el PGA de forma notable.

Oracle versión >=10g

A partir de la versión 10g se introducen 2 nuevos parámetros de gestión de memoria

que simplifican enormemente esta tarea.

SGA_TARGET, simplemente se fija un valor y redimensiona a demanda los valores

(siempre y cuando sean=0):
 Buffer cache (DB_CACHE_SIZE)
 Shared pool (SHARED_POOL_SIZE)
 Large pool (LARGE_POOL_SIZE)
 Java pool (JAVA_POOL_SIZE)
 Streams pool (STREAMS_POOL_SIZE)
PGA_AGGREGATE_TARGET, fijamos un valor y son redimensionadas las estructuras
relacionadas con el PGA de forma dinámica (siempre y cuando sean=0). Es decir todos
los parámetros:
 SORT_AREA_SIZE
 BITMAP_MERGE_AREA_SIZE
 CREATE_BITMAP_AREA_SIZE
 HASH_AREA_SIZE
Oracle recomienda de forma encarecida usar estos parámetros y olvidarnos de los
antiguos, algo que deberíamos llevar a la práctica lo antes posible. He visto auténticos
milagros en mejoras de rendimiento, simplemente usando la gestión de memoria
automática.

Una vez dicho esto lo único que tenemos que saber es si el tamaño que tenemos
asignado es el que necesita nuestra BD, es decir si no la estamos sobredimensionando
o en cambio nos estamos quedando cortos.

Mejoras para el parámetro PGA_AGGREGATE_TARGET:

SQL> SELECT PGA_TARGET_FOR_ESTIMATE,PGA_TARGET_FACTOR,ESTD_EXTRA_BYTES_RW

FROM v$pga_target_advice;

PGA_TARGET_FOR_ESTIMATE PGA_TARGET_FACTOR ESTD_EXTRA_BYTES_RW

----------------------- ----------------- -------------------

22020096 ,125 75026432

44040192 ,25 75026432

88080384 ,5 71868416

132120576 ,75 9814016

176160768 1 0
211392512 1,2 0

246624256 1,4 0

281857024 1,6 0

317088768 1,8 0

352321536 2 0

528482304 3 0

704643072 4 0

1056964608 6 0

1409286144 8 0

El valor 1 en la columna PGA_TARGET_FACTOR indica el tamaño actual para el

parámetro PGA_AGGREGATE_TARGET=176160768 (en bytes). Lo que se ha de buscar
es el primer valor de la columna ESTD_EXTRA_BYTES_RW=0, esto indica que el PGA no
ha requerido espacio extra en ningún momento.

Si por ejemplo el primer 0 lo encontrásemos en el valor 1.4 de la columna

PGA_TARGET_FACTOR, indicaría que el parámetro PGA_AGGREGATE_TARGET debería
ser 246624256.

Una vez conocido el valor adecuado (siempre que tengamos recursos suficientes),
modificamos el valor con (para probar):

SQL> ALTER system SET PGA_AGGREGATE_TARGET=246624256 scope=memory;

Y para hacer el cambio definitivo (siempre y cuando estemos trabajando con spfile):

SQL> ALTER system SET PGA_AGGREGATE_TARGET=16777216 scope=spfile;

Mejora para el parámetro SGA_TARGET:

SELECT SGA_SIZE, SGA_SIZE_FACTOR, ESTD_DB_TIME FROM v$sga_target_advice ORDER BY
SGA_SIZE_FACTOR

SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME

---------- --------------- ------------

140 1 3527
175 1,25 3239

210 1,5 3080

245 1,75 2935

280 2 2893

El valor 1 en la columna SGA_SIZE_FACTOR indica el tamaño actual para el parámetro

SGA_TARGET=140 (en megas). Lo que se ha de buscar es el primer valor de la columna
ESTD_DB_TIME que no se reduzca más (o la diferencia es muy pequeña)

En el ejemplo podríamos tomar directamente el valor de SGA_SIZE=280, ya que se

aprecia reducción en ESTD_DB_TIME.

Una vez conocido el valor adecuado (siempre que tengamos recursos suficientes),
modificamos el valor con (para probar):

SQL> ALTER system SET SGA_TARGET=280M;

Y para hacer el cambio definitivo (siempre y cuando estemos trabajando con spfile):

SQL> ALTER system SET SGA_TARGET=280M scope=spfile;

Las reducciones del SGA_TARGET se pueden hacer dinámicamente, pero para las
ampliaciones seguramente nos encontremos que el parámetro SGA_MAX_SIZE no nos
permita crecer más, será necesario para la BD y realizar la modificación con la BD
parada.

Hasta aquí es aplicable a las versiones 10g y 11g de Oracle Database.

Oracle versión >=11g

En la versión 11g se ha añadido el parámetro MEMORY_TARGET que todavía simplifica

más la gestión de memoria de la instancia. Cuando fijamos este parámetro lo que
estamos haciendo es decirle a Oracle que redimensione SGA_TARGET y
PGA_AGGREGATE_TARGET a demanda de la aplicación (siempre y cuando no se
especifiquen de forma explícita). Es decir que podemos fijar 6Gb para
MEMORY_TARGET y nos olvidamos del resto de la gestión de memoria.
Detectar mejora para MEMORY_TARGET:
SQL> SELECT MEMORY_SIZE,MEMORY_SIZE_FACTOR,ESTD_DB_TIME FROM
v$memory_target_advice;

MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME

----------- ------------------ ------------

308 1 3563

385 1,25 3767

462 1,5 3538

539 1,75 3508

616 2 3508

El valor 1 en la columna MEMORY_SIZE_FACTOR indica el tamaño actual para el

parámetro MEMORY_TARGET=308 (en megas). Lo que se ha de buscar es el primer
valor de la columna ESTD_DB_TIME que no se reduzca más (o la diferencia es muy
pequeña)

En el ejemplo podríamos tomar el valor de MEMORY_SIZE=539, ya que con un valor

más alto no se aprecia reducción en ESTD_DB_TIME.

Una vez conocido el valor adecuado (siempre que tengamos recursos suficientes),
modificamos el valor con (para probar):

SQL> ALTER system SET MEMORY_TARGET=539M;

Y para hacer el cambio definitivo (siempre y cuando estemos trabajando con spfile):

SQL> ALTER system SET MEMORY_TARGET=539M scope=spfile;

Las reducciones del MEMORY_TARGET se pueden hacer dinámicamente, pero para las
ampliaciones seguramente nos encontremos que el parámetro
MEMORY_MAX_TARGET no nos permita crecer más, será necesario para la BD y
realizar la modificación con la BD parada.
¿Qué es un PGA de Oracle?

No toda la memoria RAM en Oracle es de memoria compartida. Cuando se inicia un

proceso de usuario, este proceso tiene un área privada de RAM, que se utiliza para
ordenar los resultados de SQL y la gestión se une especial llamado "hash" se une. Esta
RAM privada que se conoce como el Área de Programa Global (PGA). Cada individuo
área de PGA se asigna la memoria cada vez que un nuevo usuario se conecta a la base
de datos.

Oracle Database 10g se encargará de la PGA para usted si se establece el parámetro

pga_aggregate_target (vamos a discutir los parámetros y la forma en que se
establecen más adelante en este libro), pero usted puede asignar manualmente el
tamaño de la PGA a través de parámetros como sort_area_size y hash_area_size. Le
recomendamos que permitirá a Oracle para configurar estas zonas, y sólo configurar el
parámetro pga_aggregate_target. El PGA puede ser fundamental para el rendimiento,
especialmente si la aplicación está haciendo un gran número de clases. Operaciones de
ordenación producirse si utiliza ORDER BY y GROUP BY comandos en las instrucciones
SQL

¿Qué es un SGA de Oracle?

El SGA (System Global Area o también Shared Global Area) es la zona de memoria en la
que la BD Oracle guarda información sobre su estado. Esta estructura de memoria está
disponible para todos los procesos, por eso se dice que está compartida. Sirve para
facilitar la transferencia de información entre usuarios y también almacena la
información estructural de la BD más frecuentemente requerida.

Es una estructura básica de memoria de Oracle que sirve para facilitar la transferencia
de información entre usuarios. Almacena la mayor parte de la información sobre la
propia estructura de la base de datos que es consultada con más frecuencia. Actúa de
forma similar a la caché de un PC. Si un usuario realiza una consulta SQL contra la base
de datos y ésta ya ha sido ejecutada por otro usuario, tal vez se encuentre almacenada
en la SGA, si es así, Oracle devolverá el resultado de la consulta SQL al segundo usuario
que la ha solicitado bastante más rápida pues no tendrá que leer de los archivos de
datos.

Está Compuesto por:

 Diccionario Cache
 Los Redo Log Buffers
 Los Database Buffers

Lo mínimo que hay que saber para solucionar errores con la SGA de Oracle
Hay que tener en cuenta que la SGA es mucho más de lo que hay explicado aquí, pero
esto es una guía para solucionar problemas que pueden aparecer y entenderla de
manera más rápida

Definición:

SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que sirve
para facilitar la transferencia de información entre usuarios y también almacena la
información estructural de la BD más frecuentemente requerida.

El área global del sistema y un conjunto de procesos de la base de datos constituyen

una instancia de una base de datos Oracle. La base de datos Oracle automáticamente
reserva memoria para el área global del sistema cuando se inicia una instancia, y el
sistema operativo reclama la memoria cuando se apaga dicha instancia. Cada instancia
tiene su propia SGA.

¿Que contiene la SGA?

Memoria Oracle (SGA) Su tamaño está determinado por los parámetros:

• Shared_Pool_Size= Tamaño en bytes del área para SQL compartidos y sentencias
PL/SQL.
• Db_Block_Size = Tamaño en bytes de un solo bloque de datos.
• Db_Block_Buffers = Numero de Buffers a localizar en memoria.
• Log_Buffer = Numero de bytes localizados para los Redo Log Buffer.

Está Compuesto por:

• Los Redo Log Buffers
• Los Database Buffers
• Shared SQL Pool

Oracle descarga / libera la información contenida en la shared pool por cualquiera de

las siguientes razones:

• Si un objeto del esquema referenciado en una sentencia sql, es modificado

posteriormente en cualquier manera, el área del sql compartido es invalidado y la
sentencia tendrá que ser recompilada la próxima vez que se ejecute.

• Si se cambia el nombre global de la base de datos, toda la información en en la

shared pool es descargada.

• El administrador puede manualmente desalojar toda la información en esta área

compartida para evaluar el rendimiento con respecto a ésta área de memoria, que
sería esperada luego de que la instancia inicie sin apagar la instancia actual. La
sentencia ALTER SYSTEM FLUSH SHARED_POOL es usada para esto (versiones 10 o
posterior).

El total disponible de memoria en un sistema tiene que estar configurado de forma

que todos los componentes de ese sistema funcionen óptimamente. Una pauta a
seguir para que el sistema quede bien configurado podría ser el siguiente:

¿Qué tamaño dar a la SGA en un sistema nuevo o del que conocemos el número de
usuarios, procesos, etc…?

Oracle SGA Componentes –> 50% del total de la memoria del sistema.
Sistema operativo + Otros –> + o – 15% del total de la memoria del sistema.
Memoria de usuario –> + o – 35% del total de la memoria del sistema.

Esta es la primera pauta que podemos seguir a la hora de reservar o ver la memoria
que se necesita o que se puede poner cómo máximo en un sistema para que Oracle
funcione correctamente y los demás componentes del sistema puedan hacerlo
también. (Habría que tener en cuenta también el número de usuarios que accederán
concurrentemente al sistema).

Una vez que hemos decidido que la SGA de nuestra base de datos ORACLE va a ser el
50% de la memoria total del sistema. Esta memoria la tenemos que dividir entre los
componentes que la forman. (Database buffer cache, shared_pool_area, fixed size,
redo log buffer).

Componentes de la SGA (Memoria SGA)

Database Buffer Cache ~80% de la SGA

Shared Pool Area ~12% de la SGA
Fixed Size ~1% de la SGA
Redo Log Buffer ~0.1% de la SGA

Seguidamente se muestran una serie de consultas básicas que nos darán la

información que necesitamos para saber cómo está la SGA.

• La siguiente consulta nos da información de la Shared Pool indicando el espacio

ocupado/libre tanto en bytes como en megabytes.

select * from ( select POOL, NAME, BYTES, BYTES/1048576 as MBytes from v$sgastat
where pool=’shared pool’ order by BYTES desc ) where rownum <= 25;

El campo “free memory” es el que indica el espacio libre en esos momentos. Para sacar
exactamente TOTALES de espacio de la SGA ocupado y libre, ejecutaremos la siguiente
sentencia:

select name,to_number(value/1024/1024) Mbytesfrom v$parameter where name

=’shared_pool_size’ union all select name,bytes/1024/1024 from v$sgastat where
pool = ‘shared pool’ and name = ‘free memory’;

Esto nos devolverá en MB el espacio total ocupado y libre de la SGA. Podemos

comprobar que nos devuelve el resultado correcto mirando directamente en los
parámetros generales de Oracle de la siguiente manera:

select * from v$system_parameterwhere name like ‘%shared%’;

Nos dará el valor en bytes una descripción de los parámetros de Oracle.

Un error típico que suele dar relacionado con la SGA es el ORA-04031

Este error es fácil de solucionar siempre y cuando se tenga claro que es debido a que
falta espacio en la SGA, bien porque se ha quedado pequeña, se definió mal desde un
principio o porque está muy fragmentada.

Existe un comando que libera la SGA sin tener que parar la BBDD a partir de la versión
10 de Oracle. Este comando es el siguiente:

SVRMGRL> alter system flush shared_pool;

Ejemplo:

Connected to: Oracle8i Enterprise Edition Release 8.1.7.4.0 – Production

JServer Release 8.1.7.4.0 – Production
SQL> select count(*) from v$sqlarea;

COUNT(*)
———-
828

SQL> alter system flush shared_pool;

System altered.

SQL> select count(*) from v$sqlarea;

COUNT(*)
———-
18
También desde la version 10 de Oracle podemos modificar el tamaño en caliente. Se
haría de la siguiente manera:

SVRMGRL> alter system set shared_pool_size = 400M; SVRMGRL> alter system set
shared_pool_reserved_size = <15% de la shared_pool_size>;

Se ha de tener en cuenta que a partir de las versión 10 de Oracle si se tiene el

parámetro SGA_TARGET activado, será Oracle quien automáticamente gestione la
memória de la SGA. Por tanto, la modificación de los parámetros shared_pool_XXXX no
tendrán efecto.

Manipulación de los parámetros del SGA

Existen tres tipos de parámetros en Oracle:

- Parámetros “fijos”=> Son parámetros que una vez instalada la base de datos no se
pueden volver a modificar / configurar. El juego de caracteres es un claro ejemplo.

- Parámetros Estáticos => Son parámetros que se pueden modificar, pero su

modificación implica cerrar la base de datos y volverla a abrir para que los lea del
fichero y pueda realizar el cambio.

- Parámetros Dinámicos=> Son parámetros cuyo valor se puede cambiar sin necesidad
de cerrar la base de datos a diferencia de los estáticos.

Podemos asignar valores a los parámetros de la siguiente manera:

SQL> ALTER SYSTEM SET <parámetro> = <valor> [SCOPE = <ámbito>]

El valor del ámbito puede ser uno de los siguientes.

• spfile –> Fichero de parámetros

• memory –> En memória (en caliente)

• both –> En memória y en el fichero de parámetros spfile.

Ejemplo:

El ejemplo anterior sólo funciona a partir de la versión 9.

Para ver el valor actual de un parámetro.

SQL> show parameter <parámetro>

Existe una manera sencilla de verificar que parámetros son dinámicos y cuales son
estáticos.

La vista V$PARAMETER nos proporciona este tipo de información.

La columna ISSYS_MODIFIABLE contiene tres (3) tipos de valores:

• Immediate
• Deferred
• False

Por ejemplo:

SQL> select distinct ISSYS_MODIFIABLE from V$PARAMETER;

ISSYS_MODIFIABLE
—————————
IMMEDIATE
DEFERRED
FALSE

IMMEDIATE: identifica aquellos parámetros dinámicos, es decir, los ajustes se realizan

de manera inmediata.

DEFERRED: los ajustes pueden ser realizados en “caliente” pero tomarán efecto solo
después de que la base de datos sea re-inicializada.

FALSE: obligatoriamente la base de datos debe bajarse para poder efectuar el cambio.
La siguiente sentencia nos permite conocer lo anterior mencionado:

Col NAME format a50 Col ISSYS_MODIFIABLE format a20

Select NAME, ISSYS_MODIFIABLE From V$PARAMETER Order by 1

Para mostrar el estado actual del SGA.

SQL> show sga

Parámetros de memoria SGA

1. Objetivo
Este documento pretende realizar una comparación entre estos dos parámetros de
ORACLE. (Disponibles los dos en Oracle 10g)

2. Referencia de estos parámetros:

sga_max_size:
Especifica el máximo tamaño de SGA que puede tener la instancia mientras esté
levantada. (Disponible a partir de la versión 9)
Tipo de
Entero (big integer)
parámetro

Sintaxis SGA_MAX_SIZE = entero [K | M | G]

Inicial tamaño para la SGA al levantar la instancia de base de datos,

Valor por
este valor depende de las diferentes “pools” de la SGA como el
defecto
buffer cache, la shared pool, large pool

Tipo de
Estático
parámetro

Rango de
Mínimo : 0
valores
 Máximo: depende del sistema operativo

sga_target:
Especifica el tamaño total para todos los componentes de la SGA. De esta forma las
siguientes áreas de memoria se configuran automáticamente. (Disponible a partir de la
versión 10).

 Buffer cache ( DB_CACHE_SIZE )

 Shared pool ( SHARED_POOL_SIZE )
 Large pool ( LARGE_POOL_SIZE )
 Java pool ( JAVA_POOL_SIZE )

Tipo de parámetro Entero (big integer)

Sintaxis SGA_Target = entero[K | M | G]

El valor por defecto es 0 (este parámetro está

Valor por defecto
deshabilitado)

Tipo de parámetro Modificable (ALTER SYSTEM )

Mínimo: 64
Rango de valores
Máximo: depende del sistema operativo

3. Diferencias entre estos parámetros

Ambos parámetros existen en la versión 10g. Su significado es diferente.
sga_max_size: Establece el máximo tamaño que puede alojar la SGA cuando se levanta
la instancia de base de datos. Este parámetro permitirá aumentar el tamaño de la SGA
sin necesidad de iniciar la instancia, teniendo en cuenta que el total de la SGA no
exceda este parámetro.
sga_target: Especifica el total de tamaño que dispondrá la SGA cuando la instancia se
inicia. Si utilizamos este parámetro no tendremos necesidad de definir los valores para
db_cache_size, shared_pool_size, large_pool_size, java_pool_size puesto que oracle
automáticamente ajusta estos componentes incluyendo stream_pool_size.
Normalmente sga_max_size y sga_target tendrán el mismo valor, pero habrá veces
cuando se quiera ajustar para el máximo número de cargas y en éste caso podrá ser
diferente. En este caso sga_max_size será mayor que sga_target, de este modo podrás
alojar dinámicamente el ajuste del parámetro sga_target.