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
Para preservar a sua solução de recuperação de desastres no envio de registos, atualize ou aplique atualizações de manutenção na ordem adequada. As atualizações de manutenção incluem pacotes de serviço ou atualizações cumulativas.
Observação
Uma configuração atualizada de envio de registos utiliza a backup compression default opção de configuração ao nível do servidor para controlar se a compressão de backup é usada para os ficheiros de backup dos registos de transações. Pode especificar como será feita a compressão dos backups de registo para cada configuração de envio de registos. Para obter mais informações, consulte Configurar envio de logs (SQL Server).
Pré-requisitos
Antes de começar, reveja as seguintes informações importantes.
| Artigo | Description |
|---|---|
| Atualizações de versões e edições suportadas | Verifique se pode atualizar para a versão desejada do SQL Server a partir do seu sistema operativo Windows existente e da versão do SQL Server. Por exemplo, não podes atualizar diretamente de uma instância do SQL Server 2005 (9.x) para o SQL Server 2025 (17.x). |
| Escolha um método de atualização do Mecanismo de Banco de Dados | Selecione o método de atualização adequado e os passos com base na sua análise das versões e edições suportadas. Considere também outros componentes instalados no seu ambiente para atualizar os componentes na ordem correta. |
| Planear e testar o plano de atualização do Mecanismo de Base de Dados | Revise as notas de lançamento e os problemas conhecidos de atualização, a lista de verificação pré-atualização, desenvolvendo e testando o plano de atualização. |
| Requisitos de hardware e software para a instalação do SQL Server | Revise os requisitos de software para instalar o SQL Server. Se for necessário outro software, instale-o em cada nó antes de iniciar o processo de atualização para minimizar qualquer tempo de inatividade. |
| Suporte para grupos de disponibilidade contida adicionado no SQL Server 2022 (16.x) | Se quiser começar a usar grupos de disponibilidade contida com log shipping, precisa de eliminar e recriar a topologia de log shipping. No entanto, se já estiveres a usar grupos de disponibilidade contida com envio de logs, as atualizações são suportadas. |
| Suporte TDS 8.0 adicionado no SQL Server 2025 (17.x) | Se quiser usar TDS 8.0 com o envio de logs em SQL 2025 e versões posteriores, primeiro precisa de remover a sua configuração atual de envio de logs. |
Proteja os seus dados antes da atualização
Para proteger os seus dados durante uma atualização de envio de registos, siga estes passos:
Faça uma cópia de segurança completa da base de dados em todas as bases de dados principais.
Para obter mais informações, consulte Criar um backup completo de banco de dados (SQL Server).
Execute o comando DBCC CHECKDB em todas as bases de dados primárias.
Importante
Certifica-te de que o teu servidor principal tem espaço suficiente para guardar as cópias de backup dos registos durante o tempo que a atualização dos secundários demorar. Se estiver a passar para um secundário, esta mesma preocupação aplica-se ao secundário (o novo primário).
Atualize a instância (opcional) do servidor monitor
Podes atualizar a instância do servidor de monitor, se existir, a qualquer momento. No entanto, não precisas de atualizar o servidor monitor opcional quando atualizas os servidores principal e secundário.
Enquanto o servidor monitor está a ser atualizado, a configuração de envio de registos continua a funcionar, mas o seu estado não está registado nas tabelas do monitor. Quaisquer alertas configurados não são ativados enquanto o servidor de monitorização está a ser atualizado. Após a atualização, pode atualizar a informação nas tabelas de monitorização executando o procedimento armazenado de sistema sp_refresh_log_shipping_monitor. Para mais informações sobre um servidor monitor, consulte Sobre o Envio de Logs (SQL Server).
Atualizar as instâncias dos servidores secundários
O processo de atualização envolve atualizar as instâncias secundárias do servidor SQL Server antes de atualizar a instância principal do servidor. Atualiza sempre primeiro as instâncias secundárias do SQL Server. O envio de registos continua ao longo de todo o processo de atualização porque as instâncias secundárias do servidor atualizado continuam a restaurar as cópias de segurança dos registos a partir da instância principal do servidor.
Se atualizar a instância do servidor principal antes da instância secundária, o envio de logs falha porque um backup criado numa versão mais recente do SQL Server não pode ser restaurado numa versão mais antiga do SQL Server. Podes atualizar as instâncias secundárias simultaneamente ou em série, mas tens de atualizar todas as instâncias secundárias antes de atualizar a instância primária para evitar falhas no envio de registos.
Ao atualizar uma instância secundária de servidor, os trabalhos de envio de log para copiar e restaurar não funcionam. Esta condição significa que as cópias de segurança dos registos de transações não restauradas acumulam-se na réplica principal, e é necessário ter espaço suficiente para guardar essas cópias de segurança não restauradas. A quantidade de acumulação depende da frequência de backup agendada na instância principal do servidor e da sequência em que se atualizam as instâncias secundárias. Além disso, se estiver configurado um servidor de monitorização separado, podem ser emitidos alertas indicando que as restaurações não foram realizadas durante mais tempo do que o intervalo configurado.
Depois de atualizares as instâncias secundárias do servidor, os trabalhos dos agentes de envio de registos retomam e continuam a copiar e restaurar cópias de segurança dos registos da instância principal do servidor para as instâncias secundárias. O tempo necessário para que as instâncias do servidor secundário atualizem a base de dados secundária varia, dependendo do tempo necessário para atualizar a instância do servidor secundário e da frequência das cópias de segurança no servidor principal.
Durante a atualização do servidor, a base de dados secundária em si não é atualizada para a nova versão. Só é atualizado se for ativado iniciando um failover da base de dados de registos enviados. Em teoria, esta condição poderia persistir indefinidamente. O tempo necessário para atualizar os metadados da base de dados quando é iniciado um failover é reduzido.
Importante
A RESTORE WITH STANDBY opção não é suportada para uma base de dados que precisa de atualização. Se uma base de dados secundária atualizada for configurada usando RESTORE WITH STANDBY, os registos de transações já não podem ser restaurados após a atualização. Para retomar o envio de registos nessa base de dados secundária, precisa de configurar novamente o envio de registos nesse servidor de espera. Para mais informações sobre a STANDBY opção, consulte Restaurar uma Cópia de Segurança de Registo de Transações (SQL Server).
Atualizar a instância principal do servidor
Como o log shipping é principalmente uma solução de recuperação de desastres, o cenário mais simples e comum é atualizar a instância principal no local. A base de dados não está disponível durante esta atualização. Assim que o servidor é atualizado, a base de dados é automaticamente reativada, o que provoca a sua atualização. Depois de a base de dados ser atualizada, os trabalhos de envio de registos retomam.
O envio de registos também suporta a opção de fazer failover para um envio secundário de logs e, opcionalmente , mudar os papéis entre servidores primários e secundários de envio de log.
No entanto, como o transporte de logs raramente é configurado como uma solução de alta disponibilidade (as opções mais recentes são muito mais robustas), o failover geralmente não minimiza o tempo de inatividade. Os objetos da base de dados do sistema não estão sincronizados, e permitir que os clientes localizem e se liguem facilmente a um secundário promovido pode ser um desafio.