Gerenciar cópias de banco de dados de caixa de correio

APLICA-SE A:2016 2019 Subscription Edition

No Exchange Server, você pode usar o EAC (Console de Gerenciamento do Exchange) ou o Shell de Gerenciamento do Exchange para adicionar cópias de banco de dados de caixa de correio depois que um grupo de disponibilidade de banco de dados (DAG) for criado, configurado e preenchido com membros do servidor de Caixa de Correio.

Gerenciar cópias de banco de dados

Depois que várias cópias de um banco de dados forem criadas, você poderá usar o EAC ou o Shell de Gerenciamento do Exchange para realizar as seguintes tarefas:

• Monitore a integridade e o status de cada cópia.
• Realize outras tarefas de gerenciamento associadas a cópias de banco de dados. Por exemplo:
  • Suspender ou retomar uma cópia de banco de dados.
  • Propague uma cópia do banco de dados.
  • Monitore cópias de banco de dados.
  • Definir configurações de cópia de banco de dados
  • Remover uma cópia de banco de dados.

Suspender e retomar cópias de banco de dados

Por vários motivos, como a execução de manutenção planejada, talvez seja necessário suspender e retomar a atividade de replicação contínua para uma cópia de banco de dados. Além disso, algumas tarefas administrativas, como propagação, exigem que você primeiro suspenda uma cópia de banco de dados. Recomendamos que você suspenda todas as atividades de replicação quando o caminho para o banco de dados ou seus arquivos de log estiver sendo alterado. Você pode suspender e retomar a atividade de cópia de banco de dados usando o EAC ou executando os cmdlets Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange. Para obter instruções detalhadas sobre como suspender ou retomar a atividade de replicação contínua para uma cópia do banco de dados, consulte Suspender ou retomar uma cópia do banco de dados de caixa de correio.

Propagar uma cópia do banco de dados

A propagação, também conhecida como atualização, é quando um banco de dados em branco ou uma cópia do banco de dados de produção é adicionada ao local da cópia de destino em outro servidor de Caixa de Correio no mesmo DAG que o banco de dados ativo. Esse banco de dados se torna o banco de dados de linha de base para a cópia mantida por esse servidor.

Dependendo da situação, você pode propagar um banco de dados usando um processo automático ou um processo manual iniciado por você. Quando uma cópia de banco de dados é adicionada, a cópia é propagada automaticamente, se o servidor de destino e seu armazenamento estiverem configurados corretamente. Para propagar manualmente uma cópia de banco de dados e não quiser que a propagação automática ocorra ao criar a cópia, você pode usar o parâmetro SeedingPostponed no cmdlet Add-MailboxDatabaseCopy .

As cópias de banco de dados raramente precisam ser propagadas novamente após a propagação inicial. No entanto, se a nova propagação for necessária ou se o sistema propagar manualmente uma cópia do banco de dados em vez de o sistema propagar automaticamente a cópia, você terá duas opções:

• Use o assistente de Cópia de Banco de Dados de Caixa de Correio de Atualização no EAC.
• Use o cmdlet Update-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange.

Antes de propagar uma cópia de banco de dados, você deve primeiro suspender a cópia de banco de dados de caixa de correio. Para obter etapas detalhadas sobre como propagar a cópia de um banco de dados, consulte Atualizar uma cópia de banco de dados de caixa de correio.

Após a conclusão de uma operação de propagação manual, a replicação da cópia do banco de dados da caixa de correio propagada é retomada automaticamente. Se você não quiser que a replicação seja retomada automaticamente, poderá usar o parâmetro ManualResume no cmdlet Update-MailboxDatabaseCopy .

Escolher o que propagar

Ao executar uma operação de propagação, você pode optar por:

• Semear a cópia do banco de dados da caixa de correio.
• Propague o catálogo de índice de conteúdo para a cópia do banco de dados da caixa de correio.
• Propague a cópia do banco de dados e a cópia do catálogo do índice de conteúdo.

O comportamento padrão do assistente de Atualização de Cópia do Banco de Dados de Caixa de Correio e do cmdlet Update-MailboxDatabaseCopy é propagar a cópia do banco de dados de caixa de correio e a cópia do catálogo de índice de conteúdo.

Para propagar apenas a cópia do banco de dados da caixa de correio sem propagar o catálogo de índice de conteúdo, use o parâmetro DatabaseOnly no cmdlet Update-MailboxDatabaseCopy .

Para propagar apenas a cópia do catálogo do índice de conteúdo, use o parâmetro CatalogOnly no cmdlet Update-MailboxDatabaseCopy .

Selecionar a fonte da propagação

Você pode usar qualquer cópia de banco de dados íntegra como a fonte de propagação para outra cópia desse banco de dados. Essa opção é particularmente útil quando você tem um DAG estendido em vários locais físicos.

Por exemplo, considere a seguinte implantação do DAG de quatro membros:

• MBX1 e MBX2 estão localizados em Portland, Oregon.
• MBX3 e MBX4 estão localizados em Nova York, Nova York.
• Um banco de dados de caixa de correio chamado DB1 está ativo no MBX1.
• Existem cópias passivas do DB1 no MBX2 e no MBX3.

Ao adicionar uma cópia do DB1 ao MBX4, você pode usar a cópia no MBX3 como a origem para propagação. Essa opção evita a propagação no link WAN (rede de longa distância) entre Portland e Nova York.

Para usar uma cópia específica como uma fonte de propagação ao adicionar uma nova cópia de banco de dados, você pode fazer as seguintes etapas:

• Use o parâmetro SeedingPostponed no cmdlet Add-MailboxDatabaseCopy para adicionar a cópia do banco de dados. Caso contrário, a cópia do banco de dados será explicitamente propagada usando a cópia ativa do banco de dados como origem.

• Você pode especificar o servidor de origem a ser usado no assistente de Cópia de Banco de Dados de Caixa de Correio de Atualização no EAC ou pode usar o parâmetro SourceServer no cmdlet Update-MailboxDatabaseCopy para especificar o servidor de origem desejado para propagação.

  No exemplo anterior, você especificaria MBX3 como o servidor de origem. Caso contrário, a cópia do banco de dados será explicitamente propagada da cópia ativa do banco de dados.

Propagação e redes

Além de selecionar um servidor de origem específico para propagar uma cópia de banco de dados de caixa de correio, você também pode usar o Shell de Gerenciamento do Exchange para especificar quais redes DAG usar. Você pode substituir as configurações de compactação e criptografia da rede DAG durante a operação de propagação.

Você pode especificar as redes a serem usadas para propagação usando o parâmetro Network no cmdlet Update-MailboxDatabaseCopy e especificar as redes DAG que deseja usar. Se você não usar o parâmetro Network , o sistema usará o seguinte comportamento padrão para selecionar uma rede a ser usada para a operação de propagação:

• Se o servidor de origem e o servidor de destino estiverem na mesma sub-rede e uma rede de replicação que inclua a sub-rede estiver configurada, a rede de replicação será usada.

• Se o servidor de origem e o servidor de destino estiverem em sub-redes diferentes, mesmo que uma rede de replicação que contenha essas sub-redes esteja configurada, a rede do cliente (MAPI) será usada para a propagação.

• Se o servidor de origem e o servidor de destino estiverem em datacenters diferentes, a rede do cliente (MAPI) será usada para a propagação.

No nível do DAG, as redes do DAG são configuradas para criptografia e compactação. As configurações padrão usam criptografia e compactação somente para comunicações em sub-redes diferentes. Se a origem e o destino estiverem em sub-redes diferentes e o DAG estiver configurado com os valores padrão para NetworkCompression e NetworkEncryption, você poderá substituir esses valores usando os parâmetros NetworkCompressionOverride e NetworkEncryptionOverride no cmdlet Update-MailboxDatabaseCopy .

Processo de propagação

Quando você inicia um processo de propagação usando os cmdlets Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy , as seguintes tarefas são executadas:

1. As propriedades do banco de dados do Active Directory são lidas para validar o banco de dados e os servidores especificados e para verificar se os servidores de origem e destino estão executando o Exchange Server, se ambos são membros do mesmo DAG e se o banco de dados especificado não é um banco de dados de recuperação. Os caminhos do arquivo de banco de dados também são lidos.

2. As preparações ocorrem para verificações novamente propagadas a partir do serviço de replicação do Microsoft Exchange no servidor de destino.

3. O serviço de replicação do Microsoft Exchange no servidor de destino verifica a presença de arquivos do log de transação e do banco de dados nos diretórios de arquivos lidos pelas verificações do Active Directory na etapa 1.

4. O serviço de replicação do Microsoft Exchange retorna as informações de status do servidor de destino para a interface administrativa onde o cmdlet foi executado.

5. Se todas as verificações preliminares forem aprovadas, você será solicitado a confirmar a operação antes de continuar. Se você confirmar a operação, o processo continuará. Se um erro for encontrado durante as verificações preliminares, o erro será informado e haverá falha na operação.

6. A operação de propagação é iniciada no serviço de replicação do Microsoft Exchange no servidor de destino.

7. O serviço de replicação do Microsoft Exchange suspende a replicação do banco de dados para a cópia do banco de dados ativa.

8. O serviço de Replicação do Microsoft Exchange atualiza as informações de estado do banco de dados para refletir um status de Semeação.

9. Se o servidor de destino ainda não tiver os diretórios do banco de dados de destino e dos arquivos de log, eles serão criados.

10. Uma solicitação TCP para propagar o banco de dados é passada do serviço de Replicação do Microsoft Exchange no servidor de destino para o serviço de Replicação do Microsoft Exchange no servidor de origem. Essa solicitação e as comunicações subsequentes para propagar o banco de dados ocorrem em uma rede DAG configurada como uma rede de replicação.

11. O serviço de replicação do Microsoft Exchange no servidor de origem inicia um backup de streaming do Mecanismo de Armazenamento Extensível (ESE) por meio da interface de serviço de Armazenamento de Informações do Microsoft Exchange.

12. O serviço de Armazenamento de Informações do Microsoft Exchange transmite os dados do banco de dados para o serviço de replicação do Microsoft Exchange.

13. Os dados do banco de dados são movidos do serviço de replicação do Microsoft Exchange do servidor de origem para o serviço de replicação do Microsoft Exchange do servidor de destino.

14. O serviço de Replicação do Microsoft Exchange no servidor de destino grava a cópia do banco de dados em um diretório temporário localizado no diretório de banco de dados principal chamado temp-seeding.

15. A operação de backup de streaming no servidor de origem termina quando se atinge o final do banco de dados.

16. A operação de gravação no servidor de destino é concluída e o banco de dados é movido do diretório temp-seeding para o local final. O diretório temp-seeding é excluído.

17. No servidor de destino, o serviço de replicação do Microsoft Exchange usa um proxy para uma solicitação ao serviço de pesquisa do Microsoft Exchange para montar o catálogo do índice de conteúdo, caso ele exista. Se houver arquivos de catálogo desatualizados existentes de uma instância anterior da cópia do banco de dados, haverá falha na operação da montagem, que dispara a necessidade de replicar o catálogo do servidor de origem. Da mesma forma, se o catálogo não existir em uma nova instância da cópia do banco de dados no servidor de destino, uma cópia do catálogo será obrigatória. O serviço de replicação do Microsoft Exchange orienta o serviço de pesquisa do Microsoft Exchange a suspender a indexação da cópia do banco de dados enquanto um novo catálogo é copiado da origem.

18. O serviço de replicação do Microsoft Exchange no servidor de destino envia uma solicitação de catálogo de propagação para o serviço de replicação do Microsoft Exchange no servidor de origem.

19. No servidor de origem, o serviço de Replicação do Microsoft Exchange solicita as informações de diretório do serviço Pesquisa do Microsoft Exchange e solicita que a indexação seja suspensa.

20. O serviço de pesquisa do Microsoft Exchange no servidor de origem retorna as informações sobre o diretório do catálogo de pesquisa para o serviço de replicação do Microsoft Exchange.

21. O serviço de replicação do Microsoft Exchange no servidor de origem lê os arquivos de catálogo a partir do diretório.

22. O serviço de replicação do Microsoft Exchange no servidor de origem move os dados do catálogo para o serviço de replicação do Microsoft Exchange no servidor de destino, usando uma conexão na rede de replicação. Após a conclusão da leitura, o serviço de replicação do Microsoft Exchange envia uma solicitação para o serviço de pesquisa do Microsoft Exchange, para retomar a indexação do banco de dados de origem.

23. Se houver algum arquivo de catálogo existente no servidor de destino no diretório, o serviço de replicação do Microsoft Exchange no servidor de destino o excluirá.

24. O serviço de Replicação do Microsoft Exchange no servidor de destino grava os dados do catálogo em um diretório temporário chamado CiSeed.Temp até que os dados sejam completamente transferidos.

25. O serviço de replicação do Microsoft Exchange move todos os dados do catálogo para o local final.

26. O serviço de replicação do Microsoft Exchange no servidor de destino retoma a indexação de pesquisa no banco de dados de destino.

27. O serviço de replicação do Microsoft Exchange no servidor de destino retorna um status de conclusão.

28. O resultado final da operação é passado para a interface administrativa a partir da qual o cmdlet foi chamado.

Configurar cópias de banco de dados

Após a criação de uma cópia de banco de dados, é possível exibir e modificar as definições de configuração quando necessário. É possível exibir algumas informações de configuração examinando a página Propriedades de uma cópia de banco de dados no EAC. Você também pode usar os cmdlets Get-MailboxDatabase e Set-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange para exibir e definir as configurações de cópia do banco de dados. Por exemplo, tempo de retardo de repetição, tempo de retardo de truncamento e ordem de preferência de ativação. Para instruções detalhadas sobre como visualizar e configurar as definições de cópia do banco de dados, consulte Configurar propriedades de cópia de banco de dados de caixa de correio.

Usar opções de retardo de truncamento e de retardo de repetição

As cópias de banco de dados de caixa de correio dão suporte ao uso de um tempo de retardo de repetição e de um tempo de retardo de truncamento, ambos configurados em minutos. A configuração de um tempo de retardo de repetição permite restaurar uma cópia de backup de banco de dados para uma hora específica. A configuração de um tempo de retardo de truncamento permite usar os logs em uma cópia de banco de dados passiva para se recuperar da perda de arquivos de log na cópia de banco de dados ativa. Como esses dois recursos resultam no acúmulo temporário de arquivos de log, o uso de qualquer um deles afeta o design do armazenamento.

Tempo de retardo de repetição

O tempo de retardo de repetição é uma propriedade de cópia de banco de dados de caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a repetição de log para a cópia de banco de dados. O temporizador de retardo de repetição é iniciado quando um arquivo de log é replicado para a cópia passiva e passa na inspeção com êxito. Atrasando a repetição dos logs para a cópia de banco de dados, você tem a possibilidade de recuperar o banco de dados para um ponto específico anterior. Uma cópia de banco de dados de caixa de correio configurada com um tempo de retardo de repetição maior que zero é chamada de cópia de banco de dados de caixa de correio com retardamento ou, simplesmente, uma cópia com retardamento.

Uma estratégia que usa cópias de banco de dados e os recursos de retenção de litígio no Exchange Server pode fornecer proteção contra uma série de falhas que normalmente causariam perda de dados. No entanto, esses recursos não podem fornecer proteção contra perda de dados devido à corrupção lógica. Embora a corrupção lógica seja rara, ela pode causar perda de dados. As cópias com retardamento são projetadas para evitar a perda de dados devido à corrupção lógica. Em geral, há dois tipos de dano lógico:

• Corrupção lógica do banco de dados: a soma de verificação das páginas do banco de dados corresponde, mas os dados nas páginas estão errados logicamente. Essa situação ocorre quando o ESE tenta gravar uma página de banco de dados. Embora o sistema operacional retorne uma mensagem de sucesso, os dados nunca são gravados no disco ou são gravados no local errado. Essa condição é conhecida como liberação perdida. Para evitar que liberações perdidas percam dados, o ESE inclui um mecanismo de detecção de liberação perdida no banco de dados com um recurso de aplicação de patch de página (restauração de página única).

• Corrupção lógica da loja: os dados são adicionados, excluídos ou manipulados de uma forma que o usuário não espera. Aplicativos que não são da Microsoft geralmente causam esses casos. Geralmente é considerada corrupção no sentido de que o usuário a vê como corrupção. O repositório do Exchange considera a transação que produziu o dano lógico uma série de operações MAPI válidas. O recurso de retenção de litígio no Exchange Server fornece proteção contra corrupção lógica de armazenamento (porque impede que o conteúdo seja excluído permanentemente por um usuário ou aplicativo). No entanto, pode haver cenários em que uma caixa de correio do usuário fica tão corrompida que seria mais fácil restaurar o banco de dados para um ponto no tempo antes da corrupção e, em seguida, exportar a caixa de correio do usuário para recuperar dados não corrompidos.

A combinação das cópias de banco de dados, da diretiva de guarda e da restauração de página única do ESE deixa apenas o caso de dano lógico raro, mas catastrófico, do repositório. Sua decisão de usar uma cópia de banco de dados com retardo de repetição (cópia com retardamento) depende de quais aplicativos que não são da Microsoft você usa e do histórico da sua organização com corrupção lógica de repositório.

Se você optar por usar cópias com retardamento, lembre-se das seguintes implicações quanto ao uso:

• O tempo de retardo de repetição é um valor configurado pelo administrador. Por padrão, o tempo de retardo de repetição está desabilitado.

• A configuração de tempo de retardo de repetição tem uma configuração padrão de zero dias e uma configuração máxima de 14 dias.

• As cópias com retardamento não são consideradas cópias altamente disponíveis. Em vez disso, eles são projetados para fins de recuperação de desastres, para proteger contra a corrupção lógica da loja.

• Quanto maior for o tempo de retardo de repetição definido, mais longo será o processo de recuperação do banco de dados. Pode levar várias horas para recuperar um banco de dados devido a:

  • O número de arquivos de log a serem reproduzidos.
  • A velocidade na qual seu hardware pode reproduzi-los.

• Recomendamos que você determine se as cópias com retardamento são críticas para a estratégia de recuperação de desastre geral. Se o uso deles for crítico à estratégia, recomendamos o uso de várias cópias com retardamento ou o uso de uma RAID (Redundant Array of Independent Disks) para proteger uma única cópia com retardamento, se você não tiver várias cópias com retardamento. Se perder um disco ou ocorrer um dano, você não perderá o ponto com retardamento.

• Cópias com retardamento não podem ser corrigidas com o recurso de restauração de página única ESE. Se uma cópia retardada encontrar corrupção de página de banco de dados (por exemplo, um erro -1018), a cópia precisará ser propagada novamente. A nova propagação perde o aspecto defasado da cópia.

Se você quiser que o banco de dados reproduza todos os arquivos de log e torne a cópia do banco de dados atual, ativar e recuperar uma cópia de banco de dados de caixa de correio com retardamento é um processo fácil. Se quiser reproduzir arquivos de log até um determinado momento, o processo será mais difícil, pois será necessário manipular manualmente os arquivos de log e executar Exchange Server Utilitários de Banco de Dados (Eseutil.exe).

Para obter etapas detalhadas sobre como ativar uma cópia de banco de dados de caixa de correio com retardamento, consulte Ativar uma cópia de banco de dados de caixa de correio com retardamento.

Tempo de retardo de truncamento

O tempo de retardo de truncamento é a propriedade de uma cópia de banco de dados de caixa de correio que especifica o tempo em minutos para atrasar a exclusão do log para a cópia de banco de dados depois que o arquivo de log tiver sido reproduzido na cópia de banco de dados. O cronômetro do retardo de truncamento se inicia quando um arquivo de log é replicado para a cópia passiva e passa com êxito pela inspeção, além de ser repetido com êxito na cópia do banco de dados. Atrasando o truncamento dos logs da cópia de banco de dados, você tem a possibilidade de se recuperar de falhas que afetam os arquivos de log para a cópia ativa do banco de dados.

Cópias de banco de dados e truncamento de log

O truncamento de log funciona da mesma forma no Exchange 2016 e no Exchange 2019 como no Exchange 2010. O comportamento do truncamento é determinado pelas configurações do tempo de retardo de repetição e do tempo de retardo de truncamento da cópia.

Os seguintes critérios deverão ser atendidos para que um arquivo de log do banco de dados seja truncado quando as configurações do retardo forem deixadas em valores-padrão iguais a zero (desabilitadas):

• O backup do arquivo de log é feito com êxito ou o registro circular é habilitado.
• O arquivo de log deve estar abaixo do ponto de verificação (o arquivo de log mínimo obrigatório à recuperação) para o banco de dados.
• Todas as outras cópias com retardamento inspecionaram o arquivo de log.
• Todas as outras cópias (exceto cópias com retardamento) reproduziram o arquivo de log.

Os seguintes critérios devem ser atendidos para que ocorra o truncamento de uma cópia de banco de dados com retardamento:

• O arquivo de log deve estar abaixo do ponto de verificação do banco de dados.
• O arquivo de log deve ser anterior a ReplayLagTime + TruncationLagTime.
• O arquivo de log é truncado na cópia ativa.

No Exchange Server, o truncamento de log não ocorre em uma cópia de banco de dados de caixa de correio ativa quando uma ou mais cópias passivas são suspensas. Se as atividades de manutenção planejadas levarem um longo período de tempo (por exemplo, vários dias), você poderá ter um acúmulo considerável de arquivos de log. Para evitar que a unidade de log fiquei cheia de logs de transação, você pode remover a cópia do banco de dados passiva afetada, ao invés de suspendê-la. Quando a manutenção planejada estiver concluída, você pode readicionar a cópia do banco de dados passiva.

O Exchange Server agora tem um recurso chamado truncamento flexível que está desabilitado por padrão. Durante as operações normais, cada cópia de banco de dados mantém os logs que precisam ser enviados para outras cópias de banco de dados até que todas as cópias de um banco de dados sejam confirmadas:

• Eles reproduziram os arquivos de log (cópias passivas).
• Eles receberam os arquivos de log (cópias com atraso).

Esse é o comportamento padrão de truncamento de log. Se uma cópia do banco de dados ficar offline por algum motivo, os arquivos de log começam a se acumular nos discos usados pelas outras cópias do banco de dados. Se a cópia do banco de dados afetada continuar offline por um longo período, isto fará com que as demais cópias do banco de dados fiquem sem espaço em disco.

O comportamento do truncamento é diferente quando o truncamento flexível e o registro circular estão habilitados. Cada cópia de banco de dados rastreia seu próprio espaço livre em disco e aplica o comportamento de truncamento flexível caso o espaço livre seja reduzido.

• Para a cópia ativa, a cópia isolada mais antiga (a cópia de banco de dados passiva que está mais longe da reprodução do log) é ignorada e o truncamento respeita as cópias passivas mais antigas restantes. A cópia do banco de dados ativa é onde o truncamento global é calculado.

• Para uma cópia passiva, se o espaço ficar baixo, ela truncará independentemente seus arquivos de log usando os parâmetros configurados descritos posteriormente na tabela Valor do Registro. As cópias passivas tentam respeitar a decisão de truncamento tomada na cópia ativa. Apesar da implicação do nome MinCopiesToProtect, o Exchange ignora apenas o retardatário mais antigo conhecido no momento em que o truncamento é executado.

Quando o banco de dados offline é colocado online novamente, seus arquivos de log ausentes são excluídos das outras cópias íntegras e seu status de cópia de banco de dados é FailedAndSuspended. Neste caso, se o Autoreseed estiver configurado, a cópia afetada será automaticamente redistribuída. Se o Autoreseed não estiver configurado, a cópia do banco de dados precisará ser propagada manualmente por um administrador.

Se o log circular estiver desabilitado, o truncamento flexível respeitará todos os backups feitos. O truncamento flexível não remove os arquivos de log que não têm backup.

O truncamento é um recurso recomendado para a arquitetura preferencial em que os backups não são usados e o registro circular está habilitado.

A quantidade necessária de cópias íntegras, o limite de espaço livre em disco e a quantidade de logs que deve ser mantida são parâmetros que podem ser configurados. Por padrão, o limite de espaço livre em disco é de 204800 MB (200 GB) e a quantidade de logs a manter é de 100.000 (100 GB) para cópias passivas e de 10.000 (10 GB) para cópias ativas.

A habilitação do truncamento flexível e a configuração dos parâmetros de truncamento flexível são obtidas pela edição do Registro do Windows em cada membro do DAG. Há três valores do registro que podem ser configurados que são armazenados em HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. A chave BackupInformation Os seguintes valores DWORD não existem por padrão e devem ser criados manualmente. Os valores do Registro DWORD em BackupInformation são descritos na tabela abaixo:

Ao usar o valor do Registro LooseTruncation_MinLogsToProtect, o comportamento é diferente para cópias de banco de dados ativas e passivas

• Ativo: o número de logs extras retidos antes dos logs exigidos pelas cópias passivas protegidas e o intervalo necessário da cópia ativa.
• Passivo: o número de logs mantidos do log mais recente disponível. Um décimo desse número também é usado para manter logs antes do intervalo necessário dessa cópia passiva.

Os dois limites estão em vigor para garantir que as cópias de banco de dados com retardamento não ocupem muito espaço, já que o intervalo necessário geralmente é muito grande.

Política de ativação do banco de dados

Há cenários em que você pode querer criar uma cópia do banco de dados da caixa de correio e impedir que o sistema ative automaticamente essa cópia. Por exemplo, após uma falha:

• Você implanta uma ou mais cópias de banco de dados de caixa de correio em um datacenter alternativo ou em espera.
• Você configura uma cópia de banco de dados com retardamento para fins de recuperação.
• Você está fazendo uma manutenção ou uma atualização do servidor.

Em cada um dos cenários anteriores, você tem cópias de banco de dados que não deseja que o sistema ative automaticamente. Para impedir que o sistema ative automaticamente uma cópia de banco de dados de caixa de correio, é possível configurar a cópia a ser bloqueada (suspensa) para ativação.

Essa configuração permite que o sistema mantenha a moeda do banco de dados por meio do envio e da reprodução de logs, mas impede que o sistema ative e use automaticamente a cópia. Um administrador deve ativar manualmente as cópias bloqueadas para ativação.

Você pode definir o parâmetro DatabaseCopyAutoActivationPolicy como Bloqueado para:

• Um servidor inteiro usando o cmdlet Set-MailboxServer .
• Uma cópia de banco de dados individual usando o cmdlet Set-MailboxDatabaseCopy .

Para mais informações sobre como configurar a diretiva de ativação do banco de dados, consulte Configurar a política de ativação para uma cópia do banco de dados de caixa de correio.

Efeito das movimentações de caixa de correio sobre a replicação contínua

Em um banco de dados de caixa de correio com uma taxa alta de geração de log, há uma chance maior de perda de dados se a replicação das cópias de banco de dados passivas não conseguir acompanhar a geração do log. Um cenário que pode incluir uma alta taxa de geração de log é a movimentação de caixa de correio. O Exchange Server inclui uma API de Garantia de Dados que é usada por serviços como o Serviço de Replicação de Caixa de Correio do Exchange (MRS) para marcar a integridade da arquitetura de cópia de banco de dados com base no valor do parâmetro DataMoveReplicationConstraint que foi definido pelo sistema ou por um administrador. Especificamente, a API de Garantia de Dados pode ser usada para:

• Verificar integridade da replicação: confirma se o número de pré-requisitos de cópias de banco de dados está disponível.

• Verificar liberação de replicação: confirma se os arquivos de log necessários são repetidos em relação ao número de pré-requisito de cópias de banco de dados.

Quando executada, a API retorna as seguintes informações de status para o aplicativo fazendo a chamada:

• Repetir: significa que há erros transitórios que impedem que uma condição seja verificada no banco de dados.

• Satisfeito: significa que o banco de dados atende às condições necessárias ou o banco de dados não é replicado.

• NotSatisfied: significa que o banco de dados não atende às condições necessárias. Além disso, as informações são fornecidas ao aplicativo fazendo a chamada em relação a por que a resposta NotSatisfied foi retornada.

O valor do parâmetro DataMoveReplicationConstraint para o banco de dados da caixa de correio determina quantas cópias de banco de dados devem ser avaliadas como parte da solicitação. O parâmetro DataMoveReplicationConstraint tem os seguintes valores possíveis:

• None: Quando você cria um banco de dados de caixa de correio, esse valor é definido por padrão. Quando esse valor é definido, as condições da API de Garantia de Dados são ignoradas. Essa configuração deve ser usada apenas para bancos de dados de caixa de correio que não são replicados.

• SecondCopy: esse é o valor padrão quando você adiciona a segunda cópia de um banco de dados de caixa de correio. Quando esse valor é definido, pelo menos uma cópia de banco de dados passiva deve atender às condições de API de Garantia de Dados.

• SecondDatacenter: quando esse valor é definido, pelo menos uma cópia de banco de dados passiva em outro site do Active Directory deve atender às condições da API de Garantia de Dados.

• AllDatacenters: quando esse valor é definido, pelo menos uma cópia de banco de dados passiva em cada site do Active Directory deve atender às condições da API de Garantia de Dados.

• AllCopies: quando esse valor é definido, todas as cópias do banco de dados de caixa de correio devem atender às condições da API de Garantia de Dados.

Verificar a Integridade da Replicação

Quando a API de Garantia de Dados é executada para avaliar a integridade da infraestrutura da cópia de banco de dados, vários itens são avaliados.

Em todos os cenários, a cópia de banco de dados passiva deve atender às seguintes condições:

• Estar íntegra.

• Ter uma fila de repetição dentro de 10 minutos do tempo de retardo de repetição.

• Ter um comprimento de fila de cópia de menos de 10 logs.

• Ter um comprimento média de fila de cópia de menos de 10 logs. O comprimento médio da fila de cópias é calculado com base no número de vezes que o aplicativo consultou o status do banco de dados.

Verificar Despejo de Replicação

A API de Garantia de Dados também pode ser usada para validar que um número de pré-requisito de cópias de banco de dados tenham repetido os logs de transação requeridos. Isso é verificado comparando o último carimbo de data/hora repetido do log com o carimbo de data/hora de confirmação do serviço de chamada (na maioria dos casos, é o carimbo de data/hora do último arquivo de log que contém os dados necessários) mais cinco segundos extras (para lidar com distorções ou descompassos do relógio do sistema). Se o carimbo de data/hora de repetição for maior que o carimbo de data/hora da confirmação, o parâmetro DataMoveReplicationConstraint será satisfeito. Se o carimbo de data/hora de repetição for menor que o carimbo de data/hora da confirmação, o DataMoveReplicationConstraint não será satisfeito.

Antes de mover um grande número de caixas de correio de ou para bancos de dados de replicação em um DAG, recomendamos que você configure o parâmetro DataMoveReplicationConstraint em cada banco de dados de caixa de correio de acordo com a seguinte tabela:

Balancear cópias de banco de dados

Devido à natureza inerente dos DAGs, como resultado de alternâncias e failovers de banco de dados, as cópias de banco de dados de caixa de correio ativas mudam de host várias vezes ao longo da vida útil de um DAG. Como resultado, os DAGs podem se tornar desbalanceados em termos de distribuição de cópia de banco de dados de caixa de correio ativa. A tabela a seguir mostra um exemplo de DAG que tem quatro bancos de dados com quatro cópias de cada banco de dados (para um total de 16 bancos de dados em cada servidor) com uma distribuição irregular de cópias de banco de dados ativas.

No exemplo anterior, há quatro cópias de cada banco de dados e, por isso, somente quatro valores possíveis para preferência de ativação (1, 2, 3 ou 4). A coluna Lista de contagem de preferência mostra a contagem do número de bancos de dados com cada um desses valores. Por exemplo, em EX3, há 13 cópias de bancos de dados com uma preferência de ativação de 1, duas cópias com uma preferência de ativação de 2, uma cópia com uma preferência de ativação de 3 e nenhuma cópia com uma preferência de ativação de 4.

Como é possível ver, esse DAG não é balanceado em termos do número de bancos de dados ativos hospedados por todos os membros do DAG, o número de bancos de dados passivos hospedados pelos membros do DAG ou a contagem de preferência de ativação dos bancos de dados hospedados.

Você pode usar o script RedistributeActiveDatabases.ps1 para equilibrar as cópias de banco de dados de caixas de correio ativas em um DAG. Esse script move bancos de dados entre suas cópias em uma tentativa de equilibrar o número de bancos de dados montados em cada servidor do DAG. Se necessário, o script também tentará equilibrar os bancos de dados ativos entre sites.

O script fornece duas opções para balancear cópias de banco de dados ativas em um DAG:

• BalanceDbsByActivationPreference: quando essa opção é especificada, o script tenta mover os bancos de dados para sua cópia preferencial (com base na preferência de ativação) sem considerar o site do Active Directory.

• BalanceDbsBySiteAndActivationPreference: quando essa opção é especificada, o script tenta mover bancos de dados ativos para sua cópia preferida, ao mesmo tempo em que tenta equilibrar bancos de dados ativos em cada site do Active Directory.

Após executar o script com a primeira opção, o DAG anterior desbalanceado se tornará balanceado, como mostrado na seguinte tabela.

Como mostrado na tabela anterior, esse DAG está agora balanceado em termos do número de bancos de dados ativos e passivos em cada servidor e preferência de ativação nos servidores.

A tabela a seguir lista os parâmetros disponíveis para o script RedistributeActiveDatabases.ps1.

Exemplos de RedistributeActiveDatabases.ps1

Esse exemplo mostra a distribuição de banco de dados para um DAG, incluindo a lista de contagem de preferência.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

Esse exemplo redistribui e balanceia as cópias de banco de dados de caixa de correio ativas em um DAG usando a preferência de ativação sem solicitar uma entrada.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

Esse exemplo redistribui e balanceia as cópias de banco de dados de caixa de correio ativas em um DAG usando a preferência de ativação e produz um resumo da distribuição.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Monitorar cópias de banco de dados

Você pode exibir várias informações, incluindo o comprimento de filas de cópia, comprimento da fila de repetição, informações de estado de status e índice de conteúdo, examinando os detalhes de uma cópia de banco de dados no EAC. Você também pode usar o cmdlet Get-MailboxDatabaseCopyStatus no Shell de Gerenciamento do Exchange para exibir uma variedade de informações de status para uma cópia de banco de dados.

Para obter mais informações sobre como monitorar cópias de banco de dados, consulte Monitorar grupos de disponibilidade de banco de dados.

Remover uma cópia de banco de dados

Uma cópia de banco de dados pode ser removida a qualquer momento usando o EAC ou usando o cmdlet Remove-MailboxDatabaseCopy no Shell de Gerenciamento do Exchange. Após remover uma cópia de banco de dados, você precisará excluir manualmente todos os arquivos de log de transações e de banco de dados do servidor do qual a cópia de banco de dados está sendo removida. Para obter etapas detalhadas sobre como remover uma cópia de um banco de dados, consulte Remover uma cópia do banco de dados de caixa de correio.

Alternâncias de banco de dados

O servidor de Caixa de Correio que hospeda a cópia ativa de um banco de dados é conhecido como o banco de dados de caixa de correio mestre. O processo de ativação de uma cópia de banco de dados passiva altera o banco de dados de caixa de correio mestre do banco de dados e transforma a cópia passiva na nova cópia ativa. Esse processo é chamado de alternância de banco de dados. Em uma alternância de banco de dados, a cópia ativa de um banco de dados é desmontada em um servidor de Caixa de Correio e uma cópia passiva desse banco de dados é montada como o novo banco de dados de caixa de correio ativo em outro servidor de Caixa de Correio. Ao realizar uma alternância, também é possível substituir a configuração da discagem automática de montagem do banco de dados no novo banco de dados de caixa de correio mestre.

É possível identificar rapidamente que servidor de Caixa de Correio é o banco de dados de caixa de correio mestre atual revisando-se a coluna da direita na guia Cópias de Banco de Dados no EAC. Você pode executar uma alternância usando o link Ativar no EAC ou usando o cmdlet Move-ActiveMailboxDatabase no Shell de Gerenciamento do Exchange.

Há várias verificações internas executadas antes que uma cópia passiva seja ativada. Em alguns casos, a alternância de banco de dados é bloqueada ou cancelada. Em outros casos, você pode usar cmdlets para mover ou ignorar algumas verificações.

• O status da cópia de banco de dados é verificado. Se a cópia de banco de dados estiver em um estado com falha, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar a marca de integridade usando o parâmetro SkipHealthChecks do cmdlet Move-ActiveMailboxDatabase. Esse parâmetro permite mover a cópia ativa para uma cópia de banco de dados em um estado de falha.

• A cópia do banco de dados ativo é verificada para saber se ela é uma fonte de propagação para quaisquer cópias passivas do banco de dados. Se a cópia ativa estiver sendo usada como uma fonte para a propagação, a alternância é bloqueada. Você pode substituir esse comportamento e ignorar a marca de origem de propagação usando o parâmetro SkipActiveCopyChecks do cmdlet Move-ActiveMailboxDatabase. Esse parâmetro permite que você mova uma cópia ativa que está sendo usada como uma fonte de propagação. O uso desse parâmetro faz com que a operação de propagação seja cancelada e considerada com falha.

• Os comprimentos da fila de cópia e da fila de repetição para a cópia de banco de dados são verificados para assegurar-se de que os valores estejam dentro dos critérios configurados. Além disso, a cópia de banco de dados é verificada para assegurar-se de que ela não esteja em uso como uma origem para propagação. Se os valores dos comprimentos das filas estiverem fora dos critérios configurados ou se o banco de dados estiver sendo usado como uma origem para propagação, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar essas verificações usando o parâmetro SkipLagChecks do cmdlet Move-ActiveMailboxDatabase . Esse parâmetro permite a ativação de uma cópia com filas de repetição e cópia fora dos critérios configurados.

• O estado do catálogo de pesquisa (índice do conteúdo) da cópia de banco de dados é verificado. Se o catálogo de pesquisa não estiver atualizado, estiver em um estado não íntegro ou estiver corrompido, a alternância será bloqueada. Você pode substituir esse comportamento e ignorar a marca do catálogo de pesquisa usando o parâmetro SkipClientExperienceChecks do cmdlet Move-ActiveMailboxDatabase. Esse parâmetro faz essa pesquisa ignorar a verificação da integridade do catálogo. Se o catálogo de pesquisa da cópia de banco de dados que você está ativando estiver em um estado não íntegro ou inutilizável e você usar esse parâmetro para ignorar a marca de integridade do catálogo e ativar a cópia de banco de dados, será necessário rastrear ou propagar o catálogo de pesquisa novamente.

Ao executar uma alternância de banco de dados, você também tem a opção de substituir as configurações de discagem de montagem configuradas para o servidor que hospeda a cópia de banco de dados passiva que está sendo ativada. Usar o parâmetro MountDialOverride do cmdlet Move-ActiveMailboxDatabase instrui o servidor de destino a substituir suas próprias configurações de discagem de montagem e usar as configurações especificadas pelo parâmetro MountDialOverride .

Para instruções detalhadas sobre como realizar uma alternância de uma cópia de banco de dados, consulte Ativar uma cópia do banco de dados de caixa de correio.