Partilhar via


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

Aplica-se a: SQL Server em Windows

Há várias abordagens a serem consideradas quando você planeja atualizar o 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 no local, migrar para uma nova instalação ou realizar uma atualização gradual. O diagrama a seguir ajuda você a escolher entre essas abordagens. Cada abordagem no diagrama também é discutida no artigo. Para ajudá-lo com os pontos de decisão no diagrama, revise 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, visite o Centro de Avaliação .

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

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

Você também pode considerar atualizar seu banco de dados SQL do Azure, instância gerenciada do SQL do Azure ou virtualizar seu ambiente do SQL Server como parte de seu plano de atualização. Para obter mais informações sobre essas opções, consulte os seguintes links:

Atualização no local

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

A abordagem de atualização no local é a mais fácil, requer algum tempo de inatividade, demora mais para reverter caso seja necessário, e não é suportada para todos os cenários.

Para obter uma lista de recursos suportados pelas edições do SQL Server no Windows, consulte:

Essa abordagem é freqüentemente usada nos seguintes cenários:

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

  • Um ambiente de produção não crítico que pode tolerar tempo de inatividade e que está sendo executado em um hardware e software recentes. A quantidade de tempo de inatividade depende do tamanho do banco de dados e da velocidade do subsistema de E/S. A atualização do SQL Server 2014 (12.x) quando tabelas com otimização de memória estão em uso leva algum tempo extra. Para obter mais informações, consulte Planejar e testar o plano de atualização do Mecanismo de Banco de Dados.

Em um nível alto, 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 do Mecanismo de Banco de Dados Não HA In-Place Upgrade.

Para obter etapas detalhadas, consulte Atualizar o SQL Server usando o Assistente de Instalação (Configuração).

Considerações

O programa de Instalação do SQL Server para e reinicia a instância do SQL Server como parte das verificações de pré-atualização.

Quando você atualiza o SQL Server, a instância anterior do SQL Server é substituída e não existirá mais no seu computador. Antes de atualizar, faça backup de bancos de dados do SQL Server e 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, freqüentemente em um novo hardware e com uma nova versão do sistema operacional. Depois de instalar o SQL Server no novo ambiente, você executa várias etapas para preparar o novo ambiente, de modo que possa migrar os bancos de dados de usuários existentes do ambiente existente para o novo ambiente e minimizar o tempo de inatividade. Essas etapas incluem a migração do seguinte:

  • 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 desse banco de dados deve ser disponibilizada 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 devem ser recriados no servidor de destino. Se um plano de manutenção de aplicativo ou banco de dados depender de trabalhos do SQL Server Agent, cujos metadados são armazenados no banco de dados msdb, você deverá recriar esses trabalhos na instância do servidor de destino. Da mesma forma, os metadados de um gatilho no nível do servidor são armazenados em master.

    Ao mover o banco de dados de um aplicativo para outra instância do servidor, você deve recriar todos os metadados das entidades e objetos dependentes em master e msdb na instância do servidor de destino. Por exemplo, se um aplicativo de banco de dados usa gatilhos no nível do servidor, apenas anexar ou restaurar o banco de dados no novo sistema não é suficiente. O banco de dados não funciona como esperado, a menos que você recrie manualmente os metadados para esses gatilhos no banco de dados master. Para obter informações detalhadas, consulte Gerenciar metadados ao disponibilizar um banco de dados em outro servidor

  • pacotes do Integration Services armazenados em msdb: Se você estiver armazenando pacotes no msdb, precisará criar scripts 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 o SQL Server. Para obter mais informações, consulte Pacotes de Atualização dos Serviços de Integração.

  • chaves de criptografia do Reporting Services: Uma parte importante da configuração do servidor de relatório é criar 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 muitas operações de rotina e permite reutilizar um banco de dados existente do servidor de relatório em uma nova instalação. Para obter mais informações, consulte Fazer backup e restaurar chaves de criptografia do SQL Server Reporting Services (SSRS) e Atualizar e migrar o Reporting Services

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

Atenção

A quantidade de tempo de inatividade depende do tamanho do banco de dados e da velocidade do subsistema de E/S. A atualização do SQL Server 2014 (12.x) quando as tabelas com otimização de memória estiverem em uso levará algum tempo extra. Para obter mais informações, consulte Planejar e testar o plano de atualização do Mecanismo de Banco de Dados.

Depois de migrar bancos de dados de usuários, você aponta novos usuários para a nova instância do SQL Server usando um dos vários métodos (por exemplo, renomear o servidor, usar uma entrada 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 já tiver uma solução de alta disponibilidade (HA) em uso ou algum outro ambiente com múltiplas instâncias do SQL Server, opte por Atualização contínua. Se você não tiver uma solução de alta disponibilidade em vigor, poderá considerar configurar temporariamente o espelhamento de banco de dados para minimizar ainda mais o tempo de inatividade para facilitar essa atualização ou aproveitar esta oportunidade para configurar um grupo de disponibilidade Always On como uma solução de HA permanente.

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

  • Uma instalação do SQL Server em um sistema operacional sem suporte.
  • Uma instalação x86 (32 bits) do SQL Server, pois o SQL Server 2016 (13.x) e versões posteriores não oferecem suporte a instalações x86.
  • SQL Server para novo hardware e/ou uma nova versão do sistema operacional.
  • SQL Server com consolidação de servidor.
  • O SQL Server 2005 (9.x) não é suportado para atualização no local, e isso também se aplica ao SQL Server 2016 (13.x) e versões posteriores. Para obter mais informações, consulte Opções de fim de suporte do SQL Server.

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

  • Ambiente de armazenamento anexado: Se você tiver um ambiente SQL Server usando armazenamento anexado, o diagrama a seguir e os links dentro do diagrama para guiá-lo pelas etapas necessárias para uma nova atualização de instalação do Mecanismo de Banco de Dados.

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

  • ambiente de armazenamento SAN: Se tiveres um ambiente SQL Server usando armazenamento SAN, o diagrama a seguir e os links dentro do diagrama irão orientá-lo pelas etapas necessárias para uma nova atualização de instalação do Mecanismo de Banco de Dados.

    diagrama que mostra um novo método de atualização de instalação usando desanexar e anexar para armazenamento SAN.

Atualização gradual

Uma atualização sem interrupção é necessária em ambientes de solução do SQL Server envolvendo várias instâncias do SQL Server que devem ser atualizadas em uma determinada ordem para maximizar o tempo de atividade, minimizar o risco e preservar a funcionalidade. Uma atualização sem interrupção é essencialmente a atualização de várias instâncias do SQL Server em uma ordem específica. Você executa uma atualização no local em cada instância existente do SQL Server ou uma instalação nova para facilitar a atualização do hardware e/ou do sistema operacional como parte do projeto de atualização. Há vários cenários nos quais você precisa usar a abordagem de atualização contínua. Estes estão documentados nos seguintes artigos: