{"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\/pt\/blog\/administrirovanie\/perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu","title":{"rendered":"Transfer\u00eancia de dados de backup de uma nova vers\u00e3o do MS SQL Server para uma vers\u00e3o anterior","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Antecedentes<\/h2>\n

Certa vez, para reproduzir um bug, precisei de um backup do banco de produ\u00e7\u00e3o.<\/p>\n

Para minha surpresa, encontrei as seguintes limita\u00e7\u00f5es:<\/p>\n

    \n
  1. O backup do banco foi feito na vers\u00e3o SQL Server 2016<\/i> e n\u00e3o era compat\u00edvel com minha SQL Server 2014<\/i>.<\/li>\n
  2. No meu computador de trabalho, o sistema operacional utilizado era Windows 7<\/i>, portanto, n\u00e3o consegui atualizar SQL Server<\/i> para a vers\u00e3o 2016<\/li>\n
  3. O produto suportado fazia parte de um sistema maior com uma arquitetura legada fortemente interligada e tamb\u00e9m se referia a outros produtos e bancos, portanto, sua implementa\u00e7\u00e3o em outra esta\u00e7\u00e3o poderia levar muito tempo.<\/li>\n<\/ol>\n

    Tendo em vista o exposto, cheguei \u00e0 conclus\u00e3o de que era hora de solu\u00e7\u00f5es alternativas.<\/a><\/noindex><\/p>\n

    Recupera\u00e7\u00e3o de dados do backup<\/h2>\n

    Decidi usar uma m\u00e1quina virtual Oracle VM VirtualBox<\/a><\/noindex> com Windows 10 (pode-se obter uma imagem de teste para o navegador Edge daqui<\/a><\/noindex>). Na m\u00e1quina virtual, foi instalado o SQL Server 2016 e nela foi restaurado o banco de dados do aplicativo a partir do backup (um guia<\/a><\/noindex>).<\/p>\n

    Configura\u00e7\u00e3o de acesso ao SQL Server na m\u00e1quina virtual<\/h2>\n

    Em seguida, era necess\u00e1rio tomar algumas medidas para permitir o acesso ao SQL Server externamente:<\/p>\n

      \n
    1. Adicionar uma regra ao firewall para permitir solicita\u00e7\u00f5es \u00e0 porta 1433<\/i>.<\/li>\n
    2. Preferencialmente, o acesso ao servidor deve ser feito n\u00e3o por autentica\u00e7\u00e3o do Windows, mas pelo SQL com login e senha (\u00e9 mais f\u00e1cil configurar o acesso). No entanto, nesse caso, n\u00e3o se deve esquecer de habilitar nas propriedades do SQL Server a possibilidade de autentica\u00e7\u00e3o SQL.<\/li>\n
    3. Nas configura\u00e7\u00f5es do usu\u00e1rio no SQL Server, na aba User Mapping<\/i> indicar para o banco restaurado o papel do usu\u00e1rio db_securityadmin<\/i>.<\/li>\n<\/ol>\n

      Transfer\u00eancia de dados<\/h2>\n

      Na verdade, a transfer\u00eancia de dados consiste em duas etapas:<\/p>\n

        \n
      1. Transfer\u00eancia do esquema de dados (tabelas, vis\u00f5es, procedimentos armazenados, etc.)<\/li>\n
      2. Transfer\u00eancia dos pr\u00f3prios dados<\/li>\n<\/ol>\n

        Transfer\u00eancia do esquema de dados<\/h3>\n

        Realizamos as seguintes opera\u00e7\u00f5es:<\/p>\n

          \n
        1. Escolhendo Tasks -> Generate Scripts<\/i> para o banco a ser transferido.<\/li>\n
        2. Selecionamos os objetos necess\u00e1rios para a transfer\u00eancia ou deixamos o valor padr\u00e3o (nesse caso, ser\u00e3o criados scripts para todos os objetos do banco).<\/li>\n
        3. Indicamos as configura\u00e7\u00f5es para salvar o script. O mais conveniente \u00e9 salvar o script em um \u00fanico arquivo com codifica\u00e7\u00e3o Unicode. Assim, em caso de falha, n\u00e3o ser\u00e1 necess\u00e1rio repetir todas as etapas.<\/li>\n<\/ol>\n

          Ap\u00f3s salvar o script, ele pode ser executado no SQL Server original (vers\u00e3o antiga) para criar o banco necess\u00e1rio.<\/p>\n

          Aten\u00e7\u00e3o:<\/b> Ap\u00f3s a execu\u00e7\u00e3o do script, \u00e9 necess\u00e1rio verificar se as configura\u00e7\u00f5es do banco a partir do backup est\u00e3o de acordo com o banco criado pelo script. No meu caso, o script n\u00e3o tinha a configura\u00e7\u00e3o para COLLATE, o que resultou em falhas na transfer\u00eancia de dados e em manobras para recriar o banco com o script ajustado.<\/p>\n

          Transfer\u00eancia de dados<\/h3>\n

          Antes de transferir dados, \u00e9 necess\u00e1rio desativar a verifica\u00e7\u00e3o de todas as restri\u00e7\u00f5es no banco:<\/p>\n

          EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'<\/code><\/pre>\n
          Transferimos os dados usando o assistente de importa\u00e7\u00e3o de dados Tarefas -> Importar Dados<\/i> no SQL Server onde o banco criado pelo script est\u00e1 localizado:<\/p>\n
            \n
          1. Especificamos as configura\u00e7\u00f5es de conex\u00e3o \u00e0 origem (SQL Server 2016 em uma m\u00e1quina virtual). Eu usei o Data Source SQL Server Native Client<\/i> e a autentica\u00e7\u00e3o SQL mencionada anteriormente.<\/li>\n
          2. Especificamos as configura\u00e7\u00f5es de conex\u00e3o ao destino (SQL Server 2014 na m\u00e1quina host).<\/li>\n
          3. Em seguida, configuramos o mapeamento. \u00c9 necess\u00e1rio selecionar todos n\u00e3o somente leitura<\/b> objetos (por exemplo, n\u00e3o \u00e9 preciso selecionar visualiza\u00e7\u00f5es). Como op\u00e7\u00f5es adicionais, deve-se escolher \"Permitir inser\u00e7\u00e3o em colunas de identidade\"<\/i>, se tais colunas forem utilizadas.
            \nAten\u00e7\u00e3o:<\/b> se ao tentar selecionar v\u00e1rias tabelas e definir a propriedade \"Permitir inser\u00e7\u00e3o em colunas de identidade\"<\/i> a propriedade j\u00e1 tiver sido definida anteriormente para pelo menos uma das tabelas selecionadas, no di\u00e1logo ser\u00e1 indicado que a propriedade j\u00e1 est\u00e1 configurada para todas as tabelas selecionadas. Esse fato pode confundir e levar a erros na transfer\u00eancia.<\/li>\n
          4. Iniciamos a transfer\u00eancia.<\/li>\n
          5. Restauramos a verifica\u00e7\u00e3o de restri\u00e7\u00f5es:\n
            EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'<\/code><\/pre>\n<\/li>\n<\/ol>\n
            Se ocorrerem erros, verificamos as configura\u00e7\u00f5es, removemos o banco criado com erros, o recriamos a partir do script, realizamos as corre\u00e7\u00f5es e repetimos a transfer\u00eancia de dados.<\/p>\n
            Conclus\u00e3o<\/h2>\n
            Essa situa\u00e7\u00e3o ocorre com bastante raridade e surge apenas devido \u00e0s restri\u00e7\u00f5es mencionadas. Na maior parte das vezes, a solu\u00e7\u00e3o \u00e9 atualizar o SQL Server ou conectar-se a um servidor remoto, se a arquitetura do aplicativo permitir. No entanto, ningu\u00e9m est\u00e1 a salvo de c\u00f3digo legado e desenvolvimentos mal feitos. Espero que voc\u00ea n\u00e3o precise desta instru\u00e7\u00e3o, mas se precisar, que ela ajude a economizar muito tempo e nervos. Obrigado pela aten\u00e7\u00e3o!<\/p>\n
            Lista de fontes utilizadas<\/h2>\n