Por que a replicação da SAN está causando corrupção aleatória do banco de dados?

Question

Ter uma questão estranha com uma tecnologia de recuperação de desastres que estamos tentando implementar. O ambiente em ambos os datacenters é o mesmo com o VMware e a Dell Equallogic Sans, que são as mesmas versões.

Quando nós replicamos de um datacenter para outro, os bancos de dados aleatórios estão sendo corrompidos de alguma forma e acabam no modo suspeito. Cada vez que tentamos este método, diferentes bancos de dados serão corrompidos. Isso é um comportamento no SQL que está causando isso? Este é o software usado no SAN para replicar causando esses erros?

Eu fui capaz de alterar o estado do banco de dados para o modo de emergência e executar o DBCC CheckDB, mas é um problema e banco de dados diferente de cada vez. Alguns dos erros que encontrei são problemas de índice e problemas de incompatibilidade de dados. Eu ainda estou no processo de verificar outros bancos de dados para ver se consigo encontrar um padrão. Se encontrar outras coisas, eu vou ter certeza de postar se isso ajudará.

Eu ouvi falar de pessoas implementando este procedimento com sucesso e é a última tarefa no projeto para descobrir antes que possamos fechar a Carta do Projeto.

Eu estava realmente esperando que pudéssemos usar os recursos internos do SQL Server como espelhamento ou AO-AGS.

As versões do SQL são 2008 R2 e 2012. Estamos no processo de instalação de alguns servidores SQL 2014 novos. Além disso, eles são todos padrão, não corporativos.

Qualquer entrada ou coisas que eu poderia tentar seria de grande ajuda, obrigado antecipadamente !!

Edit # 1 8/6/15 12:50 CST - A seguir estão algumas das mensagens de erro que encontrei no Windows Event Viewer, que é mais ou menos o que o DBCC CheckDB produziu.

.

• EventID 605 - Tentativa de buscar a página lógica (1: 22620) no banco de dados 26 falhou. Ele pertence à unidade de alocação 72057594239385600 para não para 72057594249412608
• EventID 824 - SQL Server detectou um erro de E / S baseado em consistência lógica: PEDED incorreto (esperado 1: 1230; 0: 0). Ocorreu durante uma leitura de uma página (1: 1230) no ID do banco de dados 58 no deslocamento 0x000000999C000 no arquivo 'D: \ mydatabase.mdf'. Mensagens adicionais no log de erros do SQL Server ou o log de eventos do sistema podem fornecer mais detalhes. Esta é uma condição de erro grave que ameaça a integridade do banco de dados e deve estar correta imediatamente. Complete uma verificação de consistência de banco de dados completo (DBCC Checkdb).
• EventID 7886 - Uma operação de leitura em um objeto grande falhou durante o envio de dados para o cliente. Uma causa comum para isso é se o aplicativo estiver sendo executado no nível de isolamento de leitura não confirmado. Esta conexão será encerrada.
• EventID 608 - Não foi encontrada uma entrada de catálogo para a partição ID 72057594383564800 no banco de dados 23. Os metadados são inconsistentes. Execute o DBCC CheckdB para verificar se há uma corrupção de metadados.

editar # 2 8/6/15 2:24 PM CST - recebido informação que restaurar arquivos .bak dos bancos de dados no modo suspeito corrige o assunto.

Answer 1

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 trabalham na camada de bloco e alguns gerenciamos o arquivo de registro de transação / arquivo de dados são melhores que outros, assim como outras áreas.

Você pode mostrar a equipe OPS que não, o SQL Server não correu aleatoriamente dados como este. Você pode restaurar backups para outro servidor, espelhamento de configuração e tudo isso acontece sem corrupção. No minuto em que a replicação de nível San acontece. Se o SQL Server causou corrupção como este, não seria por perto. O SQL Server tem quase milhões de linhas de código que lidam com corrupção, corrigindo a corrupção e reduzindo o potencial da corrupção. Você não recebe esse problema em qualquer outro ambiente e só aparece com a replicação de SAN, correta?

Firmware é muitas vezes uma das principais causas desses tipos de problemas. Obtenha seu Rep de Suporte à Dell na linha, eles terão muito mais informações e solucionar problemas. Não se contente com um representante preguiçoso, os dados e a hora do seu empreendimento estão na linha. Eles têm muitas ferramentas que verificam o que está causando isso em segundo plano e outras ferramentas, como o DPAC, o que pode ajudar. Este não é um problema do mecanismo do SQL Server, precisaremos do suporte total dos ops.

Editar: Se o seu firmware estiver desatualizado, obtenha uma política da equipe OPS que gerencia a SAN que afirma que manterão o firmware em toda a pilha das máquinas que eles gerenciam atualizadas. Se este SLA não existir, você deve anotar isso 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 de SAN.

Muitas vezes também pode ser incompatibilidade nas configurações. Talvez tamanhos de bloco diferentes, etc. Mas o San OS deve ser capaz de detectar esses problemas normalmente.