Partilhar via

Atualizar o envio de logs para o SQL Server 2014 (Transact-SQL)

É possível preservar as configurações de envio de logs ao atualizar do SQL Server 2005, DO SQL Server 2008, do SQL Server 2008 R2 ou do SQL Server 2012 para o SQL Server 2014. Este tópico descreve cenários alternativos e práticas recomendadas para atualizar uma configuração de envio de logs.

Observação

A compactação de backup foi introduzida no SQL Server 2008 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).

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

  1. 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).

  2. Execute o comando DBCC CHECKDB em todos os bancos de dados primários.

Atualizando a Instância do Monitor Server

Se existir uma instância do servidor monitor, ela poderá ser atualizada em qualquer momento.

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.

Atualizando configurações de envio de logs com um único servidor secundário

O processo de atualização descrito nesta seção pressupõe uma configuração que consiste no servidor primário e apenas um servidor secundário. Essa configuração é representada na ilustração a seguir, que mostra uma instância de servidor primário, A e uma única instância de servidor secundário, B.

Um servidor secundário e nenhum servidor monitor

Para obter informações sobre como atualizar vários servidores secundários, consulte Atualizando várias instâncias de servidor secundário, mais adiante neste tópico.

Atualizando a instância do servidor secundário

O processo de atualização envolve a atualização das instâncias de servidor secundário de uma configuração de envio de logs do SQL Server 2005 ou superior para o SQL Server 2014 antes de atualizar a instância do servidor primário. Sempre atualize a instância do servidor secundário primeiro. Se o servidor primário fosse atualizado antes de um servidor secundário, o envio de logs falharia porque 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.

O envio de logs continua durante todo o processo de atualização porque os servidores secundários atualizados continuam restaurando os backups de log do SQL Server 2005 ou do servidor primário superior. O processo de atualização das instâncias de servidor secundário depende, em parte, de se a configuração de envio de logs possui vários servidores secundários. Para obter mais informações, consulte Atualizando várias instâncias de servidor secundário, mais adiante neste tópico.

Enquanto a instância do servidor secundário está sendo atualizada, os trabalhos de cópia e restauração do transporte de logs não são executados, portanto, os backups de log de transações não restaurados serão acumulados. A quantidade de acúmulo depende da frequência do backup agendado no servidor primário. 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.

Depois que o servidor secundário tiver sido atualizado, 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, o servidor A. O tempo necessário para que o servidor secundário atualize o banco de dados secundário varia, dependendo do tempo necessário para atualizar o 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 é atualizado para um banco de dados do SQL Server 2014. Ele será atualizado somente se for colocado online.

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, consulte RESTORE Arguments (Transact-SQL).

Atualizando a instância do servidor primário

Ao planejar uma atualização, uma consideração significativa é a quantidade de tempo que o banco de dados ficará indisponível. O cenário de atualização mais simples envolve o banco de dados não disponível enquanto você atualiza o servidor primário (cenário 1, abaixo).

Ao custo de um processo de atualização mais complicado, você pode maximizar a disponibilidade do banco de dados fazendo failover do SQL Server 2005 ou servidor primário superior para um servidor secundário do SQL Server 2014 antes de atualizar o servidor primário original (cenário 2, abaixo). Há duas variantes do cenário de failover. Você pode alternar de volta para o servidor primário original e manter a configuração de envio de log original. Como alternativa, você pode remover a configuração de envio de log original antes de atualizar o servidor primário original e, posteriormente, criar uma nova configuração usando o novo servidor primário. Esta seção descreve esses dois cenários.

Importante

Certifique-se de atualizar a instância do servidor secundário antes de atualizar a instância do servidor primário. Para obter mais informações, consulte Atualizar a Instância do Servidor Secundário, anteriormente neste tópico.

Cenário 1: Atualize a instância do servidor primário sem realizar failover

Esse é o cenário mais simples, mas causa mais tempo de inatividade do que usar failover. A instância do servidor primário é simplesmente atualizada e o banco de dados não está disponí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.

Cenário 2: atualizar a instância do servidor primário com failover

Esse cenário maximiza a disponibilidade e minimiza o tempo de inatividade. Ele utiliza um failover controlado para a instância secundária do servidor, mantendo o banco de dados disponível enquanto a instância do servidor primário original é atualizada. O tempo de inatividade é limitado ao tempo relativamente curto necessário para fazer failover, em vez do tempo necessário para atualizar a instância do servidor primário.

A atualização da instância do servidor primário com failover envolve três procedimentos gerais: executar um failover controlado para o servidor secundário, atualizar a instância original do servidor primário para o SQL Server 2014 e configurar o envio de logs em uma instância do servidor primário do SQL Server 2014. Esses procedimentos são descritos nesta seção.

Importante

Se você planeja ter a instância do servidor secundário como a nova instância do servidor primário, precisará remover a configuração de envio de logs. O envio de logs precisará ser reconfigurado do novo primário para o novo secundário, depois que a instância original do servidor primário tiver sido atualizada. Para mais informações, consulte Remover Envio de Logs (SQL Server).

Procedimento 1: executar um failover controlado para o servidor secundário

Failover controlado para o servidor secundário:

  1. Execute manualmente um backup de log final do log de transações no banco de dados primário especificando WITH NORECOVERY. Este backup de log captura quaisquer registros de log que ainda não foram feitos backup e coloca o banco de dados offline. Observe que, embora o banco de dados esteja offline, o trabalho de backup de envio de logs falhará.

    O exemplo a seguir cria um backup de log final do banco de dados AdventureWorks no servidor primário. O arquivo de backup é nomeado Failover_AW_20080315.trn:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

    Recomendamos que você use uma convenção de nomenclatura de arquivo distinta para diferenciar o arquivo de backup criado manualmente dos arquivos de backup criados pelo trabalho de backup de envio de logs.

  2. No servidor secundário:

    1. Verifique se todos os backups feitos automaticamente pelos trabalhos de backup de envio de logs foram aplicados. Para verificar quais trabalhos de backup foram aplicados, use o procedimento armazenado do sistema sp_help_log_shipping_monitor no servidor monitor ou nos servidores primário e secundário. O mesmo arquivo deve ser listado nas colunas last_backup_file, last_copied_file e last_restored_file . Se qualquer um dos arquivos de backup não tiver sido copiado e restaurado, invoque manualmente os trabalhos de cópia e restauração do agente para a configuração de envio de logs.

      Para obter informações sobre como iniciar um trabalho, consulte Iniciar um trabalho.

    2. Copie o arquivo de backup de log final que você criou na etapa 1 do compartilhamento de arquivos para o local usado pelo envio de logs no servidor secundário.

    3. Restaure o backup de log final especificando WITH RECOVERY para deixar o banco de dados disponível. Como parte de ser colocado online, o banco de dados será atualizado para o SQL Server 2014.

      O exemplo a seguir restaura o backup de log final do banco de dados AdventureWorks no banco de dados secundário. O exemplo usa a opção WITH RECOVERY, que coloca o banco de dados online:

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO

      Observação

      Para uma configuração que contém mais de um servidor secundário, há considerações adicionais. Para obter mais informações, consulte Atualizando várias instâncias de servidor secundário, mais adiante neste tópico.

    4. Faça failover do banco de dados redirecionando clientes do servidor primário original (servidor A) para o servidor secundário online (servidor B).

    5. Tome cuidado para que o log de transações do banco de dados secundário não preencha enquanto o banco de dados está online. Para impedir que o log de transações seja preenchido, talvez seja necessário fazer backup dele. Nesse caso, recomendamos que você faça backup dele em um local compartilhado, um compartilhamento de backup, para disponibilizar os backups para restauração na outra instância do servidor.

Procedimento 2: atualizar a instância original do servidor primário para o SQL Server 2014

Depois de atualizar a instância original do servidor primário para o SQL Server 2014, o banco de dados ainda estará offline e no formato.

Procedimento 3: Configurar o envio de logs no SQL Server 2014

O restante do processo de atualização depende se o envio de logs ainda está configurado, da seguinte maneira:

Para retornar à instância original do Servidor Primário

  1. No servidor primário provisório (servidor B), faça backup da parte final do log usando WITH NORECOVERY para criar um backup de log final e colocar o banco de dados offline. O backup de log final é nomeado Switchback_AW_20080315.trn. Por exemplo:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Se algum backup de log de transações tiver sido feito no banco de dados primário provisório, além do backup final que você criou na etapa 1, restaure esses backups de log usando WITH NORECOVERY para o banco de dados offline no servidor primário original (servidor A). O banco de dados é atualizado para o formato SQL Server 2014 quando o primeiro backup de log é restaurado.

  3. Restaure o backup do tail-log, Switchback_AW_20080315.trn, no banco de dados primário original (no servidor A) usando WITH RECOVERY para colocar o banco de dados online.

  4. Realize a transferência de volta para o banco de dados primário original (no servidor A) redirecionando os clientes do servidor primário original para o servidor secundário que está online.

Depois que o banco de dados ficar online, a configuração original de envio de logs será retomada.

Para manter a instância do servidor secundário antiga como a nova instância do servidor primário

Estabeleça uma nova configuração de envio de logs usando a instância de servidor secundário antiga, B, como o servidor primário e a instância do servidor primário antigo, A, como o novo servidor secundário, da seguinte maneira:

Importante

A configuração antiga de envio de logs deveria ter sido removida do servidor primário original no início do processo antes de colocar o backup manual do log de transações que tirou o banco de dados offline.

  1. Para evitar a execução de um backup completo e restauração do banco de dados no novo servidor secundário (servidor A), aplique os backups de log do novo banco de dados primário ao novo banco de dados secundário. Na configuração de exemplo, isso envolve a restauração dos backups de log feitos no servidor B para o banco de dados no servidor A.

  2. Faça backup do log do novo banco de dados primário (no servidor B).

  3. Restaure os backups de log para a nova instância de servidor secundário (servidor A) usando WITH NORECOVERY. A primeira operação de restauração atualiza o banco de dados para o SQL Server 2014.

  4. Configure o envio de logs com o servidor secundário anterior (servidor B) como a instância do servidor primário.

    Importante

    Se você usar o SQL Server Management Studio, especifique que o banco de dados secundário já está inicializado.

    Para obter mais informações, confira Configurar o envio de logs (SQL Server).

  5. Faça failover do banco de dados redirecionando clientes do servidor primário original (servidor A) para o servidor secundário online (servidor B).

    Importante

    Ao fazer failover para um novo banco de dados primário, você deve garantir que seus metadados sejam consistentes com os metadados do banco de dados primário original. Para obter mais informações, confira Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server).

Atualizando várias instâncias de servidor secundário

Essa configuração é representada na ilustração a seguir, que mostra uma instância de servidor primário, A e duas instâncias de servidor secundário, B e C.

Dois servidores secundários e nenhum servidor monitor

Esta seção discute como realizar atualizações por meio de um processo de failover e depois retornar ao servidor primário original. Ao atualizar a instância primária com failover, o processo torna-se mais complexo quando existem várias instâncias de servidor secundário. No procedimento a seguir, depois que todos os servidores secundários são atualizados, o servidor primário faz failover para um dos bancos de dados secundários atualizados. O servidor primário original é atualizado, e o envio de logs é transferido de volta para ele.

Importante

Sempre atualize todas as instâncias do servidor secundário antes de atualizar o servidor primário.

Para atualizar através de failover e depois retornar ao servidor primário original

  1. Atualize todas as instâncias de servidor secundárias (servidor B e servidor C).

  2. Obtenha a parte final do log de transações do banco de dados primário (no servidor A) e tire o banco de dados offline, fazendo backup do log de transações usando WITH NORECOVERY.

  3. No servidor secundário para o qual você planeja fazer failover (servidor B), coloca o banco de dados secundário online, restaurando o backup de log usando WITH RECOVERY.

  4. Em todos os outros servidores secundários (servidor C), deixe o banco de dados secundário offline restaurando o backup de log usando WITH NORECOVERY.

    Observação

    Os trabalhos de cópia e restauração de envio de logs serão executados nos servidores secundários, mas os trabalhos não farão nada porque novos arquivos de backup de log não serão colocados no compartilhamento de backup.

  5. Faça failover do banco de dados redirecionando clientes do servidor primário original (servidor A) para o servidor secundário online (servidor B). O banco de dados online torna-se um servidor primário provisório, mantendo o banco de dados disponível enquanto o servidor primário original está offline (servidor A).

  6. Atualize o servidor primário original (servidor A).

  7. No banco de dados no qual você fez failover do banco de dados primário provisório (no servidor B), faça backup manual do log de transações usando WITH NORECOVERY. Isso coloca o banco de dados offline.

  8. Restaure todos os backups de log de transações criados no banco de dados primário provisório (no servidor B) para todos os outros bancos de dados secundários (no servidor C) usando WITH NORECOVERY. Isso permite que o envio de logs continue do banco de dados primário original após sua atualização, sem a necessidade de uma restauração completa do banco de dados em cada banco de dados secundário.

  9. Restaure o log de transações do servidor primário provisório (servidor B) para o banco de dados primário original (no servidor A) usando WITH RECOVERY.

Redistribuindo o envio de logs

Se você não quiser migrar sua configuração de envio de logs usando um dos procedimentos mostrados acima, poderá reimplantar o envio de logs do zero reinicializando seu banco de dados secundário com um backup completo e restauração do banco de dados primário. Essa pode ser uma opção desejável se você tiver um banco de dados pequeno ou se a alta disponibilidade não for crucial durante o procedimento de atualização.

Para obter informações sobre como habilitar o envio de logs, consulte Configurar o envio de logs (SQL Server).

Consulte Também

Backups de log de transações (SQL Server)Aplicar backups de log de transações (SQL Server)Tabelas de envio de logs e procedimentos armazenados

  • Last updated on