Microsoft SQL Serverエラー9001の診断：データベースのログは利用できません
週末の間、私が実行しているWebサイトが機能しなくなり、Webサイトに要求が行われるたびにイベントビューアに次のエラーが記録されました。
イベントID：9001
データベース 'データベース名'のログは使用できません。イベントログで関連するエラーメッセージを確認してください。エラーを解決し、データベースを再起動します。
ウェブサイトは専用サーバーでホストされているので、サーバーにRDPでアクセスしてぶらぶらすることができます。データベースのLDFファイルはC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATAフォルダーに存在しますが、Management Studioからデータベースを操作しようとすると、同じエラー-9001：を報告するダイアログボックスが表示されます。データベースのログは利用不可...
このエラーを受け取ったのはこれが初めてであり、このサイト（およびその他のサイト）をこの専用Webサーバーで2年以上ホストしています。
このエラーはログファイルの破損を示していると私は理解しています。データベースをデタッチし、数日前からバックアップを復元することで、Webサイトをオンラインに戻すことができましたが、このエラーは、ハードドライブの障害など、さらに厄介な問題を示していることが心配です。
ウェブホスティング会社のサポートにメールを送ったところ、これが返信でした。
イベントログには他の原因の兆候は見られないため、ログが破損している可能性があります。現在、メモリのリソースは87％であり、これも影響を与える可能性がありますが、ほとんどありません。
ログは「破損する」だけですか？
私の質問：この問題を診断するために次に実行する必要がある手順は何ですか？これが実際にハードウェアの問題であるかどうかをどのように判断できますか？もしそうなら、ディスクを交換する以外にオプションはありますか？
ありがとう
データベース破損の問題の99％以上は、ストレージシステムの問題です。残りの問題の半分はメモリ不良が原因であり、残りの半分はSQL Serverのバグです。
おそらくストレージの問題です。
それが再度発生する場合は、データベースに対してDBCC CHECKDBを実行します。これにより、破損に関する詳細情報が得られ、復元を実行せずに問題を修正できるかどうかがわかります。データベースに対してcheckdbを実行するには、おそらくデータベースを緊急モードでオンラインにする必要があります。
メモリ使用率が87％であっても、問題とは関係ありません。 SQL Serverは、設計上、メモリを100％（またはそれに近い）まで実行します。
Management Studioでデータベースをオフラインにしてすぐにオンラインに戻すことで、これを解決できました。 dbcc checkdbは、これを実行した後に解決されたエラーをスローしていました。 なぜこれはうまくいったとは言えませんdidうまくいきました。
私も最近この問題を抱えており、山ほどの調査を行った結果、データベースがAUTO CLOSEに設定されている場合はよくあるようです。すべてのデータベースをAUTO CLOSE = FALSEに設定しました。これは1つのデータベースから始まり、2つのデータベースに移り、次はすべてのデータベースに適用されました。データベースを復元する代わりに、SQL Server Instance Serviceを再起動しただけです。症状を修正する別の方法は、問題のあるデータベースをオフラインにして、再びオンラインに戻すことです。
MS SQLは、データベースの破損を回避するために、影響を受けるデータベースのログをオフラインにします。そのため、9001エラーが発生します。
影響を受けるデータベースをオフライン/オンラインにすると、エラーが再発するまでMS SQLが影響を受けるデータベースログを有効にします。
これを解決する別の方法は、Auto_CloseオプションをOFFに変更することです
http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases
私はあなたがあなたのSQLサーバー用のディスクを狙うレイドを持っていると推測/希望します。ハードウェアの問題が疑われる場合、私が最初に行うことは、RAIDメンテナンス/診断ツールを実行することです。
2番目のことは（おそらく可能であれば同時に）、データベースで（おそらくシステムデータベースも）dbcc checkdbを実行します。
では、最初のステップとして、ログとmdfファイルを完全に別のドライブにバックアップします。早く！ （ファイルコピー）
また、データベース全体のバックアップを実行してみてください。
次に、以下を試してください。ログファイルを削除できる場合は、現在のデータベースを使用してデタッチするか、ディスク上のまったく別の場所に移動します。次に、データベースを再接続すると、GUIにログファイルが表示されます。ログファイルの削除（または削除）をクリックして表示されないようにし、[OK]をクリックします。基本的にログなしでアタッチすると、デフォルトの場所にデータベースのログファイルが作成されます。
お知らせ下さい。
昨日、同じエラーが発生しました。「データベース '％'のログは利用できません。致命的なエラー9001、メッセージ21。管理者に連絡してください」-
回避策-「TempDB」を確認しましたが、他のシステムデータベースと同様にアクセスできませんでした。次に、修復オプションに進む前に、そのインスタンスのSQLサービスを再起動するだけで問題は解決しました:) :)
はい、私もこれと同じ問題を抱えていました。tempDbエラー9001に関するものでした。つまり、ログは利用できません。私たちはサービスを再開し、すべてが順調でした。
この背後にある問題は、SAN=またはストレージの問題でしたが、I/O書き込み操作中に、15秒を超えて書き込むことができませんでした。