Temos um problema contínuo com nosso servidor sql de produção (físico) onde recebemos aleatoriamente esse erro no log que coloca o banco de dados em estado de recuperação
SQLServerLogMgr::LogWriter: Operating system error 1117(The request could not be performed because of an I/O device error.) encountered.
O problema sempre ocorre em nossa unidade armazenando os logs de transações. O banco de dados normalmente se recupera sozinho, mas poucas instâncias isso não acontece e precisamos reiniciar a instância para recuperar. Nenhum erro retornado de qualquer banco de dados para dbcc checkdb.
Nossa equipe de armazenamento está investigando há semanas com nosso fornecedor, mas sem sorte. A investigação está em andamento.
Dito isto, como o dba do sql server deve lidar com esse erro além de reportá-lo à equipe de armazenamento e verificar se há corrupção no banco de dados? Eu estou querendo saber se há mais informações que eu possa coletar do lado do servidor sql que possa ajudar em sua investigação?
Executando o SQL Server 2012 SP3, o armazenamento é uma SAN.
Primeira atualização
Nossa equipe de infraestrutura fez as seguintes alterações ontem à noite
- Atualizado o firmware em todas as NICs no servidor de banco de dados
- Atualizado o firmware nos switches de rede
- Quadros Jumbo habilitados para ICSCI
Ainda não recebemos o erro, atualizarei novamente em cerca de uma semana.
Segunda atualização
As alterações feitas na atualização anterior não resolveram o problema. Ontem à noite, movemos o tempdb da SAN para a unidade local no servidor físico e desabilitamos o rastreamento de conexão de otimização iSCSI. Ainda não recebemos o erro e também vemos leitura/gravação de disco muito mais rápida em nossos dados e unidades de log (ainda na san) e, claro, o tempdb sendo local. Além disso, estávamos recebendo muitos erros de iSCSI nos logs de eventos do Windows durante a hora do erro e também ao longo do dia. Como essas mudanças na noite passada, os erros de iCSI desapareceram, ainda há alguns chegando, mas não tanto.
Obrigado, Kevin
Realmente não há nada que você possa fazer do lado do banco de dados. O SQL Server é uma vítima do hardware subjacente e da virtualização (se houver) com problemas. O problema subjacente (driver, hardware, configuração, etc.) precisa ser corrigido. Observe que, se você estiver em um ambiente virtualizado, pode ser uma camada de software intermediária ou um problema com a configuração do host/convidado etc., e não um problema de hardware ou armazenamento físico.
Realisticamente, remover todos os drivers de filtro e software associado, parar e entre camadas removendo-os e colocando-os em soluções de armazenamento físico (se virtual) e/ou em mudança (por exemplo, usando local em vez de remoto/SAN) pode ajudar a ajudar na solução do problema. A atualização de drivers (por exemplo, multipathing, dispositivo, firmware etc.) também pode ser útil, mas não é algo que eu cobraria de um DBA, mas de um datacenter ou administrador de sistemas.
Na verdade, não. Abaixo, estamos chamando as APIs de leitura e gravação através do Windows. O código de retorno da chamada da API por meio do Windows é esse código de erro do Windows que estamos borbulhando para que o administrador do SQL Server saiba por que o SQL Server está tendo problemas.
Se alguma coisa, como é um único volume, eles devem ser capazes de isolá-lo no back-end e habilitar o rastreamento de infraestrutura. Se esta for uma máquina física, isso seria do controlador HBA/scsi e abaixo através do hardware. Se for virtual, então do Host pelas mesmas camadas.
Infelizmente, isso é mais fácil de dizer do que fazer e a maioria dos lugares está mal equipada para realmente investigar esse tipo de problema - especialmente quando o ambiente é virtualizado.
O que dizem os logs de eventos do sistema? Há mais NTFS ou outros problemas de corrupção surgindo? Os dispositivos estão sendo redefinidos? O log de eventos do sistema deve ser dissecado com um pente de dentes extremamente finos para ver se há uma série de eventos ou itens que parecem levar a isso ou se é espontâneo. Além disso, descobri que esses eventos geralmente se agrupam em torno de determinados itens, como horários de alto uso em um controlador específico ou SANs sobrecarregadas.