Compartilhar via

Noções Básicas Sobre o Banco de Dados de Caixa de Correio e Fatores de Capacidade de Log

  • Artigo

Tópico modificado em: 2010-02-03

Este tópico explica os fatores que devem ser considerados ao planejar o banco de dados de caixa de correio e a capacidade de log, como parte do projeto do armazenamento do servidor de caixa de correio no Microsoft Exchange Server 2010.

Capacidade do Banco de Dados de Caixa de Correio

Muitos fatores influenciam o plano da capacidade de dimensionamento de bancos de dados de Caixa de Correio do Exchange Server 2010. Esta seção aborda:

  • Cotas de Armazenamento de Caixa de Correio
  • Espaço em Branco do Banco de Dados
  • Itens Recuperáveis do Banco de Dados de Caixa de Correio
  • Tamanho Real da Caixa de Correio
  • Indexação de Conteúdo
  • Manutenção de Banco de Dados Offline
  • Banco de Dados de Recuperação
  • Tamanho do Banco de Dados
  • Sobrecarga de Crescimento do Banco de Dados

Cotas de Armazenamento de Caixa de Correio

A primeira métrica a ser conhecida é o limite do tamanho do armazenamento, conhecido como cota de armazenamento da caixa de correio, que está em vigor na sua organização. Conhecer a quantidade de dados que um usuário final tem permissão de armazenar em sua caixa de correio permite que você determine quantas caixas de correio de usuário podem ser hospedadas no servidor. Embora as cotas de armazenamento de caixa de correio possam mudar em resposta a alterações nos requisitos organizacionais, ter uma meta para a cota de armazenamento de caixa de correio é o primeiro passo para determinar a capacidade do banco de dados de caixa de correio necessária.

Por exemplo, se você tiver um servidor com 5.000 caixas de correio de usuário de 250 MB cada, você precisa de, no mínimo, 1.25 TB de espaço em disco, excluindo requisitos de espaço para itens recuperáveis. Se um limite não for definido para as cotas de armazenamento de caixas de correio, será difícil estimar a capacidade do banco de dados. As cotas de armazenamento de caixas de correio para o Exchange 2010 precisam incluir o espaço para a caixa de correio principal e para a caixa de correio de arquivo morto (quando usado). Para obter mais informações, consulte Gerenciando Servidores de Caixa de Correio e Gerenciando o Arquivo Pessoal.

Espaço em Branco do Banco de Dados

O tamanho do banco de dados no disco físico não é simplesmente o número de usuários multiplicado pela cota de armazenamento de caixa de correio. Quando a maioria dos usuários não está próxima de atingir de sua cota de armazenamento de caixa de correio, os bancos de dados consomem menos espaço, e o espaço em branco não é uma problema de capacidade. O próprio banco de dados sempre terá páginas livres, ou espaço em branco, distribuídos em seu interior. Durante a manutenção em segundo plano do banco de dados, itens marcados para remoção do banco de dados são removidos, liberando essas páginas. O percentual de espaço em branco muda constantemente, devido aos esforços do processo de desfragmentação online 24x7.

Você pode estimar o volume do espaço em branco no banco de dados conhecendo o volume de emails e enviados e recebidos pelos usuários com caixas de correio no banco de dados. Por exemplo, se você tiver 100 caixas de correio de 2 GB (total de 200 GB) em um banco de dados cujos usuários enviam e recebem uma média de 10 MB de email por dia, o espaço em branco será de aproximadamente 1 GB (100 caixas de correio x 10 MB por caixa de correio). O volume do espaço em branco pode exceder essa aproximação caso a manutenção em segundo plano do banco de dados não possa concluir uma passagem completa.

Retornar ao início

Itens Recuperáveis do Banco de Dados de Caixa de Correio

Cada banco de dados tem um dumpster que armazena itens excluídos temporariamente. Por padrão, itens excluídos temporariamente são armazenados por 14 dias e itens de calendário são armazenados por 120 dias no Exchange 2010.

Além disso, o Exchange 2010 também inclui a capacidade de impedir a limpeza de dados antes que a janela de retenção de itens excluídos tenha passado. Essa funcionalidade é conhecida como recuperação de item único. Quando a recuperação de item único estiver habilitada (desabilitada por padrão), existe um aumento adicional de 1,2 por cento no tamanho da caixa de correio, para uma janela de retenção de itens excluídos de 14 dias. Para dados de log da versão do calendário (habilitados por padrão), existe um aumento adicional de 5,8 por cento no tamanho da caixa de correio.

A fórmula para determinar os requisitos de espaço do dumpster para 14 dias de retenção de itens excluídos, com recuperação de item único e log da versão do calendário habilitados é:

Tamanho do Dumpster = (Mensagens de Entrada/Saída Diárias x Média do Tamanho das Mensagens x Janela de Retenção de Itens Excluídos) + (Tamanho da Cota de Caixa de Correio x 0,012) + (Tamanho da Cota de Caixa de Correio x 0,058)

Por exemplo, se o tamanho da caixa de correio for 2 GB, habilitar a recuperação de item único por 14 dias de retenção de itens excluídos requer um adicional de 25 MB de espaço, e o recurso do log do calendário requer um adicional de 119 MB.

Para obter mais informações, consulte os tópicos:

Tamanho Real da Caixa de Correio

Com o tempo, as caixas de correio de usuário atingirão a cota de armazenamento de caixa de correio, de modo que um volume de email equivalente às mensagens de entrada precisará ser excluída para permanecer abaixo da cota de armazenamento de caixa de correio. Essa exigência significa que o dumpster crescerá até um tamanho máximo equivalente ao volume de emails enviados e recebidos a cada dia, multiplicado pelo número de dias dentro da janela de retenção de itens excluídos. Se a maioria dos usuários não atingiu a cota de armazenamento, apenas alguns dos emails de entrada/saída são excluídos. Portanto, o crescimento é dividido entre o dumpster e o aumento no tamanho da caixa de correio.

A seguir, está uma fórmula para o tamanho do banco de dados usando uma caixa de correio de 2 GB, sem usar o recurso de arquivo morto:

Tamanho do Banco de Dados = Cota da Caixa de Correio + Espaço em Branco + Tamanho do Dumpster

Por exemplo, uma caixa de correio com 100 mensagens de 250 MB por dia, que recebe 37 MB de mensagens por semana de cinco dias úteis (com mensagens com tamanho médio de 75KB), consumirá 120 MB no dumpster com a recuperação de item único habilitada por 14 dias, e 7,3 MB de espaço em branco, para uma caixa de correio com tamanho total de 378 MB. Outro exemplo é uma caixa de correio com perfil de 100 mensagens de 2 GB por dia, que recebe 37 MB de emails por semana, o que consumirá 246 MB no dumpster e 7,3 MB de espaço em branco, para uma caixa de correio com tamanho total de 2,25 GB.

Depois de determinado o tamanho real projetado da caixa de correio, você pode usar o valor para determinar o número máximo de usuários por banco de dados. Divida o tamanho da caixa de correio projetado pelo tamanho do banco de dados recomendado. Este valor também ajudará a determinar quantos bancos de dados serão necessários para manipular a conta do usuário projetada, considerando bancos de dados completamente preenchidos. Lembre-se de que, devido à E/S não transacional ou devido às limitações de hardware, pode ser necessário modificar o número de usuários colocados em um único servidor. Alguns administradores preferirão usar mais bancos de dados para reduzir ainda mais o tamanho do banco de dados. Esse método pode ser auxiliado com janelas de backup e de restauração às custas de mais complexidade no gerenciamento de mais bancos de dados por servidor.

Indexação de Conteúdo

A indexação de conteúdo cria um índice ou catálogo que permite aos usuários pesquisar com facilidade e rapidez os itens de email em vez de vasculhar manualmente a caixa de correio. O Exchange 2010 cria um índice de aproximadamente 10 por cento do tamanho total do banco de dados, que é colocado no mesmo LUN do banco de dados. Portanto, um adicional de 10 por cento precisa ser fatorado no tamanho do LUN do banco de dados, para indexação de conteúdo.

Retornar ao início

Manutenção de Banco de Dados Offline

Um banco de dados que precisa ser compactado offline precisa de capacidade igual ao tamanho do banco de dados de destino mais 10 por cento. Se você alocar espaço suficiente para um banco de dados único, ou um conjunto de backup, espaço adicional deve ser disponibilizado para executar essas operações.

Importante

Os procedimentos de manutenção offline devem ser implementados apenas sob solicitação do Suporte e Atendimento ao Cliente Microsoft, porque invalidam todas as cópias de banco de dados e exigem nova propagação total do banco de dados.

Banco de Dados de Recuperação

Se você planeja usar um banco de dados de recuperação como parte dos planos de recuperação de desastres, capacidade suficiente deve ser disponibilizada para manipular todos os bancos de dados que você quiser restaurar simultaneamente nesse servidor. Para obter mais informações, consulte Bancos de dados de recuperação.

Tamanho do Banco de Dados

O tamanho do banco de dados determina quantas caixas de correio implantar dentro de cada banco de dados e quantos bancos de dados implantar. O tamanho do banco de dados a ser implantado depende de vários fatores:

  • Contratos de Nível de Serviço (SLAs) de backup/restauração   O tamanho do banco de dados, essencialmente, dita a velocidade do backup e restauração dos dados, dentro de um tempo razoável.
  • Arquitetura de alta disponibilidade   Se você planeja ter várias cópias de bancos de dados, pode projetá-los para até 2 TB de tamanho, porque as cópias se tornarão sua primeira linha de defesa em termos de operações de recuperação.
  • Arquitetura de armazenamento   Se você planeja implantar em armazenamento JBOD (um disco hospeda o banco de dados e seus logs de transações correspondentes), o tamanho do disco usado dita o tamanho máximo do banco de dados. Por exemplo, em um disco de 1 TB (com uma capacidade formatada de aproximadamente 917 GB), você também precisa incluir espaço para logs de transações e índices de conteúdo, e garantir que todo o espaço disponível não seja consumido.

Sobrecarga de Crescimento do Banco de Dados

Depois que todos os fatores tiverem sido considerados e calculados, é recomendável que você inclua um fator de sobrecarga adicional de 20 por cento para o número de unidade lógica (LUN) do banco de dados . Esse valor considerará os outros dados que residem no banco de dados que não são necessariamente vistos durante o cálculo dos tamanhos da caixa de correio e o espaço em branco.

Retornar ao início

Capacidade de Log

Os arquivos de log de transações são um registro de todas as transações executadas pelo mecanismo do banco de dados. Todas as transações são gravadas no log primeiro e depois lentamente gravadas no banco de dados. Ao contrário do Exchange Server 2003, os arquivos de logs de transações no Exchange 2010 tiveram o tamanho reduzido de 5 MB para 1 MB. Essa alteração foi feita para oferecer suporte aos recursos de replicação contínua e para minimizar o volume de perda de dados se o armazenamento principal falhar.

Você pode usar a tabela a seguir para estimar o número de logs de transações que serão gerados em um servidor Caixa de Correio do Exchange 2010, em que o tamanho médio das mensagens é 75 KB.

Número de logs de transações gerados para cada perfil de caixa de correio

Perfil da mensagem (tamanho médio de mensagem de 75 KB) Número de logs de transações gerados por dia

50

10

100

20

150

30

200

40

250

50

300

60

350

70

400

80

450

90

500

100

Você pode usar as diretrizes a seguir para compreender como o tamanho das mensagens afeta a taxa de geração de logs de transações:

  • Se o tamanho médio das mensagens dobra para 150 KB, os logs gerados por caixa de correio aumenta por um fator de 1,9. Esse número representa a porcentagem do banco de dados que contém os anexos e as tabelas de mensagens (corpos das mensagens e anexos).
  • Portanto, quando o tamanho da mensagem dobrar para mais de 150 KB, o mesmo acontece com a taxa de geração de logs por caixa de correio, aumentando de 1,9 para 3,8.

Por exemplo, se você tiver 100 mensagens por dia e:

  • Um tamanho médio de mensagem de 150 KB, os logs gerados pela caixa de correio são de 20 × 1,9 = 38.
  • Um tamanho médio de mensagem de 300 KB, os logs gerados pela caixa de correio são de 20 × 3,8 = 76.

As seções a seguir abordam os fatores que afetam sua capacidade de dimensionamento do log:

  • Fatores de Backup e Restauração
  • Operações de Movimentação de Caixa de Correio
  • Fator de Sobrecarga de Crescimento do Log
  • Fatores de Alta Disponibilidade
  • Planejamento da Capacidade do LUN

Fatores de Backup e Restauração

O dimensionamento do LUN de log é parcialmente dependente da sua estrutura de backup e restauração. Por exemplo, se sua estrutura permite que você retorne duas semanas e repita todos os logs gerados desde então, você precisa de duas semanas de espaço de arquivo de log. Se sua estrutura de backup incluir backups diferenciais diários e semanais completos, o LUN do log precisa ser maior que uma semana inteira de logs para permitir o backup e a repetição durante a restauração. A maioria das empresas que executa backup completo todas as noites, aloca duas ou três vezes a capacidade de geração de log diária. Essa abordagem é adotada para evitar que uma falha de backup faça com que a unidade de log seja preenchida, o que desmontaria o banco de dados.

Se você planeja usar os recursos de resiliência de caixa de correio e recuperação de item único dentro do Exchange 2010 enquanto faz o backup da infraestrutura (e, assim, habilita o log circular), como prática recomendada, você deve garantir que alocou três vezes a capacidade de geração de log diária exigida. Isso garante que, quando a replicação for suspensa ou não estiver funcionando normalmente, os bancos de dados não desmontem devido a falhas de truncamento.

Operações de Movimentação de Caixa de Correio

A movimentação de caixas de correio é um fator de capacidade primordial para implantações grandes de caixa de correio. Muitas grandes empresas movem uma porcentagem de suas caixas de correio noturna ou semanalmente para bancos de dados, servidores ou sites diferentes. Se é o que sua organização faz, você pode achar necessário fornecer capacidade extra para o LUN de log, a fim de acomodar movimentações de caixa de correio.

Embora os logs do servidor de origem registrem exclusões de registro, que são pequenas, o servidor de destino deve gravar todos os dados transferidos em logs de transações. Se você gerar 10 GB de arquivos de log em um dia, e mantiver um buffer de três dias de 30 GB, mover 50 caixas de correio de 2 GB (100 GB) preencheria seu LUN de log de destino e causaria inatividade. Em casos como esses, pode ser necessário alocar capacidade adicional para que os LUNs de log se adaptem às suas práticas de movimentação de caixa de correio.

Fator de Sobrecarga de Crescimento do Log

Para a maioria das implementações, é recomendável que você adicione um fator de sobrecarga de 20% ao tamanho do log (depois que todos os outros fatores tiverem sido considerados) quando criar o LUN do log, a fim de garantir que há capacidade necessária em momentos inesperados de geração de logs.

Fatores de Alta Disponibilidade

A alta disponibilidade influencia os requisitos de capacidade do log de três formas significativas:

  • Contagem de cópias de bancos de dados   A capacidade de log de todo o sistema é aumentada com base no número de cópias de bancos de dados escolhido na implantação da alta disponibilidade. Se você tiver três cópias de bancos de dados espalhadas em três servidores, precisa fornecer capacidade de log para cada cópia, em cada servidor.
  • Mecanismo de truncamento de log   A alta disponibilidade no Exchange 2010, com a capacidade de ter até 16 cópias de cada banco de dados de caixa de correio, fornece a base para usar o log circular da replicação contínua com o mecanismo de truncamento/exclusão do log, ao invés de executar backups totais/incrementais para truncar/excluir logs mais antigos. Para obter mais informações, consulte a seção "Truncamento de Log sem Backups" em Understanding Backup, Restore and Disaster Recovery e Alta disponibilidade e resiliência do site.
  • Intervalo de repetição da cópia de banco de dados   A alta disponibilidade no Exchange 2010 fornece a opção de defasar o intervalo de repetição em cópias passivas de banco de dados (uma configuração por cópia). Este recurso é usado para fornecer um atraso para quando os logs forem executados em cópias de bancos de dados defasadas. Esse atraso pode ser útil para proteção contra eventos que poderiam fazer com que conteúdo indesejável fosse replicado em todas as cópias de bancos de dados. É possível interromper o registro do conteúdo nas cópias de bancos de dados defasadas suspendendo a repetição, antes que os logs com o conteúdo indesejado sejam executados no banco de dados.
    Quando o intervalo de repetição estiver habilitado para uma cópia de banco de dados, os requisitos de capacidade do log consequentemente mudam. Se você tiver um intervalo de 14 dias configurado, precisa providenciar 17 dias de logs. A capacidade de log adicional é exigida apenas para a cópia do banco de dados que tem o intervalo configurado; outras cópias do banco de dados, que não têm um intervalo, terão requisitos de capacidade de log normais (não defasados).

Para obter mais informações, consulte Noções Básicas Sobre Fatores de Alta Disponibilidade.

Planejamento da Capacidade do LUN

Os requisitos de capacidade para o LUN serão baseados no tamanho do conjunto de dados (banco de dados, logs de transações, índice de conteúdo e espaço de recuperação) e algum espaço livre adicional. A maioria dos programas de gerenciamento de operações tem limites de capacidade que fornecem um alerta, quando a utilização de um LUN está acima de 80%.

Você pode usar a fórmula a seguir para determinar o tamanho apropriado do LUN:

Capacidade do LUN = Tamanho dos Dados / (1 - Requisito de Porcentagem de Espaço Livre)

Por exemplo, se você tiver um requisito de tamanho de dados de 3000 MB e um requisito de espaço livre de 20%, o LUN que armazena esses dados deve ter 3750 MB de tamanho.