オペレーティングシステムがエラー21を返しました（デバイスの準備ができていません。）
回答:
ウィンドウを再起動するたびに、一部のデータベースでこのエラーが発生します。（OSエラー21-デバイスの準備ができていません）
これは、SQL Serverの起動時、またはSQL Serverがオンラインになった後に状態が移行したときに、ディスクがオフラインまたはオンラインになっていないことが原因です。
3.SQL Serverを再起動するとエラーが消えます
はい、データベースがSQL Server内で再マウントされているためです。また、データベースをオフライン->オンラインにすることもでき、ディスクデバイスが修正されていると想定して機能します。
これは、データベースをディスクに配置し、ディスクを無効にし、選択クエリを実行して（エラーを取得する）、ディスクをオンラインに戻し、同じエラーで選択が依然として失敗することを通知することで、テスト環境で簡単に再現できます。再び機能し、OSエラー21が発生しないようにするには、データベースを再マウントする必要があります。
あなたは何をするべきか？
最初にオンラインにならない理由、またはオフラインになる理由（状態遷移）、またはウィンドウの準備ができているが実際には表示されない理由（おそらく他のドライバーをロードする必要がある）を理解するために、誰かにウィンドウトレースを行わせるそれ）。
さらに、ディスクフィルタードライバーが最新の状態であることを確認します。これは、ウイルス対策、ホスト侵入防止など、サービス/起動/状態をブロックしている可能性があるためです。
私は原因を見つけたと思います。
ほとんどの場合、問題は「高速起動」電源オプションが原因です。
これは、起動時間を短縮するためのWindowsの手法です。高速スタートアップは、コールドシャットダウンの要素と休止状態機能を組み合わせたものです。
ここには長所と短所に関する別の記事があります
無効にしましたが、問題は解決したようです。
これらは私の観察であり、私が問題を解決した方法です（同じ問題を抱えている可能性のある他の人のために）
- SQLサーバーを実行しているamazon ec2インスタンスを使用していました。
- D：ドライブにマップされたec2インスタンスに接続されたEBSブロックデバイスがありました。
- データとログはD：ドライブにありました。
- ec2インスタンスを停止して後で起動すると、「デバイスの準備ができていません」というエラーが常に発生し、データベースが起動しませんでした。
- MSSQLSERVERサービスを「遅延起動」で設定してみました。
- しかし、SQLサーバーのログから、遅延が守られず、MSSQLSERVERが起動と同時に起動したことがわかりました。
- eventviewerから、D：ドライブが正常になる時刻を観察しました。
- SQL Serverのログから、SQL Serverがユーザーデータベースを起動している時刻を確認しました。
- 私はそれを観察しました、D：ドライブは6秒後にのみ利用可能です。そして明らかに「デバイスの準備ができていません」エラーが表示されます。
- また、「MSSQLSERVER」を起動する「SQL SERVER LaunchPad」という名前の別のサービスがあったため、「遅延開始」が守られなかったことにも言及しました。
- 「ランチパッド」の分析機能は必要ありません。そのため、そのサービスを無効にしました。
- これで、「MSSQLSERVER」は遅延して起動し、D：ドライブファイルを見つけることができます。
MSSMSを介してローカルのデフォルトのMS SQLインスタンス（2017）に接続するときに発生した完全なエラーは次のとおりです。
ファイル 'D：\ MSSQL \ DATA \ tempdev.mdf'のオフセット0x000000000ae000での読み取り中に、オペレーティングシステムがエラー21（デバイスの準備ができていません。）をSQL Serverに返しました。SQL Serverエラーログとオペレーティングシステムエラーログにメッセージが追加されると、さらに詳しい情報が得られる場合があります。これは、データベースの整合性を脅かす深刻なシステムレベルのエラー状態であり、すぐに修正する必要があります。完全なデータベース整合性チェック（DBCC CHECKDB）を実行します。このエラーは多くの要因によって引き起こされる可能性があります。詳細については、SQL Server Books Onlineを参照してください。（Microsoft SQL Server、エラー：823）ヘルプが必要な場合は、http：//go.microsoft.com/fwlink？ProdName = Microsoft％20SQL％20Server＆EvtSrc = MSSQLServer＆EvtID = 823＆LinkId = 20476をクリックして ください。
tempdbを新しいDドライブに移動したら、これを取得し始めました。SQLサービスの開始/停止を実行すると、エラーが削除されます。すべてがC上にあったときにこのエラーが発生したことはありません。どちらのドライブもSSDであり、Bitlockerで暗号化されています。これが問題であるかどうかは不明です。おそらく、オペレーティングシステムで必要になるため、Cドライブが非常に早くロック解除され、Dドライブが後でロック解除されます。 。
- Maxの回答（https://dba.stackexchange.com/a/175115）に従って、「高速起動」を無効にすると問題が解決しました。記事Maxへのリンク（https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/）によると、「 「電源ボタンの機能」を選択し、「現在使用できない設定を変更する」を選択します。
- Venvigの回答（https://dba.stackexchange.com/a/226115）とは異なり、「SQL Server」サービスをStartup Type =「Automatic（Delayed Start）」に設定しても問題は解決しました（Windows'Fast Startup re-有効）。
私は何度も同じ問題に遭遇し、私の解決策を共有する必要があると考えました（すでに提供されている回答にもかかわらず）。
したがって、2つのSQLインスタンス（SQL 2008とSQL 2017）があります。このエラーはSQL08インスタンスでは発生しませんが、SQl17で発生します。これは、各SQLインスタンスのインストール/セットアップ中に提供される「アカウント資格情報」が原因です。
これは、Windowsサービスで確認できます。SQL08は「ローカルシステムアカウント」を使用するように設定され、失敗したSQL17はセットアップ中に「ネットワークアカウント」に設定されました。変更して、ここでSQLサービスを再起動します（またはSQLブラウザーでインスタンスを再起動します）。
この問題の2番目の部分は、SQL Server Management Studio V17を使用する場合のSQL Server 2017 CTP 2.0に固有のものです。この場合、SMO は、ローカルディスクの空き容量情報を取得するために、古い「xp_fixeddrives」の代わりに「sys.dm_os_enumerate_fixed_drives」を使用するように切り替えました。。これを回避するには、デバイスマネージャーに移動し、引用されたドライブを一時的に無効にします（私の場合、ドライブ "G"は私のDVD-ROMドライブです）。
この問題も私を苛立たせました。SQL Serverインスタンスに接続されている5つのdbがあり、そのうち3つは正常に動作していますが、2つは問題があります
ファイル 'E：\ xxxxxxxx.mdf'のオフセット0x00000000204000での読み取り中に、オペレーティングシステムがエラー21（デバイスの準備ができていません。）をSQL Serverに返しました
これが私の解決策です。
- Services.mscをオンにして、SQL Server（インスタンス名）というサービスを見つけ、右クリックして再起動します。
- ssmsに戻り、dbを更新すると、問題なく機能するはずです。
余談ですが、私はdbをオフライン/オンラインの方法で試してみました。私の場合はうまくいきませんでした。sqlserverサービスを再起動するブルートフォースはうまく機能しました。これは、すべてのデータベースをオフラインにすることの利害関係が高すぎる人にとっては問題になるかもしれません。ただし、私のようにローカルで開発しているだけの場合は、このソリューションで問題ありません。