Noções Básicas Sobre o Banco de Dados de Caixa de Correio e Fatores de Capacidade de Log
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2015-03-09
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 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.
Voltar 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. Recuperação de item único está desativada por padrão. Quando a recuperação de item único estiver habilitada, 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, existe um aumento adicional de 3 por cento no tamanho da caixa de correio. Dados de registro de versão do calendário estão habilitados por padrão.
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,03)
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 61 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.
Para determinar o tamanho do banco de dados com uma caixa de correio de 2 GB sem usar o recurso de arquivo morto pessoal, consulte a seção "Requisitos de capacidade da caixa de correio" no tópico Exemplo de Design da Função de Servidor Caixa de Correio do Exchange 2010.
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.
Voltar 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.
Voltar 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.
O valor de Número de logs de transações gerados por dia está baseado no perfil da mensagem selecionada e no tamanho médio da mensagem. Ele indica quantos logs de transações serão gerados por caixa de correio diariamente. Os número de geração de logs por conta de perfil da mensagem para:
Impacto do tamanho da mensagem
Volume de dados enviados/recebidos
Operações de manutenção da integridade do banco de dados
Operações de gerenciamento de registros
Dados armazenados em uma caixa de correio que não seja uma mensagem (tarefas, compromissos do calendário local, contatos)
Sobreposição forçada de log (um mecanismo que fecha periodicamente o arquivo do log da transação atual)
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 causariam conteúdo indesejado a ser replicado em todas as cópias do banco de dados. O conteúdo pode ter sus execução interrompida na cópia do banco de dados através da suspensão de execução antes que os logs com conteúdo indesejado forem 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.
Evitando o consumo total de espaço de disco de log de transações
Para evitar que todo o seu espaço em disco seja consumido em log de transações, você deve primeiro calcular uma linha de base do seu ambiente para determinar a taxa de geração de log típica por dia. Segundo, você deve configurar o monitoramento e agir com relação a todos os alertas que são gerados. Você deve monitorar os seguintes itens:
Espaço de disco de LUN de Log de transações. Configure vários limiares e diferentes mecanismos de alerta. Por exemplo, se você souber a sua linha de base de geração típica de log, é possível configurar um limite para informar quando você estiver a 20 por cento da sua linha de base.
Seus backups foram concluídos com êxito (e você não está aproveitando a Proteção de Dados Nativa do Exchange).
O truncamento de eventos no Log do aplicativo.
Sua consistência de replicação de cópia de banco de dados.
Solucionando problemas de crescimento inexplicável nos logs de transação
Para ajudar a solucionar problemas de crescimento inexplicável em logs de transações, consulte Gerenciar o Log de Crescimento de Banco de Dados Usando o Script Troubleshoot-DatabaseSpace.ps1 no Shell.
© 2010 Microsoft Corporation. Todos os direitos reservados.