4.2. Definición de los modos de operación de un DBMS

Una responsabilidad importante del administrador de la base es prepararse para la posibilidad de hardware, software, red, proceso o fallo del sistema. Si un fallo de este tipo afecta a la operación de un sistema de base de datos, debe generalmente recuperar la base de datos y volver al funcionamiento normal tan pronto como sea posible. La recuperación debe proteger la base de datos y usuarios asociados de problemas innecesarios y evitar o reducir la posibilidad de tener que duplicar el trabajo manualmente.

Los procesos de recuperación varían en función del tipo de fallo que se produjo, las estructuras afectadas, y el tipo de recuperación que realice. Si no hay archivos perddidos o dañados, la recuperación puede equivaler a no más de reiniciar una instancia. Si se han perdido los datos, la recuperación requiere pasos adicionales.

El manejador de Recovery es una utilidad que simplifica las operaciones de backup y recovery.

Los errores y fracasos

Varios problemas pueden detener el funcionamiento normal de una base de datos Oracle o afectar base de datos de I/O en el disco. Las siguientes secciones describen los tipos más comunes. Para algunos de estos problemas, la recuperación es automática y requiere poca o ninguna acción por parte del usuario de base de datos o el administrador de base de datos.

Error Usuario

Un administrador de base de datos puede hacer poco para evitar errores de usuario como la caída accidental de una tabla. Por lo general, un error del usuario puede ser reducida por el aumento de formación sobre los principios de base de datos y de aplicación. Por otra parte, mediante la planificación de un sistema de recuperación de efectivo antes de tiempo, el administrador puede facilitar el trabajo necesario para recuperarse de muchos tipos de errores del usuario.

Declaración de incumplimiento

Declaración de fracaso se produce cuando hay un fallo de lógica en el manejo de una declaración en un programa de Oracle. Por ejemplo, suponga que todas las extensiones de una tabla (en otras palabras, el número de extensiones especificadas en el parámetro MAXEXTENTS de la sentencia CREATE TABLE) están asignados, y están completamente llenos de datos; la tabla está absolutamente llena. Una sentencia INSERT válida puede no insertar una fila por falta de espacio disponible. Por lo tanto, si se emitió, el comando falla.

Si se produce un fallo de declaración, el software o sistema operativo Oracle devuelve un código de error o un mensaje. Un fallo declaración generalmente no requiere de acción o de recuperación de pasos; Oracle corrige automáticamente por no declaración retrotrayendo los efectos (en su caso) de la declaración y de devolver el control a la aplicación. El usuario puede simplemente volver a ejecutar la sentencia después de corregir el problema indicado por el mensaje de error.

El fracaso del proceso

Un fallo de proceso es un fracaso en un usuario, servidor o proceso en segundo plano de una instancia de base de datos como una desconexión anormal o la terminación del proceso. Cuando se produce un fallo de proceso, el proceso subordinado fallido no puede seguir trabajando, aunque los otros procesos de la instancia de base de datos puede continuar.

SMON (System Monitor): Es el supervisor del sistema y se encarga de todas las recuperaciones que sean necesarias durante el arranque. Esto puede ser necesario si la BD se paró inesperadamente por fallo físico, lógico u otras causas. Este proceso realiza la recuperación de la instancia de BD a partir de losarchivos redo log. Además límpia los segmentos temporales no utilizados y compacta los huecos libres contiguos en losarchivos de datos. Este proceso se despierta regularmente para comprobar si debe intervenir

PMON (Process Monitor): Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos en la SGA (System Global Area). Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transacción cancelada. Este proceso se despierta regularmente para comprobar si su intervención es necesaria.

SQL> oradebug setmypid SQL> oradebug setmypid        
SQL> oradebug wakeup 2 SQL> oradebug activación 

DBWR (Database Writer): Es el responsable de gestionar el contenido de los buffers de datos y del caché del diccionario. Él lee los bloques de los archivos de datos y los almacena en la SGA. Luego escribe en los archivos de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.

Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la información del buffer de la BD cuando se valida una transacción. Cada validación no se lleva a la BD física de manera inmediata sino que los bloques de la BD modificados se vuelcan a los archivos de datos periodicamente o cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:

Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en losarchivos de redo log. El proceso de escritura es asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.

En UNIX, el proceso de DBWR es asincrónica.Esto significa que una base de datos de escribir no siempre resulta en un yo físico inmediato de E/S por el DBWR. Por el contrario, el proceso deDBWRpuede esperar hasta que un conjunto de "bloqueo sucio" han acumulado en los buffers de datos, y luego escribir el conjunto de bloques en una sola operación.

Cuando se utiliza un sofisticado sistema de nuevo de almacenamiento de gama como EMC, la naturaleza de la base de datos, escribe se vuelve aún más complejo.A menudo, un cuadro de EMC aplazar el escribir en los discos físicos para optimizador de rendimiento de E/S. Para ello, el cuadro de EMC le enviará un acuse de recibo de inmediato y volver al proceso DBWR que la E/S se ha completado, cuando en realidad el bloque de datos reside en la memoria RAM de la caché en disco de EMC. Esta compleja interacción a menudo conduce a señalar con el dedo entreEMC y Oracle cada vez que un error provoca un disco escribir a fallar.

LogWriter

El proceso “Log Writer”, es el encargado de transferir la información de los registros del Redo Log Cache a los ficheros físicos de REDO. Este proceso se encarga de escribir las entradas a disco lo suficientemente rápido para asegurar que siempre hay espacio en el buffer. El LGWR escribe a disco en los siguientes casos:
  1. Cuando se produce un COMMIT
  2. Cuando se llena 1/3 el buffer de redo (aunque no se hayan confirmado los registros)
  3. Cada 3 segundos

Como vemos en la imagen anexa, hay 3 grupos de ficheros de Redo. En primer lugar se empieza guardando los registros del buffer de Redo Log en el primer grupo de ficheros de logs hasta que éste grupo se llena, momento en el cual se empiezan a guardar los registros en el segundo grupo, para luego continuar en el tercer grupo. Al llenarse este último se vuelven a escribir los registros en el primer grupo de ficheros, funcionando este sistema como un buffer circular.

Si la base de datos se encuentra en modo Archiver, cuando se llena un grupo de ficheros de Redo Log, éste es archivado, con lo que no perderemos la información. El respaldo de los ficheros de Redo puede configurarse para ser almacenados en hasta 10 lugares distintos. Se recomienda tener la base de datos en modo Archiver para base de datos en producción, no tanto para base de datos de desarrollo.

Checkpoint este proceso escribe en los archivos de control los checkpoints. Estos puntos de sincronización son referencias al estado coherente de todos los archivos de la base de datos en un instante determinado.

Fallo en la red

Cuando su sistema utiliza redes como redes de área local y líneas telefónicas para conectar las estaciones de trabajo a los servidores de bases de datos, o para conectar varios servidores de bases de datos para formar un sistema de base de datos distribuida, fallos en la red, como las conexiones telefónicas abortados o fallos de software de comunicación de red pueden interrumpir la operación normal de un sistema de base de datos. Por ejemplo:

Un fallo en la red podría interrumpir la ejecución normal de una aplicación de cliente y causar un fallo de proceso de que se produzca. En este caso, el Oracle PMON proceso en segundo plano detecta y resuelve el proceso de servidor abortado para el proceso de usuario desconectado, como se describe en la sección anterior.

Un fallo en la red podría interrumpir la confirmación en dos fases de una transacción distribuida. Después de que el problema de la red se corrige, el Oracle proceso en segundo plano RECO de cada servidor de base de datos involucrados resuelve automáticamente las transacciones distribuidas aún no resueltos en todos los nodos del sistema de base de datos distribuida.



Anterior
Valid XHTML
home

Siguiente