Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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.
Baixar
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:
- visão geral do SQL Server em Máquinas Virtuais do Azure
- Banco de Dados SQL do Azure
- O que é o Azure SQL?
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:
- Edições e funcionalidades suportadas do SQL Server 2025
- Edições e recursos suportados do SQL Server 2022
- Edições e recursos suportados do SQL Server 2019
- Edições e funcionalidades suportadas do SQL Server 2017
- Edições e funcionalidades suportadas do SQL Server 2016
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:
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
masteremsdbe 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 dadosmastere 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 dadosmsdb, 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 emmaster.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
masteremsdbna 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 dadosmaster. Para obter informações detalhadas, consulte Gerenciar metadados ao disponibilizar um banco de dados em outro servidorpacotes do Integration Services armazenados em
msdb: Se você estiver armazenando pacotes nomsdb, 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.
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.
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:
- Grupos de disponibilidade: para obter etapas detalhadas para executar uma atualização sem interrupção neste ambiente, consulte Atualizar réplicas do grupo de disponibilidade
- Instâncias de cluster de failover: para obter etapas detalhadas para executar uma atualização sem interrupção neste ambiente, consulte Atualizar uma instância de cluster de failover
- Instâncias espelhadas: para obter etapas detalhadas para executar uma atualização contínua neste ambiente, consulte Atualizando instâncias espelhadas
- Instâncias de envio de logs: para obter etapas detalhadas para executar uma atualização sem interrupção neste ambiente, consulte Atualizando o envio de logs para o SQL Server 2016 (Transact-SQL)
- Um ambiente de replicação: para obter etapas detalhadas para executar uma atualização sem interrupção neste ambiente, consulte Atualizar ou corrigir bancos de dados replicados
- Um ambiente de expansão do SQL Server Reporting Services: para obter etapas detalhadas para executar uma atualização sem interrupção neste ambiente, consulte Atualizar e migrar o Reporting Services