PGA de Oracle

Las siglas provienen de Program/Private Global Area, y es la memoria privada de cada proceso servidor. En esta memoria cada proceso almacena información que sólo es necesaria para su propio funcionamiento como por ejemplo sus variables globales, el estado actual de cada cursor (SQL) que se ejecuta... etc.

La PGA se compone de:

• Área SQL privada: cada SQL que se ejecuta necesita de este espacio para poder llevar el control de las operaciones propias de la sentencia. Se asigna cuando se abre el cursor y se libera completamente cuando se cierra. Esta parte de memoria se subdivide en dos: a) area persistente: perdura durante toda la vida del cursor. Guarda las bind variables además de otras cosas; b) area en tiempo de ejecución: se libera cuando finaliza la ejecución de la sentencia SQL (aunque no se haya cerrado el cursor ). Constituyen las áreas de trabajo (working areas) que se explican más adelante. El número máximo de cursores, y por tanto, el número máximo de áreas SQL privadas, que un usuario puede tener abiertos al mismo tiempo se controla con el parámetro OPEN_CURSORS. También hay que tener en cuenta que esta área SQL privada se almacena en la PGA si la Instancia está configurada como servidores dedicados (dedicated servers). En caso de servidors compartidos (shared servers) se almacena en la SGA.

• Memoria de las sesiones: guarda información relativa a la sesión como el login, variables de sesión... etc. En servidores compartidos (shared servers) este área pasa a ser pública ya que diferentes usuarios comparten los mismos procesos servidores.

¿Qué son las áreas de trabajo (working areas)?
Las área de trabajo (working areas) son el espacio usado por el proceso servidor para realizar ordenaciones y clasificaciones como los ORDER BY, GROUP BY o HASH JOIN. Esta área es la de mayor tamaño y forma parte del área en tiempo de ejecución.

Su tamaño es determinante para obtener buenos tiempos de respuesta en operaciones de este tipo, ya que si el espacio se queda pequeño para realizar estas tareas es necesario liberar espacio usando el tablespace temporal del usuario. Ésta actividad de swapping afecta drásticamente al rendimiento y recibe el nombre de "extra pass".

¿Dónde se almacena la PGA?
La PGA se almacena en la memoria del servidor pero fuera de la SGA. Por tanto, para dimensionar ambas áreas hay que tener en cuenta que la suma de las dos no supere los límites específicos del servidor y la plataforma (tamaño máximo memoria RAM, 2 GB en Windows sin /3GB, 3 GB en Windows con /3GB... etc.).¿El tamaño de la PGA es configurable?
Sí, pero únicamente es configurable el tamaño de las áreas de trabajo. Desde Oracle9i el DBA puede fijar el tamaño máximo del cónjunto de todas las PGAs de la Instancia a través del parámetro PGA_AGGREGATE_TARGET. De esta forma, Oracle dinámicamente gestiona el tamaño de cada área de trabajo para que la suma de todas las PGAs (no de todas las áreas, que es un parte de la PGA como ya se ha indicado) no exceda del límite impuesto. En versiones anteriores la forma de controlar el tamaño de cada área de trabajo era a través de los parámetros SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE y CREATE_BITMAP_AREA_SIZE.

Para que la Instancia tenga el cuenta el parámetro PGA_AGGREGATE_TARGET, el parámetro WORKAREA_SIZE_POLICY se debe asignar a AUTO (por omisión). Con MANUAL, se indica que se trabaja de la forma anterior y se fija cada parámetro *_AREA_SIZE por separado.

¿Cuándo se crea la PGA?
La crea el Listener durante la creación del proceso servidor. Si esta memoria no puede ser asignada o reservada la creación del proceso servidor falla y el Listener devuelve un ORA-12500: TNS:listener failed to start a dedicated server process. Igualmente, si durante la ejecución de alguna sentencia es necesario incrementar el tamaño de la PGA y el sistema operativo no tiene más memoria para darle se devuelve un error indicándolo.

¿Cuándo se destruye la PGA?
Al cerrar el proceso servidor su PGA asociada se libera y se devuelve al sistema operativo el espacio reservado. El proceso servidor se cierra cuando el usuario ejecuta EXIT o DISCONNECT, lanza un Ctrl+C, se pierde la comunicación con el servidor, se produce un ORA-600 que desconecta la sesión, el DBA lanza un KILL SESSION, etc.

¿Cuánto ocupa cada PGA?
En cada versión de Oracle, e incluso en cada release, el tamaño mínimo cambia. No obstante, como el tamaño es cambiante en función del área de trabajo, lo mejor que se puede hacer para comprobar cuánto ocupa o cómo ocupa es monitorizarlas.

¿Cómo se monitoriza la PGA?
Hay diferentes vistas para saber cuánto ocupa cada PGA individual o para saber cuánto ocupan todas las PGAs o incluso para saber si está bien configurado el parámetro PGA_AGGREGGATE_TARGET.

Con V$PROCESS se puede saber el tamaño de la PGA de cada proceso de la Instancia (el proceso puede ser background o foreground -también llamado shadow-). Si es un proceso background se sabé rápidamente qué proceso es porque lleva el nombre del proceso en la columna PROGRAM. Si es un proceso shadow se sabe el usuario que hay detrás cruzando las columnas ADDR.V$PROCESS con PADDR.V$SESSION. Veamos un ejemplo:

SQL> select sid, serial#, username, command, status, machine from v$session where paddr='BE103FA4';

SID SERIAL# USERNAME COMMAND STATUS MACHINE
---- ---------- -------- ------- -------- -------
1386 9 TEST_USR 0 INACTIVE SATURNO

Para obtener unas estadísticas de la PGA se puede usar la vista V$PGASTAT:

SQL> select * from v$pgastat;

NAME VALUE UNIT
---------------------------------------- ---------- -------
aggregate PGA target parameter 256901120 bytes
aggregate PGA auto target 58300416 bytes
global memory bound 51380224 bytes
total PGA inuse 192188416 bytes
total PGA allocated 283714560 bytes
maximum PGA allocated 548391936 bytes
total freeable PGA memory 0 bytes
process count 343
max processes count 404
PGA memory freed back to OS 0 bytes
total PGA used for auto workareas 0 bytes
maximum PGA used for auto workareas 78736384 bytes
total PGA used for manual workareas 0 bytes
maximum PGA used for manual workareas 530432 bytes
over allocation count 15599
bytes processed 8,1983E+11 bytes
extra bytes read/written 1,4539E+10 bytes
cache hit percentage 98,25 percent
recompute count (total) 208640

Aggregate PGA target parameter indica el valor del parámetro PGA_AGGREGGATE_TARGET.
Aggregate PGA auto target indica la cantidad de PGA que Oracle puede usar como áreas de trabajo. Este valor varía en función de la carga de trabajo. Total PGA allocated indica el valor total de PGA asignado. Este es el valor que Oracle intenta mantener por debajo de PGA_AGGREGGATE_TARGET. Este valor puede ser más alto que el indicado por el parámetro de inicialización en momentos puntuales de mucha carga o de forma constante si PGA_AGGREGGATE_TARGET está pobremente dimensionado. Over allocation count indica el número de veces que ha habido que sobrepasar el límite impuesto por PGA_AGGREGGATE_TARGET, lo que es síntoma de que hay que aumentar el parámetro.
Cache hit percentage indica el número de veces que se ha podido realizar una operación intensiva de ordenación/clasificación sin incurrir en un "extra pass". Si este valor no es cercano al 100% indica que hay que aumentar el parámetro PGA_AGGREGGATE_TARGET.

La vista V$PGA_TARGET_ADVICE es muy útil para predecir cómo cambiaría el comportamiento de la Instancia si modificamos le valor de PGA_AGGREGATE_TARGET. Para que esta vista recopile información el parámetro STATISTICS_LEVEL debe estar configurado a TYPICAL o ALL:

SQL> select pga_target_for_estimate, pga_target_factor,
estd_pga_cache_hit_percentage, estd_overalloc_count
from v$pga_target_advice;

PGA_TGT_FE PGA_TGT_F ESTD_HIT_PCTGE ESTD_OVRALL_COUNT
---------- --------- -------------- -----------------
32112640   ,125      67             67303
64225280   ,25       67             67303
128450560  ,5        67             66960
192675840  ,75       74             40785
256901120  1         97             4652
308281344  1,2       98             73
359661568  1,4       98             0
411041792  1,6       98             0

462422016  1,8       98             0

513802240  2         98             0

770703360  3         98             0

1027604480 4         100            0

1541406720 6         100            0

2055208960 8         100            0

La columna pga_target_for_estimated indica la estimación para las que las demás columnas están dando información. La columna pga_target_factor indica la relación entre el valor de PGA_AGGREGGATE_TARGET actual y el valor de estimación de esa fila. Cuando este factor está a 1 indica la relación 1 a 1 -el tamaño actual-. Si es 2, es 1 a 2 -el doble-, y si es 0,125 es 1 a 0,125 -una octava parte-. La columna estd_pga_cache_hit_percentage indica el porcentage de éxito, operación resueltas sin "extra pass" para ese pga_target_for_estimated. Por último, la columna estd_overalloc_count indica el número de veces que habría que sobrepasar el valor indicado por PGA_AGGREGGATE_TARGET para ese pga_target_for_estimated.

Para este caso el valor óptimo sería subir el valor del parámetro 1,4 veces porque nos da una estimación de 0 "extra passes". Seguir aumentándolo no aportaría ninguna mejora. Si estamos justos de memoria y 73 "extra passes" son asumbles se puede empezar aumentándolo 1,2 veces en vez 1,4 y después de un tiempo de trabajo volver a chequear los valores.

Por último decir que las vistas V$PGASTAT y V$PGA_TARGET_ADVICE guardan información de la Instancia en tiempo real. Cuando se reinicia la Instancia estas vistas empiezan a recopilar datos nuevos. Para ver el histórica entre reinicios están las vistas DBA_HIST_PGASTAT y DBA_HIST_PGA_TARGET_ADVICE respectivamente.

Espero de sirva de ayuda,

Saludos.
CCZ

SGA de Oracle:

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.
La SGA se divide en varias partes:
Buffers de BD, Database Buffer Cache

Es el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora.
Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.

Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registrosredo log en los ficheros redo log.
El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool

En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

• Plan de ejecución de la sentencia SQL.
• Texto de la sentencia.
• Lista de objetos referenciados.
Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:

• Comprobar si la sentencia se encuentra en el área compartida.
• Comprobar si los objetos referenciados son los mismos.
• Comprobar si el usuario tiene acceso a los objetos referenciados.
Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan en la zona de SQL compartida.
También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.
Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

Espero sirva de ayuda,

Saludos.

CCZ

Administrador de Base de Datos

Los roles que deben cumplir los administradores de Base de Datos o (DBA):

Recuperabilidad

Esto significa que, si ocurre algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. El DBA debe definir y poner en practica un plan de recuperación adecuado que incluya, por ejemplo una descarga o "vaciado" periódico de la base de datos en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a partir de vaciado más reciente cuando sea necesario. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA's.

Integridad

La integridad de una base de datos significa que, la base de datos ó los programas que generaron su contenido, incorporen métodos que aseguren que el contenido de los datos del sistema no se rompan así como las reglas del negocio. Por ejemplo, un distribuidor puede tener una regla la cual permita que solo los clientes individuales puedan solicitar órdenes; a su vez cada orden identifique a uno y solo un proveedor.

Seguridad

La seguridad se encarga de limitar a los usuarios a ejecutar únicamente las operaciones permitidas. Al igual que otros metadatos, una DBMS relacional maneja la seguridad en forma de tablas. Estas tablas son las "llaves del reino" por lo cual se deben proteger de posibles intrusos.extraños

Disponibilidad

El DBA debe mantener la disponibilidad, esto significa que los usuarios tengan acceso a los datos cuando lo necesiten para atender a las necesidades del negocio.

Desempeño

Esto significa que la base de datos no cause tiempos de respuesta poco razonables. En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es solo uno de los elementos que determinan la experiencia de los usuarios en línea y los programas desatendidos. El desempeñoes una de las mayores motivaciones de los DBA para coordinarse con los especialistas de otras áreas del sistema fuera de las líneas burocráticas tradicionales.

Desarrollo y Soporte a Pruebas

Las actividades de soporte incluyen la colecta de datos de producción para llevar a cabo pruebas con ellos; consultar a los programadores respecto al desempeño; y hacer cambios a los diseños de tablas de manera que se puedan proporcionar nuevos tipos de almacenamientos para las funciones de los programas.

Administrar el sistema manejador de base de datos

La concurrencia de múltiples usuarios requiere la estandarización de los procesos de operación; el DBA es responsable de éstas especificaciones y de asegurarse que estas lleguen a quienes concierne. Todo el ámbito de la base de datos se rige por estándares, desde la forma de como se captura la información (tipo de dato, longitud, formato), como es procesada y presentada. El nivel de estandarización alcanza hasta los aspectos más internos de la base de datos; como sé accesa a un archivo, como se determinan los índices primarios y auxiliares, registros, etc.

El DBA debe procurar siempre que los estándares que serán aplicados beneficien también a los usuarios, privilegiando siempre la optimización en la operación del DBMS y el apego de las políticas de la empresa. Entre las funciones del DBA se encuentra la de revisar los estándares periódicamente para determinar su operatividad, ajustarlos, ampliarlos o cancelarlos y hacer que éstos se cumplan.

Establecer el diccionario de datos

Cuando se definen estándares sobre la estructura de la base de datos, se deben de registrarse en una sección del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de proceso pueden acceder. Este metadato debe precisar información que nos indique con claridad el tipo de datos que serán utilizados, sus ámbitos de influencia y sus limitantes de seguridad.

Asegurar la confiabilidad de la base de datos

Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas necesarias para la reparación de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz.

Espero sirva de ayuda,
Saludos.

CCZ