Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:
SQL Server
Para preservar sua solução de recuperação de desastre de envio de logs, atualize ou aplique atualizações de manutenção na ordem apropriada. As atualizações de manutenção incluem pacotes de serviço ou atualizações cumulativas.
Observação
Uma configuração de envio de logs atualizada usa a opção backup compression default de configuração no nível do servidor para controlar se a compactação de backup é usada para os arquivos de backup do log de transações. Você pode especificar o comportamento de compactação dos backups de log para cada configuração de envio. Para obter mais informações, veja Configurar o envio de logs (SQL Server).
Pré-requisitos
Antes de começar, examine as informações importantes a seguir.
| Artigo | DESCRIÇÃO |
|---|---|
| Atualizações suportadas de versão e edição | Verifique se você pode atualizar a partir do seu sistema operacional Windows existente e da versão atual do SQL Server para a versão desejada do SQL Server. Por exemplo, você não pode atualizar diretamente de uma instância do SQL Server 2005 (9.x) para o SQL Server 2025 (17.x). |
| Escolher um método de atualização do Mecanismo de Banco de Dados | Selecione o método de atualização apropriado e as etapas com base na revisão de atualizações de versão e edição com suporte. Considere também outros componentes instalados em seu ambiente para atualizar componentes na ordem correta. |
| Planejar e testar o plano de atualização do Mecanismo de Banco de Dados | Examine as notas de versão e os problemas conhecidos de atualização, a lista de verificação de pré-atualização e desenvolva e teste o plano de atualização. |
| Requisitos de hardware e software para instalar o SQL Server | Examine os requisitos de software para instalar o SQL Server. Se outro software for necessário, instale-o em cada nó antes de iniciar o processo de atualização para minimizar qualquer tempo de inatividade. |
| Suporte para grupos de disponibilidade contidos adicionado no SQL Server 2022 (16.x) | Se você quiser começar a usar grupos de disponibilidade independentes com o envio de logs, será necessário descartar e recriar a topologia de envio de logs. No entanto, se você já estiver usando grupos de disponibilidade independentes com envio de logs, há suporte para atualizações. |
| Suporte ao TDS 8.0 adicionado no SQL Server 2025 (17.x) | Se você quiser usar o TDS 8.0 com envio de logs no SQL 2025 e versões posteriores, primeiro será necessário remover a configuração de envio de logs existente. |
Proteger seus dados antes da atualização
Para proteger seus dados durante uma atualização de envio de logs, siga estas etapas:
Execute um backup de banco de dados completo em cada banco de dados primário.
Para obter mais informações, confira Criar um backup completo de banco de dados (SQL Server).
Execute o comando DBCC CHECKDB em cada banco de dados primário.
Importante
Verifique se o servidor primário tem espaço suficiente para manter as cópias de backup de log pelo tempo que durar a atualização dos servidores secundários. Se você estiver fazendo failover para um secundário, essa mesma preocupação se aplicará ao secundário (o novo primário).
Atualizar a instância do servidor do monitor (opcional)
Você pode atualizar a instância do servidor monitor, se houver, a qualquer momento. No entanto, você não precisa atualizar o servidor de monitor opcional ao atualizar os servidores primário e secundário.
Enquanto o servidor monitor está sendo atualizado, a configuração de remessa de logs continua funcionando, mas seu status não é registrado nas tabelas do monitor. Todos os alertas configurados não são disparados enquanto o servidor monitor está sendo atualizado. Após a atualização, você pode atualizar as informações nas tabelas de monitor executando o procedimento armazenado do sistema sp_refresh_log_shipping_monitor. Para obter mais informações sobre um servidor monitor, consulte Sobre o envio de logs (SQL Server).
Atualizar as instâncias do servidor secundário
O processo de atualização envolve a atualização das instâncias de servidor secundário do SQL Server antes de atualizar a instância do servidor primário. Atualize sempre as instâncias secundárias do SQL Server primeiro. O envio de logs continua durante todo o processo de atualização porque as instâncias de servidor secundárias atualizadas continuam restaurando os backups de log da instância do servidor primário.
Se você atualizar a instância do servidor primário antes da instância do servidor secundário, o envio de logs falhará porque um backup criado em uma versão mais recente do SQL Server não poderá ser restaurado em uma versão mais antiga do SQL Server. Você pode atualizar as instâncias secundárias simultaneamente ou serialmente, mas deve atualizar todas as instâncias secundárias antes de atualizar a instância primária para evitar uma falha no envio de logs.
Durante a atualização de uma instância de servidor secundário, os trabalhos de cópia e restauração do log shipping não são executados. Essa condição significa que os backups de log de transações não modificados se acumulam na réplica primária e você precisa ter espaço suficiente para manter esses backups não modificados. A quantidade de acúmulo depende da frequência do backup agendado na instância do servidor primário e da sequência na qual você atualiza as instâncias secundárias. Além disso, se um servidor monitor separado estiver configurado, os alertas poderão ser gerados indicando que as restaurações não foram executadas por mais tempo do que o intervalo configurado.
Depois de atualizar as instâncias do servidor secundário, os trabalhos dos agentes de envio de logs serão retomados e continuarão a copiar e restaurar backups de log da instância do servidor primário para as instâncias de servidor secundárias. O tempo necessário para que as instâncias de servidor secundário atualizem o banco de dados secundário varia, dependendo do tempo necessário para atualizar a instância do servidor secundário e da frequência dos backups no servidor primário.
Durante a atualização do servidor, o próprio banco de dados secundário não é atualizado para a nova versão. Ele será atualizado somente se for colocado online iniciando um failover do banco de dados enviado pelo log. Em teoria, essa condição pode persistir indefinidamente. A quantidade de tempo para atualizar os metadados do banco de dados quando um failover é iniciado é pequena.
Importante
A RESTORE WITH STANDBY opção não tem suporte para um banco de dados que requer atualização. Se um banco de dados secundário atualizado for configurado usando RESTORE WITH STANDBY, os logs de transações não poderão mais ser restaurados após a atualização. Para retomar o envio de logs nesse banco de dados secundário, você precisa configurar o envio de logs novamente nesse servidor em espera. Para obter mais informações sobre a opção STANDBY , consulte Restaurar um Backup de Log de Transações (SQL Server).
Atualizar a instância do servidor primário
Como o envio de logs é principalmente uma solução de recuperação de desastre, o cenário mais simples e comum é atualizar a instância primária no local. O banco de dados não está disponível durante essa atualização. Depois que o servidor é atualizado, o banco de dados é automaticamente colocado online novamente, o que faz com que ele seja atualizado. Depois que o banco de dados é atualizado, os trabalhos de envio de logs são retomados.
O envio de logs também dá suporte à opção de realizar failover para um servidor secundário de envio de logs e, opcionalmente, alterar papéis entre servidores primários e secundários de envio de logs.
No entanto, como o envio de logs raramente é configurado como uma solução de alta disponibilidade (opções mais recentes são muito mais robustas), fazer failover geralmente não minimiza o tempo de inatividade. Os objetos de banco de dados do sistema não são sincronizados e permitir que os clientes localizem e conectem-se facilmente a um secundário promovido pode ser desafiador.