O sistema operacional retornou o erro 21 (o dispositivo não está pronto.)

Sempre que reinicio o Windows, em alguns bancos de dados, recebo este erro:

O sistema operacional retornou o erro 21 (o dispositivo não está pronto.)

1. Eu verifiquei o disco com chkdsk /r- sem setores defeituosos.

2. Eu executei DBCC CHECKDBsem erros:

   *(CHECKDB found 0 allocation errors and 0 consistency errors in database)* 

3. Se eu reiniciar o SQL Server, os erros desaparecem.

Windows 10 e SQL Server 2016 Express.

Toda vez que eu reinicio o Windows, para alguns bancos de dados sai esse erro. (Erro 21 do SO - Dispositivo não pronto)

Isso ocorre porque um disco está offline ou não está online no momento em que o SQL Server foi iniciado ou teve a transição de estados após o SQL Server estar online.

3.Se eu reiniciar o SQL Server, os erros desaparecerão

Sim, porque os bancos de dados foram remontados no SQL Server. Você também pode offline-> online o banco de dados e ele funcionaria, assumindo que o dispositivo de disco foi corrigido.

Isso pode ser facilmente reproduzido em um ambiente de teste colocando um banco de dados em um disco, desativando o disco, executando uma consulta de seleção (para obter o erro), colocando o disco novamente online e notando que a seleção ainda falha com o mesmo erro. O banco de dados precisará ser remontado para funcionar novamente e não obter o Erro 21 do SO.

O que você deveria fazer?

Peça a alguém que rastreie o Windows para descobrir por que ele não está online inicialmente ou por que está offline (qualquer transição de estado) ou por que ele está pronto para o Windows, mas realmente não está (talvez outros drivers precisem ser carregados para isto).

Além disso, verifique se todos os drivers de filtro de disco estão atualizados quanto a antivírus, proteções contra invasões de host etc., pois também podem estar bloqueando o serviço / inicialização / estado.

Eu acho que encontrei a causa.

Provavelmente, o problema deve-se às opções de energia "Inicialização rápida" .

É uma técnica do Windows para reduzir o tempo de inicialização; A Inicialização rápida combina elementos de um desligamento a frio e o recurso de hibernação .

Aqui você pode encontrar outro artigo sobre prós e contras

Eu o desativei e o problema parece estar resolvido.

Estas são minhas observações e como resolvi o problema (para o benefício de outras pessoas que podem ter o mesmo problema)

• Eu estava usando a instância amazon ec2 executando o servidor sql.
• Eu tinha um dispositivo EBS Block conectado à instância ec2, que foi mapeado para a unidade D :.
• Meus dados e logs estavam na unidade D :.
• Quando paro a instância do ec2 e a trazo mais tarde, sempre tive o erro de "dispositivo não pronto" e os bancos de dados não apareciam.
• Tentei configurar o serviço MSSQLSERVER com "Inicialização atrasada".
• No entanto, nos logs do servidor sql, descobri que o atraso não era respeitado e o MSSQLSERVER foi iniciado junto com a inicialização.
• No visualizador de eventos, observei o momento em que a unidade D: fica saudável.
• Nos logs do servidor sql, observei o horário em que o SQL Server está iniciando meu banco de dados de usuários.
• Eu observei que, D: drive só está disponível após 6 segundos depois; e, obviamente, o erro "O dispositivo não está pronto" é exibido.
• Também observei que o "Início atrasado" não foi respeitado porque havia outro serviço chamado "SQL SERVER LaunchPad" que inicia "MSSQLSERVER".
• Não preciso do recurso de análise do "Launchpad". Então, eu desabilitei esse serviço.
• Agora "MSSQLSERVER" inicia com um atraso e pode encontrar os arquivos da unidade D :.

O erro completo que obtive ao conectar-me à minha instância local padrão do MS SQL (2017) via MSSMS é:

O sistema operacional retornou o erro 21 (O dispositivo não está pronto.) Para o SQL Server durante uma leitura no deslocamento 0x000000000ae000 no arquivo 'D: \ MSSQL \ DATA \ tempdev.mdf'. Mensagens adicionais no log de erros do SQL Server e no log de erros do sistema operacional podem fornecer mais detalhes. Essa é uma condição grave de erro no nível do sistema que ameaça a integridade do banco de dados e deve ser corrigida imediatamente. Conclua uma verificação completa da consistência do banco de dados (DBCC CHECKDB). Este erro pode ser causado por muitos fatores; para obter mais informações, consulte os Manuais Online do SQL Server. (Microsoft SQL Server, erro: 823) Para obter ajuda, clique em: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=823&LinkId=20476

Comecei a obtê-lo assim que mudei meu tempdb para minha nova unidade D. Fazer um start / stop do serviço SQL remove o erro. Nunca obtive esse erro quando tudo estava em C. Ambas as minhas unidades são SSD e criptografadas com o Bitlocker, não tenho certeza se esse poderia ser o problema, talvez a unidade C seja desbloqueada muito cedo porque o sistema operacional precisa e a unidade D seja desbloqueada mais tarde .

1. De acordo com a resposta de Max ( https://dba.stackexchange.com/a/175115 ), desabilitar a "Inicialização rápida" solucionou meu problema. De acordo com o artigo Max links para ( https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/ ), é bastante obscuro encontrar, no " Escolha o que os botões liga / desliga fazem "e" Altere as configurações que estão indisponíveis no momento ".
2. Diferentemente da resposta do Venvig ( https://dba.stackexchange.com/a/226115 ), definir o serviço "SQL Server" como Tipo de inicialização = "Automático (início atrasado)" também resolveu o meu problema (com a inicialização rápida do Windows) ativado).

Já encontrei o mesmo problema muitas vezes e achei que deveria compartilhar minha solução (apesar das respostas já fornecidas):

Então, eu tenho duas instâncias SQL (SQL 2008 e SQL 2017). O erro não se manifesta na minha instância SQL08, mas no SQl17. Isso é causado pelas "credenciais da conta" fornecidas durante a instalação / configuração de cada instância SQL:

Isso pode ser visto em Serviços do Windows. O SQL08 foi configurado para usar a "Conta do sistema local", enquanto o SQL17 com falha foi definido como "CONTA DE REDE" durante a instalação. Então, basta mudar isso e reiniciar o serviço SQL aqui (ou reiniciar a instância no navegador SQL).

A segunda parte desse problema é exclusiva do SQL Server 2017 CTP 2.0 ao usar o SQL Server Management Studio V17. Nesse caso, o SMO passou a usar " sys.dm_os_enumerate_fixed_drives " em vez do antigo " xp_fixeddrives " para obter informações de espaço livre do disco local . Para solucionar isso, vá para o DEVICE MANAGER e desative temporariamente a unidade citada (no meu caso, era a unidade "G", que é apenas a minha unidade de DVD-ROM).

Esse problema também me irritou. Tenho 5 dbs conectados à minha instância do SQL Server, 3 dos quais estão funcionando bem, mas 2 dos quais reclamam

O sistema operacional retornou o erro 21 (O dispositivo não está pronto.) Para o SQL Server durante uma leitura no deslocamento 0x00000000204000 no arquivo 'E: \ xxxxxxxx.mdf'

Aqui está a minha solução.

1. Ative o Services.msc , localize o serviço chamado SQL Server (nome da instância) , clique com o botão direito do mouse e reinicie -o.
2. Volte para ssms, atualize seu banco de dados e as coisas devem funcionar.

Em uma nota lateral, tentei usar o método offline / online de db. Não funcionou no meu caso. A força bruta ao reiniciar o serviço sqlserver funcionou bem. isso pode ser um problema para aqueles cuja participação em colocar todos os dbs offline é muito alta. No entanto, se você está apenas desenvolvendo desenvolvimento local como eu, essa solução deve ser boa.