Solía mover bases de datos casi constantemente, debido a la reconfiguración de SAN y las migraciones.
Suponiendo que está moviendo un servidor completo a la vez, iría con algo como su ruta # 2. (Si está moviendo una base de datos a la vez, y eventualmente está haciendo todas las bases de datos en un servidor, eso sería más problemático ya que tendría que cambiar las rutas a los archivos).
Tenga en cuenta que "usuario único" no necesariamente significa USTED. Puede ir a DBCC CHECKDB una base de datos y no poder ingresar porque ya hay alguien allí. Prepare un script que pueda ejecutar para arrancar "todos menos usted" de una base de datos y mantenerlo en un lugar práctico. Tenga en cuenta que SQL 2000 no tiene las mismas características de "mantener a todos fuera" como las versiones más modernas.
Un viejo truco es pausar el servicio de SQL Server. Esto evitará nuevos inicios de sesión, pero cualquiera que ya esté conectado puede continuar como de costumbre. Entonces: conéctese a través de una ventana SSMS para que pueda trabajar, luego pause el servicio, luego elimine las conexiones indeseables, haga lo suyo a través de la ventana de comandos SSMS (no la GUI, hace y rompe muchas conexiones) y luego pause el servicio. Advertencia: no estoy seguro de cómo se desarrollaría eso en un clúster. Es posible que desee realizar una conmutación por error.
Es útil tener una manera de mantener a todos los usuarios de la aplicación fuera de un servidor hasta que haya terminado su trabajo. De lo contrario, las conexiones pueden comenzar a aparecer mientras intenta hacer cosas, lo que puede conducir a la contención de recursos y / o la lentitud. He utilizado las siguientes formas en el pasado, dependiendo de la situación exacta: Apagar el servidor de aplicaciones Uso de ALTER DATABASE .. SET RESTRICTED_USER (Si las cuentas de la aplicación son miembros de los roles db_owner, sysadmin o dbcreator, eso es un problema. ) Informar a los usuarios que el sistema estará desconectado en un momento específico, como un domingo por la mañana. (Esto no funcionará en un entorno "real" 24x7). Desenchufe la NIC que está frente a los servidores o usuarios de la aplicación. (En este caso, podría ingresar a través de otra NIC conectada a una red solo para administradores oa través de la OIT).
Separar una gran cantidad de bases de datos y volver a conectarlas puede ser mucho trabajo. Si hace eso, asegúrese de tener su script "adjuntar" escrito antes de tiempo.
He tenido mucho éxito al detener SQL Server, copiar todo, cambiar las letras de unidad e iniciar SQL Server. No separar / adjuntar. Mientras SQL Server esté apagado y esté copiando (no MOVIENDO) archivos, no puede tener demasiados problemas, incluso si está moviendo las bases de datos del sistema. Como las rutas son las mismas, SQL Server no se dará cuenta de que algo ha cambiado mientras el servicio estaba apagado. Solo asegúrese de que las letras de unidad apunten a los volúmenes correctos o las cosas le irán mal.
Mi problema más frecuente era no obtener las ACL en los directorios de archivos correctamente. Las versiones más modernas de SQL Server son mejores para establecer solo los permisos que necesita la cuenta de servicio, mientras que las versiones anteriores parecen menos exigentes. Si olvida configurar las ACL y la cuenta de servicio no es un administrador local (no es que lo recomiendo), una o más bases de datos pueden no abrirse cuando se inicia la instancia. No entre en pánico, solo cambie las ACL y adjunte la base de datos.
Generalmente uso ROBOCOPY para hacer este tipo de trabajo. Hay un interruptor de línea de comando para preservar las ACL.
Usar un cálculo / verificación CRC no es una mala idea, pero nunca lo he hecho. Cuando las bases de datos vuelven a funcionar, ejecuto CHECKDB () en todas ellas. Por lo general, prepararé un script para esto con anticipación, en lugar de confiar en iniciar manualmente un trabajo de mantenimiento. De esa forma, puedo verificar primero un par de bases de datos más pequeñas antes de verificar una base de datos grande que puede tardar muchos minutos u horas en ejecutarse. Dudo que una comprobación de CRC (o una herramienta de comparación de datos de Redgate) encontrara algo que CHECKDB () no vería, y si lo hiciera, SQL Server no podría solucionarlo.
Después de copiar los archivos, pero antes de reiniciar la instancia, iré y cambiaré ligeramente la ruta de archivo de las carpetas ANTIGUAS cambiando el nombre de una de las carpetas. Esta es una verificación adicional contra el problema "¡Uy, el servidor todavía está apuntando a los archivos antiguos"!
No tenga prisa por soltar los archivos antiguos y recuperar espacio en el almacenamiento anterior y asegúrese de que sus copias de seguridad completas se hayan ejecutado correctamente. Pruebe restaurar un par de esas copias de seguridad en otro lugar. Una vez que tenga buenas ejecuciones de checkdb () y buenas copias de seguridad completas, puede pensar en dejar ese viejo almacenamiento y cerrar el Lefthand.
Los peores problemas que he tenido con estas migraciones han sucedido después de pensar que había terminado. Ese sería el administrador de SAN diciéndome que algo había sucedido y que mis sistemas de archivos estaban codificados. (Repartido, reformateado, copiado nuevamente).
Otro problema divertido es que la SAN es lenta sin razón aparente. Si cree que tomará 10 horas copiar sus datos y está copiado en un 30% en la hora número 9, tiene un problema. Observe los tiempos de transferencia (la robocopia muestra% copiado y proporciona estimaciones de tiempo, o puede usar Perfmon) y tenga un plan alternativo si algo sale raro.
Además, no estoy seguro de si sus volúmenes se dividirán para usted, pero es posible que desee asegurarse de que estén utilizando un desplazamiento de 1 MB. En Windows Server 2008 y superior, esto no debería ser un problema. En sistemas operativos más antiguos, lo es. Hay un montón de cosas en Google sobre esto, y sus chicos de almacenamiento deberían saberlo, pero yo preguntaría.
