Gerenciando a Replicação Contínua em Espera
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Tópico modificado em: 2008-11-19
Além das tarefas de gerenciamento e administração diárias de uma organização do Microsoft Exchange, há tarefas específicas de uma replicação contínua em espera (SCR). Geralmente, as tarefas administrativas de SCR são:
Configurar o armazenamento em disco para SCR e gerenciar volumes de disco.
Habilitar e desabilitar SCR.
Monitorar a atividade de replicação.
Montar, desmontar, criar e remover bancos de dados.
Mover o local de armazenamento do grupo de armazenamento ou dos arquivos de banco de dados quando um grupo de armazenamento estiver habilitado para SCR.
Verificando o funcionamento do destino de SCR.
Gerenciar a atividade de replicação e repetição.
Recuperar de danos.
Essas tarefas são discutidas no lembrete deste tópico.
A SCR é habilitada e gerenciada somente para uso no Shell de Gerenciamento do Exchange. O Console de Gerenciamento do Exchange não pode ser usado para habilitar ou desabilitar a SCR, visualizar o status da SCR ou gerenciar quaisquer aspectos da SCR.
Configurando o armazenamento em disco para replicação contínua em espera
A SCR não exige configuração especial de armazenamento em disco. A SCR exige armazenamento que oferece capacidade adequada. Soluções de armazenamento equivalentes devem ser configuradas para todos os destinos da SCR configurados para o mesmo grupo de armazenamento. Recomenda-se seguir os procedimentos de configuração indicados pelo fornecedor de armazenamento, para concluir a configuração.
Gerenciamento de volumes de discos em um ambiente de SCR
Durante o gerenciamento de um ambiente de SCR, pode ser necessário gerenciar volumes de discos que estejam conectados ao servidor Exchange. Por exemplo, talvez seja necessário desconectar temporariamente o sistema para manutenção ou por outros motivos. Se a manutenção precisar ser executada no volume de disco que contém a cópia ativa do grupo de armazenamento, o banco de dados na cópia ativa do grupo de armazenamento deverá ser desmontado. Se a manutenção tiver de ser executada nos volumes de discos que contenham a cópia passiva do grupo de armazenamento, toda a E/S (entrada/saída) para o volume deverá ser parada, interrompendo a replicação. Para obter mais informações sobre como gerenciar volumes de discos, consulte Como preparar atividades de gerenciamento de disco ao usar a SCR.
Habilitando a replicação contínua em espera
A SCR é habilitada para uso no Shell de Gerenciamento do Exchange executando o cmdlet New-StorageGroup ou o cmdlet Enable-StorageGroupCopy. Esses dois cmdlets incluem alguns parâmetros novos que são introduzidos com o Microsoft Exchange Server 2007 Service Pack 1 (SP1):
-StandbyMachine Esse parâmetro é usado para especificar o nome do computador que conterá o destino da SCR. O valor desse parâmetro é definido como parte do valor do atributo msExchStandbyCopyMachines do grupo de armazenamento que está sendo habilitado para SCR. O atributo msExchStandbyCopyMachines é uma cadeia de caracteres com vários valores Unicode que é adicionado ao esquema de serviço de diretório do Active Directory quando o Exchange 2007 SP1 é introduzido na organização do Exchange.
-ReplayLagTime Esse parâmetro é usado para especificar o tempo que o serviço de replicação do Microsoft Exchange aguarda antes de repetir os arquivos de log que foram copiados para o computador de destino de SCR. O formato desse parâmetro é (Dias.Horas:Minutos:Segundos). A definição padrão para esse valor é de 24 horas. A definição máxima permitida para esse valor é de 7 dias. A definição mínima permitida é de 0 segundos, embora a definição desse valor como 0 segundos não afete o atraso padrão na atividade de repetição do log de 50 arquivos de log. Depois de definido, o valor desse parâmetro não pode ser alterado sem que a SCR seja desabilitada e reabilitada.
-TruncationLagTime Esse parâmetro é usado para especificar o tempo que o serviço de replicação do Microsoft Exchange deve aguardar antes de truncar os arquivos de log que foram copiados no computador de destino SCR e repetidos na cópia do banco de dados. O período de tempo começa depois que o log foi repetido com êxito na cópia do banco de dados. O formato desse parâmetro é (Dias.Horas:Minutos:Segundos). A definição máxima permitida para esse valor é de 7 dias. A definição mínima permitida é de 0 segundos, embora a definição desse valor como 0 segundos elimine efetivamente qualquer atraso na atividade de truncamento do log. Depois de definido, o valor desse parâmetro não pode ser alterado sem que a SCR seja desabilitada e reabilitada.
-SeedingPostponed Esse parâmetro pode ser usado para ignorar a propagação inicial do destino de SCR. Se esse parâmetro for usado, o administrador deverá propagar manualmente o destino de SCR usando o cmdlet Update-StorageGroupCopy. Esse parâmetro está disponível somente com o cmdlet Enable-StorageGroupCopy. Ele não está disponível com o cmdlet New-StorageGroup, pois não existe um banco de dados de origem nesse ponto.
Importante
Para alterar as configurações de atraso de truncamento ou repetição, você deve primeiro desabilitar a SCR e, em seguida habilitá-la usando os novos valores dessas configurações.
Além do atraso de repetição configurado pelo administrador que é especificado com o parâmetro ReplayLagTime, o Exchange impede também que um número fixo de arquivos de log sejam repetidos em um destino de SCR, independentemente do valor de ReplayLagTime, usando a seguinte fórmula:
Máximo de ("valor de ReplayLagTime" ou "X arquivos de log")
em que X=50. Essa é uma proteção contra a necessidade de repropagar um grupo de armazenamento em situações em que uma origem de SCR que esteja em um ambiente de replicação contínua, por exemplo, LCR (replicação contínua local) ou CCR (replicação contínua em cluster), experimenta um failover com perdas e é colocado online usando o cmdlet Restore-StorageGroupCopy. Com o atraso da atividade de repetição nos destinos de SCR, quando ocorre um failover com perdas para uma origem de SCR, as chances de precisar repropagar as cópias de SCR são minimizadas, pois a natureza da perda de dados na origem de SCR coloca as duas cópias próximas no tempo.
Importante
A construção de 50 arquivos de log no intervalo e o valor do parâmetro ReplayLagTime tem implicações para a criação do banco de destino inicial de SCR. Um banco de dados de destino de SCR não será criado até que 50 arquivos de log de transações tenham sido replicados no computador de destino de SCR e até que o período de tempo especificado por ReplayLagTime (ou o ReplayLagTime padrão de 24 horas) tenha decorrido.
Quando você habilitar a SCR para um grupo de armazenamento, uma cópia do grupo de armazenamento (arquivos do sistema, arquivos de log e o arquivo do banco de dados) será automaticamente criada e mantida no computador de destino de SCR, usando os mesmos caminhos do grupo de armazenamento na origem de SCR.
Depois que a SCR tiver sido habilitada, recomendamos monitorar a integridade e o status de cada grupo de armazenamento usando o cmdlet Test-ReplicationHealth. Para obter etapas detalhadas sobre como habilitar uma SCR, consulte Como habilitar a Replicação Contínua Em Espera para um grupo de armazenamento existente e Como habilitar a replicação contínua em espera para um novo grupo de armazenamento.
SCR e truncamento de log
Como não é possível fazer backups de um banco de dados de destino de SCR, o truncamento de log de SCR não se baseia nos tempos de backup. Em vez disso, o truncamento de log é determinado pelo ponto de verificação na origem de SCR e no valor do TruncationLagTime.
Se a origem de SCR for um CMS (servidor de caixas de correio clusterizadas) em um ambiente de CCR, a lógica de truncamento de log incluirá a cópia e a inspeção bem-sucedidas dos arquivos de log por todos os destinos de SCR. Isso significa que se um destino de SCR não estiver disponível, o truncamento de log não ocorrerá na origem de SCR mesmo se forem feitos backups.
Em um ambiente de SCR, um destino de SCR que é desabilitado e então reabilitado poderá não precisar ser repropagado se todos os arquivos de log necessários estiverem disponíveis, com base no seguinte:
Se o Iog circular estiver habilitado para o grupo de armazenamento, então a exclusão do log resultará no destino de SCR reabilitado, exigindo uma repropagação devido a intervalos na seqüência de logs.
Se um backup for feito incluindo o truncamento do arquivo de log, então a exclusão do log resultará no destino de SCR reabilitado, exigindo uma repropagação devido a intervalos na seqüência de logs.
Se os arquivos de log não estiverem truncados por um dos meios descritos anteriormente, a desabilitação e a habilitação de SCR não deverá exigir uma repropagação. Nesse caso, os arquivos de log no destino de SCR precisarão ser excluídos, mas serão novamente replicados com base na origem de SCR.
Se você planeja reabilitar um destino de SCR que foi anteriormente desabilitado, como melhor prática, recomendamos não executar nenhuma operação de truncamento de log (por exemplo, habilitando o log circular ou executando backups de truncamento de log) até que o destino de SCR seja reabilidado e a alteração na configuração que exigiu a habilitação esteja replicada em todo o Active Directory.
Desabilitando a replicação contínua em espera
A SCR é desabilitada somente usando o cmdlet Disable-StorageGroupCopy e o parâmetro StandbyMachine. Ao desabilitar a SCR, é importante que você inclua o valor apropriado para o parâmetro StandbyMachine. Se o grupo de armazenamento de SCR também tiver a LCR habilitada e você não incluir o parâmetro StandbyMachine como parte desse comando, a LCR será desabilitada para o grupo de armazenamento.
Desabilitar a SCR é necessário para alterar o valor dos parâmetros ReplayLagTime ou TruncationLogDelay. Esses valores não podem ser modificados enquanto a SCR estiver habilitada. Portanto, para alterar as configurações de atraso de truncamento ou de repetição, você deve primeiro desabilitar a SCR e depois habilitá-la novamente usando os novos valores dessas configurações.
Para obter etapas detalhadas sobre como desabilitar a SCR para um grupo de armazenamento, consulte Como desabilitar a replicação contínua em espera para um grupo de armazenamento.
Monitorando a atividade de replicação
Embora a SCR não exija nenhum monitoramento especial, recomendamos o monitoramento regular de cada grupo de armazenamento para verificar se ele está replicando corretamente os arquivos de log. O Pacote de Gerenciamento do Exchange Server 2007 para o Microsoft Operations Manager 2005 inclui alertas para vários problemas críticos relacionados a ambientes de SCR:
O serviço de Replicação do Microsoft Exchange não está sendo executado. Observe que o evento que gera esse alerta não é exibido repetidamente depois que o serviço é parado, portanto qualquer alerta associado a ele seria perdido, caso ele fosse apagado.
A cópia de destino de SCR está em um estado de Falha.
A cópia de destino de SCR está em um estado Adequado, mas está atrasada na cópia de log.
Você deve investigar e resolver todos os alertas anteriores gerados pelo Pacote de Gerenciamento do Exchange 2007 o mais rápido possível.
Cmdlet Test-ReplicationHealth
O Exchange 2007 SP1 apresenta um novo cmdlet chamado Test-ReplicationHealth. Esse cmdlet é projetado para monitoramento proativo de replicação contínua (LCR, CCR e SCR) e da pipeline de replicação contínua. O cmdlet Test-ReplicationHealth verifica todos os aspectos da replicação, os serviços de cluster, a replicação do grupo de armazenamento e o status de repetição para fornecer uma visão geral completa do sistema de replicação. Especificamente, o cmdlet Test-ReplicationHealth executa os testes descritos na tabela a seguir.
Testes executados pelo cmdlet Test-ReplicationHealth
| Teste | Descrição |
|---|---|
Status de rede de cluster |
Verifica se as redes gerenciadas por cluster encontradas no nó local estão em execução. Esse teste se aplica somente a ambientes de CCR. |
Estado do grupo de quorum |
Verifica se o grupo de clusters que contém o recurso de quorum é adequado. Esse teste se aplica somente a ambientes de CCR. |
Estado do quorum de compartilhamento de arquivos |
Verifica se o valor do FileSharePath usado pelo quórum de Conjunto de Nós Principais com testemunha de compartilhamento de arquivo está acessível. Esse teste se aplica somente a ambientes de CCR. |
Estado do grupo de servidores de caixas de correio clusterizadas |
Verifica a integridade do CMS, confirmando se todos os recursos no grupo estão online. Esse teste se aplica somente a ambientes de CCR. |
Estado do nó |
Verifica se algum dos nós do cluster está em um estado pausado. Esse teste se aplica somente a ambientes de CCR. |
Status de registro de DNS |
Verifica se todas as interfaces de rede gerenciadas por cluster, configuradas com Exigir registro de DNS para obter êxito passaram pelo registro de DNS. Esse teste se aplica somente a ambientes de CCR. |
Status de serviço de replicação |
Verifique se o serviço de Replicação do Microsoft Exchange do nó local é adequado. |
Cópia do grupo de armazenamento suspensa |
Verifica se a replicação contínua foi suspensa em todos os grupos de armazenamento. |
Falha na cópia do grupo de armazenamento |
Verifica se todas as cópias do grupo de armazenamento estão em um estado de Falha. |
Comprimento da fila de replicação do grupo de armazenamento |
Verifica se algum grupo de armazenamento tem um comprimento da fila de cópias de replicação maior que os limites da prática recomendada. Atualmente, esses limites são:
|
Bancos de dados desmontados após o failover |
Verifica se algum banco de dados está desmontado ou com falha após um failover. Esse teste verifica somente os bancos de dados cujo resultado de um failover seja com falha. |
Montar e desmontar bancos de dados
Ocasionalmente, pode ser necessário montar ou desmontar bancos de dados em um ambiente de SCR. Se o grupo de armazenamento de origem de SCR ou o banco de dados precisar de reconfiguração ou manutenção, será necessário bloquear os serviços que interagem com ambos enquanto a atividade estiver em andamento. Isso pode ser necessário para executar uma reconfiguração ou corrigir problemas com o servidor ou o banco de dados. Quando o banco de dados estiver desmontado, ele está inacessível.
Movendo o local do grupo de armazenamento e dos arquivos de banco de dados
Você pode alterar o local de um banco de dados em um grupo de armazenamento habilitado para SCR. Em um ambiente de SCR, há dois arquivos de bancos de dados, um para cada cópia. Ao movimentar os arquivos do grupo de armazenamento ou o arquivo de banco de dados, os locais das duas cópias deverá ser alterado em tandem.
Dica
O caminho completo para os arquivos do grupo de armazenamento e o arquivo do banco de dados devem corresponder na orgiem de SCR e em todos os destinos de SCR.
Procedimentos semelhantes são usados para reconfigurar o local de um log de grupos de armazenamento e arquivos de sistema e o local dos arquivos de banco de dados em um ambiente de SCR. Para obter etapas detalhadas de como alterar o local de arquivos de log e arquivos de sistema de um grupo de armazenamento habilitado para SCR, consulte Como mover um grupo de armazenamento em um ambiente de Replicação Contínua em Espera. Para obter etapas detalhadas de como alterar o local dos arquivos de banco de dados em um ambiente de SCR, consulte Como mover um banco de dados em um ambiente de replicação contínua em espera.
Importante
Os bancos de dados não podem ser colocados na raiz de um volume.
Exibindo informações de status
Todo o monitoramento e o status é executado usando o Shell de Gerenciamento do Exchange. O Console de Gerenciamento do Exchange não exibe o status da cópia ou nenhuma outra informação sobre SCR. Depois de habilitada a SCR de um grupo de armazenamento, você pode usar o Shell de Gerenciamento do Exchange para exibir as definições de configuração específicas de SCR do grupo de armazenamento e do seu banco de dados.
Informações de status para replicação contínua em espera
O Exchange 2007 publica diversas informações de status para cópias de SCR. A tabela a seguir descreve as informações de status disponíveis para grupos de armazenamento habilitados para SCR. Para obter etapas detalhadas que explicam como obter informações de status, consulte Como exibir o status de replicação contínua em espera.
Dica
A tabela a seguir lista as propriedades na ordem em que elas aparecem ao exibir a saída completa do cmdlet Get-StorageGroupCopyStatus.
Informações de status disponíveis para grupos de armazenamento habilitados para SCR
| Propriedade | Descrição |
|---|---|
Identity |
Servidor e nome do grupo de armazenamento consultado. |
StorageGroupName |
Nome do grupo de armazenamento consultado. |
SummaryCopyStatus |
Status geral atual da cópia de SCR. Os valores possíveis são:
|
Faha |
A verificação do banco de dados ou dos logs identificou uma inconsistência que impede a replicação. Como alternativa, há um problema de configuração ou acesso com a cópia ativa ou passiva. Os valores possíveis são True e False. |
FailedMessage |
Mensagem de texto que identifica a condição que causou a falha na replicação. Essa pode não ser a única área com problema de replicação. |
Propagação |
Propagação em andamento. Os valores possíveis são True e False. |
Suspender |
A replicação (e repetição) foi interrompida na cópia passiva. Isso impede o avanço do banco de dados e a cópia dos logs. Os valores possíveis são True e False. |
SuspendComment |
Comentário opcional do administrador com um motivo ou uma observação que explica por que a atividade de replicação foi interrompida. |
CopyQueueLength |
Número de arquivos de log de transações que aguardam para serem copiados na pasta de arquivos de log da cópia passiva. Enquanto não for verificado se há danos na cópia, ela não será considerada concluída. |
ReplayQueueLength |
Número de arquivos de log de transações que foram copiados e aguardam para serem repetidos na cópia passiva. |
LatestAvailableLogTime |
Carimbo de hora no grupo de armazenamento de origem do novo arquivo de log de transações recém-detectado. |
LastCopyNotificationedLogTime |
Hora associada ao último novo log gerado pelo grupo de armazenamento ativo e conhecido pela cópia. |
LastCopiedLogTime |
Carimbo de hora no grupo de armazenamento de origem da última cópia bem-sucedida de um arquivo de log de transações. |
LastInspectedLogTime |
Carimbo de hora no grupo de armazenamento de destino da última verificação bem-sucedida de um arquivo de log de transações. |
LastReplayedLogTime |
Carimbo de hora no grupo de armazenamento de destino da última repetição bem-sucedida de um arquivo de log de transações. |
LastLogGenerated |
Último número de log sabidamente gerado na cópia ativa do grupo de armazenamento. |
LastLogCopied |
Último número de geração de log copiado com êxito na pasta de logs da cópia passiva. |
LastLogNotified |
Último número de log gerado pelo grupo de armazenamento ativo e conhecido pela cópia. |
LastLogInspected |
Último número de geração de log cuja consistência e dados foram verificados. |
LastLogReplayed |
Último número de geração de log repetido com êxito na cópia passiva do grupo de armazenamento. |
LatestFullBackupTime |
Hora do último backup completo. |
LatestIncrementalBackupTime |
Hora do último backup incremental. |
SnapshotBackup |
O backup foi obtido usando as APIs de streaming herdadas ou o VSS (Serviço de Cópias de Sombra de Volume). Os valores possíveis são True e False. |
Você pode avaliar rapidamente a condição de uma cópia de SCR verificando os valores de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Essas três propriedades mostram se a cópia de SCR está funcionando corretamente e relativamente atualizada nos logs de cópia e de repetição. Se as seguintes condições ocorrerem, você deverá determinar a causa e corrigir o problema:
A cópia está permanecendo um tempo significativo em um estado insatisfatório.
O comprimento da fila de cópias é maior que cinco.
O comprimento da fila de repetição é maior que 20.
A hora da última verificação de logs não mostra uma hora atual. Há duas razões prováveis que poderiam causar isso: o grupo de armazenamento não está tendo muitas alterações ou o servidor de replicação está parado.
O comprimento da fila de repetição e os valores de comprimento da fila de cópia estão disponíveis como contadores de desempenho. São os contadores CopyQueueLength e ReplayQueueLength no objeto de desempenho Replicação do MSExchange.
Existem alguns raros cenários em que o status da replicação pode ficar confuso. A seguir, está uma lista desses cenários:
Um grupo de armazenamento inativo (ou seja, que não esteja alterando) pode informar que está adequado quando, na verdade, não está. Esse cenário poderia ocorrer devido a uma condição inadequada não poder ser detectada até que um log seja repetido.
Durante a inicialização da replicação, o status da replicação está sendo avaliado e pode não ser preciso. Quando a inicialização estiver concluída, o status será atualizado.
O valor do campo LastLogGenerated pode estar errado quando um banco de dados é desmontado. No entanto, todos os logs com conteúdo do usuário final serão replicados se a cópia do grupo de armazenamento estiver replicando.
Quando há um ou mais logs ausentes no meio de um fluxo de logs, a cópia passiva continua tentando fazer a recuperação. Ao fazer isso, o status da replicação aIterna entre os estados de falha e adequado. As filas de repetição e de cópia continuam a crescer.
Em algumas condições muito raras, um log pode ser verificado com êxito, mas a repetição ainda pode falhar. Nessa situação, o sistema alterna entre os estados com falha e adequado, à medida que tentar recuperar. As filas de repetição e de cópia continuam a crescer.
Verificando a integridade de um destino de SCR
Ao usar a SCR, é recomendável verificar a integridade de cada cópia de destino de SCR periodicamente, executando uma verificação de consistência física no banco de dados e nos arquivos de log de transações. Uma verificação de consistência física examina os arquivos de logs de transação e de bancos de dados em busca de danos. Você pode executar a verificação usando a versão da linha de comando da ferramenta Serviço de Cópias de Sombra de Volume do Microsoft (VSSAdmin.exe) e os Utilitários do Banco de Dados do Exchange Server (Eseutil.exe). Para obter etapas detalhadas sobre como usar o VSSAmin e o Eseutil para verificar danos físicos nos logs de transações e nos arquivos de banco de dados, consulte Como verificar uma cópia de replicação contínua em espera.
Dica
Antes de executar uma verificação de consistência física em um banco de dados, suspenda temporariamente todas as atividades de replicação do grupo de armazenamento. Você pode suspender as atividades de replicação, usando o cmdlet Suspend-StorageGroupCopy no Shell de Gerenciamento do Exchange. Quando a verificação de consistência tiver sido concluída, você poderá retomar a atividade de repetição do log de transações, usando o cmdlet Resume-StorageGroupCopy. É recomendável executar a verificação fora do horário de produção e reduzir o tempo de suspensão da atividade de repetição. Isso ocorre porque a suspensão da cópia do grupo de armazenamento interrompe todas as atualizações na cópia de SCR, fazendo com que algum conteúdo fique vulnerável a falhas.
Gerenciando a replicação e a repetição
O gerenciamento da replicação e da repetição de arquivos de log em um ambiente de SCR envolve as seguintes atividades principais:
Interromper a replicação da cópia de grupo de armazenamento
Reiniciar a replicação da cópia de grupo de armazenamento
Repropagar um grupo de armazenamento
Interromper e reiniciar alterações na cópia de grupo de armazenamento e no banco de dados
Por vários motivos, pode ser necessário interromper e reiniciar a atividade de replicação de log de transações. A replicação do log de transações ocorre quando o serviço de Replicação do Microsoft Exchange está sendo executado, um grupo de armazenamento foi habilitado para SCR e a origem e o destino de SCR estão operacionais. Se a origem ou o destino de SCR tornar-se indisponível, será necessário parar a replicação. Além disso, algumas tarefas administrativas, como propagação, exigem a suspensão da replicação de um grupo de armazenamento habilitado para SCR. Se você precisar interromper todos os acessos para os arquivos de dados de destino, suspenda a replicação.
Ocasionalmente, pode ser necessário controlar as atividades do destino de SCR. Isso pode ser necessário para executar uma reconfiguração ou corrigir problemas com o servidor ou o banco de dados. A interrupção da repetição de log também é necessária para executar uma verificação de consistência física do destino de SCR. Quando for necessário controlar as atualizações de cópia do banco de dados, a replicação deverá ser interrompida para o destino de SCR. Também pode ser necessário interromper a replicação quando os logs de destino de SCR estiverem sendo manipulados por algum motivo.
Para obter mais informações sobre como interromper alterações de replicação nas cópias de SCR, consulte Como suspender alterações feitas em um destino de replicação contínua em espera. Para obter mais informações sobre como reiniciar alterações de replicação nas cópias de SCR, consulte Como continuar a replicação em um destino de replicação contínua em espera. Para obter mais informações sobre como executar uma verificação de integridade nos logs de transações da cópia passiva e no arquivo de banco de dados, consulte Como verificar uma cópia de replicação contínua em espera.
Propagando e repropagando uma cópia do grupo de armazenamento
A propagação e a repropagação de uma cópia de grupo de armazenamento em um ambiente de SCR é executada usando o cmdlet Update-StorageGroupCopy com o parâmetro StandbyMachine, que é um novo parâmetro adicionado no Exchange 2007 SP1.
Para obter etapas detalhadas sobre como propagar ou repropagar um destino de SCR, consulte Como propagar um destino de replicação contínua em espera.
Recuperação após danos pela avaliação do status da replicação no momento do dano
Após uma falha ou dano de uma cópia do banco de dados, será necessário avaliar se você deseja continuar a operação imediatamente usando uma cópia de SCR. A SCR fornece os principais elementos de informações para auxiliar nessa decisão:
Condições da cópia no momento da falha
Filas de cópia e repetição no momento da falha
Hora da última verificação de log no momento da falha
As informações podem ser obtidas usando o cmdlet Get-StorageGroupCopyStatus. Para obter etapas detalhadas sobre como obter essas informações, consulte Como exibir o status de replicação contínua em espera.
Dica
A hora da última verificação de log fornece informações sobre as alterações mais recentes da origem de SCR. Isso ajuda a detectar falhas que ocorrem quando o serviço de Replicação do Microsoft Exchange não está iniciado, pois os comprimentos das filas não são exatos quando o serviço de Replicação do Microsoft Exchange está parado.
O comprimento da fila de cópia inclui as melhores informações disponíveis da origem de SCR no momento da falha. Com base nessas informações e em sua avaliação do tempo de recuperação do banco de dados danificado, você poderá decidir se o destino de SCR disponível será ativado:
Se o comprimento da fila de repetição for significativo, a recuperação poderá levar tempo, mas não será um indicador de que uma perda de dados significativa ocorrerá.
Se o comprimento da fila de cópias for significativa, vários logs poderão ser perdidos. Se o banco de dados estiver ativado, ele será restaurado para um período de aproximadamente o último log copiado (também fornecido pelo cmdlet Get-StorageGroupCopyStatus).
Se a hora da última verificação de log for significativamente anterior à hora da falha, será bem provável que o serviço de Replicação do Microsoft Exchange esteja parado e que as outras informações da fila não sejam exatas.
Dica
Devido à natureza da SCR, bem como às latências e falhas de comunicação, é possível que o comprimento da fila de cópia não seja exato, porque o estado atual da cópia ativa é atualizado de forma assíncrona. Em geral, a imprecisão está limitada às atividades ocorridas aproximadamente um minuto antes e após a falha.
Dica
Um banco de dados com falha não pode ser usado para propagar um destino de SCR.