Atualização do envio de logs para SQL Server 2016 (Transact-SQL)
Aplica-se a: 
SQL Server
Para preservar a solução de recuperação de desastre de envio de logs, atualize ou aplique atualizações de serviço na ordem apropriada. Atualizações de serviço incluem service packs ou atualizações cumulativas.
Observação
A compactação de backup foi introduzida no SQL Server 2008 (10.0.x) Enterprise. Uma configuração de envio de logs atualizada usa a opção de configuração no nível do servidor de compactação de backup padrão para controlar se a compactação será utilizada para os arquivos de backup de log de transações. O comportamento de compactação de backups de log pode ser especificado para cada configuração de envio de logs. Para obter mais informações, confira Configurar o envio de logs (SQL Server).
Neste tópico:
Pré-requisitos
Antes de começar, examine as seguintes informações importantes:
Atualizações compatíveis de versão e edição: Verifique se você pode atualizar para o SQL Server 2016 de sua versão do sistema operacional Windows e da versão do SQL Server. Por exemplo, não é possível atualizar diretamente de uma instância do SQL Server 2005 para o SQL Server 2019 (15.x).
Escolher um método de atualização do mecanismo de banco de dados: selecione o método e as etapas de atualização apropriados com base em sua análise de atualizações de versão e de edição com suporte e também com base em outros componentes instalados em seu ambiente a fim de atualizar os componentes na ordem correta.
Planejar e testar o plano de atualização do mecanismo de banco de dados: Analise as notas de versão e os problemas conhecidos da atualização, a lista de verificação pré-atualização, e desenvolva e teste o plano de atualização.
Requisitos de hardware e software para a instalação do SQL Server 2016: Analise os requisitos de software para a instalação do SQL Server. Se for necessário um software adicional, instale-o em cada nó antes de começar o processo de atualização para minimizar qualquer tempo de inatividade.
Proteja os dados antes da atualização
Como uma prática recomendada, sugerimos que você proteja seus dados antes de uma atualização de envio de logs.
Para proteger os dados
Execute um backup completo de todos os bancos de dados primários.
Para obter mais informações, confira Criar um backup completo de banco de dados (SQL Server).
Execute o comando DBCC CHECKDB em todos os bancos de dados primários.
Importante
Verifique se você tem espaço suficiente no servidor primário para manter as cópias de backup do log durante toda a atualização dos secundários. Se estiver realizando o failover para um secundário, essa mesma preocupação se aplicará ao secundário (o novo primário).
Atualização da instância do servidor monitor (opcional)
Se existir uma instância do servidor monitor, ela poderá ser atualizada em 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 envio de logs continua funcionando, mas seu status não será registrado nas tabelas do monitor. Qualquer alerta que tenha sido configurado não será disparado, enquanto o servidor monitor estiver sendo atualizado. Após a atualização, você poderá atualizar as informações nas tabelas do monitor executando o procedimento armazenado do sistema sp_refresh_log_shipping_monitor. Para obter mais informações sobre um servidor de monitor, confira Sobre o envio de logs (SQL Server).
Atualização das instâncias do servidor secundário
O processo de atualização envolve atualizar as instâncias do servidor secundário do SQL Server antes de atualizar a instância de servidor primário. Sempre atualize primeiro a instância do SQL Server secundário. O envio de logs continua ao longo do processo de atualização, pois as instâncias do servidor secundário atualizadas continuam restaurando os backups de log da instância do servidor primário. Se o servidor primário for atualizado antes da instância do servidor secundário, o envio de logs falhará, pois um backup criado em uma versão mais recente do SQL Server não pode ser restaurado em uma versão mais antiga do SQL Server. Você pode atualizar as instâncias secundárias de maneira simultânea ou em série, mas todas as instâncias secundárias devem ser atualizadas antes de atualizar a instância primária, a fim de evitar uma falha de envio de logs.
Enquanto uma instância do servidor secundário estiver sendo atualizada, os trabalhos de cópia e restauração de envio de logs não serão executados. Isso significa que os backups de log de transações não restaurados serão acumulados no primário, e você precisará ter espaço suficiente para manter esses backups não restaurados. A quantidade de acumulação dependerá da frequência de backups agendados 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 tiver sido configurado, alertas poderão ser gerados indicando que restaurações não foram realizadas por um período mais longo do que o intervalo configurado.
Assim que as instâncias do servidor secundário forem atualizadas, os trabalhos de agentes de envio de logs serão retomados e continuarão a copiar e a restaurar os backups de log da instância de servidor primário para as instâncias do servidor secundário. A quantidade de tempo necessário para as instâncias do servidor secundário atualizarem o banco de dados secundário varia, dependendo do tempo gasto para atualizar a instância do servidor secundário e da frequência dos backups no servidor primário.
Observação
Durante a atualização do servidor, o banco de dados secundário não será atualizado para uma nova versão. Ele será atualizado apenas se for colocado online por meio de um failover do banco de dados de logs enviados. Em teoria, essa condição pode persistir indefinidamente. O tempo necessário para atualizar os metadados do banco de dados quando um failover é iniciado é pequeno.
Importante
A opção RESTORE WITH STANDBY não tem suporte para um banco de dados que requer atualização. Se um banco de dados secundário atualizado foi configurado usando RESTORE WITH STANDBY, os logs de transação já não poderão ser restaurados depois da atualização. Para retomar o envio de logs no banco de dados secundário, você precisará configurar o envio de logs novamente no servidor em espera. Para obter mais informações sobre a opção STANDBY, confira Restaurar um backup de log de transações (SQL Server).
Atualizando a instância do servidor primário
Como o envio de log é basicamente uma solução de recuperação de desastres, o cenário mais simples e mais comum é atualizar a instância primária no local, e o banco de dados simplesmente fica indisponível durante essa atualização. Quando o servidor é atualizado, o banco de dados fica online automaticamente, o que faz com que ele seja atualizado. Depois que o banco de dados é atualizado, os trabalhos de envio de logs são retomados.
Observação
O envio de log também dá suporte à opção Executar failover para um secundário de envio de logs (SQL Server) e, opcionalmente, Alterar funções entre servidores de envio de log primários e secundários (SQL Server). 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), o failover geralmente não reduzirá o tempo de inatividade, pois os objetos de banco de dados do sistema não serão sincronizados, e permitir que os clientes localizem e se conectem facilmente a um secundário promovido pode ser um trabalho difícil.
Consulte Também
Atualizar para o SQL Server 2016 usando o Assistente de Instalação (instalação)
Instalar o SQL Server 2016 do prompt de comando
Configurar o envio de logs (SQL Server)
Monitorar envio de logs (Transact-SQL)
Tabelas de envio de log e procedimentos armazenados