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

4 Comentários:

Anónimo dijo...

Me gustó mucho tu artículo, me despejó muchas dudas que tenía! :)

Anónimo dijo...

muy bueno loco

Anónimo dijo...

heyy en mi caso... tengo un mega problemaa.. se han eliminado o sacado de la carpeta los redo01.log redo02.log y redo03.log y pues al momentos de querer levantar la BD obviamente tengo problemas se monta, pero me dice que no puede ser abierta!!! para esto te comento que los conocimientos en oraclo son de usuario nivel 0, porque se han eliminado. que puedo hacer.. se pueden volver a generar sin perder mi BD. auxilio!!! pensabamos que si elminamos los lOG no afectarian, y como requeriamos espacio y esos log cada uno era de 50 megas.. pos se nos hizo facil tumbarlos, pero ahora leyendo se que son muy importantes... he vuelto a pegarlos donde estaban, pero ya no se puede hacer nada.. puesta que han reiniciado el server... y pues ahora ya no los reconoce.. o no se que pex.. auxilioo!!! plz
saltoz2002@hotmail.com

ciwoc dijo...

En principio no tendria que haber perdida de los datos actuales, solo has perdido la posible operación de recuperación en algun punto anterior a este.
Puedes intentar recrear los redologs.
Mira-te esto a ver si te puede ayudar:

http://es.scribd.com/doc/66979373/329/BORRADO-REDO-LOGS-CORRUPTOS

Publicar un comentario

Oracle Wars © 2008. Template by Dicas Blogger.

TOPO