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

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

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 servidor monitor

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 as configurações de envio de logs com um único servidor secundário

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

Para obter informações sobre como atualizar vários servidores secundários, consulte Atualizando várias instâncias do servidor secundário, posteriormente 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 SQL Server 2005 ou superior para SQL Server 2014 antes de atualizar a instância do servidor primário. Sempre atualize primeiro a instância do servidor secundário. 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 poderá 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 servidor primário SQL Server 2005 ou superior. O processo para atualizar as instâncias do servidor secundário depende em parte 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 do servidor secundárioposteriormente neste tópico.

Enquanto a 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, portanto, os backups de log de transações não restaurados serão acumulados. A quantidade de acumulação dependerá da frequência de backups agendados 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 retomarão a copiar e a restaurar os backups de log da instância do servidor primário, o servidor A. O tempo necessário para o servidor secundário atualizar 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.

Atualizando a instância do servidor primário

Ao planejar uma atualização, uma consideração importante é a quantidade de tempo que seu banco de dados ficará indisponível. O cenário de atualização mais simples indisponibiliza o banco de dados durante a atualização do 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 servidor primário SQL Server 2005 ou superior para um servidor secundário 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 novamente para o servidor primário original e manter a configuração original de envio de logs. Alternativamente, você poderá remover a configuração original de envio de logs 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 os dois cenários.

Cenário 1: Atualização da instância do servidor primário sem failover

Este é o cenário mais simples, entretanto ele gera mais tempo de inatividade do que o cenário que usa failover. A instância do servidor primário é simplesmente atualizada e o banco de dados fica indisponível durante esta 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: Atualização da instância do servidor primário com failover

Este cenário maximiza a disponibilidade e minimiza tempo de inatividade. Ele utiliza um failover controlado para a instância do servidor secundário, o que mantém 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 do 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 do servidor primário original para SQL Server 2014 e configurar o envio de logs em uma instância do servidor primário SQL Server 2014. Esses procedimentos são descritos nesta seção.

Procedimento 1: execute um failover controlado no servidor secundário

Failover controlado no servidor secundário:

1. Execute manualmente um backup final do log de transações no banco de dados primário especificando WITH NORECOVERY. Esse backup de log captura quaisquer registros de log ainda sem backup e coloca o banco de dados offline. Observe que enquanto o banco de dados estiver offline, o trabalho de backup de envio de logs falhará.

   O exemplo seguinte cria um backup da parte final do log do banco de dados do AdventureWorks no servidor primário. O arquivo de backup é nomeado como 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 nomeação 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. Assegure-se de que todos os backups obtidos automaticamente pelo backup de envio de logs tenham sido aplicados. Para marcar 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 alguns dos arquivos de backup não foram copiados e restaurados, chame 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 Start a Job.

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

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

      O exemplo seguinte restaura o backup da parte final do log do banco de dados do AdventureWorks no banco de dados secundário. O exemplo usa a opção de 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 do servidor secundárioposteriormente neste tópico.

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

   5. Cuidado para que o log de transações do banco de dados secundário não seja preenchido enquanto o banco de dados estiver online. Para impedir que o log de transações seja preenchido, talvez seja necessário fazer seu backup. Nesse caso, recomendamos que você faça seu backup em um local compartilhado, um compartilhamento de backup, para tornar os backups disponíveis para restauração em outra instância do servidor.

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

Depois que você atualizar a instância original do servidor primário para 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 dependerá de o envio de logs ainda estar configurado, como a seguir:

• Se você manteve a configuração de envio de logs SQL Server 2005 ou superior, volte para a instância original do servidor primário. Para obter mais informações, consulte Para alternar novamente para a instância do servidor primário originalposteriormente nessa seção.

• Se você tiver removido a configuração de envio de logs antes de efetuar o failover, crie uma nova configuração de envio de logs em que a instância do servidor secundário original seja a nova instância do servidor primário. Para obter mais informações, consulte Para manter a instância do servidor secundário antiga como a nova instância do servidor primárioposteriormente nessa seção.

Para alternar novamente para a instância do servidor primário original

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

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

2. Se alguns backups de log de transações forem feitos no banco de dados primário provisório, além do backup da parte final que você criou na etapa 1, restaure aqueles 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 SQL Server formato 2014 quando o primeiro backup de log é restaurado.

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

4. Efetue o failover novamente no banco de dados primário original (no servidor A) redirecionando os clientes para o servidor secundário online do servidor primário original.

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

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 utilizando a instância do servidor secundário antiga, B, como o servidor primário e a instância do servidor primário antiga, A, como o novo servidor secundário, como a seguir:

1. Para evitar a realizaçã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 no novo banco de dados secundário. Na configuração de exemplo, isto envolve a restauração dos backups de log efetuados no servidor B para o banco de dados do 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 do servidor secundário (servidor A) usando WITH NORECOVERY. A primeira operação de restauração atualiza o banco de dados para 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 SQL Server Management Studio, especifique que o banco de dados secundário já está inicializado.

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

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

   Importante

   Quando você efetuar o failover para um novo banco de dados primário, deverá assegurar-se de que os metadados estejam 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 do servidor secundário

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

Esta seção discute como atualizar usando um failover e alternando de volta para o servidor primário original. O processo de atualização da instância primária com failover torna-se mais complexo quando há várias instâncias do servidor secundário. No procedimento seguinte, depois que todos os servidores secundários forem atualizados, ocorrerá o failover do servidor primário para um dos bancos de dados secundários atualizados. O servidor primário original será atualizado e ocorrerá o failover do envio de logs novamente para ele.

Para atualizar usando um failover e alternando de volta para o servidor primário original

1. Atualize todas as instâncias do servidor secundário (servidores B e C).

2. Obtenha a parte final do log de transações do banco de dados primário (no servidor A) e coloque o banco de dados offline efetuando o backup do log de transações por meio do WITH NORECOVERY.

3. No servidor secundário para o qual você planeja efetuar failover (servidor B) coloque o banco de dados secundário online restaurando o backup de log por meio do 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 por meio do 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 serão bem-sucedidos porque novos arquivos de backup de log não serão colocados no compartilhamento de backup.

5. Efetue o failover do banco de dados redirecionando os clientes do servidor primário original (servidor A) para o servidor secundário online (servidor B). O banco de dados online se tornará um servidor primário provisório, mantendo o banco de dados disponível enquanto o servidor primário original estiver 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 que você criou no banco de dados primário provisório (no servidor B) para todos os outros bancos de dados secundários (no servidor C) com o WITH NORECOVERY. Isso permite que o envio de logs continue do banco de dados primário original depois de sua atualização, sem exigir uma restauração completa 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) por meio do WITH RECOVERY.

Reimplantando o envio de logs

Se você não desejar migrar sua configuração de envio de logs usando um dos procedimentos citados acima, é possível reimplantar o envio de logs do zero, reinicializando seu banco de dados secundário com um backup completo e com a restauração do banco de dados primário. Essa pode ser uma boa opção, se você tiver um banco de dados pequeno ou se uma 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)Tabelasde envio de logs e procedimentos armazenados