Estou lutando com esse problema há muitos meses, estou dizendo que não é um problema de banco de dados e atribuo este caso à equipe de armazenamento e sistema operacional e eles o estão atribuindo a mim posteriormente. Esse problema está acontecendo repetidamente e não há nenhum padrão definido de ocorrência.
Eu verifiquei a mesma pergunta feita aqui e posso dizer que isso não é um problema com corrupção de banco de dados, pois estou usando o script de Ola Hallengren para trabalho de manutenção e verificação de integridade do banco de dados (checkdb) é feito semanalmente para banco de dados de usuário e sistema e nenhum problema relatado naquilo.
Acessou o segundo link também para a pergunta semelhante e pode confirmar que o tempdb está em estado de recuperação simples.
Eu adicionei um arquivo adicional para dados e registrei ambos para que, se um ficar indisponível, o outro ainda estará acessível, mas depois soube que o acesso do tempdb é sequencial, então ele irá para o segundo arquivo somente quando o primeiro ficar cheio:
Toda vez que esse problema ocorre, posso ver que temos outro erro no log do aplicativo do Windows, conforme abaixo:
SQLServerLogMgr::LogWriter: Operating system error 170(The requested resource is in use.) encountered.
A equipe de armazenamento excluiu esses arquivos da verificação antivírus.
Uma coisa a notar aqui - verifiquei outros bancos de dados do sistema e seus locais de arquivos e pude ver que, para mestre e modelo, dados e arquivo de log estão na mesma unidade (unidade E), enquanto para tempdb e msdb, os dados estão na unidade E e log arquivo está na unidade G, não tenho certeza se isso é relevante.
Existe alguma sequência de verificação do banco de dados do sistema quando um trabalho é acionado ou qualquer evento é acionado? Se for um problema com essa unidade, o msdb também estará na mesma unidade.
Este é um servidor em cluster com unidades de banco de dados compartilhadas em dois servidores e o servidor é usado para o aplicativo sharepoint.
Server Version: Windows Server 2012 Standard
SQL Server: Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) - 11.0.7462.6 (X64)
Jan 5 2018 22:11:56
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
A única opção que nos resta é reiniciar o serviço ou fazer failover - simplesmente não parece bom fazê-lo.
Qualquer ajuda neste sentido é apreciada.
Sim, isso é resultado do erro do sistema operacional que o logwriter está enfrentando. Nesse caso, é o erro do sistema operacional 170, que é o recurso que está em uso. Isso é muito condenável que o problema esteja fora do SQL Server (exceto quaisquer DLLs de terceiros ruins carregadas no espaço de endereço).
Normalmente, quando vejo isso, é antivírus, proteção de host, software de desfragmentação, software de backup, etc., que acaba mantendo longos bloqueios nos arquivos ou em ambientes clusterizados quando as unidades não estão configuradas corretamente no back-end.
Não estou tentando ser rude, mas não estou comprando. Diga a eles que você quer provas. Além disso, só porque o arquivo está "excluído" não significa que o software antivírus não o veja, ele ainda o faz - apenas não faz todas as verificações detalhadas na maioria dos casos.
O que agora?
Eu começaria verificando se um aplicativo não autorizado está tentando fazer algo. O problema é que isso pode acontecer a qualquer momento e o aplicativo ofensivo (se houver) pode manter o bloqueio por um curto período ou por um longo tempo - não sabemos.
Uma das maneiras de fazer isso rapidamente seria usar o aplicativo de manipulação sysinternals no arquivo com o problema. Como esse erro tem um código de erro no SQL Server para ele, você deve ser capaz de criar um alerta de agente para executar um trabalho que chame um pequeno arquivo em lotes ou PowerShell ou o que você criar para executar o identificador no arquivo. Isso deve ajudar a tentar pegar as informações rapidamente (mas pode não ser rápido o suficiente).
Outra maneira de fazer isso, especialmente se você puder reproduzi-lo com bastante frequência ou fácil, é executar o monitor de processo (procmon), que é outra ferramenta sysinternals para capturar o que está tocando nesse arquivo que não seja o SQL Server.