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

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2015-03-09

Mobilidade de banco de dados é uma nova arquitetura do Microsoft Exchange Server 2010 que remove o conceito de grupos de armazenamento e desvincula um banco de dados de caixa de correio do Exchange 2010 de um servidor Caixa de Correio. Como os grupos de armazenamento foram removidos do Exchange 2010, a replicação contínua agora funciona no nível do banco de dados. No Exchange 2010, os logs de transação são replicados para um ou mais servidores de Caixa de Correio e repetidos em uma ou mais cópias de um banco de dados de caixa de correio armazenado nesses servidores. Vários conceitos usados na replicação contínua do Exchange Server 2007 continuam no Exchange 2010. Eles incluem os conceitos de divergência, o uso da discagem automática de montagem do banco de dados e o uso de redes públicas e privadas.

Gerenciando cópias de banco de dados

Após a criação de várias cópias de um banco de dados, é possível usar o Console de Gerenciamento do Exchange (EMC) e o Shell de Gerenciamento do Exchange para monitorar a integridade e o status de cada cópia, além de realizar outras tarefas de gerenciamento associadas a cópias de banco de dados. Algumas das tarefas de gerenciamento que você talvez precise realizar incluem a suspensão ou a retomada de uma cópia de banco de dados, a propagação de uma cópia de banco de dados, o monitoramento de cópias de banco de dados, a configuração das definições da cópia de banco de dados e a remoção da cópia de banco de dados.

Suspendendo e retomando cópias de banco de dados

Por várias razões, como realizaçã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 a propagação, exigem que você primeiro suspenda a cópia do banco de dados. Também recomendamos suspender toda a atividade de replicação quando o caminho do banco de dados ou dos arquivos de log estiver sendo alterado. É possível suspender e retomar a atividade de cópia de banco de dados usando o EMC ou executando os cmdlets Suspend-DatabaseCopy e Resume-DatabaseCopy no Shell. Para instruções detalhadas sobre como suspender ou retomar a atividade de replicação contínua para uma cópia de banco de dados, consulte Suspender ou Retomar uma Cópia do Banco de Dados de Caixa de Correio.

O truncamento de log não ocorre na cópia do banco de dados de caixa de correio ativo, quando uma ou mais cópias passivas são suspensas. Se você tiver planejado atividades de manutenção que vão demorar muito (por exemplo, alguns dias), você pode 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.

Propagando uma cópia de banco de dados

A propagação, também conhecida como atualização, é o processo no qual um banco de dados, seja um banco de dados vazio ou uma cópia do banco de dados de produção, é adicionado ao local da cópia de destino em outro servidor de Caixa de Correio no mesmo grupo de disponibilidade do banco de dados (DAG) do banco de dados de produção. Ele se torna o banco de dados de linha de base para a cópia mantida pelo servidor.

Dependendo da situação, a propagação pode ser um processo automático ou manual que você inicia. Quando uma cópia de banco de dados for adicionada, ela será propagada automaticamente, desde que o servidor de destino e o armazenamento sejam configurados corretamente. Se você quiser propagar manualmente uma cópia do banco de dados e não quiser que ocorra a propagação automática quando criar a cópia, você poderá usar o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy.

As cópias de banco de dados raramente precisam ser novamente propagadas após a propagação inicial. Mas, se uma nova propagação for necessária ou se você quiser propagar manualmente uma cópia de banco de dados em vez de o sistema propagá-la automaticamente, essas tarefas poderão ser realizadas usando-se o assistente para Atualizar Cópia de Banco de Dados no EMC ou o cmdlet Update-MailboxDatabaseCopy no Shell. 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 instruções detalhadas sobre como propagar a cópia de um banco de dados, consulte Atualizar uma Cópia do 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 de banco de dados de caixa de correio propagada é retomada automaticamente. Se você não quiser que a replicação seja retomada automaticamente, será possível usar o parâmetro ManualResume durante a execução do cmdlet Update-MailboxDatabaseCopy.

Escolhendo o que propagar

Ao realizar uma operação de propagação, você pode optar por propagar a cópia de banco de dados de caixa de correio, o catálogo do índice de conteúdo da cópia de banco de dados de caixa de correio ou 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 para Atualizar Cópia de Banco de Dados e do cmdlet Update-MailboxDatabaseCopy é propagar a cópia do banco de dados de caixa de correio e a cópia do catálogo do índice de conteúdo. Para propagar apenas a cópia de banco de dados de caixa de correio sem propagar o catálogo do índice de conteúdo, use o parâmetro DatabaseOnly ao executar o cmdlet Update-MailboxDatabaseCopy. Para propagar apenas a cópia do catálogo do índice de conteúdo, use o parâmetro CatalogOnly ao executar o cmdlet Update-MailboxDatabaseCopy.

Selecionando a fonte da propagação

No Exchange 2007, a replicação contínua só pode propagar uma cópia de banco de dados copiando a cópia ativa do banco de dados. No Exchange 2010, qualquer cópia de banco de dados íntegra pode ser usada como a origem de propagação de uma cópia adicional desse banco de dados. Isso é especialmente útil quando você tem um DAG estendido por vários locais físicos. Por exemplo, considere uma implantação do DAG com quatro membros, na qual dois membros (MBX1 e MBX2) estejam localizados em Portland, Oregon, e dois (MBX3 e MBX4) estejam em Nova York, Nova York. Um banco de dados de caixa de correio chamado DB1 está ativo em MBX1 e há cópias passivas de DB1 em MBX2 e MBX3. Ao adicionar uma cópia de DB1 a MBX4, você tem a opção de usar a cópia em MBX3 como a origem de propagação e, ao fazer isso, você evita a propagação pelo link WAN (rede de longa distância) entre Portland e Nova York.

Para usar uma cópia específica como a origem de propagação ao adicionar uma nova cópia de banco de dados, você faria o seguinte:

• Use o parâmetro SeedingPostponed ao executar o cmdlet Add-MailboxDatabaseCopy para adicionar a cópia de banco de dados. Se o parâmetro SeedingPostponed não for usado, a cópia de banco de dados será propagada explicitamente usando-se a cópia ativa do banco de dados como a fonte.

• Use o parâmetro SourceServer ao executar o cmdlet Update-MailboxDatabaseCopy e especifique o servidor de origem desejado da propagação. No exemplo anterior, você especificaria MBX3 como o servidor de origem. Se o parâmetro SourceServer não for usado, a cópia de banco de dados será propagada explicitamente usando-se a cópia ativa do banco de dados como a fonte.

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, também é possível especificar quais redes do DAG usar e, opcionalmente, substituir as configurações de compactação e criptografia da rede do DAG durante a operação de propagação.

Para especificar as redes que você deseja usar para propagação, use o parâmetro Network ao executar o cmdlet Update-MailboxDatabaseCopy e especifique as redes do DAG que você 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 na 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 tiver sido configurada incluindo a sub-rede, 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 contendo essas sub-redes for configurada, a rede cliente (MAPI) será usada na propagação.

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

No nível do DAG, as redes do DAG são configuradas para criptografia e compactação. As configurações padrão são para usar a criptografia e a compactação apenas na comunicação 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, será possível substituir esses valores usando-se os parâmetros NetworkCompressionOverride e NetworkEncryptionOverride, respectivamente, durante a execução do cmdlet Update-MailboxDatabaseCopy.

Processo de propagação

Quando você iniciar um processo de propagação usando os cmdlets Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy, as seguintes tarefas serão realizadas:

1. As propriedades do banco de dados do Active Directory são lidas para validar o banco de dados especificado e os servidores, além de verificar se os servidores de origem e de destino estão executando o Exchange 2010, se eles 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 tiverem sido 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. As informações de estado do banco de dados são atualizadas pelo serviço de replicação do Microsoft Exchange para refletir um status de Propagação.

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

10. Uma solicitação 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, usando TCP. Essa solicitação e a comunicação subsequente para a propagação do banco de dados ocorrem em uma rede do 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 e não estiver 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 sobre o diretório do serviço de pesquisa do Microsoft Exchange e a suspensão dessa indexação.

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é a conclusão da transferência dos dados.

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.

Configurando 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 EMC. Também é possível usar os cmdlets Get-MailboxDatabase e Set-MailboxDatabaseCopy no Shell para exibir e configurar as definições de cópia do banco de dados, como intervalo de repetição, intervalo de truncamento e ordem de preferência de ativação. Para instruções detalhadas sobre como exibir e definir as configurações de cópia de banco de dados, consulte Configurar as Propriedades de Cópia do Banco de Dados de Caixa de Correio.

Usando opções de intervalo 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 recursos resultam na criação temporária de arquivos de log, o uso de um deles afetará o projeto de armazenamento.

Tempo de retardo de repetição

Tempo de retardo de repetição é uma propriedade de uma cópia de banco de dados de caixa de correio que especifica o tempo, em minutos, de atraso para a repetição do log para a cópia de banco de dados. O cronômetro do tempo de retardo de repetição se inicia quando um arquivo de log é replicado para a cópia passiva e passa com êxito pela 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 de banco de dados de caixa de correio configurada com um tempo de retardo de repetição maior que 0 é conhecida como uma 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 em litígio no Exchange 2010 podem fornecer proteção contra várias falhas que acabariam causando a perda de dados. No entanto, esses recursos não podem fornecer proteção contra a perda de dados em caso de dano lógico, que, embora raro, pode causar a perda de dados. As cópias com retardamento foram criadas para evitar a perda de dados em caso de dano lógico. Em geral, há dois tipos de dano lógico:

• Dano lógico ao banco de dados   A soma de verificação das páginas de banco de dados corresponde, mas os dados nas páginas estão errados do ponto de vista lógico. Isso pode ocorrer quando o ESE tenta gravar em uma página de banco de dados e, mesmo que o sistema operacional retorne uma mensagem de êxito, os dados jamais são gravados no disco ou são gravados no lugar errado. Isso é conhecido 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).

• Dano lógico ao repositório   Os dados são adicionados, excluídos ou manipulados de forma inesperada pelo usuário. Esses casos normalmente são causados por aplicativos de terceiros. Ele normalmente é apenas um dano no sentido em que o usuário o considera assim. 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 em litígio do Exchange 2010 fornece proteção contra o dano lógico ao repositório (porque evita a exclusão permanente do conteúdo por um usuário ou aplicativo). No entanto, talvez haja cenários em que uma caixa de correio de usuário seja corrompida de forma que seria mais fácil restaurar o banco de dados para um ponto anterior ao dano e, em seguida, exportá-la 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. A decisão de usar uma cópia de banco de dados com um tempo de retardo de repetição (uma cópia com retardamento) dependerá dos aplicativos de terceiros usados e do histórico da organização com dano lógico ao repositório.

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

• Diferentemente da SCR (replicação contínua em espera) no Exchange 2007, que tinha um intervalo de repetição embutido em código de 50 arquivos de log, não há nenhum número embutido em código dos arquivos de log com retardamento. Em vez disso, o tempo de retardo de repetição é um valor configurado por administrador e, por padrão, permanece desabilitado.

• A configuração do tempo de retardo de repetição tem uma definição padrão de zero dia 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, elas foram criadas para fins de recuperação de desastre, para proteger do dano lógico ao armazenamento.

• Quanto maior for o tempo de retardo de repetição, mais longo será o processo de recuperação do banco de dados. Dependendo do número de arquivos de log que precisam ser repetidos durante a recuperação e da velocidade na qual o hardware pode repeti-los, talvez sejam necessárias várias horas para recuperar um banco de dados.

• 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 retardamento não podem receber o patch com o recurso de restauração de página única do ESE. Se uma cópia com retardamento encontrar um dano à página do banco de dados (por exemplo, um erro -1018), ela terá que ser novamente propagada (o que fará o aspecto com retardamento da cópia se perder).

A ativação e a recuperação de uma cópia de banco de dados de caixa de correio com retardamento formarão um processo simples, se você quiser que o banco de dados repita todos os arquivos de log e torne a cópia de banco de dados a atual. Se quiser repetir os arquivos de log até um ponto específico no tempo, essa será uma operação mais difícil porque você manipula os arquivos de log e executa a ferramenta Eseutil.

Para instruções detalhadas sobre ativar uma cópia de banco de dados de caixa de correio com retardamento, consulte Ativar uma Cópia do Banco de Dados de Caixa de Correio Atrasada.

Tempo de retardo de truncamento

Tempo de retardo de truncamento é uma propriedade de uma cópia de banco de dados de caixa de correio que especifica o tempo, em minutos, de atraso para a exclusão do log após a repetição do arquivo de log 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 log de truncamento funciona no Exchange 2010 da mesma forma que funcionava no Exchange 2007. 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 deve ser feito com êxito, ou o registro em log circular deve ser 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 devem ter inspecionado o arquivo de log.

• Todas as outras cópias (sem retardamento) devem ter repetido 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 deve ter sido truncado na cópia ativa.

Diretiva de ativação do banco de dados

Há cenários nos quais você talvez queira criar uma cópia de banco de dados de caixa de correio e impedir o sistema de ativar automaticamente essa cópia em caso de falha. Por exemplo:

• Se você implantar uma ou mais cópias de banco de dados de caixa de correio em um segundo datacenter ou em espera.

• Se você configurar uma cópia de banco de dados como uma cópia com retardamento para fins de recuperação.

• Se você estiver realizando uma manutenção ou atualização de um 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. Isso permite ao sistema manter a atualidade do banco de dados ao longo de todo o envio de logs e repetição, mas impede o sistema de ativar automaticamente e usar a cópia. As cópias bloqueadas para ativação devem ser ativadas manualmente por um administrador. É possível configurar a diretiva de ativação do banco de dados usando o cmdlet Set-MailboxServer para definir o parâmetro DatabaseCopyAutoActivationPolicy como Bloqueado.

Para mais informações sobre como configurar a diretiva de ativação do banco de dados, consulte Configurar Diretiva de Ativação para uma Cópia de Banco de Dados de Caixa de Correio.

Balanceando cópias de banco de dados

Devido à natureza inerente dos DAGs, como resultado das alternâncias e dos failovers de banco de dados, as cópias de banco de dados de caixa de correio ativas alterarão hosts várias vezes durante toda a existência 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.

DAG com distribuição de cópia ativa desbalanceada

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 balancear as cópias de banco de dados de caixa 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 bancos de dados para a sua cópia mais preferida (com base na Preferência de Ativação) sem relação com o site do Active Directory.

• BalanceDbsBySiteAndActivationPreference   Quando essa opção é especificada, o script tenta mover bancos de dados ativos para a sua cópia mais preferida, enquanto tenta também balancear os 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.

DAG com distribuição de cópia ativa balanceada

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 do RedistributeActiveDatabases.ps1.

Parâmetros do 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.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

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

Monitorando cópias de banco de dados

Uma cópia de banco de dados será a primeira defesa se ocorrer uma falha que afete a cópia ativa de um banco de dados. Por isso, é crítico monitorar a integridade e o status das cópias de bancos de dados para garantir a disponibilidade, quando necessário. É possível exibir algumas informações de integridade e status examinando a página Propriedades de uma cópia de banco de dados no EMC. Também é possível usar o cmdlet Get-MailboxDatabaseCopyStatus no Shell para exibir várias informações de status de uma cópia de banco de dados.

Para mais informações sobre o monitoramento de cópias de bancos de dados, consulte Monitorando a alta disponibilidade e resiliência do site.

Removendo uma cópia de banco de dados

Uma cópia de banco de dados pode ser removida a qualquer momento, usando-se o EMC ou o cmdlet Remove-MailboxDatabaseCopy no Shell. 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 instruções detalhadas sobre como remover uma cópia de banco de dados, consulte Remover uma Cópia de 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 Status da Cópia na guia Cópias de Banco de Dados no EMC. Apenas a cópia ativa terá um status Montado. Todas as outras cópias de banco de dados exibirão o status atual da replicação para a cópia de banco de dados. É possível realizar uma alternância usando-se o assistente para Mover Banco de Dados de Caixa de Correio Mestre no EMC ou o cmdlet Move-ActiveMailboxDatabase no Shell.

Há várias verificações internas que serão realizadas antes da ativação de uma cópia passiva:

• 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. É possível substituir esse comportamento e ignorar a verificação da integridade usando-se 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 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. É possível substituir esse comportamento e ignorar essas verificações usando-se 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. É possível substituir esse comportamento e ignorar a verificação do catálogo de pesquisa, usando-se 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ê estiver ativando estiver em um estado não íntegro ou inutilizável e usar esse parâmetro para ignorar a verificação da integridade do catálogo, você precisará rastrear ou propagar o catálogo de pesquisa novamente.

Ao realizar uma alternância de banco de dados, você também tem a opção de substituir as definições da discagem automática de montagem configuradas do servidor que hospeda a cópia de banco de dados passiva sendo ativada. O uso do parâmetro MountDialOverride do cmdlet Move-ActiveMailboxDatabase instrui o servidor de destino a substituir as configurações da discagem automática de montagem 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 Correio. Para mais informações sobre as alternâncias de bancos de dados, consulte Switchovers e Failovers.

 © 2010 Microsoft Corporation. Todos os direitos reservados.