En este artículo vamos a repasar el modelo de recuperación probablemente menos conocido y extendido: Bulk-Logged. Vamos a ver sus principales características, ventajas, limitaciones y algunos ejemplos de uso. Además, el artículo sirve de cierre a la serie SQL101 sobre los modelos de recuperación en SQL Server.
Características del modelo de recuperación Bulk-Logged
Veamos cuales son las características principales de este modelo de recuperación:
- Se reduce de manera significativa el uso del Log de Transacciones para una lista de ciertas operaciones (bulk-logged).
- Requiere hacer copia de seguridad del Log de Transacciones (T-Log backup), al igual que ocurre con el Full Recovery Model.
- No hay riesgo de pérdida de datos, a menos que cuando ocurra el desastre, el T-Log backup más reciente contenga operaciones bulk-logged.
- Permite restauraciones Point-in-time siempre y cuando el último T-Log backup que usemos no contenga operaciones bulk-logged.
- Se puede cambiar de Full Recovery a Bulk-Logged y al contrario. No tiene mucho sentido pasar de Simple.
La sintaxis para cambiar a esta opción es sencilla y similar a los anteriores artículos de esta serie:
ALTER DATABASE bonisql SET RECOVERY BULK_LOGGED;
La principal motivación para usar este modelo de recuperación es la primera característica mencionada arriba, es decir las escrituras en el Log de Transacciones son mínimas para las operaciones bulk-logged si comparamos con Full Recovery model. Ahora la pregunta natural que nos podemos hacer es ¿Cuáles son estas operaciones?
Operaciones bulk-logged
Las operaciones bulk-logged son las que pueden beneficiarse de tener un impacto mínimo en el Log de Transacciones, y las detallamos a continuación:
- BCP
- BULK INSERT
- INSERT… SELECT
- SELECT INTO
- CREATE INDEX
- ALTER INDEX (incluyendo INDEX REBUILD)
- DROP INDEX
Se trata de una lista interesante, ya que algunas de estas operaciones son bastante comunes. Sin embargo, sería un error por nuestra parte pensar que si nuestro sistema realiza las operaciones anteriores con relativa frecuencia, lo mejor es usar el modelo de recuperación Bulk-Logged. Esa será una opción adecuada dependiendo de otros factores, como vamos a ver a continuación.
Este modelo reduce significativamente las escrituras en el Log de Transacciones, pero si nuestro servidor de base de datos tiene suficiente capacidad para manejar este volumen de operaciones en el archivo de log, resultará más conveniente no hacer cambios y continuar en Full Recovery mode.
Limitaciones del modelo de recuperación Bulk-logged
Hasta aquí hemos comentado muchos aspectos positivos de este modelo de recuperación. Ahora vamos a ver sus limitaciones:
- No puede ser usado para bases de datos que usan Mirroring o Availability Groups (ambas son opciones de Alta Disponibilidad).
- No permite recuperación en un punto exacto en el tiempo cuando el último Transaction Log backup que vamos a usar contiene operaciones bulk-logged.
- En caso de necesitar un Tail-Log backup, éste puede no servir si contiene operaciones bulk-logged. Este es un backup especial que se toma para capturar los cambios en la base de datos desde el último Log backup, y que se usará durante una restauración.
Normalmente, la mayor parte de los administradores no podrán permitirse el lujo de prescindir de la alta disponibilidad, o simplemente no pueden asumir el riesgo de tener problemas en caso de tener que hacer una recuperación después de un desastre.
Conclusiones
Bulk-logged model es una opción a tener en cuenta para bases de datos que no tengan las restricciones mencionadas, y necesiten tener bajo control el tamaño de su Log de Transacciones durante grandes operaciones por lotes, cómo por ejemplo una base de datos de históricos, o una BBDD con datos que se pueden regenerar fácilmente.
Como siempre, espero que este artículo te haya servido de ayuda, y sirva para aumentar tu «caja de herramientas» a la hora de trabajar con SQL Server.
¡Hasta la próxima!
boni SQL 