¿Debo migrar datos usando separar / copiar / adjuntar o mediante copia de seguridad-restauración-reproducción?


17

Estoy a punto de embarcarme en la migración de archivos de base de datos a una nueva SAN (desde una SAN anterior) y tengo un par de opciones para implementar esto. (1) Se sugirió que considerara el nivel de esfuerzo de restaurar una copia de seguridad completa en una nueva base de datos en el servidor. Sin embargo, (2) mi plan original era copiar los archivos de la antigua SAN a la nueva SAN desconectando y volviendo a conectar la base de datos.

Mi instinto me dice que prefiero separar, copiar y adjuntar, ya que parece más a prueba de fallas, pero eso puede ser mi ingenuidad. No quiero perder una transacción o de alguna manera "romper algo" en el proceso de renombrar bases de datos.

Supongo que mi pregunta es si estoy o no justificado en mi escepticismo de la opción BACKUP-RESTORE-Replay y cuáles son otros méritos o riesgos de esa opción.

Respuestas:


16

Personalmente, evitaría los mecanismos de desconexión / conexión. Especialmente en SQL Server 2000, simplemente no confío en que siempre recuperará el servidor y podrá adjuntar esos archivos. He escuchado muchas historias en las que esto no sucedió limpiamente, solo porque tenga un Plan B no hace que el Plan A sea sensato automáticamente.

Con la copia de seguridad / restauración, no corre el riesgo de tener que ir al Plan B. Si la copia de seguridad falla, su base de datos aún está activa. Si la restauración falla, su base de datos anterior aún está activa. En ambos casos, puede restaurar el funcionamiento de la base de datos original y volver a visitar el plan más adelante. Además de la seguridad adicional aquí sobre detener SQL Server y / o desconectar, esto también significa que puede probar el hoo-has fuera de la metodología de copia de seguridad / restauración (suponiendo que actualmente tenga el espacio para realizar las copias de seguridad y otra instancia para probar el restaurar). Realmente no puede probar el enfoque de desconexión sin separar las bases de datos o detener SQL Server, y eso es difícil de hacer fuera de una ventana de mantenimiento adecuada. Y finalmente, con los otros enfoques, ni siquiera puedes comenzar a copiar los archivos hasta que hayas desconectado o derribado SQL Server.

Otro beneficio sobre el método pull-the-drive-out-from-under-SQL-Server: con copia de seguridad / restauración puede mover varios archivos a letras de unidad diferentes de lo que eran antes. Por ejemplo, cuando migramos a una nueva SAN, pudimos tener más volúmenes, por lo que pudimos mover tempdb a T: \ (que no existía antes), algunos de los datos y archivos de registro a nuevas letras de unidad, etc. para utilizar mejor toda la nueva capacidad de E / S que teníamos. Si simplemente cierra SQL Server y luego cambia los discos, debe tener las mismas letras de unidad y la misma cantidad de volúmenes.


7

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.


2

Primero, consideraría la opción de simplemente usar la función de la matriz de almacenamiento para manejar el movimiento de datos. Si no están disponibles porque el proveedor no lo admite, no lo compró, o el administrador de SAN no sabe cómo hacerlo ...

Entonces simplemente usaría los siguientes pasos.

  1. Presente el nuevo almacenamiento al servidor SQL.
  2. Detener los servicios SQL
  3. COPIE todos los datos de la unidad anterior a la nueva unidad (no olvide incluir los permisos si usa robocopy)
  4. Elimine las letras de las unidades antiguas.
  5. Cambie las letras de unidad en las nuevas unidades para que coincidan con las letras de unidad anteriores
  6. Inicie los servicios SQL

Eso es.

No es necesario separar / adjuntar, por lo que SQL Server sabe, nada ha cambiado. Y si algo sale terriblemente mal, tiene la copia anterior de las bases de datos en el antiguo LUN en la matriz de almacenamiento anterior. Fallar es solo una cuestión de cambiar las letras de unidad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.