Configurar a recuperação de desastre em farms do SharePoint usando o envio de logs do SQL Server

Atualizado em: 2009-05-21

Este artigo descreve como usar o envio de log do Microsoft SQL Server 2005 ou do Microsoft SQL Server 2008 para criar um farm de recuperação de desastre em um data center geograficamente distribuído para o Microsoft Office SharePoint Server 2007 com Service Pack 2 (SP2). Usando essa configuração, você pode fornecer um site de recuperação de desastre que forneça resultados de pesquisa atuais quando um failover ocorrer. O artigo presume que você esteja familiarizado com os conceitos e termos apresentados em Planejar-se para a disponibilidade (Office SharePoint Server).

Frequentemente, são necessárias muitas equipes ou funções em uma organização para criar e configurar um farm e um data center secundário. Para configurar e testar o ambiente secundário, você precisa consultar os administradores dos provedores de autenticação, os administradores de bancos de dados do SQL Server e todos os administradores de farm do SharePoint afetados. Este artigo se destina primariamente a administradores de farm do SharePoint para ajudá-los a fazer o seguinte:

• Entender os requisitos para criar farms de recuperação de desastre com envio de log

• Configurar ambientes de avaliação com envio de log

• Comunicar-se com os administradores de bancos de dados do SQL Server que vão configurar o envio de log para os ambientes de produção.

Este artigo inclui as seguintes seções:

• Introdução ao envio de log

• Visão geral do Office SharePoint Server e do envio de log

• Requisitos do farm e data center secundários

• Configurando o ambiente de envio de log

• Executando o failover

• Considerações ao testar o failover

• Reconfigurar o envio de log ou o failback

• Resumo

Introdução ao envio de log

O envio de log permite que você configure o SQL Server para enviar continuamente backups de logs de transações de um banco de dados primário em uma instância de servidor primário para um ou mais bancos de dados secundários em instâncias separadas de servidores secundários. Os backups de logs de transações são aplicados individualmente a cada banco de dados secundário. A criação contínua de backups dos logs de transações de um banco de dados primário e a cópia e restauração dos mesmos para um banco de dados secundário mantêm o banco de dados secundário quase sincronizado com o banco de dados primário. O envio de log também pode incluir uma instância opcional de um terceiro servidor, conhecido como servidor monitor, que registra o histórico e o status de operações de backup e restauração e emite alertas se as operações não ocorrem conforme o agendado.

O envio de log consiste em três trabalhos. Cada trabalho executa uma das seguintes operações:

1. Faz o backup do log de transações na instância do servidor primário

2. Copia o arquivo de log de transações para a instância do servidor secundário

3. Restaura o backup do log na instância do servidor secundário

O diagrama a seguir descreve o envio de log.

Para obter mais informações, consulte o artigo dos Manuais Online do SQL Server sobre envio de log (https://go.microsoft.com/fwlink/?linkid=151252\&clcid=0x416).

Visão geral do Office SharePoint Server e do envio de log

O envio de log do SQL Server pode ser usado para enviar bancos de dados de conteúdo, inclusive bancos de dados de Meus Sites e bancos de dados de logon único (SSO) de um farm que está executando o Office SharePoint Server 2007 com SP2 para um ou mais farms secundários geograficamente dispersos.

Importante

Embora seja possível configurar o envio de log em uma versão que não seja o Office SharePoint Server 2007 com SP2, é recomendável usar o Office SharePoint Server 2007 com SP2, pois ele fornece os seguintes benefícios:

• Quando um banco de dados de conteúdo é colocado no modo somente leitura, os conjuntos de sites associados a ele também são colocados no modo somente leitura e a interface do usuário é alterada para remover atividades que exijam alterações em bancos de dados.

• A pesquisa trata os bancos de dados de conteúdo que foram desanexados e reanexados para o mesmo aplicativo Web no Office SharePoint Server 2007 com SP2 como fontes de dados conhecidas e executa rastreamentos incrementais, em vez de rastreamentos completos. Isso é importante, pois, em ambientes com log enviado, é recomendável desanexar e reanexar frequentemente bancos de dados de conteúdo no farm secundário, de modo a atualizar o banco de dados de configuração no farm secundário para que o banco de dados de configuração possa reconhecer conjuntos de sites novos ou removidos. O novo recurso para executar rastreamentos incrementais após reanexar um banco de dados reduz significativamente o tempo de rastreamento e torna a pesquisa mais atualizada.

Uso de farm secundários

Presumimos que a finalidade principal de um farm secundário seja, basicamente, a recuperação de desastre. No entanto, se criar um farm secundário que execute o Office SharePoint Server 2007 com SP2, você poderá expor sites no farm secundário com envio de log aos usuários. Você pode distribuir um arquivo de hosts que aponte para os sites no farm secundário ou definir um mapeamento de acesso alternativo dedicado para cada aplicativo Web no farm secundário que você deseja expor com um namespace secundário; por exemplo, http://secundário.contoso.com ou http://somenteleitura.contoso.com. Os sites expostos não expõem a funcionalidade de gravação aos usuários. Este artigo presume que você esteja executando o Office SharePoint Server 2007 com SP2. Para obter mais informações, consulte Executar um farm que usa bancos de dados somente leitura (Office SharePoint Server).

Dica

Se você criar um farm secundário que não esteja executando o Office SharePoint Server 2007 com SP2, é recomendável não expor sites aos usuários. Farms com envio de log sem o Office SharePoint Server 2007 com SP2 instalado são somente leitura, mas não apresentam avisos claros aos usuários que tentam gravar dados no site. Para obter mais informações sobre os problemas relacionados ao uso do Office SharePoint Server com um banco de dados de conteúdo somente leitura, consulte o artigo da Base de Dados de Conhecimento sobre uso do Microsoft Windows SharePoint Services com um banco de dados de conteúdo configurado como somente leitura no Microsoft SQL Server (https://go.microsoft.com/fwlink/?linkid=117362&clcid=0x416).

Topologia de envio de log

O diagrama a seguir descreve um cenário com dois data centers e dois farms configurados para usar o envio de log. Nesse cenário, o data center de recuperação de desastre hospeda um farm secundário somente leitura.

Há dois farms lógicos, um em cada data center. Cada farm é uma instalação separada, com bancos de dados de configuração e de conteúdo da Administração Central separados, bem como Provedores de Serviços Compartilhados (SSPs) separados. Apenas os bancos de dados de conteúdo e o banco de dados de SSO têm log enviado do data center primário para o data center secundário. O SSP A fornece pesquisa no farm primário e o SSP B fornece pesquisa no farm secundário. Um script de atualização de banco de dados de configuração (C) é executado no farm secundário. Como é mostrado no diagrama, é importante coordenar o intervalo dos três processos no ambiente secundário para que eles não se sobreponham:

1. Processando bancos de dados com log enviado

2. Rastreamento de pesquisa

3. Script de atualização de bancos de dados de configuração

Essa topologia poderá ser repetida em muitos data centers, se você configurar o envio de log do SQL Server para um ou mais data centers adicionais.

Considerações gerais ao usar o envio de log com o Office SharePoint Server

Esta seção descreve as limitações do uso do envio de log com o Office SharePoint Server 2007 com SP2.

• Por padrão, o processo de failover para o envio de log é manual. Você pode criar scripts para automatizar o failover,

• Caso ocorra um failover não planejado, talvez sejam perdidos alguns dados, dependendo da frequência do envio de log e da hora da falha. É possível perder dados do último intervalo de envio de log antes da falha.

• O banco de dados de configuração não pode ter log enviado para outro farm, porque ele contém informações específicas do computador. Você deve manter manualmente as mesmas personalizações e configurações em ambos os farms.

• O banco de dados de pesquisa não pode ter log enviado com êxito para o farm secundário, porque o banco de dados de pesquisa, o arquivo de índice e o banco de dados SSP devem ser sincronizados. Para garantir a disponibilidade da pesquisa em um farm de failover com bancos de dados com log enviado, adote uma das seguintes soluções:

  • Configure e execute um SSP que esteja configurado para fornecer pesquisa no farm de failover. Essa solução pode disponibilizar a pesquisa imediatamente depois que o farm secundário entra em funcionamento, sendo adequada para grandes volumes de dados. Este artigo descreve como configurar e executar um SSP de pesquisa no farm de failover.

  • Restaure o SSP do farm primário para o farm de failover usando os recursos de backup e recuperação internos do SharePoint. Essa solução disponibiliza a pesquisa depois que o SSP é restaurado e a pesquisa rastreia o conteúdo novamente . Se o intervalo necessário para recuperar o SSP estiver de acordo com o objetivo de tempo de recuperação do farm, convém considerar essa solução. Ela não é descrita detalhadamente neste artigo. Para obter mais informações sobre como fazer o backup do SSP de pesquisa e restaurá-lo, consulte Fazer backup e restaurar SSPs (Office SharePoint Server 2007).

• Se você estiver executando o serviço de perfil no farm primário, é recomendável configurar o SSP no farm secundário para executar o serviço de perfil. Para manter os perfis de todos os SSPs sincronizados, use o Mecanismo de Replicação de Perfis de Usuário fornecido com a versão de 32 bits do Microsoft SharePoint Administration Toolkit x86 (em inglês) (https://go.microsoft.com/fwlink/?linkid=151962\&clcid=0x416) (em inglês) ou com a versão de 64 bits do Microsoft SharePoint Administration Toolkit x64 (em inglês) (https://go.microsoft.com/fwlink/?linkid=142035\&clcid=0x416) (em inglês). Para obter mais informações, consulte User Profile Replication Engine (Office SharePoint Server).

• Não é recomendável usar o envio de log com bancos de dados que não sejam de conteúdo e SSO; por exemplo, bancos de dados do Microsoft Office Project Server 2007. Para bancos de dados não mencionados anteriormente, é recomendável executar o backup e a restauração no farm de failover.

• Os conjuntos de sites adicionados ao farm primário não são automaticamente adicionados ao banco de dados de configuração no farm secundário — devem ser adicionados por meio de operações do Stsadm ou de um script. Para bnter um script de exemplo, consulte Criar um script para atualizar a lista de sites no banco de dados de configuração do farm secundário (script de atualização).

As atualizações do Office SharePoint Server devem ser aplicadas aos binários nos farms primário e secundário, mas podem ser aplicadas ao bancos de dados no farm primário e, em seguida, ter logs enviados ao farm secundário. Este artigo não abrange detalhadamente a aplicação de patches, mas a seguir é fornecida uma visão geral do processo:

1. Pause o envio de log.

2. Desanexe os bancos de dados de conteúdo do aplicativo Web no farm secundário por meio da Administração Central ou de um script.

3. Atualize ambos os farms, começando pelo farm primário.

   Importante

   Verifique se o processo de atualização foi totalmente concluído e se foi bem-sucedido no farms primário e secundário. Os bancos de dados no farm secundário não são atualizados por um processo de atualização — são atualizados pelo envio de log.

4. Iniciar o envio de log.

5. Como tentativas de anexar bancos de dados não atualizados ao farm secundário falham e podem colocar o farm em um estado sem suporte, verifique se um ou dois ciclos de envio de log foram concluídos antes de anexar os bancos de dados de conteúdo com log enviado no farm secundário.

   Opcional. Antes de anexar os bancos de dados, você também pode usar a consulta a seguir para determinar se o esquema de banco de dados do farm primário foi totalmente replicado para o farm secundário.

   USE <contentdb>

   GO

   SELECT * FROM Versions

   A consulta retorna números de versão no formato a seguir.

   00000000-0000-0000-0000-000000000000

   A última versão na lista é a versão do Office SharePoint Server 2007 instalada mais recentemente.

   Importante

   A Microsoft geralmente não dá suporte para a execução de consultas em relação aos bancos de dados que são usados pelos Produtos e Tecnologias do SharePoint. A consulta anterior é uma exceção permitida, porque lida com metadados sobre o banco de dados. Consultas diretas podem prejudicar a confiabilidade e o desempenho do sistema. Para obter mais informações sobre os efeitos de alterações diretas em bancos de dados, consulte o artigo da Base de Dados de Conhecimento sobre suporte a alterações nos bancos de dados que são usados pelos produtos de servidor do Office e pelo Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x416)

6. Anexar os bancos de dados com log enviado ao farm secundário.

Considerações sobre desempenho ao usar o envio de log com o Office SharePoint Server

Analise a quantidade de dados que estão sendo enviados no log, para definir corretamente os intervalos de trabalhos de backup, cópia e restauração para envio de log. A quantidade de dados enviada no log é afetada pela quantidade diária de alterações nos bancos de dados de conteúdo. Com base em nossa experiência, um farm típico sofre alterações de dois a quatro por cento, mas, com alterações de manutenção, o nível de alterações pode chegar a cinco a sete por cento nos horários de pico. Para determinar a quantidade de alterações nos bancos de dados de conteúdo do sistema, para cada banco de dados de conteúdo do qual enviar log, calcule a soma de alterações nos backups de logs de transações durante um determinado intervalo de tempo e calcule o percentual de alterações comparado ao tamanho do banco de dados primário.

Verificamos que é melhor fazer backups e cópias de muitos logs de transações pequenos, em vez de alguns logs de transações grandes. É recomendável agendar os backups e cópias dos logs a intervalos frequentes. Você pode restaurar os logs de transações a intervalos menos frequentes. Convém começar usando intervalos de backup e cópia de cinco minutos e um intervalo de restauração de 15 minutos. O SQL Server 2008 inclui o recurso de intervalos de envio de log inferiores a um minuto. Para obter mais informações, consulte o artigo sobre agendamento de envio de log em menos de um minuto no SQL Server 2008 (em inglês) (https://go.microsoft.com/fwlink/?linkid=151253\&clcid=0x416) (em inglês)

Poderá haver problemas de desempenho se o tempo que o sistema leva para enviar logs exceder consistentemente o tempo necessário para criar novos logs, ou seja, se houver sempre atraso no cronograma de envio de log. Esse tipo de problema pode ser causado por questões relacionadas a produtividade ou latência. Se houver questões de produtividade e latência, é recomendável considerar o uso da Replicação do Sistema de Arquivos Distribuído (DFSR) do Windows com o serviço de diretório do Active Directory que está sendo executado no Windows Server 2003 R2 ou os Serviços de Domínio Active Directory (AD DS) em execução no Windows Server 2008 para substituir o trabalho de cópia com envio de log. Para obter mais informações sobre como usar o DFSR, consulte o artigo sobre a visão geral da solução do Sistema de Arquivos Distribuído no Microsoft Windows Server 2003 R2 (https://go.microsoft.com/fwlink/?linkid=150764\&clcid=0x416) e o artigo sobre o guia passo a passo do DFS para o Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=150765\&clcid=0x416).

O gráfico a seguir compara a produtividade fornecida por várias tecnologias de replicação que podem ser usadas para copiar logs de transações com log enviado.

O SQL Server 2008 também inclui o recurso de compactação de backups para reduzir o tamanho dos arquivos para os quais você está enviando logs. Para obter mais informações, consulte o artigo sobre ajuste do desempenho de compactação de backup no SQL Server 2008, parte 1 (em inglês) (https://go.microsoft.com/fwlink/?linkid=151254\&clcid=0x416) (em inglês) e o artigo sobre ajuste de compactação de backup, parte 2 (em inglês) (https://go.microsoft.com/fwlink/?linkid=151255\&clcid=0x416) (em inglês).

Considerações de segurança ao enviar logs com o Office SharePoint Server

Para o envio de log do SQL Server com o Office SharePoint Server 2007 com SP2, os membros da equipe devem ter as seguintes permissões:

• Para configurar o Office SharePoint Server 2007 com SP2 com envio de log e executar os procedimentos fornecidos neste artigo, um membro da equipe deve ser membro do grupo Administradores de farm do SharePoint.

• Para configurar o envio de log do SQL Server e executar os procedimentos fornecidos neste artigo, um membro da equipe deve ser membro da função de servidor fixa sysadmin em cada instância do servidor.

Quando um administrador de banco de dados configura um banco de dados com log enviado, os logons e permissões do SQL Server para o banco de dados a ser usado com um farm do SharePoint não são automaticamente configurados nos bancos de dados mestre e msdb no servidor com log enviado. Em vez disso, você deve configurar as permissões para os logons necessários. As permissões incluem, sem limitação, os seguintes itens:

• A conta do pool de aplicativos da Administração Central deve ser membro das funções de servidor fixas dbcreator e securityadmin. 

• Todas as contas de pools de aplicativos e as contas de acesso de conteúdo padrão e serviços de pesquisa devem ter logons do SQL Server, embora essas contas não sejam atribuídas às funções de servidor fixas do SQL Server nem às funções de bancos de dados fixas.

• Os membros do grupo do SharePoint Administradores de Farm também devem ter logons do SQL Server e devem ser membros das mesmas funções que a conta de pool de aplicativos da Administração Central.

É recomendável transferir os logons e permissões do servidor de entidade de segurança para o servidor espelhado executando um script. Um script de exemplo está disponível no artigo da Base de Dados de Conhecimento 918992 sobre como transferir os logons e as senhas entre instâncias do SQL Server 2005 (https://go.microsoft.com/fwlink/?linkid=122053\&clcid=0x416). Para obter mais informações gerais sobre como transferir metadados do SQL Server entre instâncias, consulte o artigo dos Manuais Online do SQL Server sobre gerenciamento de metadados ao tornar um banco de dados disponível em outra instância do servidor (https://go.microsoft.com/fwlink/?linkid=122055\&clcid=0x416) e o artigo da Base de Dados de Conhecimento 321247 sobre como configurar a segurança para o envio de log do SQL Server (https://go.microsoft.com/fwlink/?linkid=150830\&clcid=0x416).

Os diretórios de backup e restauração na configuração de envio de log devem atender aos seguintes requisitos:

• Para que o trabalho de backup seja bem-sucedido, a conta de serviço do SQL Server na instância primária do servidor e a conta de proxy do trabalho de backup (por padrão, a conta do SQL Server Agent na instância primária do servidor) devem ter permissões de leitura/gravação para o diretório de backup.

• Para que o trabalho de cópia seja bem-sucedido, a conta de proxy do trabalho de cópia (por padrão, a conta do SQL Server Agent na instância secundária do servidor) deve ter permissões de leitura para o diretório de backup e permissões de gravação para o diretório de cópia.

• Para que o trabalho de restauração seja bem-sucedido, a conta de serviço do SQL Server na instância secundária do servidor e a conta de proxy do trabalho de restauração (por padrão, a conta do SQL Server Agent na instância secundária do servidor) devem ter permissão de leitura/gravação para o diretório de cópia.

Requisitos para o farm e o data center secundário

Fazemos as seguintes suposições sobre o ambiente no data center secundário:

• O data center secundário inclui um controlador de domínio em execução e o provedor de autenticação adequado. Para obter mais informações, consulte o artigo sobre instalação de um controlador de domínio adicional (https://go.microsoft.com/fwlink/?linkid=150832\&clcid=0x416).

• Se uma implantação incluir recursos de integração do Microsoft Exchange 2007, o data center secundário conterá um servidor do Exchange 2007 com log enviado ou replicado de outro modo. Para obter mais informações, consulte o artigo sobre alta disponibilidade (https://go.microsoft.com/fwlink/?linkid=150839\&clcid=0x416).

O farm de failover deve ter as seguintes características:

• Um banco de dados de configuração separado e um banco de dados de conteúdo da Administração Central separado devem ser instalados e mantidos no farm de failover, o que significa que todas as alterações de configuração no farm primário devem ser replicadas manualmente no farm de failover.

  As informações armazenadas no banco de dados de configuração incluem os itens a seguir.

  Recursos ativados	Configurações de log de diagnóstico
  Modelos de formulários implantados pelo administrador	Configurações de email
  Configurações de mapeamento de acesso alternativo	Configurações de conexão de serviço externo
  Configurações de antivírus	Configurações de pesquisa no nível de farm
  Configurações do pool de aplicativos, incluindo contas de serviço (todas as contas que são executadas como aplicativos Web, incluindo a conta do rastreador e a conta de pesquisa)	Configurações do visualizador de HTML
  Tipos de arquivo bloqueados	Configurações da Lixeira e outras configurações gerais do aplicativo Web
  Configurações de implantação de conteúdo	Configurações do trabalho de timer
  Regras de impacto do rastreador	Configurações do processamento da análise de uso
  Nomes e locais de bancos de dados	Nomes e bancos de dados de aplicativos Web. Certifique-se de documentar os nomes de bancos de dados de conteúdo associados a cada aplicativo Web.
  Modelos de cota padrão	Configurações de gerenciamento de fluxo de trabalho

  Dica

  Se você tiver configurado o mapeamento de acesso alternativo para o farm principal, será muito importante configurá-lo de modo idêntico no farm secundário, no ponto de failover. Para documentar configurações de mapeamento de acesso alternativo, exporte-as para um arquivo de texto usando o comando stsadm -o enumalternatedomains.

• Todas as personalizações, como recursos, soluções, modelos de site e soluções de terceiros, como IFilters, devem ser implantadas em ambos os farms. É recomendável empacotar todas as personalizações como soluções para possibilitar a rápida implantação. Para obter mais informações, consulte Implantar personalizações.

• Os bancos de dados de conteúdo devem ser definidos para usar o modelo de recuperação completa. Para obter informações sobre como definir o modelo de recuperação para um banco de dados, consulte o artigo sobre exibição ou alteração do modelo de recuperação de um banco de dados (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151701\&clcid=0x416).

• Os servidores primário e secundário devem estar executando a mesmo edição do SQL Server 2005 ou do SQL Server 2008. O envio de log está disponível nas edições Standard, Developer e Enterprise.

• Se você planeja expor o farm secundário com log enviado aos usuários, configure o mapeamento alternativo de acesso com um namespace secundário para o farm secundário; por exemplo, http://secundário.contoso.com ou http://somenteleitura.contoso.com. Para obter mais informações, consulte Configurar mapeamento de acesso alternativo. Você substitui esse mapeamento alternativo de acesso por um mapeamento que é idêntico ao do farm primário quando ocorre failover.

Configurando o ambiente de envio de log

Esta seção fornece procedimentos detalhados para a configuração do envio de log.

Os procedimentos desta seção presumem que a organização entenda os seguintes pré-requisitos:

• Como implantar o Office SharePoint Server

• Como definir identidades de pools de aplicativos

• Como interromper e iniciar o serviço de pesquisa

• Como configurar um Sistema de Nomes de Domínio (DNS) para começar a aceitar tráfego e parar de aceitá-lo

• Como usar o arquivo de hosts para habilitar e desabilitar sites locais

A fase de failover é composta pelos seguintes procedimentos:

• Preparar o farm primário

• Preparar o farm secundário

• Configurar o envio de log

• Anexar os bancos de dados com log enviado ao farm secundário do SharePoint

• Configurar a pesquisa e os perfis para o farm secundário

• Criar um script para atualizar a lista de sites no banco de dados de configuração do farm secundário (script de atualização)

• Coordenar os intervalos dos trabalhos de envio de log, do rastreamento de pesquisa e do script de atualização

• Opcional. Manter o SSO no farm secundário

• Opcional. Fornecer aos usuários acesso ao farm somente leitura

Preparar o farm primário

As etapas para preparar o servidor primário são:

1. Definir a identidade do pool de aplicativos nos aplicativos Web para uma conta de domínio que esteja disponível em ambos os farms. Para obter mais informações, consulte Alterar a identidade do pool de aplicativos para um aplicativo Web (Office SharePoint Server).

2. Documentar todas as definições de configuração para que seja possível aplicá-las ao farm secundário. Para obter mais informações, consulte Preparar-se para fazer backup e restaurar um farm (Office SharePoint Server 2007). Sobretudo, não deixe de documentar as configurações de mapeamento alternativo de acesso exportando-as para um arquivo de texto; use o comando stsadm -o enumalternatedomains para exportar as configurações.

3. Documentar todas as personalizações. Será mais fácil reaplicar as personalizações ao farm secundário se elas forem empacotadas como soluções. Para obter mais informações, consulte Implantar personalizações.

Preparar o farm secundário

1. Instalar e configurar o Office SharePoint Server no farm secundário. Para obter mais informações, consulte Implantar o Office SharePoint Server 2007 em um ambiente de farm de servidores.

   Caso você possua equipamento suficiente, é recomendável configurar o mesmo número de servidores Web front-end e bancos de dados como o farm primário. Se não tiver equipamento suficiente, você poderá usar menos servidores no farm secundário, mas talvez ele não possa lidar com a mesma carga que o farm primário.

   Verifique se o número de versão e o nível de aplicação de patch são os mesmos nos farms primário e secundários. Para obter mais informações, consulte o artigo sobre a Central de Recursos de Atualizações para os Produtos e Tecnologias do SharePoint (em inglês) (https://go.microsoft.com/fwlink/?linkid=106182\&clcid=0x416) (em inglês).

2. Aplique todas as configurações e personalizações que você utilizou no farm primário. Para obter mais informações, consulte Implantar personalizações.

3. Crie duplicatas de todos os aplicativos Web existentes no farm primário. Use a mesma identidade de pool de aplicativos dos aplicativos Web no farm primário. Para obter mais informações, consulte Criando e gerenciando aplicativos Web (Office SharePoint Server).

4. Desabilite os trabalhos de timer a seguir. Para obter mais informações, consulte Gerenciar trabalhos de timer do SharePoint (Office SharePoint Server).

   Processamento de tarefas de fluxo de trabalho em massa	Sincronização de Perfis	Conjunto de sites: Excluir
   Log de Alterações	Sincronização Rápida de Perfis	Análise de Uso
   Estatísticas do Banco de Dados	Processamento da Central de Registros	Definição de Trabalho da Página de Propagação de Variações
   Exclusão de Site Inativo	Lixeira	Definição de Trabalho do Site de Propagação de Variações
   Aviso de Cota de Disco	Aprovação Agendada	Atualização de Política do Watson do Windows SharePoint Services
   Política de expiração	Revisão de Página Agendada	Fluxo de trabalho
   Processamento e Relatório de Isenções	Cancelamento de Publicação Agendado	Limpeza Automática de Fluxo de Trabalho
   Alertas Imediatos	Pesquisar e Processar	Failover de Fluxo de Trabalho
   Diretiva de gerenciamento de informações	Trabalhos de Sincronização do Provedor de Serviços Compartilhados

Configurar o envio de log

Você pode configurar o envio de log usando o SQL Server Management Studio ou o Transact-SQL. Este artigo descreve como usar o Management Studio.

Configurar o envio de log no primário servidor

1. Abra o Management Studio em um servidor de banco de dados no farm primário.

2. No painel de navegação do Pesquisador de Objetos, clique com o botão direito do mouse no banco de dados de conteúdo do aplicativo Web, aponte para Tarefas e clique em Enviar Logs de Transações.

   A caixa de diálogo Propriedades do Banco de Dados é exibida.

3. Selecione Habilitar como banco de dados primário em uma configuração de envio de log.

4. Clique em Configurações de backup.

   A caixa de diálogo Configurações de Backup de Log de Transações é exibida.

   1. Em Caminho de rede para a pasta de backup, digite o caminho da pasta de backup no farm primário.

   2. Digite valores para Excluir arquivos com mais de e Alertar se nenhum backup ocorrer em.

   3. Examine o cronograma listado na seção Trabalho de backup. Se precisar personalizar o cronograma, clique em Cronograma.

      Registre os agendamentos de execução dos trabalhos de envio de log, para que você possa agendar rastreamentos de pesquisa e outros trabalhos em lotes para que não coincidam com eles.

   4. Opcional. Examine a configuração na seção Compactação se desejar usar a compactação de backup.

   5. Clique em OK.

5. Na caixa de diálogo Propriedades do Banco de Dados, na seção Bancos de dados secundários, clique em Adicionar.

   A caixa de diálogo Configurações do Banco de Dados Secundário é exibida.

   • Clique em Conectar e conecte-se à instância do SQL Server que você deseja usar como servidor secundário. Por padrão, o nome do banco de dados secundário é o mesmo nome do banco de dados do servidor primário.

   • Na guia Inicializar Banco de Dados Secundário, selecione Sim, gerar um backup completo do banco de dados primário e restaurá-lo no banco de dados secundário (e criar o banco de dados secundário se ele não existir).

   • Na guia Copiar Arquivos, na caixa Pasta de destino dos arquivos copiados, digite o caminho da pasta no servidor secundário para a qual você deseja que os backups dos logs de transações sejam copiados.

   • Na guia Restaurar Log de Transações, na seção Estado do banco de dados ao restaurar backups, selecione Modo de espera e desmarque Desconectar usuários no banco de dados ao restaurar backups.

   • Clique em OK.

   • É recomendável salvar as configurações em um script. Na caixa de diálogo Propriedades do Banco de Dados, clique em Configuração do Script e em Configuração de script em arquivo.

     Uma caixa de diálogo Salvar como é exibida. Digite a pasta em que você deseja salvar o arquivo e clique em OK.

   • Clique em OK.

     Todos os trabalhos serão executados uma vez para inicializar o envio de log e indicarão se tiveram êxito ou se falharam.

6. Repita o procedimento anterior para todos os bancos de dados para os quais planeja usar o envio de log. Para obter mais informações, consulte o artigo sobre habilitação do envio de log (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151644\&clcid=0x416) (em inglês).

Opcional. Substituir a tarefa de cópia do envio de log pela Replicação DFS

1. Habilitar e configurar a Replicação DFS (DFSR) para o ambiente. Para obter mais informações, consulte o artigo sobre replicação (https://go.microsoft.com/fwlink/?linkid=151670\&clcid=0x416). Para obter um exemplo da configuração da Replicação DFS, consulte o artigo sobre o guia passo a passo do DFS para o Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=150765\&clcid=0x416).

2. Como o DFSR será usado para o transporte, você deve desabilitar o trabalho de cópia de envio de log para cada banco de dados que participa da configuração de envio de log. Para obter mais informações, consulte o artigo sobre habilitação ou desabilitação de um trabalho (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=151673\&clcid=0x416)

Validar se o envio de log foi bem-sucedido

1. Inicie o Management Studio no servidor de banco de dados no farm secundário.

2. No painel de navegação do Pesquisador de Objetos, verifique se todos os bancos de dados de conteúdo com log enviado têm status Em Espera ou Somente Leitura.

3. Determinar quanto tempo, em média, os trabalhos de envio de log levam para ser executados no farm secundário, executando os trabalhos e cronometrando sua duração. Para obter mais informações, consulte o artigo sobre monitoramento do envio de log (em inglês) (https://go.microsoft.com/fwlink/?linkid=151682\&clcid=0x416) (em inglês).

Anexar os bancos de dados com log enviado ao farm secundário do SharePoint.

1. No site da Administração Central do SharePoint, no Início Rápido, na seção Administração Central, clique em Gerenciamento de Aplicativos. A página Gerenciamento de Aplicativos será aberta.

   Na seção Gerenciamento de Aplicativos Web do SharePoint, clique em Bancos de dados de conteúdo.

   A página Gerenciar Bancos de Dados de Conteúdo será aberta.

2. Na coluna Nome do Banco de Dados, clique no banco de dados de conteúdo a ser removido. A página Gerenciar Definições de Banco de Dados de Conteúdo será aberta.

3. Na seção Remover Banco de Dados de Conteúdo, marque a caixa de seleção Remover banco de dados de conteúdo e clique em OK.

4. Na página Gerenciar Bancos de Dados de Conteúdo, clique em Adicionar um banco de dados de conteúdo. A página Adicionar Banco de Dados de Conteúdo será aberta.

5. Digite o servidor de banco de dados e o nome de banco de dados adequados do banco de dados de conteúdo com log enviado e clique em OK.

6. Repita o procedimento para todos os bancos de dados para os quais você está usando o envio de log.

   Nesse ponto, você pode procurar conteúdo no farm secundário.

Configurar pesquisa e perfis para o farm secundário

Configure a pesquisa no farm secundário para atender aos objetivos comerciais para o cenário de recuperação de desastre. Inicialmente, convém pesquisar os mesmos bancos de dados, com as mesmas configurações e regras de rastreamento que o farm primário. Caso você verifique que não é possível agendar os rastreamentos e o envio de log de modo que eles não se sobreponham, é recomendável ajustar o conteúdo incluído nos rastreamentos. Por exemplo, antes do failover, você pode rastrear apenas os bancos de dados com conteúdo de alto impacto comercial e rastrear o conteúdo restante apenas depois do failover. Para obter mais informações, consulte Limitar ou aumentar a quantidade de conteúdo rastreada (Office SharePoint Server).

1. Interromper o trabalho do SQL Server Agente no farm secundário para desabilitar o envio de log enquanto você configura a pesquisa.

2. Configurar a pesquisa no farm secundário.

   Determine quanto tempo o rastreamento de pesquisa leva no farm secundário. Você pode usar dados coletados do farm primário para estimar o tempo necessário no farm secundário.

   Importante

   Agende os rastreamentos de pesquisa nos horários em que os trabalhos de envio de log não estão em execução. Para obter mais informações, consulte Coordenar os intervalos dos trabalhos de envio de log, do rastreamento de pesquisa e do script de atualização.

3. Iniciar o trabalho do SQL Server Agent no farm secundário para habilitar o envio de log.

4. Se você estiver usando perfis, os perfis nos SSPs de failover não serão sincronizados com os perfis nos SSPs primários — eles estarão no estado em que se encontravam ao serem importados pela primeira vez. Para manter os perfis de todos os SSPs sincronizados, use o Mecanismo de Replicação de Perfis de Usuário fornecido com a versão de 32 bits do Microsoft SharePoint Administration Toolkit x86 (em inglês) (https://go.microsoft.com/fwlink/?linkid=151962\&clcid=0x416) (em inglês) ou com a versão de 64 bits do Microsoft SharePoint Administration Toolkit x64 (em inglês) (https://go.microsoft.com/fwlink/?linkid=142035\&clcid=0x416) (em inglês). Para obter mais informações, consulte User Profile Replication Engine (Office SharePoint Server).

Criar um script para atualizar a lista de sites no banco de dados de configuração do farm secundário (script de atualização)

Use o exemplo a seguir como modelo para criar um script de atualização que você pode executar no farm secundário quando conjuntos de sites forem adicionados ou excluídos do farm primário.

No script de exemplo, substitua <nome_do_bd1>, <URL>, e <nome_do_bd2>, <URL> pelos nomes dos bancos de dados com log enviado.

Adicione seções de desanexação e anexação ao script para cada um dos bancos de dados com log enviado.

echo off

SET PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

echo %time Shutting down the Osearch service…
SC config Osearch start= disabled
SC stop Osearch

echo %time Shutting down the SQL Server Agent service…
SC \\<SQL Server> config SQLSERVERAGENT start= disabled
SC \\<SQL Server>  stop SQLSERVERAGENT
f
echo %time About to refresh Site Map…

echo %time About to detach db <db_name1>
stsadm.exe -o deletecontentdb -url <URL> -databasename <db_name1>  -databaseserver <SQL_Server>
echo %time About to attach db <db_name1>
stsadm.exe -o addcontentdb -url <URL> -databasename <db_name1> -databaseserver <SQL_Server>

echo %time  About to detach db <db_name2>
stsadm.exe -o deletecontentdb -url <URL> -databasename <db_name2>  -databaseserver <SQL_Server>
echo %time  About to attach db <db_name2>
stsadm.exe -o addcontentdb -url <URL> -databasename <db_name2> -databaseserver <SQL_Server>

rem --:: repeat for all databases ::--

echo %time Restarting the Osearch service…
SC config Osearch start= demand
SC start Osearch

echo %time Restarting the SQL Server Agent service…
SC \\<SQL Server> config SQLSERVERAGENT start= demand
SC \\<SQL Server>  start SQLSERVERAGENT

echo on

Coordenar os intervalos dos trabalhos de envio de log, do rastreamento de pesquisa e do script de atualização

1. Determinar quanto tempo, em média, os trabalhos de envio de log levam para serem executados no farm secundário e para quando você deseja agendar a execução dos trabalhos.

2. Determinar quanto tempo os rastreamentos incrementais levam no farm secundário e para quando você deseja agendar os rastreamentos. Talvez você possa usar dados de rastreamento do farm primário para determinar quanto tempo os rastreamentos incrementais levam para serem concluídos. Para obter mais informações sobre o agendamento de um rastreamento incremental, consulte Agendar um rastreamento incremental (Office SharePoint Server 2007).

3. Se possível, agende os trabalhos de envio de log e rastreamento de pesquisa para que eles não se sobreponham.

4. Se não for possível agendar o envio de log e os rastreamentos de pesquisa incrementais de modo que não se sobreponham, escolha uma das seguintes opções:

   • Execute manualmente os trabalhos de envio de log e rastreamento de pesquisa, suspendendo um conjunto de trabalhos enquanto executado o outro.

   • Deixe que o rastreamento de pesquisa prevaleça sobre o processamento de logs e crie um script para iniciar automaticamente o envio de log quando o processo rastreador não estiver em execução.

   • Se o único processo ativo no banco de dados for o processo rastreador, configure o envio de log para aguardar até que o banco de dados não esteja em uso e processar então os logs enviados.

   Se nenhuma dessas opções funcionar e se não for possível agendar a quantidade de dados que você está enviando em log e os horários de rastreamento, para que não se sobreponham, considere ações a serem eliminadas para fazer com que o sistema funcione. Por exemplo, se não for possível concluir o envio de log e a pesquisa nos horários disponíveis, rastreie apenas bancos de dados de conteúdo de alto impacto comercial antes do failover e inicie o rastreamento do conteúdo restante depois do failover.

5. Agende a execução do script de atualização. Se novos conjuntos de sites não tiverem sido adicionados ao farm primário, você não precisará executar o script de atualização. Quando novos conjuntos de sites são adicionados, o script de atualização deve ser executado periodicamente usando o Agendador de Tarefas do Windows. Quando o script de atualização é executado, suspende os processos de envio de log e rastreador. Para obter mais informações sobre o agendamento de tarefas, consulte o artigo sobre agendamento de tarefas (https://go.microsoft.com/fwlink/?linkid=151894\&clcid=0x416).

   Se o script de atualização for cancelado enquanto está sendo executado, é recomendável executá-lo manualmente para verificar se todos os bancos de dados foram reanexados e se todos os serviços foram ativados novamente.

Opcional. Manter o SSO no farm secundário

• Faça backup da chave de criptografia após configurar inicialmente o SSO e faça novo backup da chave sempre que a gerar novamente. Para obter mais informações, consulte Fazer backup de SSO (Office SharePoint Server 2007)

  Lembre-se das seguintes restrições ao fazer backup da chave de criptografia:

  • Você deve ser membro da conta de administrador do SSO para fazer backup da chave de criptografia.

  • Não é possível fazer backup da chave de criptografia remotamente. Você deve estar conectado ao servidor de chave de criptografia localmente para fazer backup da chave de criptografia.

  • Você deve transferir fisicamente o dispositivo de armazenamento removível que contém a chave de criptografia do SSO para o farm secundário e restaurá-la.

Opcional. Fornecer aos usuários acesso ao farm somente leitura

1. Se possível, forneça aos usuários um arquivo de hosts atualizado que aponte para os aplicativos Web do farm secundário que você deseja expor.

2. Se você não puder distribuir um arquivo de hosts, defina um mapeamento alternativo de acesso dedicado para cada aplicativo Web que deseja expor, como http//somenteleitura.contoso.com ou http://secundário.contoso.com, e configure o mapa no DNS.

   Dica

   Se não houver mais espaço para definir o mapeamento alternativo de acessos para um aplicativo Web, específico essa opção de mapeamento dedicado não será possível.

Executando o failover

O failover pode ser executado manualmente ou pode ser controlado por script. Este artigo descreve apenas o failover manual.

O diagrama a seguir mostra um ambiente com vários farms no qual ocorreu failover. O envio de log foi interrompido e os administradores de farm executaram as seguintes ações:

• Definiram o DNS para parar de aceitar tráfego para o farm primário.

• Aplicaram os logs de transações não aplicados aos bancos de dados no servidor secundário.

• Alternaram os bancos de dados de conteúdo no farm secundário para leitura/gravação.

• Definiram o DNS para aceitar tráfego no farm secundário.

Dica

Esta seção descreve como executar um failover completo (que não é de teste). Para obter informações sobre como testar o failover, consulte o artigo sobre considerações ao testar o failover.

A fase de failover é composta pelos procedimentos a seguir.

• Desabilitar todos os trabalhos de envio de log no farm primário

• Parar de aceitar tráfego para o farm primário

• Fazer backup dos logs de transações no servidor primário

• Restaurar os logs de transações mais recentes para o servidor secundário

• Definir bancos de dados de conteúdo para leitura/gravação

• Opcional. Restaurar a chave de criptografia do SSO

• Direcionar o tráfego para o farm secundário

• Concluir a configuração do ambiente secundário

Desabilitar todos os trabalhos de envio de log no farm primário

1. Se o farm primário ainda estiver disponível, e o envio de log ainda não tiver sido parado, desabilite todos os trabalhos de envio de log nos servidores de banco de dados no farm primário.

2. Se não for possível acessar os bancos de dados no servidores, execute a instrução Transact-SQL a seguir para cada banco de dados e vá para a etapa: Definir bancos de dados de conteúdo como leitura/gravação.

   RESTORE DATABASE content_db WITH RECOVERY
   

Parar de aceitar tráfego para o farm primário

• Siga os procedimentos recomendados para que o DNS pare de aceitar tráfego para o farm primário. Não encaminhe ainda o tráfego para o farm secundário.

  Este artigo não descreve como usar ou configurar o DNS. Para obter mais informações sobre o DNS, consulte o artigo sobre referência técnica do DNS (em inglês)(https://go.microsoft.com/fwlink/?linkid=151820\&clcid=0x416) (em inglês).

  Dica

  Os usuários encontrarão erros enquanto o farm primário não estiver disponível.

Fazer backup dos logs de transação no servidor primário

1. Determinar se o farm primário ainda está disponível e se a pasta de rede compartilhada em que os backups são armazenados pode ser acessada por ambos os farms de servidores. Se nenhuma das condições for aplicável, vá para o procedimento Definir bancos de dados de conteúdo como leitura/gravação.

2. No Management Studio, no painel de navegação do Pesquisador de Objetos, clique com o botão direito do mouse em um banco de dados de conteúdo, aponte para Tarefas e clique em Backup. A caixa de diálogo Fazer Backup do Banco de Dados será exibida.

3. Clique na lista suspensa Tipo de backup e selecione Log de transações.

4. No painel Selecione uma página, clique em Opções.

5. Na seção Log de transações, selecione Fazer backup da parte final do log e deixar o banco de dados no estado de restauração e, finalmente, clique em OK.

6. Repita o procedimento para todos os bancos de dados com log enviado.

Restaurar os logs de transações mais recentes no servidor secundário

1. Esse procedimento será útil somente se o farm primário ainda estiver disponível e se o compartilhamento de rede em que os backups são armazenados puder ser acessado por ambos os farms de servidores. Se nenhuma das condições for atendida, vá para o procedimento Definir bancos de dados de conteúdo como leitura/gravação.

   No Management Studio no servidor secundário, clique com o botão direito do mouse no banco de dados de conteúdo, aponte para Tarefas, clique em Restaurar e em Log de Transações. A caixa de diálogo Restaurar Log de Transações será exibida.

2. Na guia Geral, selecione De Arquivo e Fita e digite o caminho para o arquivo de backup que você criou no servidor primário.

3. Na seção Estado de recuperação, selecione Deixar o banco de dados pronto para uso revertendo transações não confirmadas. Os logs de transações adicionais não podem ser restaurados. (RESTAURAR COM RECUPERAÇÃO) e clique em OK.

4. Repita o procedimento para todos os bancos de dados com log enviado.

Definir bancos de dados de conteúdo como leitura/gravação

Após alternar os bancos de dados no farm secundário para leitura/gravação, você precisará restabelecer o envio de log por meio de um novo arquivo de backup no servidor secundário, que será então copiado para o servidor primário.

1. No Management Studio, clique com o botão direito do mouse no banco de dados de conteúdo que deseja alternar para leitura/gravação e clique em Propriedades. A caixa de diálogo Propriedades do Banco de Dados será exibida.

2. No painel Selecionar uma página, clique em Opções e, na lista Outras opções, vá até a seção Estado.

3. Na entrada Banco de Dados Somente Leitura, clique na seta ao lado de Verdadeiro, selecione Falso e clique em OK.

4. Repita o procedimento para todos os bancos de dados de conteúdo.

Opcional. Restaurar a chave de criptografia do SSO

1. No farm secundário, reinicie o serviço SSO.

2. Configure o SSO no servidor secundário.

3. No farm secundário, reinicie o SSO.

4. Restaure a chave por meio da unidade removível.

5. Crie uma definição de aplicativo para verificar se novas definições de aplicativos podem ser criadas.

6. Verifique se você pode obter as credenciais para vários aplicativos usando o método GetCredentials. Para obter mais informações, consulte o artigo sobre o método ISsoProvider.GetCredentials (Microsoft.SharePoint.Portal.SingleSignon(https://go.microsoft.com/fwlink/?linkid=151824\&clcid=0x416).

Direcionar o tráfego para o farm secundário

1. Verifique se as configurações do mapeamento alternativo de acesso no farm secundário correspondem às configurações do farm primário.

2. Siga os procedimentos recomendados para que o DNS direcione o tráfego para o farm secundário.

   Dica

   Depois que você desviar o tráfego no DNS para o farm secundário, talvez os usuários precisem fechar e abrir novamente seus navegadores para que a operação de redirecionamento entre em vigor.

Concluir a configuração do ambiente secundário

1. Estabeleça processos de manutenção comuns.

   • Configure a monitoração.

   • Implemente processos de backup no nível de produção.

2. Comece a restaurar o ambiente primário anterior.

Considerações sobre o teste do failover

Ao testar o failover, tenha certeza quanto ao nível de testes de failover que os contratos de nível de serviço exigem que você execute. A seguir estão relacionados alguns exemplos comuns de testes de failover.

Verification that the secondary site is live, and is being crawled   Para esse tipo de teste de failover, você pode fornecer aos usuários um arquivo de hosts ou um caminho de mapeamento alternativo de acesso para o farm secundário, para que eles possam verificar se o farm está ativo e atualizado. Não são necessárias etapas adicionais.

Farm failover   Nesse tipo de teste, o farm primário é desativado por um breve intervalo anunciado, mas o farm secundário não é alternado para o status de leitura/gravação. Para esse tipo de teste, siga os procedimentos da seção Executando o failover, com as seguintes diferenças:

Etapas para teste de failover	Descrição
Executar	1. Para iniciar o teste de failover, no farm secundário, pare o Trabalho do SQL Server Agent de forma que nenhum log esteja em processamento.
Não executar	2. Desabilite todos os trabalhos de envio de log no farm primário.
Executar	3. Parar de aceitar tráfego para o farm primário
Executar	4. Faça backup dos logs de transação no servidor primário.
Executar	5. Restaure os logs de transações mais recentes no servidor secundário.
Não executar	6. Defina bancos de dados de conteúdo como leitura-gravação.
Não executar	7. Opcional. Restaure a chave de criptografia SSO.
Executar	8. Direcione o tráfego para o farm secundário.
Não executar	9. Conclua a configuração do ambiente secundário.

Planned data center failover with additional precautions   Nesse tipo de teste, o data center primário é desativado por um intervalo anunciado. O farm secundário é alternado para o status leitura/gravação. Para esse tipo de teste, siga os procedimentos da seção Executando o failover, com as seguintes diferenças:

Etapas para teste de failover	Descrição
Executar	1. Para iniciar o teste de failover, no farm secundário, pare o Trabalho do SQL Server Agent de forma que nenhum log esteja em processamento.
Executar	2. Desabilite todos os trabalhos de envio de log no farm primário.
Executar	3. Parar de aceitar tráfego para o farm primário
Executar	4. Faça backup dos logs de transação no servidor primário.
Executar	5. Restaure os logs de transações mais recentes no servidor secundário.
Executar	6. Defina bancos de dados de conteúdo como leitura-gravação.
Executar	7. Opcional. Restaure a chave de criptografia SSO.
Executar	8. Direcione o tráfego para o farm secundário.
Não executar	9. Conclua a configuração do ambiente secundário.
Nova etapa	10. Mantenha todos os backups com log enviado no farm secundário para que você possa usar o backup do banco de dados do farm secundário para reiniciar o envio de log

Planned data center failover without additional precautions   Nesse tipo de teste, o data center primário é desativado por um intervalo anunciado para que seja determinado quanto tempo uma recuperação verdadeira levará. É possível ocorrer perda parcial de dados. O farm secundário é alternado para o status de leitura/gravação. Para esse tipo de teste, siga os procedimentos da seção Executando o failover.

Etapas para teste de failover	Descrição
Executar	1. Antes de começar, faça backup dos bancos de dados com log enviado no farm primário, para que você tenha um backup atualizado a ser usado para reiniciar o envio de log.
Executar	2. Desabilite todos os trabalhos de envio de log no farm primário.
Executar	3. Parar de aceitar tráfego para o farm primário
Executar	4. Faça backup dos logs de transação no servidor primário.
Executar	5. Restaure os logs de transações mais recentes no servidor secundário.
Executar	6. Defina bancos de dados de conteúdo como leitura-gravação.
Executar	7. Opcional. Restaure a chave de criptografia SSO.
Executar	8. Direcione o tráfego para o farm secundário.
Não executar	9. Conclua a configuração do ambiente secundário.

Reconfigurando o envio de log

Quando o farm secundário estiver funcional, o banco de dados primário original estiver acessível e o problema nesse farm tiver sido investigado e resolvido, você poderá transformar o banco de dados primário anterior no novo banco de dados secundário ou executar deliberadamente o failover do farm secundário para o farm primário anterior e, em seguida, reconfigurar o envio de log da maneira como o tinha estruturado inicialmente.

1. Configure o envio de log entre o farm secundário e o farm primário. Estabeleça uma relação de envio de log entre a instância do SQL Server no farm secundário e a instância correspondente no farm primário. Para obter detalhes, consulte a seção Configurando o ambiente de envio de log.

2. No farm primário, aplique os backups de logs de transações não aplicados a cada banco de dados.

3. Use o DNS para parar de aceitar tráfego no farm secundário.

4. Execute o failover do farm secundário para o farm primário original. Para obter detalhes, consulte a seção Executando o failover e reconfigure o envio de log.

5. Opcional. Restaure o SSO usando a cópia local da chave de criptografia na mídia.

6. Ative o farm primário novamente, verifique se tudo está funcionando conforme o esperado e altere o DNS para direcionar o tráfego de entrada para o farm primário.

7. Reconfigure o envio de log do farm primário para o farm secundário.

Resumo

O uso do envio de log para fornecer um farm de recuperação de desastre em um data center secundário é um processo complexo. Estabeleça contratos de nível de serviço claros com os usuários e teste o ambiente regularmente.

Agradecimentos

A equipe de Publicação de Conteúdo do Microsoft Office SharePoint Server agradece aos seguintes colaboradores e revisores técnicos:

• Doron Bar-Caspi, Gerente de Programa Sênior, equipe de consultoria de clientes do SharePoint

• Lindsay Allen, Gerente de Programa Líder Principal, SQL Server Customer Programs

• Sanjay Mishra, Gerente de Programa Sênior, SQL Server Customer Programs

• Burzin Patel, Gerente de Programa Sênior, SQL Server Customer Programs

• Bill Baer, Arquiteto de Tecnologias, Microsoft SharePoint Online

• Cory Burns, Engenheiro de Operações, Microsoft SharePoint Online

• Steve Peschka, Arquiteto Sênior

• JP Poissant, Consultor Sênior II, Microsoft Consulting Services, Canadá