Estou tendo um problema estranho com uma tecnologia de recuperação de desastres que estamos tentando implementar. O ambiente em ambos os datacenters é o mesmo com VMWare e Dell Equallogic SANs, que são as mesmas versões.
Quando replicamos de um datacenter para outro, os bancos de dados aleatórios são corrompidos de alguma forma e acabam no modo SUSPEITO. Cada vez que tentamos esse método, diferentes bancos de dados serão corrompidos. Este é um comportamento no SQL que está causando isso? Este é o software usado na SAN para replicar causando esses erros?
Consegui alterar o estado do banco de dados para o modo EMERGENCY e executar DBCC CHECKDB, mas é um problema e um banco de dados diferentes a cada vez. Alguns dos erros que encontrei são problemas de índice e problemas de incompatibilidade de dados. Ainda estou verificando outros bancos de dados para ver se consigo encontrar um padrão. Se encontrar outras coisas, com certeza postarei se isso ajudar.
Já ouvi falar de pessoas que implementaram esse procedimento com sucesso e é a última tarefa do projeto a descobrir antes que possamos fechar o termo de abertura do projeto.
Eu realmente esperava que pudéssemos usar apenas os recursos integrados do servidor SQL, como espelhamento ou AO-AGs.
As versões do SQL são 2008 R2 e 2012. Estamos instalando alguns novos servidores SQL 2014. Além disso, eles são todos Standard, não Enterprise.
Qualquer entrada ou coisas que eu poderia tentar seria de grande ajuda, obrigado antecipadamente!!
Edit#1 06/08/15 12:50 PM CST - A seguir estão algumas das mensagens de erro que encontrei no Windows Event Viewer, que é mais ou menos o que DBCC CHECKDB produziu.
- EventID 605 - Falha na tentativa de buscar a página lógica (1:22620) no banco de dados 26. Pertence à unidade de alocação 72057594239385600 e não a 72057594249412608
- EventID 824 - O SQL Server detectou um erro de E/S baseado em consistência lógica: paginado incorreto (esperado 1:1230; real 0:0). Ocorreu durante a leitura de uma página (1:1230) no banco de dados ID 58 no deslocamento 0x0000000099c000 no arquivo 'D:\Mydatabase.mdf'. Mensagens adicionais no log de erros do SQL Server ou no log de eventos do sistema podem fornecer mais detalhes. Esta é uma condição de erro grave que ameaçou a integridade do banco de dados e deve ser corrigida imediatamente. Conclua uma verificação completa de consistência do banco de dados (DBCC CHECKDB).
- EventID 7886 - Uma operação de leitura em um objeto grande falhou ao enviar dados para o cliente. Uma causa comum para isso é se o aplicativo estiver sendo executado no nível de isolamento READ UNCOMMITTED. Esta conexão será encerrada.
- EventID 608 - Nenhuma entrada de catálogo encontrada para a partição ID 72057594383564800 no banco de dados 23. Os metadados são inconsistentes. Execute DBCC CHECKDB para verificar se há corrupção de metadados.
Edição nº 2 06/08/15 14:24 CST - Recebi informações de que a restauração de arquivos .bak dos bancos de dados no modo SUSPEITO corrige o problema.
em relação ao seu comentário, suspeito de um problema relacionado ao Ops aqui, em vez de um problema do mecanismo do SQL Server. Esses dispositivos SAN geralmente funcionam na camada de bloco e alguns gerenciam a sincronização de log/arquivo de dados de transação melhor do que outros, bem como outras áreas.
Você pode mostrar à equipe de operações que não, o SQL Server não corrompe dados aleatoriamente como este. Você pode restaurar backups para outro servidor, configurar o espelhamento e tudo isso acontece sem corrupção. No minuto em que fazemos a replicação do nível san, isso acontece. Se o SQL Server causasse corrupção assim, não existiria. O SQL Server tem quase milhões de linhas de código que lidam com corrupção, corrigindo corrupção e reduzindo o potencial de corrupção. Você não tem esse problema em nenhum outro ambiente e só ocorre com a replicação de SAN, correto?
O firmware costuma ser uma das principais causas desses tipos de problemas. Coloque seu representante de suporte da Dell na linha, eles terão muito mais informações e solução de problemas. Não se contente com um representante preguiçoso, os dados e o tempo da sua empresa estão em jogo. Eles têm muitas ferramentas que verificam o que está causando isso em segundo plano e outras ferramentas, como o DPAC, que podem ajudar. Este não é um problema do mecanismo do SQL Server, precisaremos do suporte total do Ops.
Editar: se o seu firmware estiver desatualizado ou incompatível, obtenha uma política da equipe de operações que gerencia a SAN, informando que eles manterão o firmware atualizado na pilha das máquinas que gerenciam. Se este SLA não existir, você deve anotá-lo para seus gerentes porque você está exposto a muitos outros problemas além deste.
Estou assumindo que você está usando a replicação de nível de bloco SAN.
Muitas vezes também pode haver incompatibilidade nas configurações. Talvez tamanhos de bloco diferentes, etc., mas o san os deve ser capaz de detectar esses problemas normalmente.