Gerenciando a replicação contínua local
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2007-08-20
Além das tarefas de gerenciamento e administração diárias de uma organização do Exchange, há tarefas específicas de uma replicação contínua local (ou LCR, Local Continuos Replication). Geralmente, as tarefas administrativas de LCR são:
Configurar o armazenamento em disco para LCR e gerenciar volumes de disco.
Habilitar e desabilitar a replicação contínua local.
Monitorando 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 LCR.
Exibir status e informações de configuração para um grupo de armazenamento ou banco de dados habilitado para LCR.
Verificar a integridade de uma cópia ativa ou passiva dos dados de LCR.
Gerenciar a atividade de replicação e repetição.
Ativar a cópia passiva.
Configurando o armazenamento em disco para replicação contínua local
A replicação contínua local não exige configuração especial de armazenamento em disco. É recomendável isolar as cópias umas das outras do modo mais prático possível. A replicação contínua local exige que o armazenamento ofereça desempenho e capacidade adequados. Configure soluções de armazenamento equivalentes para cópias de grupos de armazenamento e bancos de dados habilitados para LCR. Recomenda-se também seguir os procedimentos de configuração indicados pelo fornecedor de armazenamento, para concluir a configuração.
Gerenciamento de volumes de discos
Durante o gerenciamento de um ambiente de LCR, pode ser necessário gerenciar volumes de disco que estão 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 se preparar para atividades de gerenciamento de disco de uma cópia de LCR.
Habilitando a replicação contínua local
O uso da replicação contínua local começa com a habilitação de um grupo de armazenamento para LCR. Essa tarefa pode ser executada com o Console de Gerenciamento do Exchange ou com o Shell de Gerenciamento do Exchange.
Dica
Quando um grupo de armazenamento tiver sido habilitado para LCR, uma segunda cópia do banco de dados no grupo de armazenamento será criada e mantida automaticamente no local especificado para a cópia de LCR.
Importante
Antes de habilitar a LCR, verifique se o espaço em disco é suficiente para armazenar a cópia de LCR.
Para usar a replicação contínua local, é preciso habilitar o grupo de armazenamento para LCR. Para obter etapas detalhadas sobre como habilitar um grupo de armazenamento existente para LCR, consulte Como habilitar a Replicação Contínua Local para um grupo de armazenamento existente. Para obter etapas detalhadas sobre como criar um novo grupo de armazenamento habilitado para LCR, consulte Como habilitar a replicação contínua local para um novo grupo de armazenamento.
Desabilitando a replicação contínua local
Você pode desabilitar a replicação contínua local de um grupo de armazenamento no Console de Gerenciamento do Exchange ou no Shell de Gerenciamento do Exchange. Para obter etapas detalhadas sobre como desabilitar a replicação contínua local, consulte Como desabilitar a replicação contínua local.
Importante
A exclusão de um grupo de armazenamento que contém uma cópia de LCR excluirá as cópias de LCR e de produção.
Ajuste da configuração padrão do dumpster de transporte
O dumpster de transporte é um recurso da função de servidor de Transporte de Hub, que envia mensagens recebidas recentemente após uma interrupção não programada. O servidor de Transporte de Hub mantém uma fila de emails que foram entregues recentemente a uma caixa de correio:
Em um servidor de caixas de correio em cluster, em um ambiente de CCR
Em um grupo de armazenamento habilitado para LCR
O dumpster de transporte deve estar sempre ativado ao usar CCR (replicação contínua de cluster) ou LCR. O dumpster de transporte é habilitado em toda a organização definindo a quantidade de armazenamento disponível por grupo de armazenamento e a configuração do tempo de permanência do email no dumpster de transporte.
Você pode usar o cmdlet Set-TransportConfig para alterar as definições da configuração padrão do dumpster de transporte, aplicadas no nível de grupo de armazenamento.
Recomendamos configurar o parâmetro MaxDumpsterSizePerStorageGroup, que especifica o tamanho máximo da fila do dumpster de transporte de cada grupo de armazenamento, com um tamanho igual ao tamanho da mensagem máxima que pode ser enviada multiplicado por 1,5. Por exemplo, se o tamanho máximo das mensagens for 10 megabytes (MB), configure o parâmetro MaxDumpsterSizePerStorageGroup com um valor igual a 15 MB.
Também recomendamos configurar o parâmetro MaxDumpsterTime, que especifica quanto tempo uma mensagem de email deve permanecer na fila do dumpster de transporte, com o valor 7.00:00:00, correspondente a 7 dias. As mensagens serão removidas do dumpster de transporte quando o tamanho especificado pelo MaxDumpsterSizePerStorageGroup for atingido. Caso contrário, elas serão removidas do dumpster de transporte quando o tempo especificado pelo parâmetro MaxDumpsterTime tiver transcorrido. Acreditamos que seja um tempo suficiente para permitir que uma interrupção estendida ocorra sem perda de mensagens de email.
Ao usar o recurso de dumpster de transporte, será necessário espaço adicional em disco no servidor de Transporte de Hub para hospedar as filas do dumpster de transporte. A quantidade necessária de espaço de armazenamento é aproximadamente igual ao valor de MaxDumpsterSizePerStorageGroup multiplicado pelo número de grupos de armazenamento em todos os servidores de caixas de correio em cluster de um ambiente de CCR e todos os grupos de armazenamento habilitados para LCR do site do serviço de diretório do Active Directory que contém o servidor de Transporte de Hub. Em um ambiente de CCR, a solicitação de nova entrega do dumpster de transporte em todos os servidores de Transporte de Hub do site é realizada automaticamente. Em um ambiente de LCR, a solicitação de nova entrega de todos os servidores de Transporte de Hub ocorre como parte da tarefa Restore-StorageGroupCopy
Para obter etapas detalhadas sobre como habilitar e configurar o dumpster de transporte, consulte Como configurar o dumpster de transporte. Para obter mais informações sobre o cmdlet Restore-StorageGroupCopy, consulte Restore-StorageGroupCopy.
Monitorando a atividade de replicação
A cópia passiva de um banco de dados só será útil se ela for mantida atualizada. Embora a LCR não exija nenhum monitoramento especial, recomendamos monitorar regularmente cada grupo de armazenamento para verificar se ele está replicando corretamente os arquivos de log. O Pacote de Gerenciamento do Microsoft Exchange Server 2007 para Microsoft Operations Manager 2005 inclui alertas para vários problemas críticos relacionados a ambientes de LCR:
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 é interrompido, portanto qualquer alerta associado a ele seria perdido, caso ele não fosse limpo.
A cópia passiva está em um estado de falha.
A cópia passiva está em um estado adequado, mas está significativamente atrasada na cópia ou repetição de log.
Qualquer um dos alertas anteriores gerados pelo Pacote de Gerenciamento do Exchange 2007 deve ser investigado e resolvido o mais rápido possível.
Uma alternativa ao uso do Pacote de Gerenciamento do Exchange 2007 para o Microsoft Operations Manager 2005 é acionar regularmente um script que execute o cmdlet Get-StorageGroupCopyStatus no Shell de Gerenciamento do Exchange. O cmdlet Get-StorageGroupCopyStatus fornece comprimentos de fila que incorporam o número de logs gerados pela cópia ativa. Por motivos de desempenho, os contadores de desempenho de comprimento de fila relatam apenas informações conhecidas para o serviço de Replicação do Microsoft Exchange. Sob condições muito raras, isso pode ser inconsistente com o estado da cópia ativa. Para obter mais informações sobre o cmdlet Get-StorageGroupCopyStatus, consulte "Exibindo informações de status" posteriormente neste tópico.
Montando, desmontando, criando e removendo bancos de dados
Ocasionalmente, pode ser necessário montar ou desmontar bancos de dados em um ambiente de LCR. Se o grupo de armazenamento 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 é desmontado, ele fica congelado para alterações adicionais. Nem o banco de dados nem os arquivos de log serão alterados enquanto o banco de dados estiver desmontado.
Você pode querer adicionar um banco de dados a um grupo de armazenamento habilitado para LCR. O processo é semelhante ao usado para adicionar um banco de dados em uma configuração autônoma, exceto que o caminho adicional deve ser fornecido.
Convém remover um banco de dados de um grupo de armazenamento habilitado para LCR. O processo é idêntico ao usado para remover um banco de dados em uma configuração autônoma, exceto que há duas cópias dos dados a serem removidas: a cópia ativa do banco de dados e a cópia passiva do banco de dados. Para obter etapas detalhadas de como remover um banco de dados de um grupo de armazenamento habilitado para LCR, consulte Como remover um banco de dados de um grupo de armazenamento habilitado para replicação contínua local.
Movendo o local do grupo de armazenamento e dos arquivos de banco de dados
Você pode usar tanto o Shell de Gerenciamento do Exchange quanto o Console de Gerenciamento do Exchange para alterar o local de um banco de dados em um grupo de armazenamento habilitado para LCR. Em uma configuração de LCR, há dois arquivos de bancos de dados, um para cada cópia. Os locais para as duas cópias podem ser alterados de forma independente ou em tandem.
Dica
Os nomes e caminhos dos arquivos do banco de dados devem ser iguais para as cópias ativa e passiva.
Procedimentos semelhantes são usados para reconfigurar o local do log do grupo de armazenamento e arquivos de sistema e o local dos arquivos de banco de dados em um ambiente de LCR. Para obter etapas detalhadas de como alterar o local de arquivos de log e arquivos de sistema de um grupo de armazenamento habilitado para LCR, consulte Como mover um grupo de armazenamento em um ambiente de replicação contínua local. Para obter etapas detalhadas de como alterar o local dos arquivos de banco de dados em um ambiente de LCR, consulte Como mover um banco de dados em um ambiente de replicação contínua local.
Importante
Os bancos de dados não podem ser colocados na raiz de um volume.
Exibindo informações de status
Depois de habilitada a replicação contínua local para um grupo de armazenamento, use o Console de Gerenciamento do Exchange ou o Shell de Gerenciamento do Exchange para exibir as definições de configuração específicas de LCR do grupo de armazenamento e do seu banco de dados.
Informações de status para LCR
O Exchange 2007 publica diversas informações de status para cópias LCR. A tabela a seguir descreve as informações de status disponíveis para grupos de armazenamento habilitados para LCR. Para obter etapas detalhadas que explicam como obter informações de status, consulte Como exibir o status de uma cópia de replicação contínua local. A tabela a seguir lista as propriedades na ordem em que elas aparecem ao exibir a saída completa do cmdlet Get-StorageGroupCopyStatus do Shell de Gerenciamento do Exchange.
Informações de status disponíveis para grupos de armazenamento habilitados para LCR
| 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 LCR. Os valores possíveis são:
O Microsoft Exchange Server 2007 Service Pack 1 (SP1) adiciona dois valores de status adicionais:
|
Failed |
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 de 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 de replicação. Pode não ser a única área de problema de replicação. |
Seeding |
Propagação em andamento. Os valores possíveis são True e False. |
Suspend |
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 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 que se soube ter sido gerado na cópia ativa do grupo de armazenamento. |
LastLogCopied |
Último número de geração de log que foi 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 LCR verificando os valores de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Essas três propriedades mostram se a cópia de LCR 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 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 serviço de Replicação do Microsoft Exchange está parado.
Os valores de comprimento das filas de repetição e 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. Para obter detalhes sobre o monitoramento de contadores de desempenho para LCR, consulte Como exibir contadores de desempenho para replicação contínua local.
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á. Essa situação 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 for 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. Nesse caso, o status da replicação aIterna entre os estados com falha e adequado. As filas de repetição e de cópia continuarão 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 alternará entre os estados com falha e adequado, à medida que tentar recuperar. As filas de repetição e de cópia continuarão a crescer.
Dica
No Exchange 2007 SP1, você também pode usar um novo cmdlet chamado Test-ReplicationHealth para verificar a integridade e o status dos grupos de armazenamento habilitados para replicação contínua. Para obter mais informações sobre o cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth e a seção "Cmdlet Test-ReplicationHealth" do Monitorando a replicação contínua.
Exibindo informações de configuração
Você pode usar o Console de Gerenciamento do Exchange e o Shell de Gerenciamento do Exchange para exibir informações de configuração de grupos de armazenamento e bancos de dados habilitados para LCR. As informações de configuração incluem:
Grupos de armazenamento O local dos arquivos de log de transações de LCR e dos arquivos de sistema de LCR.
Bancos de dados O local da cópia de banco de dados de LCR.
Além disso, você poderá determinar se um grupo de armazenamento ou um banco de dados está configurado para ter uma cópia de LCR. Para obter etapas detalhadas sobre como exibir as definições de configuração de LCR, consulte Como exibir as definições de configuração da replicação contínua local.
Verificando a integridade da cópia passiva
Ao usar a replicação contínua local, é recomendável verificar a integridade da cópia passiva 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 ferramenta Utilitário de Banco de Dados (Eseutil.exe) do Exchange Server. Para obter etapas detalhadas de como usar 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 Local usando Eseutil.
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 a atividade de replicação usando o cmdlet Suspend-StorageGroupCopy do Shell de Gerenciamento do Exchange ou pelo Console 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 LCR, 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 LCR 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
Interromper e reiniciar alterações na cópia do grupo de armazenamento e no banco de dados
Pode ser necessário interromper e reiniciar a atividade de replicação de log de transações. A replicação de log de transações (incluindo repetição) é controlada no nível do grupo de armazenamento. Como um grupo de armazenamento pode conter apenas um banco de dados, a replicação está localizada em apenas um banco de dados. A replicação de 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 LCR e as cópias ativa e passiva estão operacionais. Se a cópia ativa ou passiva se tornar indisponível, interrompa a replicação. Além disso, algumas tarefas administrativas, como propagação, exigem que, para suspender a replicação, um grupo de armazenamento esteja habilitado para LCR. Se você precisar interromper todos os acessos para os arquivos de dados da cópia passiva, suspenda a replicação.
Ocasionalmente, pode ser necessário controlar as atividades da cópia passiva. 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 da cópia passiva. Quando for necessário controlar as atualizações de cópia do banco de dados, a replicação deverá ser interrompida para a cópia do grupo de armazenamento. A replicação também poderá ser necessária quando os logs da cópia passiva estiverem sendo manipulados. Como um grupo de armazenamento pode conter apenas um banco de dados, as ações que afetam o comportamento de repetição são controladas no nível de grupo de armazenamento.
Recomenda-se que todas as atividades de replicação sejam interrompidas quando o local do grupo de armazenamento ou do banco de dados estiver sendo alterado.
Para obter mais informações sobre como interromper alterações de replicação nas cópias de LCR, consulte Como paralisar a replicação de um Grupo de Armazenamento que está habilitado para Replicação Contínua Local. Para obter mais informações sobre como reiniciar alterações de replicação nas cópias de LCR, consulte Como reiniciar a replicação de um grupo de armazenamento habilitado para replicação contínua local. 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 Local usando Eseutil.
Ativando a cópia passiva
A recuperação contínua local permite que você recupere uma cópia ativa danificada de um grupo de armazenamento ativando a cópia passiva do grupo de armazenamento. Se os logs de transação na cópia ativa do grupo de armazenamento não estiverem danificados, não deverá haver perda de dados. Se os logs de transação da cópia ativa do grupo de armazenamento não estiverem disponíveis, a recuperação conseguirá apenas colocar o grupo de armazenamento novamente em um determinado ponto de consistência com o último conjunto de alterações não danificado que a cópia passiva recebeu. Outra restrição é que não poderá haver nenhum arquivo de log de transações de produção ausente ou danificado antes desse ponto.
A recuperação de um grupo de armazenamento de produção danificado é mais fácil quando pontos de montagem de volume do sistema de arquivo NTFS são usados para armazenar a cópia de LCR. Ao usar os pontos de montagem de volume, você pode transplantar ou montar uma partição de destino em uma pasta ou em outro disco físico. Os pontos de montagem de volume são transparentes para os programas, incluindo o Exchange 2007.
É possível detectar a corrupção de um log de transações ou de um arquivo de banco de dados que faça parte de uma cópia de LCR pelos erros gerados por uma operação de repetição ou por uma verificação de consistência. A ação corretiva a ser tomada, se houver alguma, dependerá do tipo de dano:
Se o dano ocorrer em um arquivo de log que já tenha sido repetido, o arquivo de log danificado poderá ser ignorado com segurança. No entanto, se você estiver fazendo backups de arquivos com base em sistema da cópia LCR, será necessário excluir primeiramente todos os arquivos de log que tiverem sido repetidos.
Se o dano ocorrer em um arquivo de log da cópia ativa que não tenha sido repetido, propague novamente o grupo de armazenamento de LCR. O Exchange tentará copiar novamente um arquivo de log se ele detectar danos. Se a cópia automática não resolver o dano, propague novamente o grupo de armazenamento. Além disso, é recomendável que você verifique a integridade dos logs de transação de origem e do arquivo de banco de dados. A verificação de arquivos de dados do Exchange exige que os arquivos estejam offline e indisponíveis para acesso pelos usuários.
Se o banco de dados estiver danificado, propague novamente o grupo de armazenamento.
Para obter etapas detalhadas que explicam como ativar a cópia passiva de um banco de dados, consulte Como alternar para a cópia passiva de um banco de dados.
Avaliando o status da replicação no momento do dano
Após falha ou danificação de uma cópia do banco de dados, será necessário avaliar se você deseja continuar a operação imediatamente usando a cópia passiva. A recuperação contínua local 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 uma cópia de replicação contínua local.
Dica
A hora da última verificação de log fornece informações sobre as alterações mais recentes da cópia ativa. Essas informações o ajudam a detectar falhas que ocorrem quando o serviço de Replicação do Microsoft Exchange não está iniciado, porque 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 cópia ativa 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 a cópia disponível será montada:
Se o comprimento da fila de repetição for significativo, isso indicará que 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ópia for significativo, isso indicará que um número significativo de logs foi perdido. Se o banco de dados tiver sido montado, 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 a 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 por volta de um minuto antes e após a falha.
Dica
Um banco de dados com falha não pode ser usado para propagar uma cópia passiva.