O sistema está funcionando muito lentamente porque precisa reconstruir os dados ausentes, o que envolve CPU e E / S adicionais.
Se você tiver um disco ausente em uma configuração RAID-5, não terá uma estratégia de recuperação . Se outro disco cair, você perderá seus dados . Corra, não ande, até o fornecedor mais próximo do qual você pode obter uma peça compatível coberta pela garantia do fabricante, enviada por um serviço de entrega urgente no mesmo dia. Se o fornecedor do qual você comprou a matriz já estiver no processo de obter a peça, obtenha as duas peças e guarde a outra como reserva.
Se você tem um RAID-5 em uso em um sistema de produção, considere deixar um disco sobressalente na matriz como sobressalente.
Adicionado - Se seus logs não estiverem em um volume separado (discos fisicamente separados), mova-os para um conjunto separado de discos, mesmo que apenas um par espelhado. Isso também será uma conquista de desempenho se seu banco de dados tiver uma carga significativa, pois a contenção nos volumes de log tem um efeito desproporcionalmente ruim no desempenho.
Se isso for possível, você também pode tornar seu banco de dados mais robusto, fazendo o seguinte:
- Encerre o banco de dados.
- Faça backup do banco de dados.
- Mova os logs para um conjunto de discos fisicamente separados (reconfigure o banco de dados para que ele saiba para onde os logs foram movidos).
- Reinicie o banco de dados e o aplicativo.
Se você tiver os logs em um volume separado, poderá restaurar e avançar a partir do backup se e somente se uma falha no disco não comprometer os logs. Os logs do banco de dados devem estar em um volume de disco separado pelos seguintes motivos (entre outros):
Os padrões de uso de logs são predominantemente seqüenciais, acrescentando entradas de log ao final do arquivo (o arquivo é, na verdade, um buffer de anel). Isso significa que um grande número de entradas de log pode ser gravado rapidamente, pois há pouca atividade de busca no cabeçote do disco.
Se eles estiverem compartilhando discos físicos com uma carga de trabalho de acesso altamente aleatório (por exemplo, tabelas e índices transacionais), eles serão desacelerados desproporcionalmente à medida que a atividade de busca principal interrompe as gravações seqüenciais.
Ter os logs em um volume separado é quase sempre uma conquista de desempenho e precisa apenas de um único par espelhado para que os logs suportem uma carga de trabalho bastante pesada. Isso significa que o hardware para fazer isso é bastante barato, portanto, há um pequeno custo para uma grande conquista de desempenho e confiabilidade.
Se sua matriz de dados cair, os logs não serão perdidos. Se você tiver uma estratégia de backup adequada, poderá restaurar a partir do backup e avançar dos logs. Isso significa que uma matriz inteira pode ficar inativa no servidor sem ser um único ponto de falha. As matrizes de log e de dados precisam falhar simultaneamente para causar perda de dados.