Alguna vez se le ha caido una replicación en la cual la publicación es bastante grande, y restablecerla desde un snapshot puedo tomar varios dias; o sencillamente necesita agregar una segunda subscripción a una publicación ya existente? Bueno los siguientes pasos le pueden ayudar a hacer ese proceso menos doloroso, y ahorrar bastante tiempo de arreglagar problemas.

Cual es el problema a entender?

Muchas veces nos hemos encontrado con que una alerta nos falla, y dejamos de lado la revision de una base de datos, ya que estamos a la espera de que una alerte llegue, de ahi es donde comienzan a salir los sistemas de monitoreo especilizado.

El problema es qeu en algunos casos no se tienen los recursos para poder implementar ese sistema de monitoreo, y confimos 100% al sistema de alertas de SQL Server. Pues bueno este no deberia fallar, cierto? 

Esta es la pregunta que por lo general cuando enfrentamos un evento en el que necesitamos recuperar la base de datos nos hacen:

1. ¿Cuánto va a durar restaurando la base de datos?
2. ¿Es la forma más rápida de restaurarla?
3. ¿Vamos a recuperar todos los datos?

En el siguiente post vamos a darle respuesta a las primeras dos preguntas, la tercera va a depender de la capacidad de poder realizar un tail log backup.

Lo que este script asume:

Este escenario de configuración esta compuesto por dos servidores de bases de datos, donde la sincronización de datos se hace de forma asincrónica. Tal y como se mostraba en el artículo SQL Server Mirroring - Visión General estos son los pasos que vamos a seguir para configurar este escenario de operación de SQL Server Mirroring.

La presentacion que di en el PASS SQL Saturday 133 en Costa Rica, acerca de como utilizar particionamiento, Respaldos  y bases de datos parciales a favor de incrementar la alta disponibilidad de la base de datos en casos de falla de LUNS