Compartilhar via

Informações sobre o repositório do Exchange 2010

  • Artigo

 

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

Tópico modificado em: 2016-11-28

O repositório do Exchange é uma plataforma de repositório que fornece um único repositório para gerenciamento de vários tipos de informações em uma infra-estrutura. O repositório do Exchange (store.exe) é o repositório principal de repositório de dados do Microsoft Exchange.

Conteúdo

Bancos de dados em edições do Exchange 2010

Componentes Lógicos do repositório do Exchange

Estrutura do arquivo do repositório do Exchange

Compreendendo o log de transação

Mecanismo de repositório Extensível

Integridade do repositório

Pouco espaço em disco nos logs de banco de dados ou nas unidades de banco de dados

Limites de armazenamento do Exchange

Bancos de dados em edições do Exchange 2010

O Exchange 2010 está disponível em duas edições do servidor: Server Enterprise Edition e Server Standard Edition. O Exchange 2010 Standard Edition foi projetado para atender às necessidades de mensagens e colaboração de corporações pequenas e médias; ele também pode ser adequado para funções de servidor específicas ou filiais. O Exchange 2010 Enterprise Edition foi projetado para grandes empresas.

O Exchange 2010 Standard Edition oferece suporte a até cinco bancos de dados. O Exchange 2010 Enterprise Edition oferece suporte a até 100 bancos de dados.

Componentes Lógicos do repositório do Exchange

Os principais componentes do repositório do Exchange são os bancos de dados de caixas de correio e de pastas públicas. Esses componentes podem se localizar em um único servidor ou podem ser distribuídos por vários servidores.

Os bancos de dados de caixa de correio contêm os dados, definições de dados, índices, somas de verificação, sinalizadores e outras informações que constituem as caixas de correio do Exchange 2010. Bancos de dados de caixa de correio contêm dados particulares de um usuário individual e contêm pastas de caixa de correio geradas quando uma caixa de correio é criada para esse usuário. Um banco de dados de caixa de correio é armazenado como um arquivo de banco de dados (.edb) do Exchange.

Os bancos de dados de pasta pública contêm os dados, definições de dados, índices, somas de verificação, sinalizadores e outras informações que constituem quaisquer pastas públicas de sua organização do Exchange.

No Exchange 2010, você gerencia pastas públicas usando o Shell de Gerenciamento do Exchange. (Você também pode executar um número limitado de tarefas de gerenciamento de banco de dados de pasta pública no Console de Gerenciamento do Exchange.) Para obter mais informações sobre como gerenciar pastas públicas, consulte Gerenciando pastas públicas e Noções Básicas Sobre Pastas Públicas.

Bancos de dados em edições do Exchange 2010

Estrutura do arquivo do repositório do Exchange

Você gerencia o repositório do Exchange trabalhando com seus componentes lógicos, como bancos de dados. No entanto, o Exchange 2010 armazena dados em um conjunto especializado de arquivos de dados, como arquivos de banco de dados do Exchange (.edb), arquivos de log de transação (.log) e arquivos de ponto de verificação (.chk). A menos que você esteja fazendo backup ou restaurando dados, raramente precisará interagir com esses arquivos diretamente. A tabela a seguir descreve cada um desses arquivos com mais detalhes.

Estrutura do arquivo do repositório do Exchange

Arquivo de dados Descrição

Banco de dados do Exchange (.edb)

Esses arquivos são o repositório para dados de caixa de correio. Eles são acessados pelo ESE (Mecanismo de Armazenamento Extensível) diretamente e possuem uma estrutura de árvore B projetada para acesso rápido. Isso permite que os usuários acessem qualquer página de dados em um ciclo de E/S, um resultado quatro vezes melhor em comparação ao Exchange Server 2007. Os bancos de dados do Exchange são compostos por várias árvores B, com árvores auxiliares que trabalham com a árvore principal, contendo índices e exibições.

Log de transações (.log)

Esses arquivos são o repositório para operações como a criação ou a modificação de uma mensagem. As operações confirmadas são posteriormente gravadas no próprio banco de dados (em um arquivo .edb). Essa abordagem garante que todas as transações finalizadas e em andamento sejam registradas em log para que a integridade dos dados seja mantida em caso de interrupção do serviço. Cada banco de dados tem seu próprio conjunto de logs de transação.

Ponto de verificação (.chk)

Esses arquivos são o repositório de dados que indicam quando uma operação é gravada com êxito no banco de dados no disco rígido. O Exchange 2010 usa arquivos .chk para que uma instância do ESE possa repetir arquivos de log automaticamente em um banco de dados inconsistente ao recuperar-se de uma interrupção de serviço, começando com a próxima operação não gravada. Os arquivos .chk são posicionados no mesmo local de log dos arquivos .log.

Bancos de dados em edições do Exchange 2010

Compreendendo o log de transação

O log de transações do Exchange é um mecanismo de recuperação robusto do ESE, projetado para restaurar de forma confiável um banco de dados do Exchange para um estado consistente depois de uma parada súbita do banco de dados. O mecanismo de log também é usado ao restaurar backups online. Esta seção descreve os detalhes do log de transações no Exchange 2010 e inclui uma breve descrição do log circular.

Log de transações do Exchange

Antes que alterações sejam feitas em um arquivo de banco de dados do Exchange, o Exchange grava as alterações em um arquivo de log de transações. Depois que uma alteração tiver sido registrada com segurança, ela poderá ser gravada no arquivo de banco de dados. É comum que essas alterações se tornem disponíveis para usuários finais logo depois que as alterações tenham sido protegidas no log de transações, mas antes que tenham sido gravadas no arquivo de banco de dados.

O Exchange emprega um sofisticado sistema de gerenciamento de memória interna ajustado para alto desempenho, e que gerencia de forma eficiente o cache de dezenas de gigabytes (GB) de páginas de banco de dados. Gravar fisicamente as alterações no arquivo de banco de dados é uma tarefa de baixa prioridade durante a operação normal.

Se um banco de dados parar de repente, as alterações armazenadas em cache não serão perdidas só porque o cache de memória foi destruído. Quando o banco de dados é reiniciado, o Exchange verifica os arquivos de log e reconstrói e aplica qualquer alteração ainda não gravada no arquivo de banco de dados. Esse processo é chamado repetição de arquivos de log. O banco de dados é estruturado para que o Exchange possa determinar se qualquer operação em qualquer arquivo de log já foi aplicada ao banco de dados, se precisa ser aplicada ao banco de dados ou se não pertence ao banco de dados.

Em vez de gravar todas as informações de log em um único arquivo grande, o Exchange usa uma série de arquivos de log, cada um com exatamente um megabyte (MB), ou 1.024 quilobytes (KB), de tamanho. Quando um arquivo de log estiver cheio, o Exchange o fechará e o renomeará com um número seqüencial. O primeiro log que é preenchido termina com o nome Enn00000001.log. O nn se refere a um número de dois dígitos conhecido como nome base ou prefixo de log.

Os arquivos de log de cada banco de dados são diferenciados por nomes de arquivo com prefixos numerados (por exemplo, E00, E01, E02 ou E03). O arquivo de log atualmente aberto para um banco de dados é nomeado simplesmente Enn.log. Ele não tem um número de sequência até que seja preenchido e fechado.

O arquivo de ponto de verificação (Enn.chk) controla até que ponto o Exchange progrediu na gravação de informações registradas nos arquivos de banco de dados. Há um arquivo de ponto de verificação para cada fluxo de log e um fluxo de log separado para cada banco de dados.

Arquivos de log são numerados em um formato hexadecimal; portanto, o arquivo de log depois de E0000000009.log é E000000000A.log, e não E0000000010.log. Você pode converter números de sequência de arquivo de log em seus valores decimais usando o aplicativo Calculadora do Windows (Calc.exe) no modo Científica. Para fazer isso, execute Calc.exe e, em seguida, no menu Exibir, clique em Científica.

Para exibir o número de seqüência decimal para um arquivo de log específico, você pode examinar seu cabeçalho usando a ferramenta Exchange Server Database Utilities (Eseutil.exe). A primeira página de 4 KB de cada arquivo de log contém informações de cabeçalho que descrevem e identificam o arquivo de log e os bancos de dados a que ele pertence. O comando Eseutil /ml [log file name] exibe as informações de cabeçalho.

Se você usar a opção incorreta para exibir um cabeçalho (por exemplo, usando /ml com um cabeçalho de banco de dados em vez de /mh), um erro será exibido ou as informações de cabeçalho que serão exibidas poderão estar confusas ou incorretas.

Não é possível exibir o cabeçalho de uma banco de dados enquanto ele estiver montado. Também não é possível exibir o cabeçalho do arquivo de log atual (Enn.log) enquanto qualquer banco de dados estiver montado. O Exchange mantém o arquivo de log atual aberto enquanto ele estiver sendo utilizado por um banco de dados. Porém, o cabeçalho do arquivo de ponto de verificação pode ser exibido enquanto os bancos de dados estiverem montados. O Exchange atualiza o arquivo de ponto de verificação a cada trinta segundos e seu cabeçalho pode ser exibido, exceto durante o momento em que uma atualização está ocorrendo.

Como um administrador do Exchange, vale a pena compreender os cabeçalhos de arquivo do Exchange. Se você compreender os cabeçalhos de arquivo, poderá determinar quais arquivos de banco de dados e log são correspondentes e quais arquivos são necessários para uma recuperação bem-sucedida.

No seguinte exemplo de cabeçalho de arquivo de log, observe as primeiras quatro linhas.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Essas linhas de cabeçalho do arquivo de log mostram que esse arquivo de log é o arquivo de log atual porque o nome de arquivo de log não tem um número de sequência. A linha lGeneration mostra que quando o log for preenchido e fechado, seu número de sequência será B, correspondendo ao valor decimal 11. O nome base é e00 e, portanto, o nome de arquivo do log final será E000000000B.log.

O valor Checkpoint no exemplo do cabeçalho anterior não é realmente lido do cabeçalho de arquivo de log, mas é exibido como se fosse. Eseutil.exe lê o valor Checkpoint diretamente de Enn.chk, para que você não tenha que inserir um comando separado para saber onde o arquivo de ponto de verificação está. Se o arquivo de ponto de verificação tiver sido destruído, o valor Checkpoint exibirá NOT AVAILABLE. Nesse caso, o ponto de verificação no arquivo de log atual (0xB) e os números 7DC e 6F indicam o local no arquivo de log onde está o ponto de verificação. Observe que raramente essa informação tem alguma necessidade prática.

Se o arquivo de ponto de verificação for destruído, o Exchange ainda poderá recuperar e repetir arquivos de log de forma apropriada. Mas, para fazer isso, o Exchange começa verificando arquivos de log, começando com o arquivo mais antigo disponível, em vez de começar no log de ponto de verificação. O Exchange ignora os dados que foram aplicados ao banco de dados e prossegue sequencialmente pelos logs até que dados que devam ser aplicados sejam encontrados.

Geralmente, são necessários um ou dois segundos para que o Exchange verifique um arquivo de log que foi aplicado ao banco de dados. Se houver operações em um arquivo de log que devam ser gravadas no banco de dados, poderão ser necessários de 10 segundos a vários minutos para aplicá-las. Em geral, o conteúdo de arquivo de log pode ser gravado no banco de dados em 30 segundos ou menos.

Quando um banco de dados do Exchange é desligado normalmente, todos os dados pendentes são gravados nos arquivos de bancos de dados. Depois do desligamento normal, o conjunto de arquivos de banco de dados é considerado consistente e o Exchange o desanexa do seu fluxo de log. Isso significa que os arquivos de bancos de dados agora são independentes (atualizados). Os logs de transações não são necessários para iniciar os arquivos de bancos de dados.

Você pode saber se um banco de dados foi desligado normalmente executando o comando Eseutil /mh e examinando os cabeçalhos de arquivo.

Com todos os bancos de dados desconectados e em um estado de Desligamento Normal, todos os arquivos de log podem ser excluídos com segurança sem afetar os bancos de dados. Se você fosse excluir todos os arquivos de log, o Exchange geraria uma nova sequência de logs começando com Enn00000001.log. Você poderia mover os arquivos de banco de dados para um servidor diferente que tenha arquivos de log existentes e os bancos de dados seriam anexados a um fluxo de log diferente.

Dica

Embora você possa excluir os arquivos de log depois que todos os bancos de dados tiverem sido desligados, isso afetará sua capacidade de restaurar backups mais antigos e efetuar roll forward. O banco de dados atual não necessita mais dos arquivos de log existentes, mas eles poderão ser necessários se você precisar restaurar um banco de dados mais antigo.

Se um banco de dados estiver em um estado de Desligamento Anormal, todos os logs de transações existentes do ponto de verificação em diante deverão estar presentes para que você possa montar o banco de dados novamente. Se esses logs estiverem indisponíveis, você deverá reparar o banco de dados executando o comando Eseutil /p para tornar o banco de dados consistente e pronto para ser iniciado.

Aviso

Se você precisar reparar um banco de dados, alguns dados serão perdidos. Freqüentemente, a perda de dados é mínima; porém, ela pode ser catastrófica. Depois de executar Eseutil /p em um banco de dados, você deve executar Eseutil/ d para desfragmentar o banco de dados. Essa operação descarta e reconstrói todos os índices de banco de dados e árvores de espaço.

Além de permitir que o Exchange seja recuperado com confiabilidade de uma parada de banco de dados inesperada, o log de transações é também essencial para fazer e restaurar backups online. Para obter mais informações sobre como fazer e restaurar backups online, consulte Understanding Backup, Restore and Disaster Recovery.

Bancos de dados em edições do Exchange 2010

Log circular

Você pode configurar o Exchange para economizar espaço em disco habilitando o log circular. O log circular permite que o Exchange substitua arquivos de log de transações depois que os dados contidos nos arquivos de log tiverem sido confirmados para o banco de dados. Porém, se o log circular estiver habilitado, será possível recuperar dados somente até o último backup completo. É possível, por exemplo, habilitar o log circular ao usar a proteção de dados nativa do Exchange, na qual você não faz backups. Habilite o log circular para impedir o acúmulo de logs.

No log de transações padrão usado pelo Exchange 2010, cada transação de banco de dados é gravada em um arquivo de log e, depois, no banco de dados. Quando um arquivo de log atinge um MB, ele é renomeado e um novo arquivo de log é criado. Com o tempo, isso resultará em um conjunto de arquivos de log. Se o Exchange parar inesperadamente, você poderá recuperar as transações repetindo os dados desses arquivos de log no banco de dados. O log circular substitui e reutiliza o primeiro arquivo de log depois que os dados contidos nele foram gravados no banco de dados.

No Exchange 2010, o log circular está desabilitado por padrão. Ao habilitá-lo, você reduz os requisitos de espaço de repositório da unidade. Entretanto, sem um conjunto completo de arquivos de log de transações, não é possível recuperar qualquer dado mais recente do que o último backup completo. Em um ambiente de produção normal, o log circular não é recomendável.

Para obter informações sobre como habilitar e desabilitar o log circular, consulte Configurar Propriedades do Banco de Dados da Caixa de Correio.

Bancos de dados em edições do Exchange 2010

Mecanismo de repositório Extensível

Os bancos de dados de caixa de correio do Exchange e a fila dos servidores de Transporte de Hub e de Transporte de Borda utilizam o banco de dados ESE. O ESE é um gerenciador de tabela do ISAM (método de acesso sequencial indexado) para vários usuários com recursos completos de DML (linguagem de manipulação de dados) e DDL (linguagem de definição de dados). O ESE permite que os aplicativos armazenem registros e cria índices para acessar esses registros de formas diferentes. Para obter mais informações sobre o ESE, consulte Extensible Storage Engine Architecture (em inglês). Para melhorias no ESE do Exchange 2010, consulte Nova Funcionalidade de Repositório Principal do Exchange.

Bancos de dados em edições do Exchange 2010

Integridade do repositório

O repositório do Exchange pode detectar e corrigir vários cenários que podem fazer com que o repositório perca a integridade. O repositório do Exchange pode lidar com caixas de correio suspeitas e tempo limite de threads, usar recursos de relatório e alerta para marcar um estado não íntegro do repositório do Exchange e detectar e corrigir problemas com os bancos de dados de caixa de correio e pasta pública.

Correção e detecção de caixa de correio suspeita

Em alguns casos, uma única caixa de correio com dados corrompidos (lógicos ou físicos) pode causar falha no repositório do Exchange, e uma negação de serviço a todas as caixas de correio hospedadas pelo servidor. De forma semelhante, uma caixa de correio suspeita também pode fazer com que o repositório do Exchange falhe repetidamente. Esta seção descreve as ações tomadas pelo repositório do Exchange para detectar e isolar caixas de correio suspeitas.

Isolando a caixa de correio suspeita

Há vários tipos de eventos nos quais o repositório do Exchange marca uma caixa de correio como uma ameaça em potencial:

  • Se um thread que trabalha para a caixa de correio falha

  • Se houver mais de cinco threads na caixa de correio que não tenham progredido por muito tempo

Uma caixa de correio que seja uma ameaça em potencial é marcada, além de uma contagem indicando quantas vezes ela foi marcada. Essas informações são armazenadas no registro. O repositório do Exchange também mantém informações de carimbo de data/hora de quando a caixa de correio foi identificada como uma ameaça em potencial.

Durante uma montagem de banco de dados, o repositório do Exchange lê a hora em que as caixas de correio foram identificadas como ameaças em potencial. Se mais de duas horas se passarem, a chave de registro da caixa de correio é excluída. A vantagem de manter essas informações no registro é que em um ambiente de alta disponibilidade ela é replicada pelo banco de dados de cluster. Mesmo durante um failover do repositório do Exchange, os outros computadores têm essa informação. O caminho de registro usado para isolar a caixa de correio suspeita é HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome do Servidor>\Private-{guid do banco de dados}\QuarantinedMailboxes\{guid da caixa de correio}. As chaves para esse caminho são CrashCount e LastCrashTime.

As configurações de quantas falhas levam à quarentena de uma caixa de correio e por quanto tempo uma caixa de correio deve permanecer em quarentena são armazenadas nas chaves MailboxQuarantineCrashThreshold e MailboxQuarantineDurationInSeconds no caminho de registro HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome do Servidor>\Private-{guid do banco de dados}\QuarantinedMailboxes.

Os valores padrão dessas chaves são três falhas para MailboxQuarantineCrashThreshold e 21.600 segundos (seis horas) para MailboxQuarantineDurationInSeconds.

Atuando na caixa de correio suspeita

Por padrão, se uma caixa de correio for identificada como causadora de uma falha ou deadlock por três vezes em duas horas, o repositório do Exchange a marca como em quarentena no registro. O acesso à caixa de correio não é permitido, a não ser que o sinalizador OPEN_AS_ADMIN seja passado. Nenhum dos processos do Exchange (por exemplo, a indexação de conteúdo ou os assistentes de Caixa de Correio) pode fazer logon. As chaves de registro QuarantineState e QuarantineTime monitoram se a caixa de correio está em quarentena. Se a caixa de correio não tiver causado nenhuma falha nas últimas duas horas e não estiver em quarentena, o caminho de registro da caixa de correio é limpo pelo repositório do Exchange. Se uma caixa de correio estiver em quarentena por mais tempo do que o valor de MailboxQuarantineDurationInSeconds desde seu valor de LastCrashTime, ela será liberada da quarentena automaticamente.

Redefinindo a caixa de correio em quarentena

Quando a causa da caixa de correio suspeita for identificada e corrigida, a chave de registro da caixa de correio em quarentena deve ser redefinida manualmente por meio de sua exclusão. No entanto, se essa etapa manual for esquecida, o repositório do Exchange redefinirá automaticamente as caixas de correio em quarentena seis horas após a sinalização de quarentena ter sido definida. Se o problema não for depurado e corrigido nesse período, podem ocorrer outras falhas até que a caixa de correio ou a mensagem entre em quarentena novamente.

Dica

O banco de dados que hospeda a caixa de correio precisa ser montado novamente, ou o repositório do Exchange precisa ser reiniciado, para que a redefinição da caixa de correio em quarentena tenha efeito.

O período para redefinição de caixas de correio em quarentena pode ser controlado pela chave de registro HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nome do Servidor>\Private-{guid do banco de dados}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Relatórios e alertas

Você pode usar o cmdlet Get-MailboxStatistics para relatar o estado de quarentena de uma caixa de correio. O repositório do Exchange tem um contador do Monitor de Desempenho para a quantidade de caixas de correio em quarentena. O nome do contador é MSExchangeIS Número de Caixas de Correio\Caixas de Correio em Quarentena.

O repositório do Exchange também grava um evento sempre que põe uma caixa de correio em quarentena, com detalhes sobre qual foi a caixa de correio e a que hora. O evento 10018 identifica uma caixa de correio em quarentena.

Bancos de dados em edições do Exchange 2010

Reparo do Banco de Dados

No Exchange 2010 Service Pack 1 (SP1), use o cmdlet New-MailboxRepairRequest para detectar e reparar corrupções de caixa de correio. Esse cmdlet pode ser executado para uma caixa de correio específica ou para um banco de dados de caixa de correio. Embora essa tarefa esteja em execução, o acesso à caixa de correio foi interrompido para a caixa de correio sendo reparada. Ao executar esse cmdlet para um banco de dados de caixa de correio, apenas o acesso à caixa de correio que estiver sendo reparada será interrompido. Todas as outras caixas de correio no banco de dados permanecem operacionais. Para obter mais informações, consulte Criar uma solicitação para Reparar Caixa de Correio.

O cmdlet New-MailboxRepairRequest detecta e repara os seguintes tipos de corrupções de caixa de correio:

  • Pesquisa de corrupções de pasta (usando o valor SearchFolder do parâmetro CorruptionType)

  • Agregação de contagens em pastas que não estão refletindo os valores corretos (com o uso do valor AggregateCounts do parâmetro CorruptionType)

  • Exibições em pastas que não estão retornando o conteúdo correto (usando o valor FolderView do parâmetro CorruptionType)

  • Pastas fornecidas que estejam apontando incorretamente para pastas pai que não foram fornecidas (com o uso do valor ProvisionedFolder do parâmetro CorruptionType)

Após executar o cmdlet New-MailboxRepairRequest, é possível utilizar o Visualizador de Eventos para exibir os detalhes da solicitação. Para obter mais informações, consulte Exibir Entradas de Solicitação de Reparos de Caixa de Correio no Visualizador de Eventos.

O cmdlet New-PublicFolderDatabaseRepairRequest também pode ser usado para detectar e corrigir os problemas de replicação no banco de dados de pasta pública. As pastas públicas no banco de dados de pasta pública ainda podem ser acessadas enquanto a solicitação estiver em execução. No entanto, o acesso não está disponível para a pasta pública que está sendo reparada atualmente. Para obter mais informações, consulte Criar uma solicitação para reparo do banco de dados de pasta pública.

Bancos de dados em edições do Exchange 2010

Relatórios e detecção de tempo limite

Outra indicação de falta de integridade em um repositório do Exchange é quando os threads estão em deadlock ou não estão progredindo. Se houver mais de cinco threads em uma única caixa de correio, dez threads em um único banco de dados ou vinte threads em um único servidor que não tenham progredido em um minuto, o tempo limite é relatado no servidor. O contador de desempenho que indica os tempos limite detectados é MSExchangeIS\ Tempo Limite de Solicitação de RPC Detectado.

O repositório do Exchange também grava os seguintes eventos no servidor:

  • 10025, que relata um tempo limite no servidor do Exchange

  • 10026, que relata um tempo limite no banco de dados

  • 10027, que relata um tempo limite em uma caixa de correio individual

Se o tempo limite for detectado em uma única caixa de correio, a caixa de correio é considerada potencialmente suspeita, e é tratada de forma similar a uma falha aumentando a chave CrashCount. Isso a torna suscetível à quarentena.

Bancos de dados em edições do Exchange 2010

Pouco espaço em disco nos logs de banco de dados ou nas unidades de banco de dados

Quando o repositório do Exchange detecta que o espaço disponível em um log ou em uma unidade de banco de dados é inferior a 1 GB, ele interrompe toda a entrega de transporte para esse banco de dados. Isso é feito para impedir que um disco fique sem espaço. Quando um disco fica sem espaço, o banco de dados não pode ser montado ou depurado. O espaço do banco de dados também não pode ser recuperado. Trata-se de um mecanismo de autoproteção que só ocorre se você não reagir aos avisos de problemas de espaço de sua infraestrutura de monitoramento.

Quando o espaço em disco fica acima de 1,5 GB, o repositório do Exchange permite que as entregas continuem. Os seguintes contadores de desempenho indicam esse comportamento:

  • Caixa de Correio MSExchangeIS\ Entrega Bloqueada: Pouco espaço no banco de dados

  • Caixa de Correio MSExchangeIS\ Entrega Bloqueada: Pouco espaço de log

O repositório do Exchange também grava os seguintes eventos no servidor:

  • 10014, que indica pouco espaço em disco no log

  • 10015, que indica pouco espaço em disco no banco de dados

Caso tenha problema de pouco espaço em disco, você pode executar as seguintes ações para corrigir o problema:

Bancos de dados em edições do Exchange 2010

Limites de armazenamento do Exchange

No Exchange 2010, limites de conexão e uso foram impostos no armazenamento do Exchange para impedir que um único aplicativo ou um único usuário utilize todas as conexões disponíveis ao repositório do Exchange. Se um único usuário ou aplicativo tiver permissão para usar todas as conexões, outros usuários ou aplicativos não conseguirão acessar o repositório do Exchange o que pode resultar em tempo de inatividade.

Para obter mais informações, consulte Limites de Repositório do Exchange.

Bancos de dados em edições do Exchange 2010

 © 2010 Microsoft Corporation. Todos os direitos reservados.