lunes, 29 de noviembre de 2010

Temporary Tables y Redo Logs

Mucho se ha hablado al respecto y poco se ha entendido sobre las razones por la cuales las tablas temporales, sobre las cuales se ejecutan muchas transacciones DML, generan entradas en los Redo Logs.

El "misterio" esta en los segmentos de Undo, en la naturaleza o razón de ser de los Redo Logs y en el concepto mismo de las tablas Temporales.

La documentación de Oracle nos dice:

- Acerca de los Redo Logs:
"Las entradas de Redo Log registran datos que son usados para reconstruir todos los cambios hechos en la base de datos, incluyendo los segmentos de Undo. Por lo tanto, los redo logs tambien protegen los datos de Undo...".

- Acerca de las Temporary Tables:
"Las sentencias DML aplicadas a las tablas Temporales no generan entradas de Redo Log.Sin embargo, Las sentencias DML generan información de Undo, lo cual, la modificación a los segmentos de Undo si generan entradas sobre los Redo Log"...

Por tal motivo, aunque no se crean entradas de Redo Log para los cambios hechos en los bloques de las tablas Temporales, los cambios hechos sobre los bloques de los segmentos de Undo si generan entradas de Redo Log.
Lo anterior nos permite tener una mejora en el performance de la base de datos cuando tenemos muchas transacciones de tipo DML sobre las tablas Temporales por el nivel "menor" (menor <> nada) de entradas de Redo Log generadas que, obviamente, repercute en  menos I/O a nivel físico de la Base de Datos y, además,la creación de muchos Archive Redo Logs dependiendo de la configuración de nuestra Base de Datos.

Para muestra basta un botón:

SELECT tablespace_name, contents, logging
FROM dba_tablespaces
/

TABLESPACE_NAME                CONTENTS  LOGGING  
------------------------------ --------- ---------
SYSTEM                         PERMANENT LOGGING  
SYSAUX                         PERMANENT LOGGING  
UNDOTBS1                       UNDO      LOGGING  
TEMP                           TEMPORARY NOLOGGING
USERS                          PERMANENT LOGGING  

Indentifiquen el valor de la calumna LOGGING en aquellas filas en donde la columna  CONTENTS contiene el valor de UNDO. ¿Qué observamos? Interesante no!

La modificación a los segmentos de UNDO si generan entradas de Redo Log.

Ahora, pensemos en el siguiente escenario:

Hemos creado una tabla temporal en un tablespace en modo LOGGING y una de las columnas de la tabla es de algún tipo LOB. ¿La tabla temporal generará entradas de Redo Log? La respuesta es más que obvia. Si!. Pero tenemos un detalle aquí que es muy importante tomar en cuenta. Cuando especificamos una columna de tipo LOB en la creación de alguna tabla, Oracle crea automáticamente un lob segment y un lob index, los cuales, si no se especifica que deben estar en modo NOLOGGING o el tablespace que los contendrá esta en LOGGING como en nuestro caso, entonces, se generará más entradas de Redo Log que lo habitual por lo generado por los segmentos de UNDO.

¿Qué es una Base de Datos Oracle?

Una Base de datos Oracle es una colección de datos que son tratados como una unidad.

El propósito de una base de datos es almacenar y recuperar información relacionada y, que generalmente, forma parte esencial para el negocio de alguna empresa.

Un servidor de base de datos es la llave para solucionar problemas de manejo y administración de la información ya que maneja de manera segura una gran cantidad de información dentro de un ambiente multiusuario, ofreciendo un acceso concurrente a los datos ofrececiendo un alto rendimiento para el acceso rápido hacia los mismos.

La arquitectura de un servidor Oracle se compone por tres partes importantes:

1. Procesos de usuarios.
2. Estructuras lógicas de memoria que en conjunto son conocidas como la instancia oracle (oracle instance).
3. Estructuras de archivos físicos que en conjunto son llamados la base de datos oracle (oracle database).


1. Procesos de Usuario (User Processes)

A nivel de usuario existen dos procesos que le permiten interactuar con la base de datos:
- Proceso de usuario (User Process).
- Proceso de servidor (Server Process).

Proceso de usuario (User Process)
----------------------------------------------
Oracle inicia un proceso de usuario cada vez que un usuario o aplicación intenta interactuar con la base de datos. El Proceso de Usuario inicia la conexión con la instancia. Al inicio y manejo de la interacción entre un usuario y la instancia Oracle se llama conexión (connection). Ya establecida la conexión se crea una sesión de usuario (session) en la instancia de oracle.


Proceso de Servidor (Server Process)
-------------------------------------------------
Después de crearse una sesión en la instancia de oracle, cada usuario inicia un Proceso de Servidor en el Servidor mismo de la base de datos. El Proceso de Servidor es el responsable de realizar todas las tareas que permiten al usuario interactuar con la base de datos. Ejemplos de esas interacciones son el envío de sentencias SQL a la base de datos, recuperación o extracción de la información de los archivos físicos y el retorno de esa información al usuario.

Los Procesos de Servidor generalmente tienen relación uno a uno con los Procesos de Usuario. Cada Proceso de Usuario se conecta a uno y sólo un Proceso de Servidor. En algunas configuraciones de Oracle, múltiples Procesos de Usuario pueden compartir Procesos de Servidor.

"El Proceso de Servidor se comunica con la instancia Oracle con el nombre del usuario".

Cada conexión de un usuario con la base de datos tiene asociada un proceso de usuario y un proceso de servidor pero, además, tambien se le asocia una estructura de memoria llamada Area Global de Programa (Program Global Area o PGA) que se crea por cada sesión. La PGA almacena información especifica de cada sesión como son las bind variables y las variables de sesión. Cada Proceso de Servidor en el servidor tiene su área de memoria PGA.


2. Instancia Oracle (Oracle instance)

Una Instancia dentro de un servidor Oracle es una estructura de memoria temporal que esta conformada por una estructura de memoria principal llamada Área de Sistema Global(System Global Area o SGA) y muchos procesos background (background processes) de Oracle.
Es con la SGA con quien los Procesos de Servidor se comunican cuando un usuario accede a la información dentro de la base de datos.

Cada instancia Oracle esta conformada por los siguientes componentes:
- Área de Sistema Global (System Global Area o SGA).
- Procesos background (Background Procesess).


Área de Sistema Global (System Global Area o SGA)
---------------------------------------------------------------------
La SGA es un grupo de estructuras de memoria que contienen datos e información de control para una y sólo una instacia Oracle. En el momento en que multiples usuarios estan conectados de manera concurrente, a la misma instancia Oracle, la información contenida en la SGA es compartida entre todos los usuarios. Por tal motivo, la SGA es conocida tambien como Área Global Compartida (Shared Global Area).
Oracle automáticamente reserva memoria para la SGA cuando la instancia Oracle es iniciada, y una vez que la instancia Oracle es dada de baja, el Sistema Operativo recumera la memoria asignada a la instancia.
La SGA es de lectura y escritura. Todos los usuarios conectados a multiples procesos de la instancia Oracle pueden leer la información contenida dentro de la SGA de la instancia, y muchos procesos pueden escribir dentro de la SGA mientras la instancia este en ejecución.

La SGA contiene las siguientes estructuras de memoria:
* Database buffer cache: Contiene información que ha sido accesada recientemente por los usuarios de la base de datos.
* Redo log buffer: Contiene información de las transacciones hechas a la información con fines de recuperación de la base de datos.
* Shared pool: Contiene información de sentencias SQL recientemente ejecutadas por usuarios.
* Java pool: Mantiene información de objetos Java recientemente usados, así como código de las aplicaciones Java cuando la opción de Oracle JVM esta habilitada.
* Large pool (opcional): Contiene información de operaciones muy largas como actividades de respaldo y recuperación de la Base de Datos hechas con Recovery Manager (RMAN) y componentes de servidor compartido.
* Streams pool: Contiene información asociada con colas de mensajes y replicaciones con Oracle Streams.
* Data dictionary cache: Contiene información sobre la definición de los objetos de la base de datos.
* Otro tipo de información.

Parte de la SGA mantiene información acerca del estado de la base de datos y de la instancia misma que los procesos de fondo necesitan obtener; esta parte de la SGA es llamada SGA fija (fixed SGA). Ningún dato de usuario es almacenada en la SGA fija. La SGA tambien contiene información para la comunicación entre los procesos como información de bloqueos.
Si el sistema cuenta con la configuración de Servidor Compartido (Shared Server), entonces, las colas de solicitudes y respuestas y parte del contenido de la PGA se almacena en la SGA.

Cuando un proceso de Servidor de algún usuario requiere colocar una sentencia SQL dentro de la Shared Pool o un bloque de datos en la Data Buffer Cache, Oracle usa el espacio de memoria ocupada por la sentencia SQL ejecutada por el usuario y que ya no ha sido usada nuevamente desde su ejeccución, de la misma forma, se usa la memoria ocupada por los bloques de información que ya no han sido utilizados. Esta técnica  se basa en el algoritmo llamado "Actualmente el menos usado (Least Recently Used o LRU)" que permite a Oracle mantener continuamente las sentencias SQL más ejecutadas y los datos más usados en el Buffer de las estructuras de memoria, esto se hace para generar un mayor rendimiento en la base de datos, minimizando el parseo y la lectura y escritura en los dispositivos físicos.


Procesos background (Background Processes)
-------------------------------------------------------------
Existen muchos procesos background que realizan un trabajo específico y que ayudan al manejo de la instancia Oracle. Sólo cinco procesos background son obligatorios y se encuentran en todas las instancias Oracle. Otros procesos son opcionales dependiendo de las características o configuraciones que están siendo utilizadas en la base de datos. Los cinco principales procesos background son:

- System Monitor o SMON: Este proceso realiza la recuperación de la base de datos, si es necesaria, al momento de que la instancia Oracle es iniciada. Tambien es responsable de limpiar los segmentos temporales que no estan en uso. Si una transacción de recuperación es omitida por alguna falla de lectura o algún archivo esta fuera de línea, SMON las recupera cuando el tablespace o el archivo esta nuevamente en linea. SMON esta continuamente verificando si es que es necesario que realice alguna operación o si algún otro proceso lo necesita.

SMON además reagrupa los extents libres de aquellos tablespaces que son manejados por el diccionario de datos, generando espacio libre contiguo y fácil de asignar.

- Process Monitor o PMON: El PMON realiza operaciones de recuperación si algún proceso de usuario falla. El PMON es el responsable de limpiar los bloques dentro de los Buffers de la SGA y liberar los recursos que estaban siendo utilizados por el proceso de usuario. Tambien verifica si el proceso despachador (Dispatcher Process) o el proceso de servidor (Server Process) necesitan ser reiniciados en dado caso de que alguno de ellos no se esta ejecutando por alguna falla.

- Database Writer o DBWn: Escribe los bloques de datos modificados de la Database Buffer Cache en la SGA hacia los arvhivos físicos de la base de datos llamados Datafiles. n indica que pueden ser más de un proceso.

- Log Writer o LGWr: Este proceso escribe las entradas de redo log en disco. Las entradas de Redo Log son generadas en la Redo Log Buffer de la SGA, y el LGWr las escribe de manera secuencial dentro de los archivos de redo log en linea. Si la base de datos tiene los archivos de redo log multiplexados, el LGWr escribe las entradas de los redo log en todos los miembros del grupo de redo log que este actualmente en linea.


- Checkpoint o CKPT: En momentos específicos, todos los bloques modificados de la Data Buffer Cache en la SGA son escritos en los datafiles por el DBWn. Este evento es llamado Checkpoint. El CKPT es el responsable de indicar al DBWr cual es el punto de control o número de cambio de sistema (SCN) que debe actualizar en todos los datafiles y control files para tener los archivos sincronizados. Si algún archivo de la base de datos tiene un SCN diferente indica que este archivo necesita de operaciones de recuperación.



3. Base de Datos Oracle (Oracle database)

Una Base de Datos Oracle está compuesta de un conjunto de archivos físicos que residen en los discos de almacenamiento en el Servidor. Estos archivos son llamados control files, datafiles y redo log files. Existen también otros archivos que están asociados a la base de datos pero que técnicamente no son parte de ella; password file, PFILE, SPFILE y los Archive Redo Log files.

Control files
----------------
Los control files son archivos críticos, ya que la información que almacenan no se encuentra en algún otro archivo (excepto sus copias). Esta información incluye lo siguiente:

-El nombre de la Base de Datos.
-El nombre, ubicación y tamaño de los datafiles y redo log files.
-El tamaño de los bloques de la Base de datos (Database block size).
-El conjunto de caracteres de la base (database character set).
-Información utilizada para recuperar la base de datos en caso de algún error de usuario o de disco.

Los controlfiles son creados al momento de la creación de la base de datos en la ubicación especificada en el parámetro control_files en el archivo de parámetros.
Es altamente recomendable que se tenga multiplexados los control files en ubicaciones distintas o incluso en distintos discos. Cada una de las copias de los control files deben estar sincronizados, para ello Oracle utiliza el proceso background CKPT (Checkpoint).
Los control files son requeridos para abrir la Base de Datos.

Datafiles
------------
Los Datafiles son estructuras físicas que contienen los datos que han sido insertados en todos los segmentos de la base de datos, es por ello que su tamaño es directamente proporcional a la cantidad de segmentos que alguna vez fueron creados y a los tamaños máximos que alguna vez tuvieron dichos segmentos.

Los datafiles son estructuras físicas detrás de otra área de almacenamiento lógica llamada tablespace.

Cuando un usuario realiza una operación SQL sobre una tabla, el Proceso de Servidor del usuario copia los datos o información requerida desde los Datafiles hacia la Database Buffer Cache en la SGA. Si el usuario realiza una tansacción y la confirma (commit), entonces, los datos o la información modificada es escrita en los Datafiles desde la Database Buffer Cache por medio del proceso background DBWn.

Redo Log Files
--------------------
Siempre que un usuario realiza una transacción en la base de datos, toda la información necesaria para reproducir tal transacción en caso de ocurrir alguna falla en la base es automáticamente registrada en la Redo Log Buffer. El contenido de la Redo Log Buffer es escrito en los Redo Log Files por medio de proceso background LGWR.
Los Redo Log Files son usualmente multiplexados o copiados, cada Redo Log contiene una o más copias de si mismo formando conjuntos conocidos como redo log groups. Cada archivo multiplexado en los redo log groups son llamados redo log group member. Cada grupo de redo debe contener uno o más miembros.
Toda Base de Datos debe contener mínimo dos grupos de redo con un miembro ya que son utilizados de manera cíclica o circular.