Cuando se trata de configurar el envío de registros en SQL Server, el objetivo principal suele ser tener una solución de recuperación ante desastres (DR) en su lugar. La idea es tener copias de los registros de transacciones enviados a un servidor secundario lo más rápido posible, para que en caso de un problema en el servidor de producción, pueda cambiar al servidor secundario y minimizar el tiempo de inactividad para su empresa.
En el pasado, era práctica común restaurar estos registros de inmediato. Si estaba realizando copias de seguridad de registros cada minuto, quería asegurarse de que el servidor secundario pudiera ponerse en línea en cuestión de minutos. Este era un buen proceso, pero ha sido en gran medida reemplazado por el reflejo de bases de datos, que ofrece una recuperación más rápida en otro servidor. El reflejo de bases de datos también tiene la ventaja de dirigir automáticamente a los clientes al servidor espejo, algo que el envío de registros no puede hacer.
Sin embargo, hay situaciones en las que es posible que no desee restaurar los registros de inmediato. No todos los desastres requieren o lo obligan a cambiar de servidor. Considere desastres accidentales, como un usuario que borra todos los clientes o un DBA que actualiza accidentalmente todos los pedidos con la misma cantidad debido a una cláusula WHERE faltante. Si restaura los registros de inmediato, es probable que estos cambios se apliquen en el servidor secundario antes de que pueda contactar al DBA o hacer una conexión remota al servidor secundario para detener el proceso de envío de registros.
Una solución a este problema es tener una tercera base de datos que retrase la restauración de registros durante una o dos horas. De esta manera, aún puede tener los datos originales en ese servidor, incluso si ha realizado algunos cambios en las últimas horas. Luego puede “ponerse al día” con todos los registros excepto el que se cometió el error y transferir esos datos utilizando un paquete del Asistente SSIS. Este enfoque puede ahorrarle una cantidad significativa de tiempo y evitar explicaciones innecesarias cuando ocurran errores, porque tarde o temprano, ocurrirán.
Retrasar la restauración de registros en SQL Server puede ser una estrategia útil para tener en su conjunto de herramientas. Proporciona una capa adicional de protección contra desastres accidentales y le brinda la oportunidad de rectificar errores antes de que se propaguen al servidor secundario. Si bien el reflejo de bases de datos se ha convertido en el método preferido para una recuperación rápida, el envío de registros con un retraso aún puede ser una opción valiosa en ciertos escenarios.