ID do artigo: 822400 - Última revisão: sexta-feira, 2 de novembro de 2007 - Revisão: 5.6

Descrição das opções de recuperação de desastres para o Microsoft SQL Server

Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.

Nesta página

Expandir tudo | Recolher tudo

Sumário

Este artigo aborda várias soluções para recuperar dados de um banco de dados do Microsoft SQL Server, se ocorrer um desastre. Este artigo também descreve as vantagens e as desvantagens de cada solução.

Recuperação de desastres é um processo que você pode usar para ajudar a recuperar informações de sistemas e dados, se ocorrer um desastre.

Alguns exemplos de desastres incluem um natural ou de um desastre man-made como um incêndio ou de um desastre técnico como uma falha no disco dois em uma matriz redundante matriz de independente Disks (RAID) 5.

Planejamento de recuperação de desastres é o trabalho que é dedicado à preparação todas as ações que devem ocorrer em resposta a um desastre. O planejamento inclui a seleção de uma estratégia para ajudar a recuperar dados valiosos. A seleção da estratégia de recuperação de desastres apropriado depende de seus requisitos de negócios.

Observação As soluções que são discutidas neste artigo só fornecem descrições gerais das tecnologias que você pode usar. Essas descrições gerais são para comparar vários métodos de recuperação de desastres e planos de recuperação de desastres. Antes de você decidir em qual desastres solução de recuperação é melhor para você, certifique-se que você examinar cada uma das soluções de recuperação a desastres sugeridas em mais detalhes. Após discutir cada solução de recuperação de desastres, este artigo contém links onde você pode encontrar informações adicionais sobre essa solução.

Cluster de failover

Cluster de failover Microsoft SQL Server 2000 é projetado para failover automaticamente se ocorrer uma falha de hardware ou uma falha de software. Você pode usar cluster para criar um cluster de failover para uma única instância do SQL Server 2000 ou para várias instâncias do SQL Server 2000 de failover do SQL Server 2000. Cluster de failover permite que um sistema de banco de dados alternar automaticamente o processamento de uma instância do SQL Server de um servidor com falha para um servidor de trabalho. Portanto, o cluster de failover é útil se ocorrer uma falha do sistema operacional ou se você executar uma atualização planejada dos recursos de sistema de banco de dados. Além disso, o cluster de failover aumenta disponibilidade do servidor com nenhum tempo de inatividade.

Como o cluster de failover é projetado alta disponibilidade do servidor com quase não tempo de inatividade do servidor, os nós de cluster devem ser geograficamente próximo umas às outras. Cluster de failover não pode ser útil se ocorrer uma falha de matriz de disco.

Observação Para implementar o cluster de failover, instale o Microsoft SQL Server 2000 Enterprise Edition.

Os sistemas operacionais a seguintes oferecem suporte a failover de cluster:
  • Microsoft Windows NT 4.0, Enterprise Edition
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
Esses sistemas operacionais incluem um componente instalável, MSCS (Microsoft Cluster Service). Para implementar failover de cluster para o SQL Server, você deve instalar o MSCS.

Para obter mais informações sobre o MSCS e sua instalação, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
259267  (http://support.microsoft.com/kb/259267/ ) Serviço de cluster do Microsoft recursos de instalação do

Vantagens e desvantagens de usar clusters de failover

Vantagem
Você tem o servidor de alta disponibilidade. Automaticamente o cluster de failover ocorre se o servidor principal falhar.
Desvantagens
  • Gera uma despesa maior. A manutenção de dois servidores é duas vezes o custo de manutenção de um único servidor. Porque você precisa manter dois servidores ao mesmo tempo, é mais cara instalar e manter nós de cluster.
  • Os servidores devem estar no mesmo local. Se as ramificações da organização estão em todo o mundo e os clusters ativo/ativo devem ser implementados em ramificações, a infra-estrutura armazenamento que deseja usar e a rede é muito diferente de um cluster de servidor de dispositivo de quorum padrão. Portanto, embora seja possível, é melhor não usar servidores geograficamente distantes.
  • Você não tem nenhuma proteção contra uma falha de matriz de disco.
  • Cluster de failover não permite a criação de clusters de failover no nível do banco de dados ou no nível de objeto de banco de dados, como o nível de tabela.
Para obter mais informações sobre o cluster de failover, visite o seguinte site:
http://msdn2.microsoft.com/en-us/library/aa174512(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa174512(SQL.80).aspx)
Para obter mais informações sobre o cluster de failover, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
243218  (http://support.microsoft.com/kb/243218/ ) Ordem de instalação para o SQL Server 2000 Enterprise Edition no Microsoft Cluster Server
822250  (http://support.microsoft.com/kb/822250/ ) WebCast de suporte: Microsoft SQL Server 2000 failover clustering procedimentos de recuperação de desastres
Para obter mais informações sobre a política de suporte da Microsoft para um cluster de failover do SQL Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
327518  (http://support.microsoft.com/kb/327518/ ) A política de suporte da Microsoft para um cluster de failover do SQL Server

O espelhamento do banco de dados

Espelhamento de banco de dados é uma solução de software principalmente para aumentar a disponibilidade do banco de dados. Você só pode implementar o espelhamento em uma base por banco de dados. Espelhamento funciona somente com bancos de dados que usam o modelo de recuperação completa. Os modelos de recuperação simples e registradas em massa não suportam o espelhamento do banco de dados. Portanto, todas as operações em massa sempre totalmente são registradas. O espelhamento do banco de dados funciona com qualquer nível de compatibilidade do banco de dados com suporte.

Vantagens e desvantagens de usar o espelhamento do banco de dados

Vantagens
  • O espelhamento do banco de dados aumenta a proteção de dados.
  • O espelhamento do banco de dados aumenta a disponibilidade de um banco de dados.
  • O espelhamento do banco de dados melhora a disponibilidade de banco de dados de produção durante as atualizações.
Desvantagens
  • O banco de dados espelho deve ser idêntico para o banco de dados principal. Por exemplo, todos os objetos, logons e permissões devem ser idênticas.
  • O espelhamento do banco de dados envolve a transferência de informações de um computador para outro computador através de uma rede. Portanto, a segurança das informações que transfere do SQL Server é muito importante.

Replicação transacional Peer-to-peer

Replicação transacional Peer-to-peer foi projetada para aplicativos que podem ler ou podem modificar os dados em qualquer banco de dados que participa da duplicação. Além disso, se os servidores que hospedam os bancos de dados não estiverem disponíveis, você pode modificar o aplicativo para rotear o tráfego para os servidores restantes. Os servidores restantes contêm cópias idênticas de dados.

Vantagens e desvantagens de usando a replicação transacional peer-to-peer

Vantagens
  • Aperfeiçoado o desempenho leitura porque você pode difundir atividade em todos os nós.
  • Agregar desempenho de atualização, inserir o desempenho e excluir desempenho para a topologia se pareça com o desempenho de um único nó porque todas as alterações são propagadas para todos os nós.
Desvantagens
  • Replicação ponto a ponto não está disponível apenas no SQL Server 2005 Enterprise Edition.
  • Todos os participantes bancos de dados devem conter dados e esquemas idênticas.
  • Recomendamos que cada nó use seu próprio banco de dados distribuição. Essa configuração elimina o potencial para SQL Server 2005 com um ponto único de falha.
  • Não é possível incluir tabelas e outros objetos em várias publicações peer-to-peer dentro um banco de dados única publicação.
  • Você deve ter uma publicação habilitada para replicação ponto a ponto antes de criar inscrições.
  • Você deve inicializar inscrições, usando um backup ou definindo o valor de tipo de sincronização a inscrição para replicação oferecer suporte a apenas .
  • Replicação transacional Peer-to-peer não fornece detecção de conflitos ou resolução de conflitos.
  • Recomendamos que você não use colunas de identidade.

Manutenção de um servidor de espera quente

Você pode criar e manter um servidor em espera quente usando um dos seguintes métodos:
  • Envio de log
  • Replicação transacional
Mais informações sobre cada esses dois métodos a seguir.

Envio de log

Envio de log é incluído no resource kit para o Microsoft SQL Server 7.0 e é totalmente incorporada no SQL Server 2000 Enterprise Edition e no Microsoft SQL Server 2000 Developer Edition. Faça logon remessa usa um servidor em espera que não é usado durante as operações normais. Um servidor em espera é útil para ajudar a recuperar dados se ocorrer um desastre. Você só pode usar o envio de log no nível do banco de dados. Você não pode usá-lo no nível de instância.

Quando um servidor em espera está restaurando os logs de transação, o banco de dados está em modo exclusivo e está inutilizável. No entanto, você pode executar relatórios trabalhos entre restaurações de log de transação em lotes ou DBCC (Database Console comandos) verifica para continuamente verificar a integridade do servidor em espera. Para aplicativos, como servidores de suporte de decisão que requerem processamento contínuo em um servidor de banco de dados, o envio de log não é uma opção apropriada.

A latência no servidor em espera é baseada na freqüência os backups de log de transação são obtidos no servidor primário e, em seguida, aplicada no servidor em espera. Se o servidor principal falhar, você poderá perder as alterações que foram feitas pelas transações que ocorreram após o log de transações mais recente backup.

Por exemplo, se backups do log de transações são obtidos a cada 10 minutos, transações durante mais recente 10 minutos podem ser perdidas. Isso não significa necessariamente que as atualizações de dados que são feitas no servidor primário durante o período de latência serão perdidas. Normalmente, novas atualizações no log de transações principal podem ser recuperadas e aplicadas no servidor em espera quente com apenas um pequeno atraso de alternar do servidor primário para o servidor de espera. O principal objetivo de envio de log é manter um servidor de espera quente. Se mantém que um servidor de espera quente é seu principal objetivo, envio de log é provável que seja mais apropriado que outras soluções que este artigo descreve.

Vantagens e desvantagens de usar o envio de log

Vantagens
  • Você pode recuperar todas as atividades de banco de dados. A recuperação inclui quaisquer objetos que foram criados, como tabelas e modos de exibição. Ele também inclui alterações de segurança, como os novos usuários que foram criados e as alterações de permissão.
  • Você pode restaurar o banco de dados mais rápido. A restauração do banco de dados e o log de transações é baseada em formatos de página de nível inferior. Portanto, o envio de log acelera o processo de restauração e resulta na rápida recuperação de dados.
Desvantagens
  • O banco de dados é inutilizável durante o processo de restauração porque o banco de dados está no modo exclusivo no servidor em espera.
  • Há falta de granularidade. Durante o processo de restauração, todas as alterações no servidor principal são aplicadas no servidor em espera. Não é possível usar o envio de log para aplicar alterações a algumas tabelas e para rejeitar as alterações restantes.
  • Não há nenhum failover automático de aplicativos. Quando o servidor primário falha devido a um desastre, o servidor em espera não failover automaticamente. Portanto, você deve redirecionar explicitamente os aplicativos que se conectar ao servidor primário para o servidor espera (failover).
Observação Se seu principal objetivo é manter um servidor em espera quente, a Microsoft recomenda que você use o envio de log. O servidor espera quente reflete todas as transações que ocorrem no servidor primário. No entanto, você não pode usar o servidor espera quando o servidor primário estiver disponível.

Para obter mais informações sobre como configurar um servidor em espera quente, usando o envio de log, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
323135  (http://support.microsoft.com/kb/323135/ ) Microsoft SQL Server 2000 - como configurar (white paper) de envio de log
325220  (http://support.microsoft.com/kb/325220/ ) WebCast de suporte: Microsoft SQL Server 2000 envio de log
Para obter mais informações sobre o envio de log, visite os seguintes sites:
http://msdn2.microsoft.com/en-us/library/aa213785(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa213785(SQL.80).aspx)
http://www.microsoft.com/downloads/details.aspx?familyid=7395ec1b-199f-42bc-a31b-2056adf73f94 (http://www.microsoft.com/downloads/details.aspx?familyid=7395ec1b-199f-42bc-a31b-2056adf73f94)

Replicação transacional

Você também pode usar a replicação transacional para manter um servidor de espera quente. Replicação transacional replica os dados em um servidor (Editor) para outro servidor (assinante) com menos a latência de envio de log. Você pode implementar replicação transacional no nível do objeto banco de dados, como o nível de tabela. Portanto, a Microsoft recomenda que você use replicação transacional quando você tem menos dados para proteger, e você deve ter um plano de recuperação rápida.

Você pode usar uma inscrição de envio para forçar a replicação transacional entre dois servidores com o servidor primário como o Editor e o servidor espera como o assinante. Replicação transacional garante a replicação de dados. Quando o publisher falha, o assinante pode ser usado.

Essa solução é vulnerável a falha do Editor e o assinante ao mesmo tempo. Em uma situação como essa, você não pode proteger os dados. Todos os outros cenários, como a falha de um distribuidor ou um assinante, é melhor sincronizar novamente os dados no assinante com os dados no Editor.

Você deve usar replicação transacional para manter um servidor de espera quente somente quando você não implementar mudanças de esquema ou você não implementar outras alterações no banco de dados, como alterações de segurança que a replicação não dá suporte.

Observação Replicação não foi projetada para a manutenção de servidores em espera quentes. Com a replicação, você pode usar dados replicados no assinante para gerar relatórios. Você também pode usar a replicação para outros usos gerais sem ter que executar o processamento no Editor relativamente ocupado.

Vantagens e desvantagens de usar replicação transacional

Vantagens
  • Você pode ler dados em um assinante ao aplicar as alterações.
  • As alterações são aplicadas com menos latência.

    Observação Essa vantagem pode não ser aplicável se qualquer uma das seguintes opções for verdadeira:
    • Agentes de replicação não estão definidos para contínua .
    • Agentes de replicação são interrompidos devido a erros que podem ocorrer durante a replicação.
Replicação transacional pode levar mais tempo para aplicar as alterações porque atualizações em lotes grande devem ser executadas durante a duplicação.
Desvantagens
  • Alterações de esquema ou alterações de segurança que são executadas no Editor após o estabelecimento de replicação não estarão disponíveis no assinante.
  • O distribuidor na replicação transacional usa uma conexão ODBC (Open Database Connectivity) ou uma conexão OLE banco de dados (OLEDB) para distribuir dados. No entanto, o envio de log usa TRANSACTION RESTORE baixo nível instrução Transact-SQL para distribuir os logs de transação. Uma instrução RESTORE TRANSACTION é muito mais rápida do que uma conexão ODBC ou um OLEDB conexão.
  • Normalmente, alternar servidores apaga as configurações de replicação. Portanto, você precisa configurar a duplicação duas vezes:
    Quando você alternar para o assinante.
    Quando você alternar novamente para o publisher.
  • Se ocorrer um desastre, você deve alternar manualmente servidores redirecionando todos os aplicativos para o assinante.
Para obter mais informações sobre replicação, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
195757  (http://support.microsoft.com/kb/195757/ ) Perguntas freqüentes - SQL Server 7.0 - replicação

Recurso de backup e restauração

O recurso de backup e restauração do SQL Server fornece uma proteção importante para ajudar a proteger dados críticos que armazenam em bancos de dados SQL Server. Você pode criar uma cópia de um banco de dados (uma cópia de backup) usando o backup e restauração recurso e armazene a cópia do banco de dados em um local que está protegido contra a falha potencial de servidor que executa a instância do SQL Server. Se você tiver uma falha de sistema de banco de dados ou corrupção de banco de dados, você pode, em seguida, usar a cópia de backup para recriar o banco de dados ou para restaurar o banco de dados.

Quando você planeja a recuperação de desastres usando o backup e restauração do recurso, também determinar como crítica os dados no banco de dados é. Além disso, determinar requisitos de restauração para o banco de dados. Por exemplo, determine os requisitos de restauração a seguir:
  • O ponto que você restaurar o banco de dados. Você precisa decidir qual dos dois seguintes você deseja fazer:
    Restaure o banco de dados à condição da noite antes da falha.
    Restaure o banco de dados à condição de um ponto de tempo máximo para o tempo de falha.
  • Quanto tempo o banco de dados pode ficar indisponível. Se você deve restaurar o banco de dados imediatamente.
Depois de determinar os requisitos de restauração, você pode planejar um processo de backup mantém um conjunto de backups para atender aos requisitos

Você só pode restaurar um banco de dados à condição do ponto de tempo em que você executou o backup mais recente. Transações que ocorreram após esse backup podem ser perdidas. Portanto, a Microsoft recomenda que você use o recurso backup e restauração somente para aplicativos de banco de dados não-críticos.

Vantagens e desvantagens de usar o recurso de backup e restauração

Vantagens
  • Você pode fazer o banco de dados até para mídia removível para ajudar a proteger contra falhas no disco.
  • Você não tem dependem da rede, como você faz quando você usa clusters de failover ou envio de log.
Desvantagens
  • Quando você faz backup de banco de dados, não é possível executar operações, como criação de tabela, criação de índice, reduzindo de banco de dados ou operações nonlogged.
  • Se ocorrer uma falha, você poderá perder os dados mais recentes.
  • Se ocorrer um desastre, você deve restaurar manualmente o banco de dados.
Observação Antes de usar o procedimento de backup e restauração em um ambiente de produção, é melhor testar completamente esse procedimento em um ambiente de teste.

Para obter mais informações sobre o recurso de backup e restauração, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
325257  (http://support.microsoft.com/kb/325257/ ) WebCast de suporte: SQL Server 2000 Database recuperação: backup e restauração
281122  (http://support.microsoft.com/kb/281122/ ) Descrição da restauração de backups de arquivos e grupo de arquivos no SQL Server
Para obter mais informações sobre o recurso de backup e restauração, visite os seguintes sites:
http://msdn2.microsoft.com/en-us/library/aa196617(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa196617(SQL.80).aspx)
http://msdn2.microsoft.com/en-us/library/aa196685(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa196685(SQL.80).aspx)
http://msdn2.microsoft.com/en-us/library/aa178143(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178143(SQL.80).aspx)

Disco redundância de dados usando uma matriz redundante de discos independentes (RAID)

Um RAID armazena dados redundantes em vários discos para fornecer maior confiabilidade e o menor tempo de inatividade para servidores. Níveis de RAID 0, 1 e 5 são geralmente usados como opções de recuperação para o SQL Server. As tecnologias RAID que são mencionadas permitem a falha e a substituição de um único disco consequent sem o servidor ficar off-line. Se várias falhas de disco ocorrerem, dados podem não ser recuperáveis. Portanto, a Microsoft recomenda que você combina gerenciamento de dados redundante com um procedimento de backup e restauração para certificar-se de que você não perderá dados se uma falha de hardware ou outro desastre ocorre.

RAID 0 usa tecnologia de distribuição para acesso mais rápido enquanto RAID 1 usa tecnologia de espelhamento para confiabilidade de dados. Uma técnica comum usada no gerenciamento de banco de dados relacional envolve o uso RAID 0 e 1 RAID juntos. Nesta técnica, duas matrizes distribuídos idênticos de unidades são constantemente atualizadas para que as informações que são armazenadas em ambas as matrizes são os mesmos. Se uma matriz falhar, a outra matriz tem automaticamente sobre até que a matriz original é colocada online.

RAID 5 (também conhecido como distribuição com paridade) usa uma matriz de único disco distribuído com paridade bits escritos junto com os dados. Quando qualquer um disco falhar, os bits de paridade pode ser usados para calcular os dados ausentes até que você substituir o disco. Quando você substituir o disco, você pode usar as informações de paridade e dados restantes para recriar os dados do disco que falhou e copiar os dados recriados para o novo disco. Todas essas operações ocorrem sem tempo de inatividade do banco de dados do sistema. Um RAID fornece muitas outras opções e recursos para você ajudar a assegurar que seus sistemas de banco de dados experiência como pouco tempo de inatividade possível.

Vantagens e desvantagens de usar um RAID

Vantagem
Você não perderá dados se qualquer um disco falhar.
Desvantagens
  • Ele pode levar muito tempo para recuperar os dados.
  • Se vários discos falharem, talvez não seja capaz de recuperar dados valiosos.
Para obter mais informações sobre RAID, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
100110  (http://support.microsoft.com/kb/100110/ ) Visão geral das matrizes redundantes de discos de baixo custo (RAID)

Referências

Para baixar uma versão atualizada do Books Online do SQL Server 2000, visite o seguinte site da Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyId=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5 (http://www.microsoft.com/downloads/details.aspx?FamilyId=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5)
Para obter mais informações sobre outras opções de recuperação de desastres, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
307775  (http://support.microsoft.com/kb/307775/ ) Artigos de recuperação de desastres para o Microsoft SQL Server
Para obter mais informações sobre o cluster de failover, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
195761  (http://support.microsoft.com/kb/195761/ ) Perguntas freqüentes - SQL Server 7.0 - Failover
260758  (http://support.microsoft.com/kb/260758/ ) Perguntas freqüentes - SQL Server 2000 - clustering de Failover
274446  (http://support.microsoft.com/kb/274446/ ) Atualizar a solução de failover do SQL Server 2000 recomendada para todos os servidores virtuais não SQL Server 2000
280743  (http://support.microsoft.com/kb/280743/ ) Sites de clusters e geograficamente separados do Windows
Para obter mais informações sobre o recurso de backup e restauração, visite o seguinte site:
http://technet.microsoft.com/en-us/library/cc966495.aspx (http://technet.microsoft.com/en-us/library/cc966495.aspx)
Para obter mais informações sobre o recurso de backup e restauração, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
253817  (http://support.microsoft.com/kb/253817/ ) Como fazer backup o último log de transação quando o mestre e os arquivos de banco de dados estão danificados no SQL Server
314546  (http://support.microsoft.com/kb/314546/ ) Como mover bancos de dados entre computadores que estão executando o SQL Server
Para obter mais informações sobre arquivos e pastas do catálogo de texto completo, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
240867  (http://support.microsoft.com/kb/240867/ ) Como mover, copiar e fazer backup de arquivos e pastas do catálogo de texto completo

A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
Palavras-chave: 
kbmt kbdisasterrec kbreplication kbreplmgr kbclustering kbinfo KB822400 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 822400  (http://support.microsoft.com/kb/822400/en-us/ )