Estamos ejecutando nuestro software ERP en un servidor SQL Server 2016 como máquina virtual en VMware ESXi. Actualmente, tenemos la máquina virtual configurada con 2 unidades, los datos van a una y los registros a la otra. Tuvimos un problema cuando la VM se corrompió y volvimos a una copia de seguridad de VEEAM. La restauración tomó bastante tiempo, pero fue exitosa. Desafortunadamente, esto resultó en la pérdida de aproximadamente 4 horas de datos. Y como los registros de transacciones fallaron con el servidor, no pudimos restaurarlos desde los registros de transacciones.
Entonces pensamos en escribir los registros de transacciones en otro recurso compartido de red. Pero al intentar configurarlo en una base de datos de prueba, parece que SQL Server no lo permite.
¿Hay alguna manera de hacer esto? ¿Hay un impacto significativo en el rendimiento? ¿Existe un mejor enfoque?
Respuesta1
¿Hay alguna manera de hacer esto?
Sí, pero probablemente no quieras hacer esto. Puedes habilitarBandera de seguimiento 1807para que SQL Server utilice una ruta UNC para sus datos y archivos de registro. Sin embargo, de esa documentación:
Microsoft generalmente recomienda utilizar una red de área de almacenamiento (SAN) o un disco conectado localmente para almacenar los archivos de la base de datos de Microsoft SQL Server porque esta configuración optimiza el rendimiento y la confiabilidad de SQL Server.
(Aunque la documentación vinculada indica que SQL 2016 debería permitir esto de forma predeterminada, deberá explicar "parece que SQL Server no lo permite").
¿Hay un impacto significativo en el rendimiento?
Eso dependeen su hardware. Depende de dónde esté el almacenamiento "local": discos giratorios dentro del host ESXi, en una SAN o en otro lugar. Y depende del almacenamiento subyacente al recurso compartido de red que está considerando utilizar. Es posible que terminen usando el mismo hardware, en cuyo caso las diferencias de rendimiento podrían reducirse a una pequeña sobrecarga de VMware. Microsoft entra en detalles sobre las consideraciones de rendimiento en el documento vinculado anteriormente.
¿Existe un mejor enfoque?
Sí
Los archivos de registro de transacciones en sí (normalmente *.ldf) no son lo que desea utilizar para restaurar tras un desastre. Es apropiado tenerlos locales en el servidor. Y colocarlos en una unidad separada de los archivos de datos (normalmente *.mdf), como lo ha hecho, es algo bueno.
Cuando tiene un desastre y necesita restaurar desde una copia de seguridad, restaura desde una copia de seguridad completa, luego posiblemente desde algunas copias de seguridad diferenciales y luego posiblemente desde algunas copias de seguridad del registro de transacciones. Por lo tanto, deberías escribir tucopias de seguridada una ubicación alejada de su servidor. O como mínimo, si debe escribirlos localmente, tenga un proceso que los copie inmediatamente en otro lugar. Como habrá descubierto, muchos tipos de fallas hacen que todos los datos locales queden inutilizables.
Existen muchos tutoriales sobre cómo establecer un mecanismo de copia de seguridad adecuado.Brent Ozar IlimitadoTiene varios buenos.