Nas últimas semanas, nosso servidor Exchange teve problemas com falhas na conclusão de suas tarefas de backup, o que fez com que nossas unidades de log normalmente vazias se enchessem a ponto de o Exchange desmontar bancos de dados e registrar vários erros relacionados à reprodução de arquivos de log. Infelizmente, ninguém na equipe de backup fez seu trabalho corretamente, então, no fim de semana, tivemos uma situação de falha que desmontou ~ 40 bancos de dados devido a ~ 100 GB de logs, que geralmente ficam em ~ 3 GB. Isso fez com que todos os que trabalhavam no fim de semana não olhassem para o histórico do problema e, em vez de entrar em contato com qualquer outra pessoa, ativassem o registro circular depois que todos na equipe fossem instruídos a não, remontar todos os bancos de dados e encerrar o dia.
Ainda não ouvimos falar de nenhuma perda de dados de nenhum usuário, mas o fato de que todos os bancos de dados encontraram isso e que há reclamações sobre falhas de registro, falhas de repetição e desmontagens inesperadas preocupa-me que possa haver algumas.
Além de demitir a equipe de backup, os monitores de fim de semana e o administrador que decidiu habilitar o registro circular após um período significativo de tempo entre os backups sem salvar os logs em nenhum lugar em caso de necessidade de restaurar do backup e recuperar o que pudermos, o que é meu melhor curso de ação para determinar se perdemos alguma coisa?
Existem eventos específicos que podem estar ocultos nos 3.000.000 registros de log que abrangem a seção de seis horas enquanto isso acontecia? A realização de uma verificação de integridade é recomendada? Desfragmentar, online ou offline?
No servidor Exchange, o que aconteceu normalmente foi o seguinte: removi a fonte e o ID do evento porque tudo parece genérico e de pouca ajuda para determinar se as coisas realmente deram errado ou apenas arruinaram minha segunda-feira:
Às 'TIME', a cópia 'DATABASE' do Banco de Dados de Armazenamento de Informações do Microsoft Exchange neste servidor apresentou um erro grave que fez com que encerrasse sua atividade funcional. O erro retornado pela tentativa de remontagem foi "Existe apenas uma cópia deste banco de dados de caixa de correio (DATABASE). A recuperação automática não está disponível.". Consulte o log de eventos no servidor para outro armazenamento e eventos "ExchangeStoreDb" para obter informações mais específicas sobre as falhas.
Armazenamento de informações - DATABASE (9564) DATABASE: uma tentativa de gravar no arquivo "F:\Logs\DATABASE\E0Etmp.log" no deslocamento 1048576 (0x0000000000100000) para 0 (0x00000000) bytes falhou após 0,000 segundos com erro de sistema 112 (0x00000070) ): "Não há espaço suficiente no disco. ". A operação de gravação falhará com o erro -1808 (0xfffff8f0). Se esse erro persistir, o arquivo pode estar danificado e pode precisar ser restaurado de um backup anterior.
Armazenamento de informações - DATABASE (9564) DATABASE: Não é possível criar um novo arquivo de log porque o banco de dados não pode gravar na unidade de log. A unidade pode ser somente leitura, sem espaço em disco, mal configurada ou corrompida. Erro -529.
Armazenamento de informações - DATABASE (9564) DATABASE: A sequência do arquivo de log em "F:\Logs\DATABASE\" foi interrompida devido a um erro fatal. Nenhuma atualização adicional é possível para os bancos de dados que usam essa sequência de arquivo de log. Corrija o problema e reinicie ou restaure a partir do backup.
Armazenamento de informações - DATABASE (9564) DATABASE: A recuperação/restauração do banco de dados falhou com o erro inesperado -510.
O serviço de replicação de caixa de correio do Microsoft Exchange não conseguiu processar trabalhos em um banco de dados de caixa de correio. Banco de dados: DATABASE Error: MapiExceptionMdbOffline: não é possível abrir o armazenamento de mensagens. (hr=0x80004005, ec=1142) Contexto de diagnóstico:
Às 'TIME', a cópia do banco de dados 'DATABASE' neste servidor encontrou um erro durante a operação de montagem. Para obter mais informações, consulte o log de eventos no servidor para eventos "ExchangeStoreDb" ou "MSExchangeRepl". A operação de montagem será tentada novamente automaticamente.
Este é um servidor autônomo, portanto, os únicos erros de cópia parecem ser esperados. Há também vários erros de acesso do cliente registrados durante o tempo em que isso estava acontecendo, que eu omiti.
Costumo pensar que você tem perda mínima de dados, se houver. Isso soa bastante extremo, eu percebo, mas a base para minha opinião é que novos dados pararam de chegar quando os discos encheram. Mesmo se você perdesse dados, o que seria perdido quase certamente seriam os dados recebidos pelo servidor imediatamente antes da condição de disco cheio.
No momento em que o disco é preenchido, o Extensible Storage Engine (ESE) libera os dados de log para os logs de transação de reserva de cada banco de dados antes de desmontar o banco de dados.
Câmbio desmontou as lojas. Qualquer e-mail vindo da Internet seria enfileirado pelo seu MX secundário (ou pelo remetente, se você não tiver nenhum) e enviado posteriormente, ou NDR'd (nesse caso, o remetente estaria ciente da falha) pelo servidor do remetente. Suponho que haja uma chance de um remetente descartar uma mensagem da fila sem NDR, mas isso dificilmente é problema seu.
Os clientes do Outlook não conseguiriam se conectar aos bancos de dados do armazenamento de informações, portanto, nenhum novo e-mail de clientes internos provavelmente seria perdido.
Você mencionou falhas de repetição do log de transações. Isso soa um pouco perturbador, mas sem saber a extensão dessas falhas é difícil dizer. Devido à natureza das repetições do log de transações (ou seja, confirmar dados não confirmados gravados recentemente no banco de dados), a chance de falhas de reprodução afetarem dados armazenados mais antigos é bastante baixa. Se os usuários não estão tendo problemas com os dados mais recentes em suas caixas de correio, provavelmente não os verão mais tarde.
Realmente não há uma preocupação relacionada à fragmentação do banco de dados relacionada à condição de disco cheio. Os padrões de gravação no banco de dados não seriam alterados porque o volume do log de transações foi preenchido. A desfragmentação online ainda acontecerá normalmente. A desfragmentação offline normalmente não é mais necessária ou recomendada pela Microsoft.
É concebível, se os bancos de dados foram armazenados nos volumes que preencheram que os arquivos EDB poderiam ter fragmentação do sistema de arquivos, mas, de um modo geral, a Microsoft não recomenda a desfragmentação de volumes que contêm bancos de dados do Exchange. Você pode acessar seus arquivos .EDB
contig.exepara analisar sua fragmentação se quiser ter certeza.ESE é realmente robusto. Acho que você provavelmente está bem.