Tradueix

lunes, 8 de noviembre de 2010

Redo log (I)

Ya decía yo que me tocaba luchar en todas las batallas. Ahora el "enemigo" se llama Redo log. Ya dicen que para vencer a tu enemigo hay que entenderlo. Así que después de empaparme con la documentación online de Oracle voy a intentar escribirlo a mi manera para ver si lo recuerdo.
Todo ha empezado cuando la bbdd ha ralentizado su funcionamiento hasta límites sospechosos. He acudido al fichero que vive en /opt/app/oracle/admin//bdump/alert_.log y he visto el siguiente texto:

Thread 1 advanced to log sequence 19962
Current log# 11 seq# 19962 mem# 0: /opt/app/oracle/oradata//redo1.log
Thread 1 cannot allocate new log, sequence 19962

Checkpoint not complete

¿Que está pasando?
Algún problema con los redo log, eso seguro.

Los redo log son dos o más ficheros pre asignados que guardan los cambios que se van produciendo en la base de datos a medida que ocurren. Cada instancia de la base de datos tiene sus redo log para proteger la bbdd en caso de fallo de instancia.

¿Y porque aparece por aquí la palabra Thread?
En una configuración típica solo hay una instancia para una misma base de datos, pero en un entorno de cluster de Oracle, hay más de una instancia para una misma base de datos y cada instancia tiene su propio Thread de redo logs para evitar un atasco si usaran los mismos redo log.

¿Pero que contienen los ficheros redo log?
Los ficheros redo log contienen redo records (registro de redo) y así me quedo la mar de ancho (¿qué van a tener sino los ficheros sino registros?). Bueno, un redo record o redo entry (entrada de redo) a su vez contiene algo llamado change vector (vector de cambio) que es una descripción de un cambio hecho en un solo bloc de la bbdd. Estos registros contienen la información necesaria para reconstruir todos los cambios hechos en una bbdd incluido los segmentos de rollback.

¿Cual es el ciclo de vida de un redo log?
Como casi todo en este loco mundo de la informática empieza en la memoria. Las redo entries (entradas de redo) causadas por algún cambio en la bbdd originado por alguna sentencia SQL (INSERT, UPDATE, DELETE, CREATE, ALTER, o DROP) se generan en el espacio de memoria del usuario y procesos de Oracle las copian al redo log buffer del SGA. Las redo entries toman espacio secuencial del redo log buffer. Que por cierto, como casi todo en Oracle, el tamaño de este buffer se puede definir ajustando el parámetro de inicialización LOG_BUFFER. Es importante ajustar bien el tamaño de este buffer. A mayor tamaño se reducen las operaciones I/O aumentando el rendimiento.

Copiar a disco.
Cuando se produce un commit, es decir, se finaliza la transacción, el proceso de Oracle LGWR copia los redo records del redo log buffer, ojo, solo los correspondientes a la transacción que se ha cerrado, al fichero de redo log en el disco.
Sin embargo, no es necesario que esto suceda solo cuando se produzca un commit. También se realiza el proceso cuando:

  • se ha llenado el buffer de redo log
  • se ha hecho commit de otra transacción
En este caso se copia todo el contenido del buffer de redo log a disco, incluso aquellas entradas de las que aún no se ha realizado un commit. Estas entradas serán permanentes si se produce un commit en posterioridad.
Sigamos el curso normal. Acabamos de hacer un commit de una transacción. El proceso LGWR graba las redo entries en el fichero de redo log y le asigna un número llamado System Change Number (SCN) que identifica unequivocamente cada transacción dentro del fichero de redo log. Solo cuando absolutamente todas las entradas de redo log de la transacción están a salvo guardadas en nuestro fichero, es cuando se envía el aviso al usuario de que se ha realizado un commit con éxito.

Redo log en disco.

El redo log está compuesto por 2 ficheros como mínimo, pero pueden ser mas. ¿Porque 2? Porque se tiene que garantizar que mientras uno esté activo el otro pueda estar siendo archivado, o más bien al revés, garantizamos que mientras uno está siendo archivado (siempre y cuando estemos en modo ARCHIVELOG del cual ya hablaremos más tarde) haya otro como mínimo que esté activo.
El proceso LGWR guarda en los ficheros de redo log de un modo circular. Es decir, empieza por el primero y cuando este está lleno, continua por el siguiente disponible. En cuanto ha llenado el último disponible, vuelve a empezar por el primero y empieza el ciclo de nuevo.
El comportamiento cuando cambia de un fichero a otro varía en función de si tenemos activado o no el modo ARCHIVELOG. Si lo tenemos activado, al saltar a otro fichero, el que abandonamos se archiva en disco en un espacio habilitado a tal efecto.

(Continuará...)


links:
Managing Oracle redo logs

Oracle Concepts - Online redo log management

http://kerneltrap.org/node/14286
AskTom

Oracle Wars © 2008. Template by Dicas Blogger.

TOPO