Atualizando o envio de logs do SQL Server 2005 para o SQL Server 2008

O processo de atualização envolve a atualização das instâncias do servidor secundário de uma configuração de envio de logs do SQL Server 2005 para o SQL Server 2008 antes de atualizar a instância de servidor primário. Sempre atualize primeiro a instância do servidor secundário. Se o servidor primário fosse atualizado antes de um 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 ao longo do processo de atualização porque os servidores secundários atualizados continuam restaurando os backups de log do servidor primário do SQL Server 2005. 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 "Considerações para atualizar várias instâncias do servidor secundário", posteriormente 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 freqüê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 continuarã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 freqüê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 um banco de dados do SQL Server 2008. Ele só será atualizado se estiver online.

Importante

A opção RESTORE WITH STANDBY não será aceita para um banco de dados que necessite de atualização. Se um banco de dados secundário atualizado tiver sido configurado usando RESTORE WITH STANDBY, os logs de transação não poderão ser mais restaurados depois da atualização. Para continuar 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 Argumentos de RESTORE (Transact-SQL).

Ao planejar uma atualização, uma consideração importante é o tempo que seu banco de dados permanecerá 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).

Por meio de um processo de atualização mais complicado, você poderá maximizar a disponibilidade do seu banco de dados efetuando failover do servidor primário do SQL Server 2005 para um servidor secundário do SQL Server 2008 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. Este tópico descreve cada um desses cenários.

Importante
Atualize a instância do servidor secundário antes de atualizar a instância de servidor primário. Para obter mais informações, consulte "Atualizando a instância do servidor secundário", mencionada anteriormente neste tópico.

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

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: a execução de um failover controlado para o servidor secundário, a atualização da instância do servidor primário original para SQL Server 2008 e a configuração de envio de logs em uma instância do servidor primário do SQL Server 2008. 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 do servidor primário original tiver sido atualizada. Para obter mais informações, consulte Removendo envio de logs.

Procedimento 1. Execute um failover controlado no servidor secundário

Failover controlado no servidor secundário:

1. Execute manualmente um backup do final do log de transações do 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 verificar quais trabalhos de backup foram aplicados, use o procedimento armazenado do sistema sp_help_log_shipping_monitor (Transact-SQL) 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 forem 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 mais informações, consulte Como iniciar um trabalho (SQL Server Management Studio) ou sp_start_job (Transact-SQL).

   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 resultado de ser colocado online, o banco de dados será atualizado para SQL Server 2008.

      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 "Considerações para atualizar várias instâncias do servidor secundário", posteriormente 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. Atualize a instância do servidor primário original para o SQL Server 2008

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

Procedimento 3. Configure o envio de logs no SQL Server 2008

O resto do processo de atualização dependerá se o envio de logs ainda está configurado, como a seguir:

• Se você manteve a configuração de envio de logs do SQL Server 2005, alterne novamente para a instância do servidor primário original. Para obter mais informações, consulte "Para alternar novamente para a instância do servidor primário original", posteriormente nesta 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"Manter a instância do servidor secundário antiga como a nova instância do servidor primário", posteriormente nesta 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 efetuados no banco de dados primário provisório, outro backup da parte final diferente daquele que você criou na etapa 1, restaurará aqueles backups de log usando WITH NORECOVERY para o banco de dados offline no servidor primário original (servidor A). O banco de dados será atualizado para o formato SQL Server 2008 quando o primeiro backup de log for 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 continuará.

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:

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

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 atualizará o banco de dados para SQL Server 2008.

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 se o banco de dados secundário já está inicializado.

   Para configurar o envio de logs

   • Como habilitar o envio de logs (SQL Server Management Studio)

   • Como habilitar o envio de logs (Transact-SQL)

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, consulte Gerenciando metadados ao disponibilizar um banco de dados em outra instância do servidor.

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.

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 para o qual você efetuou failover — o banco de dados primário provisório (no servidor B), faça manualmente backup do log de transações por meio do 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.