{"id":35306,"date":"2019-10-31T22:03:32","date_gmt":"2019-10-31T19:03:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu\/"},"modified":"2020-12-15T02:10:03","modified_gmt":"2020-12-15T00:10:03","slug":"perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu","title":{"rendered":"Migraci\u00f3n de datos de la copia de seguridad de la nueva versi\u00f3n de MS SQL Server a una versi\u00f3n anterior","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Antecedentes<\/h2>\n

Una vez, para reproducir un error, necesit\u00e9 una copia de seguridad de la base de producci\u00f3n.<\/p>\n

Para mi sorpresa, me encontr\u00e9 con las siguientes limitaciones:<\/p>\n

    \n
  1. La copia de seguridad de la base se realiz\u00f3 en la versi\u00f3n SQL Server 2016<\/i> y no era compatible con mi SQL Server 2014<\/i>.<\/li>\n
  2. En mi computadora de trabajo, el sistema operativo utilizado era Windows 7<\/i>, por lo que no pude actualizar SQL Server<\/i> a la versi\u00f3n 2016<\/li>\n
  3. El producto soportado era parte de un sistema m\u00e1s grande con una arquitectura heredada muy vinculada y tambi\u00e9n acced\u00eda a otros productos y bases de datos, por lo que su implementaci\u00f3n en otra estaci\u00f3n podr\u00eda llevar mucho tiempo.<\/li>\n<\/ol>\n

    Teniendo en cuenta lo anterior, llegu\u00e9 a la conclusi\u00f3n de que era hora de algunas soluciones improvisadas.<\/a><\/noindex><\/p>\n

    Recuperaci\u00f3n de datos de la copia de seguridad<\/h2>\n

    Decid\u00ed usar una m\u00e1quina virtual Oracle VM VirtualBox<\/a><\/noindex> con Windows 10 (se puede obtener una imagen de prueba para el navegador Edge desde aqu\u00ed<\/a><\/noindex>). En la m\u00e1quina virtual se instal\u00f3 SQL Server 2016 y se restaur\u00f3 la base de datos de la aplicaci\u00f3n desde la copia de seguridad (las instrucciones<\/a><\/noindex>).<\/p>\n

    Configuraci\u00f3n del acceso a SQL Server en la m\u00e1quina virtual<\/h2>\n

    A continuaci\u00f3n, era necesario tomar algunos pasos para permitir el acceso a SQL Server desde el exterior:<\/p>\n

      \n
    1. Para el firewall, agregar una regla para permitir solicitudes en el puerto 1433<\/i>.<\/li>\n
    2. Es preferible que el acceso al servidor no se realice mediante autenticaci\u00f3n de Windows, sino a trav\u00e9s de SQL con nombre de usuario y contrase\u00f1a (es m\u00e1s f\u00e1cil configurar el acceso). Sin embargo, en este caso, no se debe olvidar habilitar la opci\u00f3n de autenticaci\u00f3n SQL en las propiedades de SQL Server.<\/li>\n
    3. En la configuraci\u00f3n del usuario en SQL Server, en la pesta\u00f1a User Mapping<\/i> especificar para la base de datos restaurada el rol de usuario db_securityadmin<\/i>.<\/li>\n<\/ol>\n

      Migraci\u00f3n de datos<\/h2>\n

      La migraci\u00f3n de datos en s\u00ed consta de dos etapas:<\/p>\n

        \n
      1. Migraci\u00f3n del esquema de datos (tablas, vistas, procedimientos almacenados, etc.)<\/li>\n
      2. Migraci\u00f3n de los propios datos<\/li>\n<\/ol>\n

        Migraci\u00f3n del esquema de datos<\/h3>\n

        Realizamos las siguientes operaciones:<\/p>\n

          \n
        1. Seleccionamos Tasks -> Generate Scripts<\/i> para la base a migrar.<\/li>\n
        2. Seleccionamos los objetos necesarios para la migraci\u00f3n o dejamos el valor predeterminado (en este caso, se crear\u00e1n scripts para todos los objetos de la base).<\/li>\n
        3. Especificamos la configuraci\u00f3n para guardar el script. Lo m\u00e1s conveniente es guardar el script en un solo archivo en codificaci\u00f3n Unicode. As\u00ed, en caso de fallo, no ser\u00e1 necesario repetir todos los pasos.<\/li>\n<\/ol>\n

          Despu\u00e9s de guardar el script, se puede ejecutar en el SQL Server de origen (versi\u00f3n anterior) para crear la base requerida.<\/p>\n

          Atenci\u00f3n:<\/b> Despu\u00e9s de ejecutar el script, es necesario verificar la correspondencia entre los ajustes de la base de datos del respaldo y la base de datos creada por el script. En mi caso, la configuraci\u00f3n de COLLATE estaba ausente en el script, lo que provocaba un error al transferir los datos y requer\u00eda rehacer la base de datos utilizando un script modificado.<\/p>\n

          Migraci\u00f3n de datos<\/h3>\n

          Antes de transferir los datos, es necesario desactivar la verificaci\u00f3n de todas las restricciones en la base de datos:<\/p>\n

          EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'<\/code><\/pre>\n
          La transferencia de datos se realiza mediante el asistente de importaci\u00f3n de datos Tareas -> Importar datos<\/i> en SQL Server, donde se encuentra la base de datos creada por el script:<\/p>\n
            \n
          1. Especificamos las configuraciones de conexi\u00f3n con la fuente (SQL Server 2016 en una m\u00e1quina virtual). Us\u00e9 la fuente de datos SQL Server Native Client<\/i> y la autenticaci\u00f3n SQL mencionada anteriormente.<\/li>\n
          2. Especificamos las configuraciones de conexi\u00f3n al destino (SQL Server 2014 en la m\u00e1quina host).<\/li>\n
          3. A continuaci\u00f3n, configuramos el mapeo. Es necesario seleccionar todos los no read-only<\/b> objetos (por ejemplo, no es necesario seleccionar vistas). Como opciones adicionales, se debe elegir \u00abPermitir inserci\u00f3n en columnas de identidad\u00bb<\/i>, si se utilizan.
            \nAtenci\u00f3n:<\/b> si al intentar seleccionar varias tablas y asignarles la propiedad \u00abPermitir inserci\u00f3n en columnas de identidad\u00bb<\/i> la propiedad ya se hab\u00eda configurado previamente para al menos una de las tablas seleccionadas, se indicar\u00e1 en el di\u00e1logo que la propiedad ya est\u00e1 establecida para todas las tablas seleccionadas. Este hecho puede confundir y llevar a errores en la transferencia.<\/li>\n
          4. Iniciamos la transferencia.<\/li>\n
          5. Restauramos la verificaci\u00f3n de las restricciones:\n
            EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'<\/code><\/pre>\n<\/li>\n<\/ol>\n
            Si hay alg\u00fan error, verificamos los ajustes, eliminamos la base de datos creada con errores, la recreamos a partir del script, hacemos las correcciones y repetimos la transferencia de datos.<\/p>\n
            Conclusi\u00f3n<\/h2>\n
            Esta tarea se encuentra relativamente rara vez y surge solo debido a las limitaciones mencionadas anteriormente. La soluci\u00f3n m\u00e1s com\u00fan implica actualizar SQL Server o conectarse a un servidor remoto, si la arquitectura de la aplicaci\u00f3n lo permite. Sin embargo, nadie est\u00e1 a salvo del c\u00f3digo legado y de las manos inexpertas de un desarrollo de mala calidad. Espero que esta gu\u00eda no sea necesaria, y si surge la necesidad, ayude a ahorrar mucho tiempo y nervios. \u00a1Gracias por su atenci\u00f3n!<\/p>\n
            Lista de fuentes utilizadas<\/h2>\n