Áreas Globales de Programas PGA (Program Global Areas)
Un área global de programa (PGA) es una región de memoria que contiene datos e información de control para los procesos de servidores. Es una memoria no compartida creada por Oracle cuando un proceso de un servidor es iniciado. Solo el servidor del proceso puede acceder a él y se lee y escribe solamente por un código de Oracle que actúa en nombre del proceso.
Contenido de un PGA
El contenido de la memoria de un PGA varía dependiendo de dónde se está ejecutando la instancia y de si el tipo de servidor es compartido. Pero generalmente la memoria del PGA puede ser clasificada de la siguiente forma:
Memoria de Sesión: La memoria de sesión (Session Memory) se asigna para mantener las variables de una sesión (logon information) y otra información relativa a la sesión. Para un servidor compartido, la memoria de sesión es compartida y no privada.
Área SQL Privada: Un área SQL privada contiene datos como por ejemplo consultas de información de ejecuciones y consultas de ejecuciones en áreas de trabajo. Cada sesión que establece una sentencia tiene un área privada de SQL. Cada usuario que emite la misma sentencia tiene su propia área SQL privada que usa un área SQL compartida. Aunque, muchas áreas SQL privadas pueden ser asociadas con la misma área SQL compartida. La ubicación de un área privada SQL depende del tipo de conexión establecida para una sesión. Si una sesión se conecta a través de un servidor dedicado, las áreas privadas SQL esta localizadas en el servidor del proceso del PGA. De cualquier forma, si una sesión se conecta a través de un servidor compartido, parte del área privada SQL se mantiene en el SGA.
Cursores y Áreas SQL
La aplicación de desarrollo de un programa precompilador Oracle o un programa OCI puede explícitamente abrir cursores, o manejar algún área privada SQL específica, y usarla como un recurso nombrado a través de la ejecución de un programa. Los cursores recursivos de Oracle que emiten implícitamente algunas sentencias SQL también usan áreas SQL. La administración de las áreas SQL privadas son responsabilidad de los procesos del usuario. La asignación y liberación de las áreas SQL privadas dependen de en qué herramienta de la aplicación se usan, aunque el número de áreas SQL privadas que un proceso de usuario puede asignar está siempre limitado el parámetro OPEN_CURSORS. El valor por defecto de este parámetro es 50.
Un área SQL privada continua existiendo hasta que el correspondiente cursor es cerrado o la sentencia es liberada. Aunque Oracle libera el área de ejecución después de que la sentencia se complete, el área persistente se mantiene en espera. Las aplicaciones de desarrollo cierran todos los cursores abiertos que no van a ser usados otra vez para liberar el área persistente y minimizar la cantidad de memoria requerida por el usuario de la aplicación.
Componentes del Área SQL Privada
El área SQL privada de un cursor se divide en 2 áreas cuya duración son diferentes:
El área persistente (Persistent Area), que contiene, por ejemplo, información envuelta. Es liberada solamente cuando el cursor es cerrado.
El área de ejecución (Run-time Area), que es liberada cuando la ejecución, valga la redundancia, es terminada.
Oracle crea el área de ejecución en el primer paso que una ejecución es pedida. Para una sentencia INSERT, UPDATE y DELETE Oracle libera el área de ejecución después de que la sentencia ha sido ejecutada. Para las consultas, Oracle libera el área de ejecución solamente cuando todas las filas han sido recorridas, o la consulta ha sido cancelada.
Áreas de Trabajo SQL
Para las consultas complejas, una gran porción del área de ejecución es dedicada a áreas de trabajo asignadas por operadores de memoria-intensiva como los siguientes:
Operadores de base de clasificación “Sort-based” (order by, group by, rollup)
Hash-join
Bitmap merge
Bitmap create
Por ejemplo, un operador de clasificación (sort operator) usa un área de trabajo (algunas veces llamado área de clasificación “sort area”) para la forma de distribución de la memoria interna (in-memory) de una serie de filas. Similarmente, un operador hash-join usa un área de trabajo (también llamada área hash) para construir una tabla hash desde su entrada izquierda. Si la cantidad de datos que deben ser procesados por estos dos operadores no entran en el área de trabajo, entonces los datos de entrada son divididos en piezas más pequeñas. Esto permite que alguna de las piezas se procesen en la memoria mientras el resto son distribuidos en un disco temporal para ser procesado luego. Aunque los operadores de bitmap no se distribuyen por el disco cuando su área de trabajo es muy pequeña, su complejidad es inversamente proporcional al tamaño de su área de trabajo. Estos operadores se ejecutan más rápido en áreas de trabajo más grandes.
El tamaño del área de trabajo puede ser controlado y modificado. Generalmente, áreas de bases de datos grandes pueden mejorar significativamente el rendimiento de un operador respecto al coste de consumo de memoria. Opcionalmente, el tamaño de un área de trabajo puede ser lo bastante grande como para almacenar los datos de entradas y las estructuras auxiliares de memoria asignadas por el operador SQL asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de entrada deben ser distribuidos por un disco de almacenamiento temporal. En caso extremo, si el tamaño del área de trabajo es muy pequeño comparado con el tamaño del dato de entrada, múltiples procesos se ejecutan sobre la parte de los datos. Esto puede aumentar el tiempo de respuesta de un operador considerablemente.
Administración de la Memoria del PGA para un Modo Dedicado
Se puede administrar el tamaño de las áreas de trabajo SQL globalmente y automáticamente. El administrador de la base de datos simplemente necesita que sea especificado el tamaño total dedicado a la memoria del PGA para las instancias de configurando el parámetro PGA_AGGREGATE_TARGET. El número especificado (por ejemplo 2G) es un objetivo global para la instancia, y se trata de asegurar que la cantidad total de memoria del PGA asignada por toda la base de datos de los procesos del servidor nunca exceda esa meta. Con PGA_AGGREGATE_TARGET, modificar el tamaño de las áreas de trabajo para todas las sesiones dedicadas es automático, y todos los parámetros *_AREA_SIZE se ignoran en estas sesiones.
Área de Ordenaciones (Sort Areas)
Las áreas de ordenaciones (Sort Areas) de Oracle son las zonas de memoria en las que se ordenan los datos, es decir el espacio en memoria que necesita la organización y ordenación de las filas. El tamaño por defecto, expresado en bytes, es específico de cada SO. Sin embargo, hay muchas razones importantes por las que este tamaño influye en el rendimiento. En el manual de Oracle 10i encontramos cuatro de ellas:
Aumentar el SORT_AREA_SIZE mejora la eficiencia de ordenaciones grandes.
Cada ordenación en una consulta puede consumir la cantidad de memoria especificada en el SORT_AREA_SIZE, y pueden haber múltiples ordenaciones en una consulta. De esta forma, si otra consulta se ejecuta en paralelo, cada ordenación puede consumir la memoria especificada en este campo.
EL SORT_AREA_SIZE también se utiliza para selecciones y actualizaciones en los índices de las tablas. Seleccionar un valor apropiado aquí, puede dar como resultado que la tabla se actualice una única vez en cada operación DML, pudiendo incluso haber cambiado varias filas a la vez.
Grandes valores en este campo nos permitirán realizar mayores búsquedas en memoria. Si se necesitase más espacio para la ordenación del que tenemos, los datos se dividirán en trozos y se utilizarán segmentos de disco temporales como apoyo en la ordenación.
En éste último caso, en el que los datos a ordenar no quepan en el área de ordenaciones, se dividen en trozos que sí quepan, se ordenan y se mezclan (merge). A esto hace referencia también el manual de Oracle9i, que si bien lo hace en trozos separados, a continuación se muestran las dos referencias juntas:
Para un mejor rendimiento del SGBD, la mayoría de las ordenaciones deberían tener lugar únicamente en memoria ya que en caso de tener que escribir a disco, obtendremos un claro efecto adverso sobre éste. Si las aplicaciones que acceden a la base de datos suelen realizar búsquedas que no caben en el área de ordenaciones, o incluso si las aplicaciones realizan demasiadas búsquedas innecesarias, entonces sería conveniente modificar el parámetro de SORT_AREA SIZE.
EL SORT_AREA_SIZE es un parámetro que se puede inicializar y modificar dinámicamente y que especifica la cantidad de memoria que se tiene disponible al realizar las ordenaciones. Si una cantidad importante de ordenaciones requiere acceso a disco para almacenar segmentos temporales, entonces la aplicación se verá claramente beneficiada al ampliar el SORT_AREA_SIZE. De forma alternativa, en un entorno DSS, aumentar este parámetro no tiene por qué hacer que la ordenación se realice únicamente en memoria, pero sí es cierto que dependiendo del valor actual y del nuevo elegido, se puede aumentar drásticamente la velocidad de la ordenación.
Por lo tanto, como conclusión, alterar este parámetro, se puede considerar como un paso importante para asegurarnos el rendimiento en ciertas circunstancias y situaciones. Sin embargo, determinar qué valor es el más apropiado, es por supuesto, la parte más complicada.
Memoria Virtual en Oracle
Oracle puede utilizar la memoria virtual proporcionada por el SO para simular memoria a base de algún dispositivo de almacenamiento como el disco duro. La memoria virtual está mapeada en la RAM. Cuando no hay suficiente memoria con ésta para ejecutar los programas (en caso de Oracle las sentencias, búsquedas, etc) se necesita un espacio auxiliar que normalmente suele ser el disco duro. Para el traspaso de información se utilizan dos técnicas principales: el Paging o paginación y el Swapping.
Paginación
La paginación consiste en dividir los programas en pequeños bloques o páginas, de manera que sea más fácil moverlos de memoria a disco y viceversa. De la misma forma, la memoria se divide en marcos de página. De esta forma, la cantidad de memoria desperdiciada por un proceso es el final de su última página, minimizando así la fragmentación interna y evitando la externa. En un momento cualquiera, la memoria se encuentra ocupada con páginas de diferentes procesos, mientras que algunos marcos están disponibles para su uso. El sistema operativo mantiene una lista de estos últimos marcos, y una tabla por cada proceso, donde consta en qué marco se encuentra cada página del proceso. De esta forma, las páginas de un proceso pueden no estar contiguamente ubicadas en memoria, y pueden intercalarse con las páginas de otros procesos.
En la tabla de páginas de un proceso, se encuentra la ubicación del marco que contiene a cada una de sus páginas. Las direcciones lógicas ahora se forman como un número de página y de un desplazamiento dentro de esa página (conocido comúnmente como offset). El número de página es usado como un índice dentro de la tabla de páginas, y una vez obtenida la dirección del marco de memoria, se utiliza el desplazamiento para componer la dirección real o dirección física. Este proceso se realiza en una parte del ordenador específicamente diseñada para esta tarea, es decir, es un proceso hardware y no software.
De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus páginas en marcos libres y se completa su tabla de páginas.
Swapping
El Swapping es el procedimiento de mover los bloques de memoria en los que están algunos procesos que no se están utilizando, desde la memoria principal a un espacio Swap dejando así hueco libre para poder cargar en memoria otros procesos que sí se van a utilizar. El espacio Swap o espacio de intercambio es una zona de disco (un fichero o una partición) que se usa para guardar las imágenes de los procesos que no han de mantenerse en memoria física.
Este procedimiento es muy similar a la paginación, con la diferencia principal de que el directorio Swap funciona exactamente igual que la memoria RAM, por lo que puede almacenar datos privados, contraseñas y todo lo que almacena ésta. Sin embargo, en la paginación, únicamente se sacan de memoria páginas pertenecientes a procesos que no se estén utilizando, además de que se pueden sacar solo algunas páginas de los procesos y no éstos enteros como se hace en el Swapping. Con respecto al tamaño que debe tener el directorio Swap, hay muchas discusiones sobre ello como por ejemplo la antigua creencia de “El Swap debe tener el doble de tamaño que la RAM.” cosa que no es válida hoy día debido a la gran capacidad de la memoria RAM de la mayoría de ordenadores.
Como conclusión, hay que destacar que el uso de la memoria virtual por parte de Oracle, va a influir bastante en el rendimiento, disminuyéndolo drásticamente en comparación con el uso únicamente de la memoria RAM.
Área de Código de Software (Sca)
El área de código de software son zonas de memoria destinadas a almacenar el código de Oracle en ejecución o que puede ejecutarse. Este código de Oracle se almacena en una zona distinta, y más protegida, que las zonas dedicadas a almacenar los códigos de programas de usuarios. La SCA suele ser de tamaño estático, cambiando únicamente cuando el software se reinstala o actualiza. El tamaño requerido para este área puede variar en función del SO. Son áreas de sólo lectura y pueden ser instalas de forma compartida o no compartida. Cuando es posible, el código de Oracle se comparte, por lo que todos los usuarios pueden acceder a él sin tener múltiples copias en memoria. El resultado es un ahorro considerable de memoria y una mejora del rendimiento general.
Por otra parte, los programas de usuario también pueden ser compartidos o no. Algunas utilidades y herramientas de Oracle (como ocurre con Oracle Forms y SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Múltiples instancias de Oracle pueden usar la misma SCA con diferentes bases de datos si están corriendo en la misma máquina. Hay que tener en cuenta que la opción de instalar software compartido puede no estar disponible en función del sistema operativo, como ocurre por ejemplo en máquinas con Windows.
Estructura de los Procesos
Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos módulos de código diferentes, que además el encargado de gestionar estos procesos es el sistema operativo, estos dos módulos diferentes son:
Aplicación o Herramienta Oracle: normalmente son programas clientes que se conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus, SQL developer
Código del Servidor de Oracle: son los diferentes procesos que se han de ejecutar en el servidor para atender las peticiones del usuario.
La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos está corriendo en un mismo proceso, si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a múltiples usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al máximo al ordenador, por ejemplo si tiene ocho núcleos el servidor, y resulta que una petición se puede paralelizar se ejecutara esa petición por partes en cada núcleo.
De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos:
1.- Procesos de Usuarios: Cada vez que un usuario ejecuta una aplicación, ya sea propia o de Oracle se crea un proceso, que puede ser de dos tipos.
Conexión: Que es la vía de comunicación entre la aplicación y la instancia de la base de datos a la que se ha conectado.
Sesión: Es la conexión específica con la base de datos proporcionando un usuario y su contraseña.
Esto permite que desde un mismo equipo se puedan conectar varios usuarios simultáneamente, y que un usuario se pueda conectar desde diferentes equipos simultáneamente.
2.- Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control sobre ellos, pueden ser de dos tipos:
Procesos de Servidor: Se crea cuando una aplicación intenta acceder a la base de datos, para atender a las peticiones de la aplicación y devolver los resultados que se precisen.
Procesos de Background: Se crean cuando se inicia una instancia de la base de datos, solo hay un proceso de cada tipo de los que especificaremos a continuación, y no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores de mantenimiento, y para guardar la integridad de la base de datos.
Los diferentes tipos de procesos son los siguientes:
Database Writer Process (DBWn)
El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso DBWn es responsable por la escritura de los buffers modificados del buffer cache al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes condiciones:
Cuando un proceso no puede encontrar un buffer limpio reusable después de haber recorrido un número de determinado de buffers en el buffer caché, éste envía una señal al DBWn para la escritura. El DBWn escribe los buffers sucios al disco. El DBWn periódicamente escribe los buffers cuando se lleva a cabo un checkpoint. Chekpoint es una posición en el hilo de redo (log) donde se iniciará luego la recuperación. La posición en el log está determinada por el último buffer sucio en el buffer caché.
Log Writer Process (LGWR)
El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los registros de redo que han sido copiados en el buffer desde la última vez que éste se escribió. El redo log buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al redo log file, el proceso servidor puede copiar nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente escribe lo suficientemente rápido para asegurar que el espacio esté siempre disponible en el buffer para nuevos registros, aun cuando la escritura al redo log file sea lenta.
LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:
Un registro de commit cuando un usuario hace commit de una transacción
Redo log buffers:
Cada tres segundos
Cuando el redo log tenga un tercio lleno
Cuando un proceso de DBWn escriba los buffers modificados a disco, si es necesario.
Cuando un usuario lleva a cabo una instrucción de commit, el LGWR coloca el registro de commit en el log buffer y escribe la transacción a disco inmediatamente en el redo log. Los cambios correspondientes a los bloques de datos en el buffer caché, son dejados hasta que se tenga una escritura más eficiente que hacer. Esto se denomina el mecanismo de fast commit. La escritura de un registro de redo del commit de la transacción es un evento atómico.
Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el redo log buffer o redo log file aparecerán sólo las transacciones comprometidas. En el redo log file se escriben todas las transacciones, no sólo las comprometidas, es por ello que el redo log permite rehacer los segmentos de undo del cualquier punto en el tiempo cuando se hace recuperación incompleta (point in time recovery).
Redo Log Files
Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de un Redo Log Group son idénticos, es decir contendrán la misma información. Dentro de un grupo de Redo Log se "multiplexan" los archivos para evitar los puntos de fallas, es decir si se perdiera un archivo de Redo Log habría otro que contendría la información y que permitiera la recuperación de la base de datos.
Los redo log se utilizan de forma circular, mediante grupos de archivos. Por defecto la base de datos Oracle genera 3 grupos de archivos. Se considerará el grupo current (actual) aquel donde se esté utilizando para escribir las transacciones actuales de la base de datos. Se considera un grupo active (activo), aquel que no es el actual y que posea transacciones cuyos cambios no se han hecho permanentes en los archivos de datos e inactivo aquel que contenga transacciones que han sido completamente escritas a disco, finalmente también se puede tener que un grupo de redo log esté limpio porque nunca haya sido escrito.
Los archivos de redo log trabajan de forma circular porque se sobrescriben, generalmente con los tres grupos se tendrá que uno de ellos se encontrará activo, el siguiente en enumeración será el actual y el siguiente estará inactivo listo para que se escriba en él. Una vez llenado el grupo actual se comenzará a escribir en el inactivo, que ahora será el actual, el que anteriormente era el actual pasará a ser activo si aún no se han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba activo pasará a ser inactivo y permitirá que al llenarse el grupo actual se escriban las transacciones en él.
Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se encontraran activos, la base de datos no permitiría ninguna transacción hasta que se escriban todas las transacciones a disco del siguiente grupo de redo log y que este quedase inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese grupo de redo log al destino de los archivos.
Checkpoint Process (CKPT)
El CKPT lleva a cabo un checkpoint, entendiéndose como tal a la escritura parcial o completa de los buffers de memoria a disco. El CKPT no es el responsable de escribir los bloques a disco, para ello llama al DBWn y como en esa escritura podrían almacenarse en disco buffers de transacciones no comprometidas el CKPT también llama al LGWR para que registre en los redo log files esta escritura que permita generar los segmentos de undo de transacciones no comprometidas cuando se realice una recuperación incompleta. También si en la escritura del checkpoint hay transacciones que no se habían terminado de escribir en disco se escriben, se actualiza la cola de transacciones activas y un grupo de redo log que estaba activo podría pasar a inactivo.
Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los archivos de datos con los detalles del checkpoint, ésta es una tarea del CKPT.
System Monitor Process (SMON)
El proceso SMON lleva a cabo la recuperación, si es necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier transacción comprometida en el redo log file que no haya sido escrita a disco. SMON también es responsable de limpiar los segmentos temporales que no estén en uso por algún tiempo y de desfragmentar si cree oportuno alguna zona de los discos.
Process Monitor (PMON)
PMON lleva a cabo procesos de recuperación cuando un proceso de usuario falla. Es responsable de la limpieza del buffer caché, también de deshacer los cambios que se hayan hecho desde el ultimo commit y de la liberación de recursos que el proceso estaba usando. Por ejemplo este restaura el status de la tabla de transacciones activas, libera los locks y remueve el ID del proceso de la lista de procesos activos, asociados a un proceso usuario que pudo haber perdido la conexión de red.
Recoverer (RECO)
Este proceso solo se observa cuando la base de datos ejecuta la opción distribuida de Oracle. La transacción distribuida es una en la que dos o más emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos en diferentes ciudades y por fallas en una línea telefónica se pierde una transacción en la mitad de su actualización. El proceso recuperador entonces resuelve las transacciones que hayan quedado inconsistentes en las dos ciudades.
Archiver Processes (ARCn)
El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento distinto para no perderlos al ser sobreescritos. El ARCn sólo está habilitado cuando la base de datos está en el modo ARCHIVELOG. En Oracle 10g para colocar la base de datos en modo archive basta con colocarla en modo ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distinguía entre el "archive" manual y automático. Con "archive" manual el DBA debía ordenar hacer la copia de los redo log a los "archives", en el modo automático se copiaban automáticamente antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG automáticamente se coloca en el modo automático.
Lock (LCKn)
Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos Oracle cuando estas se encuentran en distintos computadores y compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo).
Job Queue (SNPn)
Es un proceso opcional, que se encarga de planificar los procesos que se deben ejecutar y asegurar que todos deben de terminar en algún momento.
Queue Monitor (QMNn)
QMNn es un proceso opcional de background para el encolamiento avanzado de Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa con comunicación asíncrona. Los procesos envían los mensajes y en lugar de esperar por la respuesta siguen con su trabajo.
Dispatcher (Dnnn)
Es un proceso opcional que permite a los usuarios compartir procesos de servidor. Permitiendo que se conecten múltiples usuarios al mismo servidor.
Shared Server (Snnn)
Este tipo de proceso se encarga de atender a cada uno de los clientes conectados a la base de datos compartiendo los procesos del servidor.