Mover la base de datos de SQL Server a un nuevo disco mientras está en línea

11

Tengo una base de datos de SQL Server de 1.4TB que está luchando masivamente con las E / S de disco. Hemos instalado una nueva matriz SSD en el servidor que resolverá todos nuestros problemas, solo estamos debatiendo la mejor manera de mover la base de datos. Idealmente, si podemos hacerlo sin tiempo de inactividad, eso es lo mejor. Pero donde la elección es entre dos días de bajo rendimiento (por ejemplo, al copiar datos) versus dos horas de tiempo de inactividad, este último podría ser preferible.

Hasta ahora, las soluciones que hemos encontrado son:

  • Copia simple Desconecte la base de datos, copie los archivos, cambie las ubicaciones en SQL Server y vuelva a ponerla en línea. Cifras aproximadas estiman que esto tomará hasta cinco horas, lo cual no es realmente aceptable, pero es la solución más fácil.

  • Copia a nivel de bloque. Usando una utilidad similar a rsync, copiamos los archivos en segundo plano mientras la base de datos está activa. Cuando estamos listos para migrar, desconectamos la base de datos, hacemos una copia diferencial utilizando esta utilidad, luego apuntamos al servidor SQL a los nuevos archivos y lo ponemos en línea. El tiempo aquí es desconocido. No sabemos cuánto tiempo llevará hacer un análisis diferencial de 1.4TB y copiarlo. Nuestra otra preocupación es que la copia a nivel de bloque dejará los archivos en algún estado ilegible por SQL Server y habremos perdido nuestro tiempo.

  • Migración SQL Cree un nuevo archivo de datos SQL de 1.4TB en el nuevo disco y desactive el crecimiento automático en todos los demás archivos. Luego ejecute DBBC SHRINKFILE (-file_name-, EMPTYFILE) en todos los demás archivos de datos a su vez. Una vez que todos los datos estén disponibles, tomaré una ventana programada en algún momento para mover el archivo MDF al SSD y eliminar los otros archivos no utilizados. Me gusta esto porque minimiza el tiempo de inactividad. Pero no tengo idea de cuánto tiempo llevará esto y si causará degradación en el rendimiento mientras está sucediendo.

No tenemos ningún tipo de entorno de carga y rendimiento para probar esto. Puedo verificar que las estrategias funcionarán en nuestro entorno de preparación, pero no el impacto ni el rendimiento.

sql-server ssd seamus
fuente
¿Sus archivos de datos están almacenados en una partición LVM?
Marco
1
don't know how long it will take to do a differential analysis of 1.4TBal menos el tiempo necesario para leer esos datos. No creo que la idea de rsync ahorre mucho o nada. rsync está hecho para hacer frente a redes lentas.
usr
2
En lugar de usar EMPTYFILE, reconstruiría todos los índices en un nuevo grupo de archivos que se encuentra en el SSD. De esa manera, los índices parecen agradables y desfragmentados. EMPTYFILE podría fragmentarlos, no estoy seguro.
usr

Respuestas:

14

Un método para mover toda la base de datos es con BACKUPy RESTORE. La base de datos no estará disponible durante el cambio final, pero el tiempo de inactividad debería ser mínimo con la planificación. Este procedimiento asume el modelo FULLo BULK_LOGGEDrecuperación:

1) Realice una copia de seguridad COMPLETA (o use la existente).

2) Restaure la última copia de seguridad completa en un nombre de base de datos diferente, especificando la WITH MOVEopción de reubicar archivos en el almacenamiento SSD según lo desee y la NORECOVERYopción para que se puedan restaurar las copias de seguridad diferenciales y de registro posteriores.

3) Aplique cambios incrementales a la nueva base de datos hasta el momento del corte final con copias de seguridad del registro de transacciones y RESTORE...WITH NORECOVERY. Esto minimizará el tiempo de inactividad para el cambio final a la nueva base de datos.

4) Para cambiar a la nueva base de datos, desconecte la aplicación, realice una copia de seguridad final del registro de transacciones y aplique a la nueva base de datos WITH RECOVERY. Finalmente, cambie el nombre de la base de datos original a un nombre diferente y cambie el nombre de la base de datos reubicada al nombre original. Descarte la base de datos anterior a su conveniencia.

En el modelo de recuperación SIMPLE, podría usar un proceso similar pero sin el paso 3 de la copia de seguridad / restauración del registro de transacciones. En su lugar, use una copia de seguridad / restauración de base de datos diferencial en el paso final. Eso puede requerir más tiempo de inactividad, dependiendo de la cantidad de cambios desde la FULLcopia de seguridad inicial .

Dan Guzman
fuente
Sí, nada viene a la mente como el más simple y rápido para el mismo movimiento db del servidor.
Marian
-6 
Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.
Avinash Mendse
fuente
2
Recibes votos negativos porque no estás respondiendo la pregunta. Solo hay un servidor en la situación en discusión.
AakashM
También un buen enfoque para mover dbs son la duplicación, el envío de registros, los grupos de disponibilidad, las copias de seguridad y otros. Esto no resuelve los problemas, desafortunadamente.
Marian
En un servidor podemos crear dos instancias y hacer replicación entre dos instancias.
Avinash Mendse