Gerir cópias da base de dados da caixa de correio

APLICA-SE A:2016 2019 Subscription Edition

No Exchange Server, pode utilizar o Console de Gerenciamento do Exchange (EAC) ou a Shell de Gestão do Exchange para adicionar cópias da base de dados da caixa de correio após a criação, configuração e povoação de um grupo de disponibilidade de base de dados (DAG) com membros do servidor da Caixa de Correio.

Gerenciar cópias de banco de dados

Após a criação de várias cópias de uma base de dados, pode utilizar o EAC ou a Shell de Gestão do Exchange para efetuar as seguintes tarefas:

• Monitorize o estado de funcionamento e status de cada cópia.
• Efetue outras tarefas de gestão associadas a cópias de bases de dados. Por exemplo:
  • Suspender ou retomar uma cópia da base de dados.
  • Propagar uma cópia da base de dados.
  • Monitorizar cópias da base de dados.
  • Configurar as definições de cópia da base de dados
  • Remover uma cópia da base de dados.

Suspender e retomar cópias de banco de dados

Por vários motivos, como a realização da manutenção planeada, poderá ter de suspender e retomar a atividade de replicação contínua para uma cópia da base de dados. Além disso, algumas tarefas administrativas, como a propagação, exigem que suspenda primeiro uma cópia da base de dados. Recomendamos que suspenda toda a atividade de replicação quando o caminho da base de dados ou os respetivos ficheiros de registo estiverem a ser alterados. Pode suspender e retomar a atividade de cópia da base de dados com o EAC ou ao executar os cmdlets Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy na Shell de Gestão 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 uma base de dados em branco ou uma cópia da base de dados de produção é adicionada à localização de cópia de destino noutro servidor da Caixa de Correio no mesmo DAG que a base de dados ativa. Esta base de dados torna-se a base de dados de linha de base da cópia mantida por esse servidor.

Consoante a situação, pode propagar uma base de dados através de um processo automático ou de um processo manual que inicia. Quando é adicionada uma cópia de base de dados, a cópia é propagada automaticamente se o servidor de destino e o respetivo armazenamento estiverem configurados corretamente. Para propagar manualmente uma cópia de base de dados e não pretender que a propagação automática ocorra ao criar a cópia, pode utilizar o parâmetro SeedingPostponed no cmdlet Add-MailboxDatabaseCopy .

As cópias da base de dados raramente precisam de ser reseedidas após a propagação inicial. No entanto, se for necessário efetuar a nova semente ou para propagar manualmente uma cópia da base de dados em vez de ter o sistema a propagar automaticamente, tem duas opções:

• Utilize o assistente Atualizar Cópia da Base de Dados da Caixa de Correio no EAC.
• Utilize o cmdlet Update-MailboxDatabaseCopy na Shell de Gestão 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 seed manual, a replicação da cópia da base de dados da caixa de correio propagada é retomada automaticamente. Se não quiser que a replicação seja retomada automaticamente, pode utilizar o parâmetro ManualResume no cmdlet Update-MailboxDatabaseCopy .

Escolher o que propagar

Quando efetua uma operação de seed, pode optar por:

• Selecione a cópia da base de dados da caixa de correio.
• Selecione o catálogo de índices de conteúdos para a cópia da base de dados da caixa de correio.
• Selecione a cópia da base de dados e a cópia do catálogo de índices de conteúdos.

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 da base de dados da caixa de correio sem propagar o catálogo de índices de conteúdos, utilize o parâmetro DatabaseOnly no cmdlet Update-MailboxDatabaseCopy .

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

Selecionar a fonte da propagação

Pode utilizar qualquer cópia de base de dados em bom estado de funcionamento como a origem de propagação para outra cópia dessa base de dados. Esta opção é particularmente útil quando tem um DAG expandido em várias localizações físicas.

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

• MBX1 e MBX2 estão localizados em Portland, Oregon.
• MBX3 e MBX4 estão localizados em Nova Iorque, Nova Iorque.
• Uma base de dados de caixa de correio com o nome DB1 está ativa no MBX1.
• Existem cópias passivas de DB1 em MBX2 e MBX3.

Ao adicionar uma cópia de DB1 a MBX4, pode utilizar a cópia em MBX3 como a origem para propagação. Esta opção evita a propagação através da ligação de rede alargada (WAN) entre Portland e Nova Iorque.

Para utilizar uma cópia específica como origem para propagação ao adicionar uma nova cópia da base de dados, pode efetuar os seguintes passos:

• Utilize o parâmetro SeedingPostponed no cmdlet Add-MailboxDatabaseCopy para adicionar a cópia da base de dados. Caso contrário, a cópia da base de dados é explicitamente propagada através da cópia ativa da base de dados como a origem.

• Pode especificar o servidor de origem a utilizar no assistente Atualizar Cópia da Base de Dados da Caixa de Correio no EAC ou pode utilizar o parâmetro SourceServer no cmdlet Update-MailboxDatabaseCopy para especificar o servidor de origem pretendido para propagação.

  No exemplo anterior, especificaria MBX3 como o servidor de origem. Caso contrário, a cópia da base de dados é explicitamente propagada da cópia ativa da base de dados.

Propagação e redes

Além de selecionar um servidor de origem específico para propagar uma cópia da base de dados da caixa de correio, também pode utilizar a Shell de Gestão do Exchange para especificar as redes DAG a utilizar. Pode substituir as definições de compressão e encriptação da rede DAG durante a operação de seed.

Pode especificar as redes a utilizar para propagação utilizando o parâmetro Rede no cmdlet Update-MailboxDatabaseCopy e especificar as redes DAG que pretende utilizar. Se não utilizar o parâmetro Rede , o sistema utiliza o seguinte comportamento predefinido para selecionar uma rede a utilizar 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, será utilizada a rede de replicação.

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

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

No nível do DAG, as redes do DAG são configuradas para criptografia e compactação. As predefinições utilizam encriptação e compressão apenas 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 predefinidos para Os parâmetros NetworkCompression e NetworkEncryption, pode substituir estes valores com os parâmetros NetworkCompressionOverride e NetworkEncryptionOverride no cmdlet Update-MailboxDatabaseCopy .

Processo de propagação

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

1. As propriedades da base de dados do Active Directory são lidas para validar a base de dados e os servidores especificados e para verificar se os servidores de origem e de destino estão a executar Exchange Server, são ambos membros do mesmo DAG e que a base de dados especificada não é uma base 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 passarem, ser-lhe-á pedido que confirme 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 Replicação do Microsoft Exchange atualiza as informações de estado da base de dados para refletir uma status de Propagação.

9. Se o servidor de destino ainda não tiver os diretórios da base de dados de destino e dos ficheiros de registo, estes são criados.

10. Um pedido TCP para propagar a base de dados é transmitido do serviço replicação do Microsoft Exchange no servidor de destino para o serviço de Replicação do Microsoft Exchange no servidor de origem. Este pedido e as comunicações subsequentes para propagar a base de dados ocorrem numa 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 Replicação do Microsoft Exchange no servidor de destino escreve a cópia da base de dados num diretório temporário localizado no diretório da base de dados principal denominado propagação temporária.

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 Replicação do Microsoft Exchange solicita as informações de diretório do serviço Pesquisa do Microsoft Exchange e pede 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 Replicação do Microsoft Exchange no servidor de destino escreve os dados do catálogo num 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. Também pode utilizar os cmdlets Get-MailboxDatabase e Set-MailboxDatabaseCopy na Shell de Gestão do Exchange para ver e configurar as definições de cópia da base de dados. Por exemplo, tempo de desfasamento da repetição, tempo de atraso da truncagem 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. Uma vez que ambas as funcionalidades resultam na acumulação temporária de ficheiros de registo, a utilização de qualquer uma delas afeta a estrutura de armazenamento.

Tempo de retardo de repetição

O tempo de atraso de repetição é uma propriedade de cópia da base de dados da caixa de correio que especifica a quantidade de tempo, em minutos, para atrasar a repetição do registo da cópia da base de dados. O temporizador de atraso de repetição é iniciado quando um ficheiro de registo é replicado para a cópia passiva e passa com êxito a inspeção. 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 da base de dados da caixa de correio configurada com um tempo de atraso de repetição superior a zero é referida como uma cópia de base de dados de caixa de correio com atraso ou simplesmente uma cópia com atraso.

Uma estratégia que utiliza cópias de base de dados e as funcionalidades de retenção de litígios no Exchange Server pode fornecer proteção contra uma série de falhas que normalmente causariam perda de dados. No entanto, estas funcionalidades não podem fornecer proteção contra a perda de dados devido a danos lógicos. Embora os danos lógicos sejam raros, podem causar perda de dados. As cópias com atraso foram concebidas para evitar a perda de dados devido a danos lógicos. Em geral, há dois tipos de dano lógico:

• Danos lógicos na base de dados: a soma de verificação das páginas da base de dados corresponde, mas os dados nas páginas estão errados logicamente. Esta situação ocorre quando o ESE tenta escrever uma página de base de dados. Embora o sistema operativo devolva uma mensagem de êxito, os dados nunca são escritos no disco ou são escritos no local errado. Esta condição é referida como uma descarga 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).

• Armazenar danos lógicos: os dados são adicionados, eliminados ou manipulados de uma forma que o utilizador não espera. Geralmente, as aplicações que não são da Microsoft causam estes casos. Geralmente, considera-se corrupção no sentido em que o utilizador 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. A funcionalidade de retenção de litígios no Exchange Server fornece proteção contra danos lógicos no arquivo (porque impede que o conteúdo seja eliminado permanentemente por um utilizador ou aplicação). No entanto, podem existir cenários em que uma caixa de correio de utilizador fica tão danificada que seria mais fácil restaurar a base de dados para um ponto anterior no tempo antes dos danos e, em seguida, exportar a caixa de correio do utilizador para obter dados não registados.

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. A decisão de utilizar uma cópia de base de dados com um atraso de repetição (uma cópia atrasada) depende das aplicações que não são da Microsoft que utiliza e do histórico da sua organização com danos lógicos armazenados.

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

• O tempo de desfasamento da repetição é um valor configurado pelo administrador. Por predefinição, o tempo de desfasamento da repetição está desativado.

• A definição de tempo de atraso de repetição tem uma predefinição de zero dias e uma definição máxima de 14 dias.

• As cópias com retardamento não são consideradas cópias altamente disponíveis. Em vez disso, foram concebidos para fins de recuperação após desastre, para proteger contra danos lógicos armazenados.

• Quanto maior for o tempo de retardo de repetição definido, mais longo será o processo de recuperação do banco de dados. A recuperação de uma base de dados pode demorar várias horas devido a:

  • O número de ficheiros de registo a reproduzir.
  • A velocidade a que o 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.

• As cópias com atraso não podem ser corrigidas com a funcionalidade de restauro de página única do ESE. Se uma cópia com atraso encontrar danos na página da base de dados (por exemplo, um erro -1018), a cópia tem de ser novamente selecionada. A reseeding perde o aspeto atrasado da cópia.

Se quiser que a base de dados reproduza todos os ficheiros de registo e torne a cópia da base de dados atual, ativar e recuperar uma cópia da base de dados da caixa de correio atrasada é um processo fácil. Se quiser reproduzir ficheiros de registo até um ponto específico no tempo, o processo é mais difícil porque tem de manipular manualmente ficheiros de registo e executar Exchange Server Utilitários da Base de Dados (Eseutil.exe).

Para obter passos detalhados sobre como ativar uma cópia de base de dados de caixa de correio com atraso, consulte Ativar uma cópia da base de dados da caixa de correio com atraso.

Tempo de retardo de truncamento

O tempo de atraso da truncagem é a propriedade de uma cópia da base de dados da caixa de correio que especifica o tempo em minutos para atrasar a eliminação do registo da cópia da base de dados depois de o ficheiro de registo ter sido reproduzido na cópia da base 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

A truncagem de registos 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 ficheiro de registo tem uma cópia de segurança bem-sucedida ou o registo circular está ativado.
• 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 atraso inspecionaram o ficheiro de registo.
• Todas as outras cópias (exceto cópias atrasadas) reproduziram o ficheiro de registo.

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 ficheiro de registo está truncado na cópia ativa.

No Exchange Server, a truncagem de registos não ocorre numa cópia de base de dados de caixa de correio ativa quando uma ou mais cópias passivas são suspensas. Se as atividades de manutenção planeada demorarem um longo período de tempo (por exemplo, vários dias), poderá ter uma acumulação considerável de ficheiros de registo. 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.

Exchange Server agora tem uma funcionalidade chamada truncagem solta que está desativada por predefinição. Durante as operações normais, cada cópia da base de dados mantém os registos que têm de ser enviados para outras cópias da base de dados até que todas as cópias de uma base de dados confirmem:

• Reproduziram os ficheiros de registo (cópias passivas).
• Receberam os ficheiros de registo (cópias atrasadas).

Este comportamento é o comportamento de truncagem de registos predefinido. 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 da truncagem é diferente quando a truncagem solta e o registo circular estão ativados. 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, trunca independentemente os respetivos ficheiros de registo com os parâmetros configurados descritos posteriormente na tabela Valor do Registo. 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 mais antigo dispositivo conhecido no momento em que a truncagem é executada.

Quando a base de dados offline é colocada novamente online, os ficheiros de registo em falta são eliminados das outras cópias em bom estado de funcionamento e a cópia da base de dados status é FailedAndSuspended. Neste evento, se Autoreseed estiver configurado, a cópia afetada é automaticamente reativada. Se Autoreseed não estiver configurado, a cópia da base de dados tem de ser propagada manualmente por um administrador.

Se o registo circular estiver desativado, a truncagem solta respeita todas as cópias de segurança efetuadas. A truncagem solta não remove os ficheiros de registo que não têm cópias de segurança.

A truncagem é uma funcionalidade recomendada para a arquitetura preferencial onde as cópias de segurança não são utilizadas e o registo circular está ativado.

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 predefinição e têm de ser criados manualmente. Os valores do Registro DWORD em BackupInformation são descritos na tabela abaixo:

Ao utilizar o valor do registo LooseTruncation_MinLogsToProtect, o comportamento é diferente para cópias de bases de dados ativas e passivas

• Ativo: o número de registos adicionais retidos antes desses registos exigidos pelas cópias passivas protegidas e o intervalo necessário da cópia ativa.
• Passivo: o número de registos mantidos a partir do registo disponível mais recente. Um décimo deste número também é utilizado para manter os registos antes do intervalo necessário desta cópia passiva.

Os dois limites estão implementados para garantir que as cópias da base de dados atrasadas não ocupam demasiado espaço, uma vez que o intervalo necessário é normalmente muito grande.

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

Existem cenários em que poderá querer criar uma cópia da base de dados da caixa de correio e impedir que o sistema ative automaticamente essa cópia. Por exemplo, após uma falha:

• Implementa uma ou mais cópias de base de dados de caixa de correio num datacenter alternativo ou de reserva.
• Configure uma cópia de base de dados com atraso para fins de recuperação.
• Está a fazer 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.

Esta configuração permite que o sistema mantenha a moeda da base de dados através do envio e repetição de registos, mas impede que o sistema ative e utilize automaticamente a cópia. Um administrador tem de ativar manualmente cópias bloqueadas para ativação.

Pode definir o parâmetro DatabaseCopyAutoActivationPolicy como Bloqueado para:

• Um servidor inteiro com o cmdlet Set-MailboxServer .
• Uma cópia de base de dados individual com 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. Exchange Server inclui uma API de Garantia de Dados utilizada por serviços como o Serviço de Replicação da Caixa de Correio do Exchange (MRS) para marcar o estado de funcionamento da arquitetura de cópia da base 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 o estado de funcionamento da replicação: confirma que o número de pré-requisitos das cópias da base de dados está disponível.

• Verificar a eliminação da cache da replicação: confirma que os ficheiros de registo necessários são reproduzidos em relação ao número de pré-requisitos de cópias da base de dados.

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

• Repetição: significa que existem erros transitórios que impedem que uma condição seja verificada na base de dados.

• Satisfeito: significa que a base de dados cumpre as condições necessárias ou que a base de dados não é replicada.

• NotSatisfied: significa que a base de dados não cumpre as 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 a base de dados da caixa de correio determina quantas cópias da base de dados devem ser avaliadas como parte do pedido. O parâmetro DataMoveReplicationConstraint tem os seguintes valores possíveis:

• None: quando cria uma base de dados de caixa de correio, este valor é definido por predefiniçã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: este é o valor predefinido quando adiciona a segunda cópia de uma base 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 este valor é definido, pelo menos uma cópia passiva da base de dados noutro site do Active Directory tem de cumprir as condições da API de Garantia de Dados.

• AllDatacenters: quando este valor é definido, pelo menos uma cópia passiva da base de dados em cada site do Active Directory tem de cumprir as condições da API de Garantia de Dados.

• AllCopies: quando este valor é definido, todas as cópias da base de dados da caixa de correio têm de cumprir as 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 passiva da base de dados tem de cumprir as 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ópia é calculado com base no número de vezes que a aplicação consultou a base de dados status.

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. Isto é verificado ao comparar o último carimbo de data/hora reproduzido do registo com o do carimbo de data/hora de consolidação do serviço de chamada (na maioria dos casos, este é o carimbo de data/hora do último ficheiro de registo que contém os dados necessários) mais cinco segundos adicionais (para lidar com distorções ou desvio do relógio de tempo do sistema). Se o carimbo de data/hora de repetição for maior do que o carimbo de data/hora de consolidação, o parâmetro DataMoveReplicationConstraint é cumprido. Se o carimbo de data/hora de repetição for inferior ao carimbo de data/hora da consolidação, o DataMoveReplicationConstraint não será satisfeito.

Antes de mover um grande número de caixas de correio de/para bases de dados de replicação num DAG, recomendamos que configure o parâmetro DataMoveReplicationConstraint em cada base 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 das ativações pós-falha e das ativações pós-falha das bases de dados, as cópias de bases de dados de caixas de correio ativas alteram os anfitriões várias vezes ao longo da duração 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 esta opção é especificada, o script tenta mover as bases de dados para a respetiva cópia preferida (com base na preferência de ativação) sem ter em conta o site do Active Directory.

• BalanceDbsBySiteAndActivationPreference: quando esta opção é especificada, o script tenta mover bases de dados ativas para a respetiva cópia preferida, ao mesmo tempo que tenta equilibrar as bases de dados ativas 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. Também pode utilizar o cmdlet Get-MailboxDatabaseCopyStatus na Shell de Gestão do Exchange para ver uma variedade de informações de status para uma cópia da base de dados.

Para obter mais informações sobre como monitorizar cópias de bases de dados, veja Monitorizar grupos de disponibilidade de bases de dados.

Remover uma cópia de banco de dados

Uma cópia de base de dados pode ser removida em qualquer altura com o EAC ou com o cmdlet Remove-MailboxDatabaseCopy na Shell de Gestão 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. Pode efetuar uma transição utilizando a ligação Ativar no EAC ou utilizando o cmdlet Move-ActiveMailboxDatabase na Shell de Gestão do Exchange.

Existem várias verificações internas efetuadas antes de uma cópia passiva ser ativada. Em alguns casos, a ativação da base de dados é bloqueada ou cancelada. Noutros casos, pode utilizar 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. Pode substituir este comportamento e ignorar a marcar de estado de funcionamento com o parâmetro SkipHealthChecks do cmdlet Move-ActiveMailboxDatabase. Este parâmetro permite-lhe mover a cópia ativa para uma cópia de base de dados num 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. Pode substituir este comportamento e ignorar o marcar de origem de propagação com 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. A utilização deste parâmetro faz com que a operação de propagação seja cancelada e considerada como falhada.

• 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. Pode substituir este comportamento e ignorar estas verificações com 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. Pode substituir este comportamento e ignorar o catálogo de pesquisa marcar com 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 da base de dados que está a ativar estiver num estado de mau estado de funcionamento ou inutilizável e utilizar este parâmetro para ignorar o estado de funcionamento do catálogo marcar e ativar a cópia da base de dados, terá de pesquisar ou propagar novamente o catálogo de pesquisa.

Quando efetua uma transição de base de dados, também tem a opção de substituir as definições de marcação de montagem configuradas para o servidor que aloja a cópia passiva da base de dados que está a ser ativada. A utilização do parâmetro MountDialOverride do cmdlet Move-ActiveMailboxDatabase instrui o servidor de destino a substituir as suas próprias definições de marcação de montagem e a utilizar as definiçõ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.