Escolher um método de atualização do Mecanismo de Banco de Dados

  • Artigo

Aplica-se a: SQL Server - somente Windows

Há várias abordagens a serem consideradas quando você planeja fazer upgrade do Mecanismo de Banco de Dados de uma versão anterior do SQL Server, a fim de minimizar o tempo de inatividade e o risco. Você pode executar uma atualização in-loco, migrar para uma nova instalação ou executar uma atualização sem interrupção. O diagrama a seguir ajuda na escolha entre essas abordagens. Cada abordagem no diagrama também é discutida no artigo. Para uma ajuda com os pontos de decisão no diagrama, confira também Planejar e testar o Plano de Atualização do Mecanismo de Banco de Dados.

Diagrama que mostra uma árvore de decisão do método de atualização do Mecanismo de Banco de Dados.

Baixar

  • Para baixar o SQL Server, acesse o Centro de Avaliação.

  • Tem uma conta do Azure? Em seguida, acesse o Azure Marketplace para criar uma Máquina Virtual com a edição do SQL Server Developer Edition já instalada.

Opções de atualização do SQL do Azure

Você também pode atualizar o Banco de Dados SQL do Azure, a Instância Gerenciada de SQL do Azure ou virtualizar seu ambiente SQL Server como parte de seu plano de atualização. Para obter mais informações sobre essas opções, consulte os links a seguir:

Atualização in-loco

Com essa abordagem, o programa de Instalação do SQL Server faz upgrade da instalação existente do SQL Server, substituindo os bits do SQL Server existentes pelos novos bits do SQL Server e, depois, faz upgrade de cada um dos bancos de dados do sistema e do usuário.

O método de atualização in-loco é o mais fácil, requer algum tempo de inatividade, leva mais tempo para executar um fallback se um fallback for necessário, e não é permitido em todos os cenários. Para obter mais informações sobre os cenários de atualização in-loco com e sem suporte, veja Atualizações de versão e edição com suporte.

Essa abordagem é frequentemente usada nos seguintes cenários:

  • Um ambiente de desenvolvimento sem uma configuração de alta disponibilidade (HA).

  • Um ambiente de produção de missão não crítica que pode tolerar tempo de inatividade e que é executado em hardware e software recentes. O tempo de inatividade depende do tamanho do banco de dados e da velocidade de seu subsistema de E/S. Atualizar o SQL Server 2014 (12x) quando as tabelas com otimização de memória estiverem em uso leva um pouco mais de tempo. Para saber mais, confira Planejar e testar o plano de atualização do mecanismo de banco de dados.

Em alto nível, as etapas necessárias para uma atualização in-loco do Mecanismo de Banco de Dados são as seguintes:

Diagrama que mostra uma atualização in-loco não HA da atualização do Mecanismo de Banco de Dados.

Para obter etapas detalhadas, confira Fazer upgrade do SQL Server usando o Assistente de Instalação (Instalação).

Considerações

O programa de Instalação do SQL Server interrompee reinicia a instância do SQL Server como parte das verificações realizadas antes da atualização.

Quando você atualizar o SQL Server, a instância anterior do SQL Server será substituída e não mais existirá no computador. Antes de atualizar, faça backup dos bancos de dados do SQL Server e de outros objetos associados à instância anterior do SQL Server .

Migrar para uma nova instalação

Com essa abordagem, você mantém o ambiente atual enquanto cria um novo ambiente do SQL Server , frequentemente em um novo hardware e com uma nova versão do sistema operacional. Depois de instalar o SQL Server no novo ambiente, você deve realizar várias etapas para preparar esse novo ambiente para migrar os bancos de dados do usuário do ambiente existente para o novo ambiente e minimizar o tempo de inatividade. Essas etapas incluem a migração dos seguintes itens:

  • Objetos do sistema: Alguns aplicativos dependem de informações, entidades e/ou objetos que estão fora do escopo de um único banco de dados de usuário. Normalmente, um aplicativo tem dependências nos bancos de dados master e msdb, e também no banco de dados do usuário. Qualquer coisa armazenada fora de um banco de dados de usuário que seja necessária para o funcionamento correto daquele banco de dados deve estar disponível na instância do servidor de destino. Por exemplo, os logons de um aplicativo são armazenados como metadados no banco de dados master e precisam ser recriados no servidor de destino. Se um plano de manutenção de um banco de dados ou aplicativo depende de trabalhos do SQL Server Agent cujos metadados estão armazenados no banco de dados msdb, é necessário recriar esses trabalhos na instância do servidor de destino. De maneira semelhante, os metadados de um gatilho no nível de servidor são armazenados em master.

    Ao mover o banco de dados de um aplicativo para outra instância de servidor, é necessário recriar todos os metadados dos objetos e entidades dependentes no master e no msdb na instância do servidor de destino. Por exemplo, se um aplicativo de banco de dados usar gatilhos em nível de servidor, apenas a anexação ou a restauração do banco de dados no novo sistema não será suficiente. O banco de dados não funcionará conforme esperado a não ser que os metadados desses gatilhos sejam recriados manualmente no banco de dados master. Para obter informações detalhadas, confira Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server)

  • Pacotes do Integration Services armazenados no msdb: se você estiver armazenando pacotes no msdb, precisará escrever o script desses pacotes usando o dtutil Utility ou reimplantá-los no novo servidor. Antes de usar os pacotes no novo servidor, você precisa atualizar os pacotes para SQL Server. Para saber mais, confira Upgrade Integration Services Packages.

  • Chaves de criptografia do Reporting Services: Um parte importante da configuração do servidor de relatório é a criação de uma cópia de backup da chave simétrica usada para criptografar informações confidenciais. Uma cópia de backup da chave é necessária para várias operações rotineiras, possibilitando que você reutilize um banco de dados de servidor de relatório existente em uma nova instalação. Para obter mais informações, veja Fazer backup e restaurar as chaves de criptografia do Reporting Services e Atualizar e migrar o Reporting Services

Quando o novo ambiente do SQL Server tiver os mesmos objetos de sistema do ambiente existente, migre os bancos de dados do usuário do sistema existente para a instância do SQL Server de maneira que minimize o tempo de inatividade do sistema existente. Realize a migração do banco de dados usando backup e restauração ou redirecionando LUNs se estiver em um ambiente de SAN. As etapas para ambos os métodos são indicadas nos diagramas a seguir.

Cuidado

O tempo de inatividade depende do tamanho do banco de dados e da velocidade de seu subsistema de E/S. Atualizar o SQL Server 2014 (12x)quando as tabelas com otimização de memória estiverem em uso levará um pouco mais de tempo. Para saber mais, confira Planejar e testar o plano de atualização do mecanismo de banco de dados.

Depois de migrar bancos de dados , direcione novos usuários para a nova instância do SQL Server usando um entre vários métodos possíveis (por exemplo, renomear o servidor, usar uma entrada de DNS e modificar cadeias de conexão). A nova abordagem de instalação reduz o risco e o tempo de inatividade em comparação com uma atualização in-loco e facilita as atualizações de hardware e sistema operacional com a atualização para o SQL Server.

Observação

Se você já tiver uma solução de HA (alta disponibilidade) em vigor ou outro ambiente com várias instâncias do SQL Server, vá para Atualização sem interrupção. Se você não tiver uma solução de alta disponibilidade, considere configurar o Espelhamento de Banco de Dados temporariamente para minimizar o tempo de inatividade e facilitar a atualização ou aproveitar essa oportunidade para configurar um Grupo de Disponibilidade AlwaysOn como uma solução de HA permanente.

Por exemplo, você pode usar essa abordagem para atualizar:

  • Uma instalação do SQL Server em um sistema operacional sem suporte.
  • Uma instalação x86 (32-bit) do SQL Server, pois o SQL Server 2016 (13.x) e versões posteriores não dão suporte a instalações x86.
  • SQL Server para o novo hardware e/ou uma nova versão do sistema operacional.
  • SQL Server com a consolidação de servidores.
  • O SQL Server 2005 (9.X), assim como o SQL Server 2016 (13.x) e posteriores, não dá suporte à atualização in-loco do SQL Server 2005 (9.X). Para obter mais informações, confira Você está atualizando de uma versão mais antiga do SQL Server?.

As etapas necessárias para a atualização de uma nova instalação variam um pouco, dependendo se você estiver usando armazenamento NAS ou SAN.

  • Ambiente de armazenamento anexado: se você tiver um ambiente do SQL Server que usa o armazenamento anexado, o diagrama a seguir e os links do diagrama orientarão você pelas etapas necessárias para a atualização de uma nova instalação do Mecanismo de Banco de Dados.

    Diagrama que mostra um novo método de atualização de instalação usando o backup e a restauração para o armazenamento anexado.

  • Ambiente de armazenamento SAN: se você tiver um ambiente do SQL Server que usa o armazenamento SAN, o diagrama a seguir e os links do diagrama orientarão você pelas etapas necessárias para a atualização de uma nova instalação do Mecanismo de Banco de Dados.

    Diagrama que mostra um novo método de atualização de instalação usando a anexação e a desanexação para o armazenamento SAN.

Atualização sem interrupção

É necessária uma atualização sem interrupção em ambientes de solução do SQL Server que envolvem várias instâncias do SQL Server que devam ser atualizadas em uma determinada ordem para maximizar o tempo de atividade, minimizar os riscos e preservar a funcionalidade. Uma atualização sem interrupção é essencialmente a atualização de várias instâncias SQL Server em uma ordem específica. Você executa uma atualização no local em cada instância existente do SQL Server ou uma nova atualização de instalação para facilitar a atualização do hardware e/ou do sistema operacional como parte do projeto de atualização. Há várias situações em que a abordagem de atualização sem interrupção é necessária. Essas situações são documentadas nos seguintes artigos: