Compartilhar via

Como alternar para a cópia passiva de um banco de dados

  • Artigo

 

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2006-12-20

Este tópico explica como recuperar dados quando um banco de dados ativo e seus arquivos de log habilitados para LCR (replicação contínua local) são danificados.

Antes de começar

Você deve executar o seguinte procedimento usando uma conta que tenha permissões de Administrador do Exchange Server.

Embora o procedimento a seguir use o parâmetro ReplaceLocations do cmdlet Restore-StorageGroupCopy, é recomendável alterar as atribuições da unidade ou executar outra operação de baixo nível. É possível alterar atribuições de unidade com o snap-in Gerenciamento de Disco do MMC (Console de Gerenciamento Microsoft) ou a ferramenta Diskpart fornecida com o Microsoft Windows Server 2003. O motivo dessa recomendação é garantir que arquivos do grupo de armazenamento ativo e de banco de dados continuem com nomes de arquivos significativos que indiquem que são cópias de produção ativas. O parâmetro ReplaceLocations garante que as cópias ativas do banco de dados e de logs estão contidas nos diretórios reservados normalmente para as cópias passivas desses arquivos. Operar nessa configuração pode resultar em confusão futura ao distinguia a cópia ativa dos dados da cópia passiva dos dados.

Procedimento

Para recuperar-se de danificação da cópia ativa de um banco de dados que está habilitado para LCR

  1. Verifique se a danificação não é resultado de uma unidade de log offline, unidade de banco de dados offline ou erro de configuração de volume de disco. Se o volume do log do grupo de armazenamento de produção não estiver disponível (e poderia estar disponível) no momento do failover, poderão ser perdidos mais dados do que o necessário.

  2. Avalie se os dados na cópia passiva do banco de dados são aceitáveis. Para obter orientação sobre como fazer essa determinação, consulte Como exibir o status de uma cópia de replicação contínua local.. Geralmente, o sistema deve ser capaz de se recuperar com todos os dados da cópia ativa do banco de dados. Por isso, a avaliação deve mostrar que todos os arquivos de log necessários estão disponíveis. Se isso não ocorrer, investigue por que alguns ou todos os arquivos de log não estão disponíveis.

  3. Desmonte o banco de dados danificado. Você pode usar o cmdlet Dismount-Database no Shell de Gerenciamento do Exchange ou a opção do menu de atalho Desmontar para o banco de dados no Console de Gerenciamento do Exchange.

  4. Use o cmdlet Restore-StorageGroupCopy como indicado a seguir para ativar a cópia do banco de dados. Isso pode ser feito de duas formas:

    Dica

    A cópia da LCR é automaticamente desabilitada como parte da execução do cmdlet Restore-StorageGroupCopy.

    1. Para ativar a cópia e manter os caminhos do grupo de armazenamento de produção e do banco de dados inalterados, execute o seguinte cmdlet:

      Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

      Dica

      O método preferido é ativar a cópia em seu local atual, mover os arquivos, alterar as letras das unidades ou montar atribuições de ponto para obter os arquivos de cópia posicionados nos caminhos de produção. Através dessa estratégia, o banco de dados de produção é mantido em seu local esperado.

    2. Para ativar a cópia e atualizar os caminhos do grupo de armazenamento de produção e do banco de dados de acordo com os da cópia de LCR, execute o cmdlet Restore-StorageGroupCopy com a opção -ReplaceLocations da seguinte forma:

      Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -ReplaceLocations:$true

      Dica

      Um administrador poderá ser subseqüentemente surpreendido por isso se for deixado no lugar por um longo período. O fator decisivo deverá ser se os arquivos da cópia podem ser relocados em minutos ou não, permitindo a recuperação rápida desejada.

  5. No prompt de confirmação, digite S e pressione ENTER.

  6. Execute esta etapa se você já realizou a Etapa 4a na qual os caminhos de produção não foram alterados (-ReplaceLocations não foi especificado no cmdlet Restore-StorageGroupCopy). Os arquivos da cópia passiva devem ser relocados para os caminhos do grupo de armazenamento de produção e do banco de dados. Use o sistema de arquivos ou a ferramenta de gerenciamento de volume apropriado para mover os logs, os arquivos do sistema e o banco de dados da cópia de LCR para esses locais.

  7. Agora, o banco de dados pode ser montado.

  8. O cmdlet Restore-StorageGroupCopy desabilita automaticamente a LCR para o grupo de armazenamento. A LCR deve ser habilitada depois que a recuperação terminar. Para obter etapas detalhadas sobre como habilitar a LCR para o grupo de armazenamento, consulte Como habilitar a Replicação Contínua Local para um grupo de armazenamento existente.

Para obter mais informações

Para obter informações detalhadas de sintaxes e de parâmetros, consulte Restore-StorageGroupCopy.

Para obter mais informações sobre como gerenciar o ambiente de LCR, consulte Gerenciando a replicação contínua local.