Migración de datos de SQL Server 2005 a 2016

Soy nuevo en la administración de SQL Server, pero me siento cómodo con el lenguaje SQL y con la creación de paquetes SSIS.

Quiero migrar datos de SQL Server 2005 a 2016.

Mi pregunta es si debo preocuparme por las bases de datos del sistema y otros objetos, como índices, procedimientos almacenados, vista, seguridad y permisos. inicios de sesión o solo puedo migrar datos.

Cuál sería el procedimiento recomendado en este caso.

Max dio una respuesta decente que votaré una vez que termine de escribir esta vista alternativa.

No soy un fanático de restaurar las bases de datos del sistema cuando realizo una migración de actualización y prefiero realizar migraciones en lugar de las actualizaciones en el lugar, como lo mencioné en esta larga respuesta a otra pregunta.

Básicamente me gusta comenzar "fresco" cuando hago una migración. Encuentro que jugar con las migraciones y actualizaciones de la base de datos del sistema a través de la restauración a veces causa frustraciones con las restauraciones y puede llevar a posibles pecados.

También preguntaste sobre índices, procedimientos almacenados, vistas. Esos elementos en el nivel de la base de datos deben vivir dentro de una base de datos de usuario. Por lo tanto, cuando restaure la base de datos X al nuevo servidor, todos los objetos de la base de datos (tablas, usuarios, vistas, procesos, funciones, etc.) también estarán allí.

Lo que existe en las bases de datos del sistema son trabajos, inicios de sesión, alertas, servidores vinculados, claves de cifrado, etc. Elementos de nivel de instancia.

Me gusta revisarlos y migrar sobre lo que necesito usando varios scripts, últimamente son los scripts DBATools.Io powershell. Me gusta usar su script para copiar inicios de sesión SQL especialmente, porque maneja a los usuarios autenticados de SQL manteniendo sus contraseñas e identificadores de seguridad iguales para que los usuarios de la base de datos de esos inicios de sesión funcionen. También tienen un comando completo de migración de SQL Server que ejecuta sus subcomandos para copiar los elementos que normalmente copiaría.

No creo que Max esté equivocado con esa respuesta, de ahí el voto a favor. Acabo de tener más éxito y más suerte y me siento más cómodo migrando a una nueva en lugar de tratar de restaurar las bases de datos del sistema entre versiones. Diría que honestamente no puedo recordar la última vez que hice una migración de actualización de versión y no lo hice de esta manera en lugar de restaurar las bases de datos del sistema.

Debería considerar la migración de las bases de datos del sistema (maestro, msdb y quizás modelo), si necesita acceder a los metadatos almacenados en esas bases de datos.

Master almacena artículos como inicios de sesión, certificados de seguridad, etc.

msdb contiene detalles sobre copias de seguridad y almacena configuraciones de trabajo del Agente SQL Server, entre otros detalles.

El modelo puede haber sido personalizado por usted o su equipo para permitir que las bases de datos en blanco recién creadas contengan un conjunto de objetos predefinidos que utiliza en cada base de datos.

La migración de las bases de datos del sistema se puede lograr con bastante facilidad; MSDN ofrece instrucciones detalladas en Copia de seguridad y restauración de bases de datos del sistema (SQL Server) .

Dependiendo de sus requisitos, puede realizar una BACKUP DATABASEoperación contra las bases de datos de usuario en la instancia de 2005 y luego RESTORE DATABASEen la instancia de 2016 para traer toda la base de datos, incluidos todos los datos, índices y otros objetos.

Esto, al menos inicialmente, requerirá la misma cantidad de espacio consumido por la base de datos en la instancia de 2005. Sin embargo, una vez que haya restaurado la base de datos, puede aprovechar la compresión de datos para reducir sustancialmente la huella requerida.

Consulte Acerca de trabajar con copias de seguridad de SQL Server para obtener detalles sobre cómo realizar copias de seguridad y Acerca de los escenarios de restauración para obtener detalles sobre las restauraciones.

¿Es para 2012 o 2016? Hace una diferencia en eso, IIRC 2012 es una ruta de migración probada mientras que 2016 no lo es. Como tal, los problemas conocidos están documentados y / o serán detectados por Upgrade Advisor para 2012. Una ruta no probada aún podría funcionar sin ningún problema, es simplemente desconocido. Dicho esto, te recomiendo que vayas a 2016. Sospecho que el esfuerzo será casi el mismo.

Consulte ¿Está actualizando desde SQL Server 2005? en la documentación para las opciones de actualización de 2005 y enlaces a un proceso de actualización muy detallado. El proceso de actualización se escribió para 2014 pero aún es aplicable para 2016.