none
Migracion de SQL Server 2008 R2 a SQL Server 2016 RRS feed

  • Pregunta

  • Hola a todos

    Estabamos acostumbrados a utilizar UPGRADE ADVISOR y PROFILER (trazas) para migrar una base de una version inferior a otra superior.

    UPGRADE ADVISOR se ha depreciado y sustituido por DATA MIGRATION ASSISTANT.

    PROFILER, por ser un producto "agresivo" con la operacion de las bases de datos, se ha sustituido por XE (Extended Events).

    El problema, es que en la version 2008 R2, no existe XE, ya que esta opcion aparece en la version 2012.

    ¿Alguin sabe de algun PLAN DE MIGRACION que se pueda aplicar de 2008 R2 a 2016?

    Saludos y gracias por cualquier comentario al respecto.

    martes, 22 de mayo de 2018 17:48

Todas las respuestas

  • Extended events si existe en 2008 R2 (mas no tiene interfas grafica).

    No se si los nuevos SSMS dotaron a 2008 R2 ya de interfaz no he intentando, pero mi pregunta seria para que usas profiler para una migración? desempeño seria lo unico que se me ocurre y aun asi no creo que sea una buena practica.

    El mejor plan seria el DMA para ver si tienes algo que ya no se usa o que tengas arreglar, sacar backups, hacer restore, refrescar orphan users, checkdb, re crear indices, actualizar estadisticas y probar. 


    Blog: www.sqlservertoolbox.blogspot.com.mx


    • Editado Enrique AA miércoles, 23 de mayo de 2018 0:57
    martes, 22 de mayo de 2018 21:46
  • Muchas gracias Enrique

    Tienes razon, he probado migrar de 2012 a 2016 mediante DMA y si, tiene lo que es la MIGRACION como tal, que aca entre nos, se me hace un vil "parche", ya que solo hace un BACKUP FULL de la base fueente y un RESTORE de la misma base en el el servidor destino.

    Eso, ya lo hacia con un par de scripts que tenia desarrollados para realizar dicho trabajo.

    No hace el cambio de NIVEL DE COMPATIBILIDAD, cosa que no me preocupa, ya que tengo el script que hace dicho cambio para TODAS las bases restauradas.

    ¿Porque PROFILER?

    Simple, muchos desarrolladores tienen la mala construmbre de enviar instrucciones T-SQL desde la capa CLIENT, ¿como sabes que instrucciones ya no estan soportadas para la nueva version? (en el laboratorio que hice, 2016)

    Eso se hacia generando unas trazas (trc) que capturaban todas las instrucciones T-SQL y se le pasaban al UPGRADE ADVISOR.

    Esa es la parte que aun no he podido resolver.

    Hice un par de manuales en español, del laboratorio que hice en el uso del DMA, si alguien le interesa MIGRACION y ASSESMENT, solo tienen que pedirlo.

    Aclaro, la migracion que hice fue de on-premise a on-premise, aun no llego a Azure.

    Saludos

    martes, 22 de mayo de 2018 22:51
  • Saludos,

    Aun asi profiler funciona en 2016, aunque entiendo tu punto y me parece bueno se me hace un poco intrusivo. Una de las razones por la que no se cambia el compatibility level es el preservar la experiencia de usuario pasada, lo que mencionas va mas haya de una migracion y mas del tuning, lo cual se deberia de hacer previamente a la migracion productiva, esto se hace en el are de desarrollo y quality assurance. 


    Blog: www.sqlservertoolbox.blogspot.com.mx

    miércoles, 23 de mayo de 2018 0:56
  • 100% de acuerdo contigo, siempre y cuando, se tuviera el tiempo para realizar la revision y aplicar los cambios, te hablo de un cliente que tiene una buena cantidad de bases de datos 2008 R2 y te contrata para migrara a 2016.

    Como veras, la respuesta que el cliente espera es, "estas si, estas no, hay que hacer modificaciones a estos procedimientos y a estas aplicaciones".

    ¿Porque?

    El area de desarrollo, siempre esta al tope y te diran que no tienen tiempo para revisar sus aplicativos y ver cuales si cumplen y cuales no.

    Me he encontrado con clientes a los cuales les entregas el resultado final y te dicen, "gracias, creo que no vamos a  migrar, son demasiados los cambios a realizar y no tenemos tiempo para eso", prefieren quedarse en su version actual.

    He estado revisando DMA y la verdad que esta muy completo, incluso encontre algunos reportes en PowerBI, que toma el resultado de los archivos JSON y emite una serie de dashboards que reflejan el % de exito que se puede tener en una migracion on-premise a on-premise o bien de on-premise a Azure, lo malo, que no encontrado como analizar ese codigo T-SQL que viene desde la capa CLIENT, sin "pegarle" al tiempo de repuesta en bases de datos productivas.

    Muchas gracias por su tiempo, Saludos



    miércoles, 23 de mayo de 2018 17:18
  • Hola.

    Para lo correspondiente a los developers T-SQL, te diría que revises SQL Prompt, sobre todo para encontrar algunos T-SQL code smells e incluso hacer algo de refactoring en dicho código. Ojo, esto va a mejorar algo dicho código T-SQL, pero pues si usan cursores o tienen aspectos a revisar con los índices, entre otros aspectos, pues si hay que entrar a revisar no solo como mejorar eso sino qué deberían tener en cuenta para pasar de 2008 R2 hacia 2016.

    Revisa lo que dice el fabricante en su guía: Upgrade SQL Server. Ahí te dan muy buena información sobre que cosas tener en cuenta para que tu BD y el código T-SQL asociado, quede en dicha versión. Microsoft sacaba un excelente documento de referencia para esto, como se aprecia en este post en mi blog, pero solo lo generó para SQL Server 2014. Igual, descárgalo que muchas cosas de éste, en conjunto con el sitio Web, te ayudarán.

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    jueves, 24 de mayo de 2018 18:19
  • Guillermo

    Muchas gracias por la informacion, la tomare en cuenta para la junta de informacion que tendre la proxima semana con el cliente.

    Saludos

    viernes, 25 de mayo de 2018 17:14
  • Buenas tardes Amigo 

    Podrías apoyarme a proporcionarme tu información, me seria de gran ayuda, ahora mismo debo migrar BD de Sqlserver 2008 R2 a Sqlserver 2016.

    Espero puedas ayudarme, saludos.... 

    martes, 14 de julio de 2020 22:56
  • Buenas tardes a todos

    PROFILER, fue sustituido por DEA, Database Experimentation Assistant

    https://www.microsoft.com/en-us/download/details.aspx?id=54090

    Primero ejecutas DEA, tomas los archivos .TRC, se debe hacer en linea, no es intrusivo

    Segundo ejecutas DMA (Assessment), aunque si, es un BACKUP-RESTORE, te hace todo un análisis de código depreciado y otras yerbas, aquí, puedes pasarle las trazas para que analice ambas cosas.

    Si todo va bien, ejecutas DMA (Migración) y fin del ciclo. Cambias nivel de compatibilidad, regeneras indices .

    Ya lo he realizado varias veces con cliente que me han pedido migrar, desde 2008 a versiones superiores, sin problema alguno.

    Bueno si, hay clientes muy grandes que por el tamaño de los problemas encontrados, te pueden decir, "Excelente, pero no tengo, ni el tiempo, ni el personal para realizar las modificaciones que me indicas"

    Otro caso, he tenido clientes que tienen como sistema un "muegano" que nadie sabe en donde están los fuentes o bien, el que los hizo, ya no labora en la compañía.

    En AZURE, existe el mismo servicio de DMA solo que cambia de nombre

    Saludos



    IIslas Master Consultant SQL Server

    miércoles, 15 de julio de 2020 0:18