Que son los RedoLogs y su utilización

Los RedoLogs guardan el Journal de la BBDD en forma de modificaciones a bloques.

Es de destacar que contiene:

• Los valores nuevos de los datos.
• Indirectamente, los valores antiguos de los datos
  
  • Debido a que se guardan las modificaciones a los RollBack Segments/Undo Tablespaces.

En una BBDD debe haber, como mínimo, 2 RedoLogs por Instancia.

La escritura en los mismos es siempre estrictamente secuencial:

• Se escribe en el RedoLog cuando:
  
  • El tamaño lleno del RedoBuffer (Parámetro LOG_BUFFER) alcanza un cierto %
  • Y en cada COMMIT
    
    • Un COMMIT no termina hasta que el propio COMMIT no se ha gravado al RedoLog
    • Una misma gravación de RedoLog puede incluir varios COMMITs.
• Los RedoLogs se utilizan como un Buffer Circular:
  
  • Cuando un RedoLog se llena, se empieza a escribir en el siguiente y asi sucesivamente.
• Cuando se ha llenado un RedoLog, empieza una operación de CheckPoint
  • Un CheckPoint implica empezar la gravación de todos los bloques modificados de la cache.
  • Un RedoLog no puede sobreescribirse hasta que se han gravado todos los bloques de BBDD modificados en el momento de empezar su CheckPoint.

 A partir de aqui, podemos ver las recomendaciones para el RedoLog

Recomendaciones:

• Crear los RedoLogs en los discos más rápidos, en escritura secuencial, del sistema-.
  • Un Commit (Transacción) no termina hasta que finaliza la escritura en el RedoLog.
  • Actualmente, con la utilización de Subsistemas de discos, generalmente, la gravación del RedoLog termina cuando se ha escrito en la cache del subsistema de discos. Por tanto, este tema ya no suele ser un problema.
• Crear los RedoLogs con un tamaño relativamente grande para disminuir el número de CheckPoints.
  • El tamaño depende de la actividad.
  • Se recomienda que el cambio de RedoLog se realize con una frecuencia mínima de 30 minutos en los momentos de mayor actividad en el sistema.
  • Un tamaño de 500 Mb .. 1 Gb no es una exageración.
• Crear bastantes RedoLogs
  • Del orden de 6 .. 10 por instancia puede ser un buen número
  • Es para evitar el problema de Checkpoint Not Completed que a veces se aprecia en el Alert. Este problema implica un paro en la actividad de la BBDD hasta que termine el CheckPoint
    • Si se detecta este problema, aumentar el tamaño y el número de RedoLogs
  • Tener muchos RedoLogs y grandes, disminuye el número de escrituras en la BBDD.
• En cuanto las copias de RedoLogs: Esta es la pregunta del millón.
  • Si los RedoLogs residen en un Subsistema de Discos con Redundancia (RAID 1, RAID 5 o similar), los ficheros ya están protegidos ante error en el discon y con una copia  basta.
  • Si deseamos tener varias copias, no tiene sentido que estén en los mismos discos.
    • Si residen en un subsistema de discos, puede ser dificil asegurar que están en grupos (RAID) distintos.
• Parametrizar LOG_BUFFER con un tamaño relativamente grande.
  • El valor de varios Mb no es una exageración.
  • Por grande que sea este valor, no tiene incidencia en la información perdida en caso de caida (crash) de la BBDD.
    • Hay que recordar que:
      1. En caso de caida, toda transacción no Commitada, se pierde.
      2. Al hacer un COMMIT, se escribe al RedoLog todo el LOG_BUFFER no escrito. El COMMIT no termina hasta que ha terminado esta escritura.
    • Por tanto, en caso de caida, la información que se perderá es la no COMMITada tal y como está definido.