Windowsを再起動するたびに、一部のデータベースで次のエラーが発生します。
オペレーティングシステムがエラー21を返しました(デバイスの準備ができていません。)
chkdsk /r
でディスクをチェックしました-不良セクターはありません。エラーなしでDBCC CHECKDB
を実行しました。
*(CHECKDB found 0 allocation errors and 0 consistency errors in database)*
Windows 10およびSQL Server 2016 Express。
ウィンドウを再起動するたびに、一部のデータベースでこのエラーが発生します。 (OSエラー21-デバイスの準備ができていません)
これは、SQL Serverが起動したとき、またはSQL Serverがオンラインになった後に状態が遷移したときに、ディスクがオフラインまたはオンラインになっていないことが原因です。
3.SQL Serverを再起動するとエラーが消えます
はい、データベースがSQL Server内で再マウントされているためです。また、データベースをオフライン->オンラインにすることもでき、ディスクデバイスが修正されていると想定して機能します。
これは、データベースをディスクに配置し、ディスクを無効にし、選択クエリを実行して(エラーを取得する)、ディスクをオンラインに戻し、同じエラーで選択が依然として失敗することを通知することで、テスト環境で簡単に再現できます。再び機能し、OSエラー21が発生しないようにするには、データベースを再マウントする必要があります。
あなたは何をするべきか?
最初にオンラインにならない理由、またはオフラインになる理由(状態遷移)、またはウィンドウの準備ができているのに実際には表示されない理由(おそらく他のドライバーをロードする必要がある)を把握するために、誰かにウィンドウトレースを行わせるそれ)。
さらに、ディスクフィルタードライバーが最新の状態であることを確認します。これは、ウイルス対策、ホスト侵入防止などがサービス/起動/状態をブロックしている可能性があるためです。
私は原因を見つけたと思います。
ほとんどの場合、問題は "高速起動"電源オプション が原因です。
これは、起動時間を短縮するWindowsの手法です。高速起動は、 コールドシャットダウンと休止機能 の要素を組み合わせたものです。
ここでは、長所と短所について別の 記事 を見つけることができます
無効にしましたが、問題は解決したようです。
これらは私の観察であり、私が問題を解決した方法です(同じ問題を抱えている可能性がある他の人のために)
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ドライブが後でロック解除されます。 。
この問題も私を苛立たせました。 SQL Serverインスタンスに接続されている5つのdbがあり、そのうち3つは正常に動作していますが、2つは問題があります
オペレーティングシステムは、ファイル 'E:\ xxxxxxxx.mdf'
これが私の解決策です。
余談ですが、私はdbをオフライン/オンラインの方法で試してみました。私の場合はうまくいきませんでした。 sqlserverサービスを再起動するブルートフォースはうまく機能しました。これは、すべてのデータベースをオフラインにすることの利害関係が高すぎる人にとっては問題になるかもしれません。ただし、私のようにローカルで開発しているだけの場合は、このソリューションで問題ありません。
私は何度も同じ問題に遭遇し、私の解決策を共有する必要があると考えました(すでに提供されている回答にもかかわらず)。
したがって、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は "sys.dm_os_enumerate_fixed_drives "古い"xp_fixeddrives "の代わりに、ローカルディスクの空き容量情報を取得します。これを回避するには、デバイスマネージャーに移動し、引用されたドライブを一時的に無効にします(私の場合、ドライブ "G"は私のDVD-ROMドライブです)。