SQL Server - Migración de bases de datos

Zuljin · 29 Agosto 2024

Acá nos va a llegar una licencia de SQL Server 2022 Standard para reemplazar una base de datos SQL Server 2012 Standard.

En el SQL Server 2012 hay bases de datos de tres aplicaciones no críticas más las bases de datos de un sharepoint del año de la corneta.

Debido a que ese Sharepoint es compatible únicamente con SQL Server 2012 es que no puedo hacer un upgrade in place que así que no me queda otra que esta nueva licencia de SQL Server 2022 montarla en un servidor distinto.

Consideren de que se cuenta con una ventana de mantenimiento en que las aplicaciones que acceden a la base de datos se pueden apagar, así los respaldos serían consistentes.

¿Ustedes se han enfrentado a migraciones de sql server?
¿Cómo han hecho el movimiento de datos? ¿Respaldos a disco y luego subirlos en el otro servidor?
¿O utilizan la funcionalidad de migración del Management Studio?

Como les mencionaba, las aplicaciones no son críticas y se pueden bajar durante horas así que los respaldos y la migración con el Management Studio serán íntegras y consistentes.

Gracias y adelante estudio.

ranamaldita · 29 Agosto 2024

Yo prefiero el exportar e importar aunque no es muy rapido, mas si la DB esta en full backup mode. El otro metodo es detach y attach. Ambos requieren llevar las DB offline.

El wizard del management studio funciona, pero cuando pregunta por el metodo 1 es el detach y attach (db offline) y el otro que copia objetos no mas, este te permite seguir utilizando la DB si es critica, al final igual es pajero porque no copia indices y esas weas las hace post.

Si es harta data y hay tiempo yo prefiero detach y re attach, nunca he tenido problemas.

Soujiro · 29 Agosto 2024

las veces que me toca hacer eso de "migrar" db, sea lo que sea, prefiero sacar un backup completo con el proceso standar de backups (crontab/shedulded task), apagar la db principal para que nadie se meta a hacer hueas y RESTAURAR EL BACKUP, asi me aseguro que los backups funcionan. y no estamos haciendo burradas

Zuljin · 29 Agosto 2024

Olvidé mencionar que el tamaño de las bases de datos es poco, 20 gigas a todo reventar, así que el tiempo de respaldo y restauración es relativamente bajo y el espacio en disco es super manejable.

Menciono esto porque cuando me tocó hacer la migración de la base de datos Oracle hace 11 años la pude hacer con export/import lógicos porque la base de datos pesaba 300 gigas. Y cuando hice la última migración hace 2 años la base de datos ya pesaba 20 teras así que no era opción export/import, por lo que mi alternativa fue aplicar dataguard.

unreal4u · 29 Agosto 2024

Si son 20GB no más y te puedes permitir downtime, para qué irse por la compleja? Aplique apagado completo no más.

Saludos.

Zuljin · 29 Agosto 2024

¿Cómo lo hacen con el manejo de las cuentas de acceso? ¿Se van con el respaldo o las crean antes?

Como ven no soy del mundo SQL Server, así que prefiero preguntar hueas antes de que omitir algo importante.

cliobrando · 29 Agosto 2024

En SQL server la info de login se guarda en la DB 'master', la info de usuarios se guarda individualmente en cada db.
Puedes hacer un backup de los logins y resturarlos en la db master destino:

Transfer logins and passwords between instances - SQL Server

This article describes how to transfer the logins and the passwords between different instances of SQL Server running on Windows.

learn.microsoft.com

Harima · 29 Agosto 2024

Zuljin dijo:
¿Ustedes se han enfrentado a migraciones de sql server?

más de las que un ser humano se debería enfrentar en su vida

Zuljin dijo:
¿Cómo han hecho el movimiento de datos? ¿Respaldos a disco y luego subirlos en el otro servidor?

En el caso como el tuyo, levante un ambiente de prueba copie la BD y luego cuando llego el día fue bajar la BD y copiar al nuevo server (Full backup)
si mal no recuerdo (esto fue hace como 10 años) que los usuarios de sharepoint van todos en la misma BD de sharepoint

Eso levantar un segundo ambiente apuntando a la nueva BD cosa de hacer las pruebas de login y esas cosas, luego el día del paso bajas la BD antigua la copias al nuevo server y apuntas a ese nuevo server, recuerda que en sql debes levantar las BD en modo compatibilidad con la misma versión que tiene en el server antiguo

Zuljin · 29 Agosto 2024

Harima dijo:
más de las que un ser humano se debería enfrentar en su vida
Ver adjunto 38032

En el caso como el tuyo, levante un ambiente de prueba copie la BD y luego cuando llego el día fue bajar la BD y copiar al nuevo server (Full backup)
si mal no recuerdo (esto fue hace como 10 años) que los usuarios de sharepoint van todos en la misma BD de sharepoint

Eso levantar un segundo ambiente apuntando a la nueva BD cosa de hacer las pruebas de login y esas cosas, luego el día del paso bajas la BD antigua la copias al nuevo server y apuntas a ese nuevo server, recuerda que en sql debes levantar las BD en modo compatibilidad con la misma versión que tiene en el server antiguo

¿Por qué habría que levantar las bases de datos en modo Compatibilidad? ¿Si la levanto en el el modo compatibilidad de SQL Server 2022 nomás se rompería algo?

Harima · 29 Agosto 2024

Zuljin dijo:
¿Por qué habría que levantar las bases de datos en modo Compatibilidad? ¿Si la levanto en el el modo compatibilidad de SQL Server 2022 nomás se rompería algo?

las BD en SQL tienen versión, si levantas con una versión moderna, puede ser que el driver de conexión de la aplicación no funcione correctamente, o cosas como procedimientos almacenados y ese tipo de hiervas no funcionen. por sanidad mental la tienes que levantar con la misma versión que tiene en el server original.
en si no el servidor entero solo la BD, cuando la importes o restaures, a esa BD le pones que sea la misma versión que tiene la que esta en producción (la debería tomar por defecto, pero es mejor verificar ese tipo de cosas)

Zuljin · 29 Agosto 2024

Harima dijo:
las BD en SQL tienen versión, si levantas con una versión moderna, puede ser que el driver de conexión de la aplicación no funcione correctamente, o cosas como procedimientos almacenados y ese tipo de hiervas no funcionen. por sanidad mental la tienes que levantar con la misma versión que tiene en el server original.
en si no el servidor entero solo la BD, cuando la importes o restaures, a esa BD le pones que sea la misma versión que tiene la que esta en producción (la debería tomar por defecto, pero es mejor verificar ese tipo de cosas)

Comprendo.
Igual ya hice las pruebas de funcionalidad y andan bien con la compatibilidad de SQL Server 2022.

cliobrando · 29 Agosto 2024

Harima dijo:
las BD en SQL tienen versión, si levantas con una versión moderna, puede ser que el driver de conexión de la aplicación no funcione correctamente, o cosas como procedimientos almacenados y ese tipo de hiervas no funcionen. por sanidad mental la tienes que levantar con la misma versión que tiene en el server original.
en si no el servidor entero solo la BD, cuando la importes o restaures, a esa BD le pones que sea la misma versión que tiene la que esta en producción (la debería tomar por defecto, pero es mejor verificar ese tipo de cosas)

El driver no tiene que ver con la compatibilidad de la DB (tiene que ver más con el motor), la compatibilidad de la db tiene que ver con la funcionalidades habilitadas, por lo general es recomendable subir la compatibilidad a la nativa del motor, todas las ventajas de rendimiento o paralelismo se obtienen con la versión nativa.
No tengo memoria de alguien que haya tenido problemas aplicativos subiendo la versión nativa de compatibilidad.

Además cuando MS depreca alguna funcionalidad, lo hace directamente en el motor, no en la compatibilidad de la DB.
Edit: Adjunto documentación oficial.

ALTER DATABASE compatibility level (Transact-SQL) - SQL Server

Sets Transact-SQL and query processing behaviors to be compatible with the specified version of the Database Engine.

learn.microsoft.com

Harima · 29 Agosto 2024

cliobrando dijo:
No tengo memoria de alguien que haya tenido problemas aplicativos subiendo la versión nativa de compatibilidad.

suerte has tenido
estos dos valores son los que mas dan dolores de cabeza, a veces no se nota a la primera, pero luego lo notas en rendimiento o cuando se ejecutan ciertos SP y queda la escoba, y están ahí por algo

Recuerda que no siempre las aplicaciones usan los valores que trae el sistema si no que están en duro.

cliobrando · 29 Agosto 2024

Totalmente de acuerdo en la Collation, pero eso es un problema que puede pasar en cualquier DB, no solo en SQL Server.
El compatibility level nunca he visto una aplicación tener problemas al subirlo, es más, casi todas las ventajas de rendimiento se obtienen al subir de nivel de compatibilidad, por ejemplo en la versiones mas nuevas de SQL Server 2019 / 2022 hay operaciones que se ejecutan en multithread y eso son ganancias en rendimiento instantáneas.

Y en el caso de que tengas un problema puedes volver a bajar el nivel.

Edit: Me atrevo a preguntar si alguien ha subido el compatibility level y que haya tenido problemas documentados los comparta.

Harima · 29 Agosto 2024

cliobrando dijo:
Y en el caso de que tengas un problema puedes volver a bajar el nivel.

Por eso lo primero que le dije fue que levantar un ambiente de pruebas y validara la funcionalidad, en caso de tener problemas que use el modo de compatibilidad.

cliobrando dijo:
Edit: Me atrevo a preguntar si alguien ha tenido problemas al subir el compatibility level y que haya tenido problemas documentados los comparta.

Con las nuevas versiones no es tan común pero con 2000 hacia atrás eso era un verdadero problema, El problema más común actual es del cardinalidad, con lo cual genera una perdida de rendimiento en la BD, se puede forzar a usar el formato legacy para la cardinalidad, pero en esos casos es mejor usar la versión anterior.

Zuljin · 29 Agosto 2024

Igual en este sql server hay bases de datos que en mi experiencia las considero chicas, entonces aunque los planes de ejecución se llegasen a degradar producto del cambio de versión del motor (algo poco probable pero que igual ocurre), con el poder de procesamiento de la máquina virtual se sale jugando igual.

cliobrando · 29 Agosto 2024

@OP: SQL Server 2012 -> 2022
No podría hablar de upgrades de SQL 2000, o incluso 2005, a algo más actual, no me ha tocado ver algo así hace muuuuuuuuuuuucho tiempo.
En el caso de subir niveles de compatibilidad en versiones modernas (2008 - 2022) me imagino que es hasta difícil encontrar problemas en internet. Y lo más probable que los problemas no tengan que ver con la subida.

Harima · 29 Agosto 2024

cliobrando dijo:
@OP: SQL Server 2012 -> 2022
No podría hablar de upgrades de SQL 2000, o incluso 2005, a algo más actual, no me ha tocado ver algo así hace muuuuuuuuuuuucho tiempo.
En el caso de subir niveles de compatibilidad en versiones modernas (2008 - 2022) me imagino que es hasta difícil encontrar problemas en internet. Y lo más probable que los problemas no tengan que ver con la subida.

Zuljin dijo:
sharepoint del año de la corneta.

Por eso las recomendaciones

cliobrando · 29 Agosto 2024

Los sharepoint más nuevos tienen niveles de compatibilidad recomendados siempre y cuando se te presenten problemas "especificos".
Si no, da lo mismo el nivel.

Edit: esto tiene que ver porque el sharepoint se asocia a la versión de SQL Server con que se lanzó, si el sharepoint es del año del pico lo mas probable es que ni siquiera tenga el nivel de compatibilidad el SQL Server.

JedYX · 29 Agosto 2024

Comentario off: algunos "colegas" recordaron el nivel de compatibilidad, lo que me recordó amorosas discusiones con los dba del scotiabank por las migraciones realizadas a punta de attach, lo que hizo caer buena parte de los Sp que hacían uso de las herramientas de la versión más reciente.

Suerte con la migra..ña

SQL Server - Migración de bases de datos

Fundador

mueranse

Fanático

Fundador

I solve problems.

Fundador

Capo

Pegao al tarro

Fundador

Pegao al tarro

Fundador

Capo

Pegao al tarro

Capo

Pegao al tarro

Fundador

Capo

Pegao al tarro

Capo

Geek de carton...xD