Backups y restauraciones en SQL Server (II): modelos de recuperación.

En este segundo artículo vamos a ver los modelos de recuperación existentes en SQL Server y las características principales de cada uno de ellos.




Existen tres modelos de recuperación distintos: Full Recovery, Simple Recovery y Bulk-Logged Recovery (http://msdn.microsoft.com/es-es/library/ms189275(v=sql.90).aspx ). Cada modelo determina como debería comportarse el registro de transacciones, tanto en el uso activo como durante el backup del registro de transacciones.

• Full Recovery (recuperación completa): modelo de recuperación por defecto para una BBDD recién creada. Todo el historial de transacciones se mantiene en el registro de transacciones que deberíamos administrar. Su ventaja es que se puede restaurar hasta el momento en el que una BB.DD. falla, o hasta un punto específico en el tiempo. Su desventaja es que si lo dejamos sin administrar, el registro de transacciones puede crecer rápidamente. Si se llena el disco, lo más probable es que la BB.DD. falle. Este modo no ofrece ningún tipo de mantenimiento automatizado del registro de transacciones. La única forma de limpiar es cambiar al modo de recuperación simple o realizar una copia de seguridad del registro de transacciones.
  
   
• Simple Recovery (recuperación simple): limpia el registro de transacciones activo de las transacciones realizadas durante un checkpoint. Su ventaja es que el registro de transacciones se mantiene y no necesita una administración directa. El inconveniente es que, en caso de desastre, está garantizado un cierto nivel de pérdida de datos. Es imposible restaurar el momento exacto del fallo. A pesar de que este modo de recuperación trunca el registro de transacciones periódicamente, esto no conlleva a que no crezca. Podemos fijar el tamaño del registro de transacciones a un determinado tamaño, pero si se ejecuta una inserción masiva (Bulk Insert), SQL Server lo tratará como una inserción simple. Por tanto, no sirve como respuesta para el mantenimiento de logs por lo que no deberíamos usarlo en BB.DD. en producción.
  
   
• Bulk-Logged Recovery (recuperación de registros masiva): Cuando se utiliza este modelo, el registro de transacciones se comporta exactamente como si se estuviese en modo de recuperación completa, con una excepción: las operaciones masivas se registran mínimamente. Las operaciones masivas incluyen:
  • Importaciones masivas de datos, que se podrían realizar haciendo uso de BCP (Bulk Copy Program), el comando BULK INSERT u OPENWROWSET con la cláusula Bulk.
  • Operaciones LOB (Large OBject), tales como WRITETEXT o UPDATETEXT, para columnas NText o Image.
  • Cláusulas SELECT INTO.
  • CREATE INDEX, ALTER INDEX, ALTER INDEX REBUILD o DBCC REINDEX.
  
      Como todas estas operaciones se registran en el modelo Full Recovery, el registro de transacciones puede crecer enormemente. La ventaja del modelo Bulk-Logged Recovery es que previene de un crecimiento del registro no deseado o imprevisto. Cada vez que se realiza una operación de registro masiva, SQL Server sólo registra los identificadores de las páginas de datos que se han visto afectados. Las páginas SQL Server tienen identificadores internos, así que se puede comprimir un aumento de identificadores de páginas en una pequeña parte del registro.
  Este modelo de recuperación tiene la desventaja de que la recuperación en un punto del tiempo no es técnicamente posible. Sólo podemos restaurar al punto de la última copia de seguridad del registro de transacciones. Será posible recuperar las transacciones masivas siempre y cuando se disponga de un backup del registro de transacciones que las contiene. Por otra parte, mientras que el registro de transacciones activo en este modo es más pequeño, la copia de seguridad del log contiene copias de las páginas modificadas durante el proceso de carga masiva. El resultado son copias del registro de transacciones potencialmente grandes.
  La clave para utilizar este modelo de recuperación de forma efectiva es invocarlo sólo cuando sea necesario, y a continuación, volver al modo de recuperación completa para un punto en el tiempo del backup. Se trata de un procedimiento de riesgo, y para mover entre Bulk-Logged Recovery y Full Recovery, siempre debemos seguir los siguientes pasos:

1. Cambiar de Full Recovery a Bulk-Logged Recovery.
2. Realizar la operación de registro masivo.
3. Una vez completado, volver inmediatamente al modo Full Recovery.
4. Realizar un backup completo de la BB.DD.

En el próximo artículo veremos algo de transact SQL…