Gestión del redolog en Oracle y diferencias con el log de SQL Server

24/09/2013

En una base de datos, la gestión del log es una tarea principal de un DBA. En Oracle y SQL Server, es muy importante que sepamos para qué sirve el log y cómo gestionarlo. En este post, veremos cómo administrar el redolog de Oracle y sus similitudes/diferencias con el log de SQL Server.

Las bases de datos actuales son capaces de gestionar cientos de transacciones por minuto, pero para ello es importante que siempre trabajen en memoria. Tanto Oracle como SQL Server siempre intentarán realizar los cambios de DML en memoria ya que el acceso a disco siempre es más lento. Pero si los cambios se realizan en memoria ¿qué pasa si me falla la instancia del servidor? Para ello existe el redolog en Oracle y el log en SQL Server. Tanto uno como otro sirven para lo mismo: guardan en un fichero la sentencia de cada transacción que se ejecuta en el servidor. Así, si la instancia falla, cuando se reinicie, volverá a aplicar el log rehaciendo los cambios que existían en memoria antes del fallo, por lo que el servidor será capaz de dejarnos justo hasta el momento anterior al fallo. Eso es lo que se denomina “base de datos consistente”. Oracle y SQL Server tratan este log de forma distinta.

En Oracle el log se denomina redolog y está compuesto de 3 grupos de ficheros multiplexados  (si usamos la plantilla típica de instalación de Oracle) de tamaño fijo. Esta última coletilla es muy importante, porque al ser de tamaño fijo, Oracle cuando necesita espacio en el redolog para registrar la sentencia aplicada, si es necesario sobrescribe el redolog. De hecho los 3 grupos de redolog se van sobrescribiendo uno tra otro de forma circular.

En Oracle, podemos ver los grupos de redologs desde el Enterprise Manager, pestaña Server, opción Redolog Groups.

Grupos de redolog desde Oracle Enterprise Manager

Grupos de redolog desde Oracle Enterprise Manager

Un problema que tenemos si se sobrescriben los redologs, es que si perdemos la instancia, no podremos recuperarla  hasta el momento del fallo. Imaginemos que se inicia la instancia a las 9:00 de la mañana y que a las 22:00 horas del día anterior hicimos una copia de seguridad. Si tenemos 3 grupos y ese día tenemos una carga muy importante de transacciones en nuestra base de datos, es posible que a las 9:00 Oracle use el primer grupo de redolog, a las 10:00 el segundo grupo y a las 11:00 el tercer grupo. Osea a las 12:00 estamos ya sobrescribiendo el primer redolog. Imaginemos que la instancia falla a las 17:00 horas. Puesto que se sobrescribieron los redologs de las 9:00 de la mañana, Oracle no tiene forma de volver a aplicar los cambios y por tanto, la única forma de recuperar la instancia es volviendo a recuperar la copia de seguridad del día anterior.

Una manera de evitar que se sobrescriban los redologs son guardándolos. Para ello, existe un proceso denominado archivado (arch) que se encarga de guardar en una localización distinta los logs. Cada vez que un grupo de redolog se llena, un proceso en segundo plano denominado arch, se encarga de hacer una copia de seguridad de dicho redolog. Así cuando Oracle necesite sobrescribirlo, podrá hacerlo de un modo seguro. Siguiendo el mismo ejemplo anterior, si la instancia se cae a las 17:00 horas, Oracle puede utilizar los logs archivados (archive log) y su propio log (redologs) para devolver la instancia justo hasta el momento en el que se cayó. El modo archivado debe activarse y es imprescindible tenerlo activo en cualquier base de datos de producción para no perder información. El parámetro USE_DB_RECOVERY_FILE_DEST sirve para indicar la ruta en donde queremos guardar los ficheros archivados.

En Oracle, podemos ver la configuración de archivado desde Enterprise Manager, pestaña Availability, opción Recovery Settings.

Configuración del archivado desde Oracle Enterprise Manager

Configuración del archivado desde Oracle Enterprise Manager

Desde SqlPlus podemos consultar los grupos de redolog utilizando las vistas del diccionario v$log y v$logfile y si tenemos configurado el modo archivado con la sentencia archive log list.

Consulta de los grupos de redo log y el modo archivado en Sqlplus

Consulta de los grupos de redo log y el modo archivado en Sqlplus

En este dirección tenemos más información sobre el redolog y el modo archivado en Oracle:

http://docs.oracle.com/cd/B19306_01/server.102/b14231/onlineredo.htm

http://docs.oracle.com/cd/B19306_01/server.102/b14231/archredo.htm

En SQL Server, el log sirve para lo mismo que en Oracle. Si se cae la instancia, SQL Server pierde los datos existentes en memoria y cuando vuelve a iniciarse, necesita rehacer los cambios utilizando el log.

La gestión del log en SQL Server es distinta a Oracle: en SQL Server el log no es de tamaño fijo y no se sobrescribe. Osea el log va creciendo todo lo que necesite para poder recuperar la instancia hasta el momento del fallo. Entonces, si no se sobrescribe el log crecerá y crecerá…. Ese es un problema típico de SQL Server, y es que en muchas bases de datos el log es más grande que el propio fichero de datos.

Puesto que el log crece indefinidamente, la forma de que no crezca tanto es realizando una copia de seguridad del log con la sentencia BACKUP LOG. Dicha copia debe realizarse después de la copia de seguridad de la base de datos. La copia de seguridad del log, hace que se fuerce el truncado del log, osea que se sobrescriba (para ello ya se han guardado y sincronizado los cambios en los ficheros de datos).

Backup del log de SQL Server desde el Management Studio

Backup del log de SQL Server desde el Management Studio

Opción del truncado del log desde SQL Server Management Studio

Opción del truncado del log desde SQL Server Management Studio

En esta dirección tenemos más información de cómo hacer un backup del log en SQL Server.

http://technet.microsoft.com/en-us/library/ms179478.aspx

Como vemos, tanto Oracle como SQL Server hacen uso de un log pero cada uno lo gestiona de una forma distinta. En Oracle el redolog se sobrescribe y tiene que ser archivado. En SQL Server el log crece indefinidamente hasta que lo truncamos haciendo una copia de seguridad de él.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: