Visão geral da arquitetura de banco de dados do Exchange Server e mecanismo de banco de dados

Traduções deste artigo Traduções deste artigo
ID do artigo: 271987 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo fornece uma visão geral sobre a arquitetura de banco de dados e o mecanismo de banco de dados para o Microsoft Exchange Server. A discussão inclui informações sobre os componentes de banco de dados, manutenção da consistência do banco de dados, tipos possíveis de falhas de banco de dados e utilitários de banco de dados.

Mais Informações

Exchange Server usa bancos de dados tolerantes a falhas e baseados em transações para armazenar mensagens e informações de diretório antes que ele seja aplicado ao banco de dados. Para o Exchange Server 5.5 Standard Edition, cada banco de dados pode crescer até um máximo de 16 gigabytes (GB). Para o Exchange Server 5.5 Enterprise Edition, tamanho é limitado apenas pelo hardware.

Se ocorrer uma falha de energia ou outra falha de sistema anormal, Exchange Server usa arquivos de log de transações para reconstruir os dados que já aceito pelo servidor mas ainda não gravados no banco de dados.

Componentes de banco de dados

O design do Exchange Server se baseia em tecnologia de banco de dados padrão. O sistema se baseia em um mecanismo de banco de dados incorporado que apresenta a estrutura do disco para o Exchange Server e gerencia a memória. A tecnologia de mecanismo de banco de dados também é usada nos bastidores por outros aplicativos do Windows, por exemplo, WINS (Windows Internet Name Service) e DHCP (Dynamic Host Configuration Protocol).

Armazenamento de informações

O armazenamento de informações, que é o componente de chave para gerenciamento de banco de dados no Exchange Server, é realmente dois bancos de separado dados. O banco de dados de armazenamento de informações particulares, Priv.edb, gerencia dados de caixas de correio do usuário. O armazenamento de informações públicas, pub.edb, gerencia dados em pastas públicas.

O armazenamento de informações funciona com o MAPI (Messaging Application Programming Interface) e o mecanismo de banco de dados para garantir que todas as ações do usuário são gravadas no disco rígido do servidor. Por exemplo, quando um usuário salva uma mensagem no Microsoft Outlook, o MAPI primeiro chama o armazenamento de informações, em seguida, chama o mecanismo de banco de dados, que grava as alterações em disco.

JET Database Engine

Bancos de dados do Exchange Server são com base no formato JET, qual log usa arquivos para controlar e manter informações. Microsoft JET é um avançado 32-bit multithread mecanismo de banco de dados que combina a velocidade e desempenho com outros recursos avançados para aprimorar recursos de processamento baseados em transações.

O mecanismo de banco de dados armazena em cache do disco na memória por permutação 4 kilobytes (KB) páginas de dados dentro e para fora da memória. Ele atualiza as páginas na memória e grava páginas novas ou atualizadas de volta no disco. Isso torna o sistema mais eficiente porque quando solicitações chegar, os dados de buffers de mecanismo de banco de dados na memória em vez de constantemente indo para o disco.

Em versões anteriores ao Exchange Server 5.5, o cache de buffer é um tamanho fixo. Se for necessário mais memória, o administrador deve alterar manualmente o tamanho do buffer.

No Exchange Server 5.5, alocação de buffer dinâmico permite o cache de buffer aumentar ou reduzir, dependendo de quanta memória está disponível e quais recursos estão em uso por outros serviços em execução no computador do Microsoft Windows NT Server. Se outros serviços não estão usando memória, o mecanismo de banco de dados do Exchange Server ocupará como quantidade de memória necessária. Se outros serviços precisam de memória, o mecanismo de banco de dados oferece backup alguma memória transferindo páginas para o disco rígido e reduzindo o tamanho do buffer.

Quando um usuário faz uma solicitação, o mecanismo de banco de dados carrega a solicitação na memória e marca as páginas como "sujos" (uma página "suja" é uma página que foi gravada com dados e ainda está sendo mantida na memória). Essas páginas sujas são posteriormente gravadas bancos de dados do armazenamento de informações no disco.

Manter a consistência de banco de dados

Embora o armazenamento em cache na memória seja a maneira mais eficiente para processar dados, um efeito é que as informações no disco nunca seja completamente atualizadas. Sujas páginas na memória causar bancos de dados a ser sinalizada como inconsistentes, embora o Exchange Server está funcionando normalmente. Bancos de dados estão realmente em um estado consistente apenas quando todas as páginas sujas com êxito são transferidos do disco durante um desligamento no qual nenhum erro ocorrer.

E se você perder o conteúdo da memória? Por exemplo, se o servidor falha antes que os dados seja gravados em disco e você são deixados com um banco de dados inconsistente? Exchange usa arquivos de log de transações para se recuperar dessa situação.

Arquivos de log de transação

Arquivos de log de transações manter uma cópia segura de dados voláteis que está na memória. Se o sistema falhar, supondo que o banco de dados é não danificado, os arquivos de log permitem que você recuperar dados até a última transação confirmada antes da falha. (Observe que é recomendável que você armazene os arquivos de log em um disco rígido dedicado, para que os logs não são afetados por falhas de disco possíveis que podem danificar o banco de dados.)

Exchange é um sistema de mensagens "com base em transação" e o armazenamento de informações é um banco de dados transacional. Uma transação é um conjunto de alterações em um banco de dados, como inserções, exclusões e atualizações, na qual o sistema segue quatro constantes "ACID":
  • Atômica: O todas as operações ocorrem ou nenhum deles ocorrer.
  • Consistente: O banco de dados é transformado de um estado correto para outro.
  • Isolado: Alterações não são visíveis até que eles sejam confirmados.
  • Durable: Transações confirmadas são preservadas no banco de dados mesmo que o sistema trave.
Seguir essas constantes significa que o mecanismo de banco de dados confirma uma transação somente quando ele pode garante que os dados são duráveis ou persistente, o protegidos contra falhas ou outras falhas. O mecanismo de banco de dados registra dados somente quando os dados foi transferidos da memória para o arquivo de log de transação no disco rígido.

Por exemplo, para mover uma mensagem da pasta caixa de entrada para a pasta importante, Exchange Server executa três operações:
  1. Exclui a mensagem na pasta caixa de entrada
  2. Insere a mensagem na pasta importante
  3. Atualiza as informações sobre cada pasta para refletir o número de itens e itens não lidos
Essas operações são realizadas em uma transação. A ordem das operações não importa. Exchange Server pode excluir com segurança a mensagem da pasta caixa de entrada porque a exclusão é confirmada somente quando a mensagem com segurança é inserida na pasta importante. Mesmo se o sistema falha, o Exchange Server nunca perde uma mensagem ao movê-lo e nunca termina com duas cópias da mensagem.

Logicamente, você pode considerar os dados como movendo da memória para o arquivo de log e, em seguida, para o banco de dados no disco, mas o que realmente acontece é que dados move da memória para o banco de dados no disco. Os arquivos de log são otimizados para alta velocidade gravações, portanto, durante operações normais, o mecanismo de banco de dados, na verdade, nunca lê os arquivos de log. Ele lê dos arquivos de log somente se o serviço de armazenamento de informações pára de forma anormal ou falha e o mecanismo de banco de dados precisa recuperar por repetir os arquivos de log.

o arquivo de ponto de verificação

O mecanismo de banco de dados mantém um arquivo de ponto de verificação chamado edb.chk para cada seqüência de arquivo de log para manter o controle dos dados que ainda não tem sido gravados para o arquivo de banco de dados no disco. O arquivo de ponto de verificação é um ponteiro na seqüência de log que indica onde o armazenamento de informações do arquivo no log de precisa iniciar a recuperação em caso de falha. O arquivo de ponto de verificação é essencial para a recuperação eficiente. Sem ele, o armazenamento de informações seria inicie desde o início do arquivo de log mais antigo no disco e verifique cada página de cada arquivo de log para determinar se ele tivesse já foram gravado o banco de dados--um processo demorado, especialmente se tudo o que você deseja fazer é tornar o banco de dados consistente.

O arquivo de ponto de verificação está localizado no disco do sistema. Caso você precise recuperar o disco de sistema, esse arquivo estiver faltando provavelmente ou em apenas uma versão inválida. Mas, na maioria dos casos o arquivo de ponto de verificação se encarrega de si mesmo.

log normal

As etapas a seguir ilustram o processo de onde dados são gravados para arquivos de log de transação "normal log":
  1. O usuário envia uma mensagem.
  2. O armazenamento de informações para informar que o usuário está enviando a mensagem de chamadas de MAPI.
  3. O armazenamento de informações inicia uma transação no mecanismo de banco de dados e faz as alterações correspondentes aos dados.
  4. O mecanismo de banco de dados registra a transação na memória por dirtying uma nova página na memória.
  5. Simultaneamente, o mecanismo de banco de dados protege a transação no arquivo de log de transações e cria um registro de log. Quando o mecanismo de banco de dados chega ao fim de um arquivo de log de transações, ele passa e cria um novo arquivo de log em seqüência.
  6. O mecanismo de banco de dados grava a página com problemas no arquivo de banco de dados no disco rígido.
  7. O arquivo de ponto de verificação é atualizado.
log circular

Exchange Server oferece suporte a um recurso chamado log circular, o que foi implementada uma vez quando os administradores foram mais preocupados com espaço em disco no servidor que sobre recuperação de dados.

Registro em log circular funciona praticamente a mesma forma como normal log exceto que o arquivo de ponto de verificação é essencial para manter controle das informações que são transferidas para o disco. Durante o registro em log circular, como os avanços de arquivo de ponto de verificação para o próximo arquivo de log, arquivos antigos são reutilizados. Quando isso acontecer, você não pode usar os arquivos de log no disco em conjunto com sua mídia de backup para restaurar para a transação confirmada mais recente.

Por padrão, registro em log circular está ativado no Exchange Server 5.5 para manter um tamanho fixo para arquivos de log e evitar buildup. Quando um arquivo de log atinge seu limite de 5 MB, o mecanismo de banco de dados exclui-lo e cria um novo arquivo de log na seqüência. Como resultado, o Exchange Server mantém apenas dados suficientes no disco rígido para tornar o banco de dados consistente se ocorrer uma falha.

É recomendável que você desative o log circular no seu computador Exchange Server. Registro em log circular pode reduz a necessidade de espaço em disco, mas ele também elimina sua capacidade de recuperar até a última transação confirmada antes de uma falha. Você não pode reproduzir arquivos de log e só pode recuperar os dados até o último backup completo. Mesmo se somente um arquivo de log é sobrescrito, não é possível recuperar a outros 99 % dos dados do log.

Na verdade, o registro em log circular anula as vantagens de um sistema baseado em transação. Deixar o log circular ativado faz sentido somente se você não precisa seus dados ou se você tiver outros meios de recuperação de dados. Se você estiver preocupado sobre arquivos de log consumir os recursos de disco, é melhor limpá-las realizando backups regulares on-line. Backup remove automaticamente os arquivos de log de transações quando eles não são mais necessários.

Proteção de dados

Parece lógico ache que os arquivos de banco de dados são o aspecto mais importante da recuperação de dados. Mas no Exchange Server, arquivos de log de transações são mais importantes porque eles contêm informações que não são os arquivos de banco de dados. (Isso é por que você deve localizá-los em um servidor estável e colocá-los em discos dedicados de alto desempenho, mesmo que isso significa colocar os arquivos de banco de dados em discos mais lentos.)

Arquivos de log de transações manter uma cópia segura no disco de dados voláteis que está na memória para que o sistema pode recuperar em caso de falha. Se o sistema falha, mas o banco de dados estiver não danificado, contanto que você tenha os arquivos de log, você pode recuperar dados até a última transação confirmada antes da falha.

Arquivos de log de transações também fazer a gravação de dados mais eficientes porque ele é mais rápido para atualizar páginas seqüencialmente em um arquivo de log que ao inserir páginas em banco de dados. Quando ocorre uma alteração no banco de dados, o mecanismo de banco de dados atualiza os dados na memória. Ele grava um registro da transação síncrona o arquivo de log, informando a ele como refazer a transação se o sistema falhar. Em seguida, o mecanismo de banco de dados grava os dados para o banco de dados no disco. Para minimizar a entrada/saída de disco, o mecanismo de banco de dados transfere páginas para o disco em lotes.

Cada arquivo de log em uma seqüência pode conter até 5 MB de dados. Quando um arquivo de log estiver cheio, ele é renomeado como um arquivo de log anterior e um novo é criado com o nome do arquivo edb.log. Exchange Server associa cada arquivo de log com um número hexadecimal geração. Como arquivos de log podem ter o mesmo nome, os carimbos de mecanismo de banco de dados o cabeçalho em cada arquivo na seqüência com uma assinatura exclusiva para que ele pode distinguir entre diferentes gerações de arquivos de log.

Corrupção de banco de dados

Exchange pode enfrentar uma falha, como uma falha de hardware, que requer o sistema para tentar voltar para um estado consistente. Porque existem tipos diferentes de corrupção de banco de dados com diferentes Sintomas, diferentes ferramentas e técnicas são necessários para diagnosticar e corrigir problemas.

Há dois tipos de dano:
  • Dano físico
    No nível mais baixo, dados podem se tornar corrompidos fisicamente no disco. Isso geralmente é um problema relacionado ao hardware que sempre requer que você restaurar a partir do backup.
  • Corrupção lógica
    Corrupção lógica típica ocorre no nível do banco de dados. Por exemplo, falha no mecanismo de banco de dados poderá causar entradas de índice apontar para valores ausentes. Também pode ocorrer corrupção lógica no nível do aplicativo, em caixas de correio, mensagens, pastas e anexos. Por exemplo, corrupção de nível de aplicativo pode causar contagens de referência incorreta, acesso incorreto níveis de controle, um cabeçalho de mensagem sem um corpo de mensagem e assim por diante.

Corrupção física

Dano físico é sério, pois ele pode destruir dados e a única coisa que você pode fazer é restaurar Exchange a partir do backup. É importante que você detecta dano físico no início e resolver os problemas rapidamente.

detecção de corrupção física

Física corrupção no armazenamento de informações gera os seguintes erros no log de aplicativo do Visualizar eventos:
  • -1018 (JET_errReadVerifyFailure) os dados lidos do disco não são o mesmo que os dados que foi gravados em disco.
  • -1022 (JET_errDiskIO) O hardware, driver de dispositivo ou sistema operacional está retornando erros.
  • -510 JET_errLogWriteFail os arquivos de log estão fora do espaço em disco ou há uma falha de hardware com o disco do arquivo de log.
Embora o Exchange normalmente exiba uma mensagem de erro-1018 ou-1022 quando houver dano físico, você também pode detectar dano físico realizando backups online, que são o método recomendado da Microsoft para fazer backup de dados. Backup online também é a melhor maneira de detectar dano em um arquivo de banco de dados porque ele é o único processo que verifica sistematicamente cada única página do banco de dados.

Quando você executa um backup online, o software de backup do Windows NT lê cada página de 4 KB no arquivo de banco de dados, passa para o mecanismo de banco de dados e, em seguida, grava essa fita. O mecanismo de banco de dados verifica se a soma de verificação em cada página é correta. Se a soma de verificação na página não coincidir com a soma de verificação que calcula o mecanismo de banco de dados, há corrupção do banco de dados físico no disco rígido e logs de backup do NT de um erro -1018.

evitando a corrupção física

A melhor maneira para evitar corrupção física é preparar o servidor com qualidade de componentes de hardware e configurar o sistema corretamente. Verifique se que não estão executando utilitários de nível de arquivo, como software antivírus, nos arquivos de banco de dados e de log no computador que executa o Exchange Server.

Se você tiver hardware confiável, você nunca verá indicações de dano físico. Se você executar consistentemente em erros -1018, você provavelmente terá um problema de hardware, e possivelmente um disco defeituoso ou controlador de disco.

Uma palavra sobre cache de write-back: alguns controladores de matriz de cache de write-back incorretamente retornar confirmações bem-sucedidas em transações antes que os dados realmente foi protegidos para disco. O curso mais seguro é desativar cache de write-back, a menos que o processo de tenha bateria backup. Se você usar cache write-back, evite ter um banco de dados corrompido, certificando-se que os dados é totalmente protegidos e que você tenha procedimentos para garantir que dados armazenados em cache são repetidos para os discos direita após uma falha.

recuperação de corrupção física

A única maneira de recuperar de corrupção de banco de dados físico é restaurar do último backup boa (se tiver executado um backup sem erros, é recomendável) e rolo encaminhar os arquivos de log para trazer o sistema para um estado consistente e não danificado. Falha repetida provavelmente indica um problema com o disco onde está localizado o banco de dados.

Não é realmente possível seguro para reparar o dano físico para o banco de dados. Você pode executar o Eseutil.exe utilitário no modo de reparo para obter o banco de dados funcionando novamente, mas isso não é recomendável porque Eseutil simplesmente exclui páginas incorretas.

Observação: Se ele for em todos os possível, evitar usando o Eseutil no modo de reparo (Eseutil /p). Eseutil, que vem com o Exchange Server, é um último recurso para reparar o dano do banco de dados quando tudo o mais falhar. No modo de reparo, ele obtém um banco de dados interrompido executando novamente, simplesmente excluindo páginas danificadas. Eseutil nunca deve ser usado para recuperar dados. Se você executar o comando Eseutil /p , você também deve executar uma desfragmentação offline ( Eseutil /d ) e, em seguida, deve executar o comando Isinteg - test alltests - correção para restaurar o banco de dados para um estado consistente.

Corrupção lógica

Corrupção lógica é muito mais difícil de diagnosticar e corrigir de dano físico como corrupção lógica é imprevisível e geralmente é causada por bugs de software. Geralmente ele requer um problema para alertá-lo à corrupção lógica. (A corrupção lógica é extremamente rara no Exchange Server 5.5.)

evitando a corrupção lógica

Como corrupção lógica é tão imprevisível, não é possível à prova de falhas para impedi-lo. No entanto, há maneiras de reduzir o risco:
  • Instalar o service pack mais recente para o Microsoft Exchange Server versão 5.5 assim que possível. Os service packs corrigem um número de problemas conhecidos no Exchange Server 5.5.

    Para obter informações adicionais sobre service packs e como obtê-los, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
    241740Lista de erros corrigidos no Exchange Server 5.5 Service Pack 3
    254682XADM: Exchange Server 5.5 Post-SP3 Database Engine correções
    191014Como obter o Service Pack mais recente do Exchange Server 5.5
  • Certifique-se que seu computador Exchange Server está seguro e que a configuração não é alterada.
Se você descobre um problema e ele persiste após você seguir nessas precauções, você pode ter encontrado um novo bug. Se for esse o caso, notifique Microsoft assim que possível.
reparando corrupção lógica

Lógica corrupção pode ocorrer no armazenamento de informações ou no mecanismo de banco de dados. Como corrupção lógica pode causar sérios danos aos dados, não ignore relatórios de erros.

Você pode usar o Isinteg utilitário para verificar problemas no armazenamento de informações ou o utilitário Eseutil para verificar problemas no mecanismo de banco de dados. Observe que você deve usar esses utilitários somente como último recurso após você ter tentado restaurar o sistema de backup.

o utilitário Isinteg

O Information Store Integrity Checker (Isinteg) localiza e elimina erros de bancos de dados armazenamento de informações públicas e particulares. Esses erros podem impedir o armazenamento de informações iniciar ou impedir que os usuários fazer logon e receber, abertura ou exclusão de emails.

Isinteg não deve ser usada como parte da manutenção do armazenamento de informações normal; ele é fornecido para ajudar nas situações de recuperação de desastres. Por exemplo, você pode executar Isinteg para corrigir os contadores de armazenamento de informações na memória quando eles ficam fora de sincronia após uma falha do sistema.

Porque o utilitário Isinteg funciona no nível de esquema lógico, ele pode recuperar dados que não é possível recuperar o utilitário Eseutil. Isso ocorre porque os dados que é válidos para o utilitário Eseutil no nível do esquema físico podem ser semanticamente inválidos no nível de esquema lógico. Isinteg grava informações no log do aplicativo em Visualizar eventos para que você pode controlar o progresso da recuperação.

O utilitário Isinteg executa duas tarefas principais:
  • Ele patches o armazenamento de informações após uma restauração de um backup offline.
  • Ele testa e, opcionalmente, corrige erros no armazenamento de informações.
Para informações adicionais sobre o utilitário Isinteg e armazenamento de informações de solução de problemas, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
182081XADM: Descrição do utilitário ISINTEG

ou consulte o documento Isinteg.rtf no CD do Exchange Server 5.5, na pasta Support\Utils.

o utilitário Eseutil

O utilitário Eseutil examina a estrutura de tabelas de banco de dados e registros e desfragmenta, repara e verifica a integridade do armazenamento de informações e diretório. Porque simplesmente executando Eseutil no modo de reparo exclui páginas danificadas, use este utilitário somente após você ter tentado restaurar a partir do backup.

Para obter informações adicionais sobre o utilitário Eseutil, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
192185XADM: Como desfragmentar com o utilitário ESEUTIL (Eseutil.exe)
ou consulte o documento Eseutil.rtf no Exchange 5.5 um CD na pasta Support\Utils.

Backup de dados

Como o Exchange Server é baseado em transação, evite executar um backup offline ou nível de arquivo dos arquivos do banco de dados no disco. A melhor maneira de garantir que você está preservando todos os dados no sistema, incluindo as transações que ainda não foram liberados para o disco, é para executar backups regulares on-line.

Backup online

Backup online permite que você fazer backup de bancos de dados do Exchange Server em sua mídia de backup sem desligar o servidor. Ao Exchange Server é realizar um backup online, todos os serviços, incluindo o armazenamento de informações, continuam a executar normalmente. Páginas continuam a ser atualizado na memória e transferidas para os arquivos de banco de dados no disco, transações são registradas nos arquivos de log e o arquivo de ponto de verificação continua a mover.

Exchange usa um arquivo .pat (patch) que mantém registro das páginas atualizadas enquanto o software de backup é executado, para garantir que páginas que são modificadas durante o backup também foi efetuadas backup. Existem dois arquivos .pat, Priv.pat para o armazenamento de informações particulares e Pub.pat para o armazenamento de informações públicas.

Quando você executa um backup online, verifique regularmente o log do aplicativo em Visualizar eventos para garantir que os backups são concluída com êxito.

processo de backup online

Um programa de backup, por exemplo Windows NT Backup (Ntbackup.exe), faz o seguinte durante um backup completo ou um backup de cópia:
  1. Faz uma cópia do banco de dados e faz o backup para a fita.
  2. Adiciona um subconjunto de páginas para o arquivo .pat, as páginas que alterar após sendo copiados para a fita.
  3. Renomeia o arquivo edb.log atual para Edb x .log, onde x é o número de geração de arquivo de log em formato hexadecimal e cria uma nova geração de log.
  4. Um backup completo, faz o backup o arquivo .pat e todos os arquivos de log após o ponto de verificação (exceto nova edb.log) para a fita. Um backup de cópia, faz o backup todos os arquivos de log de antes e após o ponto de verificação.
  5. Em um backup completo, exclui arquivos de log de transação mais antigos do que o ponto de verificação. Em um backup de cópia, não exclui qualquer arquivo de log de transações.
Um programa de backup faz o seguinte durante um backup diferencial ou de um backup incremental:
  1. Em um incremental backup, faz uma cópia do log de arquivos e faz-las até a fita. Em um backup diferencial copia o banco de dados em fita.
  2. Adiciona um subconjunto de páginas para o arquivo .pat, as páginas que alterar após sendo copiados para a fita.
  3. Renomeia o arquivo edb.log atual para Edb x .log e cria uma nova geração de log.
  4. Faz backup de arquivo .pat e todos os arquivos de log antes e após o ponto de verificação, incluindo o Edb.log novo, a fita.
  5. Em um backup incremental, exclui arquivos de log de transação mais antigos que o ponto de verificação. Em um backup diferencial não exclui os arquivos de log.

Backup offline

Tente evitar fazer backups offline. Em um backup online, o programa de backup gerencia arquivos para você, mas backup offline é um processo manual e trabalhoso propenso a erro humano. Além disso, em um backup offline, não é possível validar a soma de verificação em cada página do banco de dados. Backups online são a única ferramenta mais valioso para detecção de corrupção e executar recuperação de dados.

Para obter informações adicionais sobre os backups, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
191357XADM: Restaurar um único banco de dados de backups online total
179308XADM: Como verificar os backups online do Exchange

Propriedades

ID do artigo: 271987 - Última revisão: sábado, 28 de outubro de 2006 - Revisão: 5.1
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Palavras-chave: 
kbmt kbinfo KB271987 KbMtpt
Traduçã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: 271987

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com