Crie um site como este com o WordPress.com
Comece agora

Restaurar banco de dados para versão anterior do SQL Server

Você já se deparou com a mensagem de erro abaixo,

p039_msg948

quando tentou restaurar um banco de dados utilizado anteriormente em outra instância?

1. Introdução

1.1. A mensagem de erro

Às vezes é necessário migrar um banco de dados que está em uso em uma instância A com determinada versão do SQL Server para uma outra instância B, sendo esta de versão anterior de SQL Server. Ao tentar anexar na instância B o arquivo MDF do banco de dados “BD”, desanexado previamente da instância A, a seguinte mensagem de erro é exibida:

Msg 948
The database ‘BD’ cannot be opened because it is version mmm. This server supports version nnn and earlier. A downgrade path is not supported.

onde o valor de mmm é maior do que o valor de nnn.

Mas o que significam os números mmm e nnn? Onde eles ficam armazenados?

1.2. Identificação de formato de arquivo de configuração

Suponha que você tenha desenvolvido um sistema ERP e que nele utilize um arquivo para armazenar valores dos parâmetros de configuração do cliente. Na versão 1.0 do ERP este arquivo contém 2 campos: nome da empresa e CNPJ.O primeiro campo, versão, é um número sequencial (1, 2, 3, …) que informa o formato do arquivo de configuração. Inicialmente esse valor é 1. Todos são campos texto.

p039_figura 1.2-1

Na primeira revisão do software ERP, versão 1.01, é acrescentado novo campo no arquivo de configuração para armazenar o telefone comercial da empresa:

p039_figura 1.2-2

Com esta alteração o valor do campo versão passa para 2.

Mais uma revisão no software ERP, versão 1.05, e o campo CNPJ é alterado de tamanho:

p039_figura 1.2-3

Com esta alteração o valor do campo versão passa para 3.

Posteriormente novos recursos são acrescentados no software ERP e alguns erros são corrigidos, tendo-se então a versão 1.10 do software ERP. Nenhuma alteração foi realizada no formato do arquivo de configuração; por isso ele mantém o valor 3.

Ou seja, tivemos a seguinte relação entre a versão do ERP e a versão do arquivo de configuração:

p039_figura 1.2-4

Temos assim controles independentes de versão do software ERP e do arquivo de configuração.

1.3. Internal database version

De forma análoga, o arquivo que armazena cada banco de dados possui uma numeração própria, independente da numeração de versão do software SQL Server. Cada versão do SQL Server está apta a utilizar o arquivo de banco de dados em determinado formato interno, e somente ele. O campo que contém a identificação do formato do arquivo é denominado de database version ou internal database version.

Não encontrei na documentação oficial do SQL Server informação sobre os valores de database version mas há uma função, DATABASEPROPERTYEX(), que retorna esse valor.

-- código #1
SELECT DATABASEPROPERTYEX ('nomebanco', 'version');

No sítio web Microsoft SQL Server Versions List há tabela que relaciona valores de database version e versão do SQL Server, de onde foi extraída a seguinte informação:

p039_figura 1.3-1

Atenção que para uma mesma versão do SQL Server pode existir mais de um formato de arquivo, o que significa que o database version depende da versão, nível e (não posso afirmar) do nível de atualização do SQL Server. Ou seja, o database version está diretamente relacionado com o identificador interno de versão do mecanismo do banco de dados (database engine version).

Aproveito ainda para alertar que não há relação direta entre o nível de compatibilidade (compatibility level) e o database version, embora vários artigos na web tratem os dois de forma conjunta. A respeito de nível de compatibilidade sugiro a leitura do artigo Como melhorar a performance do banco de dados ao ajustar o nível de compatibilidade, que inclusive detalha o funcionamento do identificador interno de versão do mecanismo do banco de dados (database engine version).

1.4. “A downgrade path is not supported”

Após a explicação do que é database version, podemos agora retornar à mensagem de erro inicial deste artigo, só que agora com valores informando as versões:

Msg 948
The database ‘BD’ cannot be opened because it is version 904. This server supports version 852 and earlier.

A mensagem de erro deve ser separada em duas partes para compreender o significado dela. A primeira parte,

The database ‘BD’ cannot be opened because it is version 904.

informa que o database version do banco de dados “BD” é 904, o que indica que o banco de dados estava em uma instância com SQL Server 2019. Já a parte da segunda parte da mensagem de erro,

This server supports version 852 and earlier.

informa que a versão do SQL Server da instância na qual tentou-se anexar (attach) o banco de dados “BD” é da versão 2016. Ou seja, não há como migrar diretamente o banco de dados “BD” da instância com SQL Server 2019 para a instância com SQL Server 2016.

2. Opções de migração

Como não é possível anexar/restaurar banco de dados cujo database version seja maior do que o que o mecanismo de banco de dados compreende, então é necessário encontrar outras soluções. E existem várias, cuja escolha depende principalmente do volume de dados e da localização das instâncias. Se as instâncias estão no mesmo servidor, ou compartilham unidade de armazenamento, pode-se escolher por algum processo online de migração direta entre as instâncias. Mas se as instâncias estão em diferentes servidores, em que não há conexão entre eles (ou há mas não é uma conexão rápida), deve-se avaliar a utilização de arquivo(s) intermediário(s) para a migração.

2.1. Uso de DAC (aplicativo de camada de dados)

Uma das opções é a utilização da funcionalidade Exportação de um aplicativo de camada de dados na instância de origem, o que gera um pacote contendo as definições dos objetos no banco de dados e os dados das tabelas. O pacote é gravado em um arquivo com a extensão bacpac, que posteriormente é importado na instância de destino ou no Azure SQL Database.

A primeira etapa é gerar o arquivo bacpac na instância de origem. Eis o passo a passo para a exportação, descrito na documentação citada anteriormente:

  • Conecte-se na instância SQL Server de origem;
  • Expanda o nó Bancos de Dados no Pesquisador de Objetos;
  • Clique com o botão direito do mouse no nome do banco de dados;
  • Clique em Tarefas e selecione Exportar Aplicativo da Camada de Dados;
  • Conclua as etapas das caixas de diálogo do assistente.

Eis imagens do passo a passo descrito acima.

Este slideshow necessita de JavaScript.

A etapa seguinte é importar o conteúdo do arquivo bacpac na instância de destino, conforme descrito em Importar um arquivo BACPAC para criar um novo banco de dados. O passo a passo de importação descrito na documentação é o seguinte:

  • Conecte-se na instância SQL Server de destino;
  • No Pesquisador de Objetos, clique com o botão direito do mouse no nó Bancos de Dados;
  • Selecione Importar Aplicativo da Camada de Dados;
  • Conclua as caixas de diálogo do assistente e clique em Concluir.

Eis imagens do passo a passo descrito acima.

Este slideshow necessita de JavaScript.

Observações. Ao utilizar esta solução é necessário ficar atento que o banco de dados não contenha objetos que não sejam reconhecidos na versão do SQL Server da instância de destino. No primeiro teste que fiz ocorreu erro ao exportar banco de dados de instância SQL Server 2017 para instância 2016, pois uma das funções gravadas no banco de dados utilizava a função TRANSLATE, que não existe na versão 2016 do SQL Server.

Sugiro a leitura do documento Suporte de DAC para objetos e versões do SQL Server antes de utilizar esta solução.

As ações descritas neste item também podem ser realizadas com o utilitário Sqlpackage.

2.2. Criação de scripts de importação

2.2.1. Assistente para gerar scripts

Outra solução é a geração de scripts com códigos T-SQL para criação dos objetos (tabelas, visões, funções etc) e também para a carga dos dados, o que envolve a utilização de instruções CREATE e INSERT. No Management Studio (SSMS) há um assistente que gera os scripts de forma automática, sendo possível definir quais objetos e se os scripts conterão somente a estrutura (esquema), somente os dados, ou ambos.

O passo a passo está descrito em detalhes (e com imagens) na documentação do assistente de geração de scripts e se resume a:

  • Na janela “Pesquisador de Objetos” expanda o nó da instância que contém o banco de dados a ser incluído no script;
  • Clique em “Tarefas” e a seguir em “Gerar Scripts”;
  • Conclua as etapas das caixas de diálogo do assistente.

Eis imagens do passo a passo descrito acima.

Este slideshow necessita de JavaScript.

Sugiro especial atenção ao definir as opções do script a ser gerado, em especial a “Tipos de dados para o script”, que é a que permite definir que serão gerados estrutura (esquema) e dados.

O resultado é um ou mais arquivos texto contendo instruções SQL para a criação e carga do banco de dados na nova instância.

Observações. Uma deficiência dessa solução é que é gerada uma instrução INSERT para cada linha a ser incluída na tabela; ou seja, é um processo de inclusão linha a linha.

Essa solução parece ser interessante e prática mas ela tem um problema: o arquivo texto gerado pode se tornar tão grande que torne impraticável carregá-lo no SSMS, sendo então necessário o uso do utilitário SQLCMD para realizar a importação:

PS >sqlcmd -S .\SQL2016 -d vendas -i .\nocount.sql -i .\vendas.sql

No comando acima o nome da instância é SQL2016 e o banco de dados para onde serão importadas as tabelas é vendas.

A criação de scripts não me parece uma solução prática para grandes tabelas.

2.2.2. Geração manual de scripts

Em casos específicos talvez seja necessário gerar manualmente os scripts de exportação, principalmente para quando for necessário algum tipo de conversão prévia devido a diferenças de programação entre a versão da instância de destino e a versão da instância de origem.

2.3. Assistente de importação e exportação

Outra solução é a migração online direta entre os bancos de dados, utilizando o Assistente de importação e exportação para gerar pacote DTS do Integration Services.

Caso as duas instâncias estejam no mesmo computador (ou compartilhem unidade externa de armazenamento) esta pode ser uma solução eficiente. Também pode ser utilizado entre instâncias que estejam em computadores diferentes, localizados em ambientes físicos distantes, mas neste caso a conexão de rede entre os computadores delimita o desempenho da solução.

No Management Studio o passo a passo é o seguinte:

  • Conecte-se à instancia SQL Server de origem;
  • Expanda o nó Bancos de Dados no Pesquisador de Objetos;
  • Clique com o botão direito do mouse sobre o nome do banco de dados de origem;
  • Selecione o item Tarefas;
  • Selecione o item Exportar dados;
  • Configure a conexão ao banco de dados de origem;
  • Configure a conexão ao banco de dados de destino;
  • Especifique os objetos que serão copiados;
  • Rode o pacote gerado.

Eis imagens do passo a passo descrito acima.

Este slideshow necessita de JavaScript.

2.4. Usando somente o backup

Às vezes somente está disponível o arquivo de backup completo para restaurar o banco de dados em instância de versão anterior do SQL Server. Neste caso, embora não seja possível utilizar as soluções propostas nos itens anteriores, ainda assim é possível realizar a migração.

2.4.1. Instância temporária em paralelo

Uma alternativa é, no mesmo servidor em que está a instância de destino, criar uma nova instância com a mesma versão (nível e nível de atualização) do SQL Server da instância de origem do backup. A seguir é restaurar o backup do banco de dados nessa nova instância e, após restaurado, utilizar uma das soluções anteriores (preferencialmente o uso da assistente de importação e exportação, descrito no item 2.3) e ao final apagar o banco de dados da instância temporária e também desinstalar a instância temporária.

2.4.2. ApexSQL Data Diff

O objetivo principal do software ApexSQL Data Diff é sincronizar bases de dados mas também é possível utilizar como origem dos dados um arquivo de backup, realizando então o sincronismo unidirecional (do backup para o banco de dados). O passo inicial é criar a estrutura vazia do banco de dados na instância de destino e a seguir utilizar o software ApexSQL Data Diff para carregar o banco de dados utilizando o backup como origem.

3. Fontes de estudos

3.1. Documentação

3.2. Artigos e tópicos de fóruns técnicos

3.3. Sítios web

Publicidade

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.

%d blogueiros gostam disto: