¿Qué Pasa Durante un Respaldo en Caliente?

Cuando ocurre un respaldo en linea o en caliente hay algunos mitos alrededor de esto que todavía se escuchan:

Mito #1: El respaldo en caliente genera una gran cantidad de informacion de redo.
Mito #2: El modo de bitácoras históricas (archivelog mode) dramáticamente alenta a la base
Mito #3: Cuando hay un respaldo en linea en progreso el archivo a respaldar se congela

Existen dos formas de genera el respaldo en línea, la primera es utilizando un respaldo manual asistido por el usuario, y la segunda por medio de la herramienta RMAN. Se requiere que la base de datos se encuentre en modo de bitácoras históricas a efecto de que se puedan realizar los respaldos en linea. Ambas técnicas generarán el respaldo de una manera parecida, como se explicará más adelante, sin embargo RMAN es más eficiente que el respaldo asistido por el usuario.

Respaldo Asistido por el Usuario

La sintaxis para generar el respaldo en linea es la siguiente:

alter tablespace TS_NAME begin backup;

Cuando este comando es emitido, se realiza un checkpoint en ese momento contra el tablesapace a respaldar; entonces el encabezado el datafile es congelado de modo de que no se permiten mas actualizaciones sobre éste (el encabezado del archivo), esto le permite a la base de datos sabre cuál fue la última vez que el tablespace contenía información consistente.

El datafile con el respaldo en curso seguirá recibiendo operaciones de lectura y escritura como cualquier otro datafile, i.e. la actividad de Entrada/Salida no se congela.

Cada vez que un renglón es modificado, no solamente el renglón, sino el bloque completo es registrado en el archivo de redolog , esto solo pasará la primera ve que el bloque sea modificado en transacciones subsecuentes sobre el mismo bloque solo la transacción que modifica el contenido del bloque será almacenada de manera convencional.

Durantel el proceso del respaldo asistido por usuario el evento de "Bloque Fracturad" puede llegarase a presentar. Hay que recordar que el bloque es la mínima unidad de E/S de la base de datos yq ue un bloque se compone de varios bloques de sistema operativo, asumiendo un tamaño de bloque de 8K y bloques de Sistema Operativo de 512, esto hace que el bloque Oracle conste de 16 bloques de Sistema Operativo. Si durante el proceso de respaldo de un bloque hay una operación de escritura sobre el bloque, entonces el bloque tendrá una imagen de antes y una imagen de después de la modificación, el resultado es que el bloque quedará corrupto en el respaldo. Este fenómeno es normal, la consistencia del archivo no está garantizada con este método de respaldo, esta es la razón por la que el encabezado del archivo tiene que congelarse de modo que esto marca el punto en el tiempo a partir del que el proceso de recuperación tiene que iniciarse, y esta es la razón por la que Oracle almacena la imagen completa del bloque en el archivo de redolog.

Al momento en que el comando alter tablespace TS_NAME end backup; es emitido se concluye el proceso de respaldo y el encabezado del archivo de datos retoma la actividad normal de Entrada/Salida.

Respado con RMAN
El mismo proceso ocure cuando un respaldo con RMAN tiene lugar, la única diferencia consiste en que RMAN tienen un manejo más eficiente del evento de bloque fracturado, éste no escribe bloques fragmentados al archivo de respaldo, por lo que RMAN no necesita escribir la imagen del bloque en los archivos de redolog.

Algunso consejos prácticos para la gente que realiza todavia respaldos asistidos por el usuario es que no dejen que el comando BEGIN BACKUP corra por períodos prolongados de tiempo, entre más tiempo transcurra para la ejecución del respaldo más probabilidades habrá de que ocurra el evento de bloque fracturado, lo cual puede generar una mayor cantidad de bloques escritos a los archivos de redolog