none
MSSQLSERVER サービスが開始できない RRS feed

  • 質問

  • お世話になっております。

    以下事象の解消にご協力いただきたく、宜しくお願い致します。

    【環境情報】

    Windows Server 2008R2
    SQL Server 2008R2

    CBKMRGD3,CBKMRGD4でWSFCにてクラスター構成を組んでいる。
    SQLインストール時のドライブ構成として、以下をクラスターディスクで構成している。
    Mドライブ:SQL実データ(mdfファイル)
    Nドライブ:SQLトランザクションログ(LDFファイル)
    Oドライブ:SQL構成DBデータ(masterなどのmdf,ldfファイル),SQL TEMPログ、エラーログ(.LOGファイル)

    以下記述の事象より、M,N,Oドライブはすべて容量が逼迫(残り10MB)の状態である。

    【事象】

    現在の状態として、「SQL Server(MSSQLSERVER」サービスが実行できない状態。
    Windowsのローカルサービス、クラスターサービス、SQLサーバー構成マネージャーいずれからも起動不可。
    イベントログに出力されているエラーは以下となる。
    イベントID:17058,MSSQLSERVER
    initerrlog: エラー ログ ファイル 'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG' を開けませんでした。オペレーティング システム エラー = 5(アクセスが拒否されました。)。

    【経緯】

    ・開発環境にてSharePointジョブ履歴の削除を実行すると、Mドライブが逼迫してしまう事象の調査を実施。
    SharePointジョブ履歴の削除=Oドライブ上の不要データを削除するSharePointの機能
    削除対象のテーブルはSharePoint_Configテーブルとなり、該当のDBの復旧モデルは完全復旧モデルとなる
    上記実行時のトランザクションログが膨大となり、Mドライブが逼迫してしまう事象。

    1.SharePointジョブ履歴の削除により、膨大なトランザクションログが発生し、Mドライブが逼迫するものと考え、該当DBの復旧モデルを単純復旧モデルへ変更
    2.上記単純復旧モデルの状態でSharePointジョブ履歴の削除を実行
    3.単純復旧モデルにも関わらず、膨大なトランザクションログが発生しMドライブが逼迫
    4.Mドライブ逼迫後に該当のSharePoin_Configテーブルにアクセス不可となる。(その他のDBにはアクセス可能)
    5.Mドライブ内に過去の作業時に保管した不要ログファイルがあったため、別ドライブへ退避
    6.退避後、すぐにトランザクションログが増えまたしてもMドライブが逼迫
    7.6の状態から、該当DBにアクセスできない状態ではあるが裏でJOB履歴の削除は実行され続けていると考え、
     実行中のクエリを強制終了するために、sqlserver.exeをタスクマネージャーからプロセスキル
    8.7にてsqlserver.exeのプロセスキルをした段階から、SQLサービスが起動しなくなる
    9.サービス起動不可時に出力されるエラーイベントは以下
    イベントID:17058,MSSQLSERVER
    initerrlog: エラー ログ ファイル 'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG' を開けませんでした。オペレーティング システム エラー = 5(アクセスが拒否されました。)。

    【切り分け内容】

    それぞれ、以下を実施しましたが改善はみられませんでした。
    ・Windwosサービスからのサービス起動
    ・クラスターサービスからのサービス起動
    ・SQLサーバー構成マネージャーからのサービス起動
    ・クラスターフェールオーバー
    ・OS再起動
    ・各種容量逼迫しているドライブ内の不要ファイル削除実施し、ドライブの空き容量確保
    ・エラー内容より、サービス実行アカウントがERROLOGにアクセス権がないと考え、
     サービス実行アカウントをドメインのSQL権限のあるアカウントからローカルアカウントへ変更しております。
     その後、元々のドメインアカウントへ変更していますが、出力するエラー内容に変化はありませんでした。

    【確認事項】
    ・発生しているエラーイベントより、Nドライブ内のエラーログファイルへサービス実行アカウントの権限がないためサービス起動できないと考えております。
     ただ、上記経緯からもサービス実行のためのアカウント情報は特に変更しておりません。
     エラー内容から、その他考えられる原因や対処法ございますでしょうか。
    ・上記経緯から、sqlserver.exeのプロセスキルした段階からサービスが起動出来なくなっております。
     プロセスをキルしたことと、サービスが起動しないことによる因果関係が分かっておらずプロセスキルしたことでサービスが起動しなくなることなどございますでしょうか。
    ・SQLにて利用する、上記のM,N,Oドライブが全て逼迫状態にありますがサービス起動できないことと関連性はございますでしょうか。
    ・その他、確認観点や必要なログ等ございましたらご教示いただけますでしょうか。

    2021年2月25日 8:51

回答

  • 問題の切り分けとして、以下について実施されてみてはいかがでしょう。

    1) SQL Server サービス起動アカウントに指定している ドメイン ユーザー に、'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\' フォルダに対する フルコントロール権限 を付与後、フェール オーバー クラスタ マネージャ から SQL Server クラスタ リソースを開始し、現象が解消するか確認。

    2) 1) で現象が解消しなかった場合、「N:\MSSQL10_50.MSSQLSERVER\MSSQL\」に正常にアクセスできることを確認後、SQL Server 構成マネージャー から SQL Server エラーログの配置パスを変更 (例えば、N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log2) 後、フェール オーバー クラスタ マネージャ から SQL Server クラスタ リソースを開始し、現象が解消するか確認。※ 起動パラメータ -e が SQL Server エラーログの配置パス


    SQL Server ログ - ERRORLOG ファイルの保存場所
    https://sql55.com/column/how-to-find-error-log-file-location.php

    個人的には、OS エラー 32 ではなく、 OS エラー 5 であるため、SQL Server サービス起動アカウントに指定したアカウントの権限で、エラーログ ファイル (ERRORLOG) に対するアクセス権限がないことを疑っています

    ---
    イベントID:17058,MSSQLSERVER 
    initerrlog: エラー ログ ファイル 'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG' を開けませんでした。オペレーティング システム エラー = 5(アクセスが拒否されました。)
    ---




    • 編集済み NOBTA 2021年2月25日 11:00
    • 回答としてマーク KK0108_kk 2021年3月4日 12:11
    2021年2月25日 10:55

すべての返信

  • 問題の切り分けとして、以下について実施されてみてはいかがでしょう。

    1) SQL Server サービス起動アカウントに指定している ドメイン ユーザー に、'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\' フォルダに対する フルコントロール権限 を付与後、フェール オーバー クラスタ マネージャ から SQL Server クラスタ リソースを開始し、現象が解消するか確認。

    2) 1) で現象が解消しなかった場合、「N:\MSSQL10_50.MSSQLSERVER\MSSQL\」に正常にアクセスできることを確認後、SQL Server 構成マネージャー から SQL Server エラーログの配置パスを変更 (例えば、N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log2) 後、フェール オーバー クラスタ マネージャ から SQL Server クラスタ リソースを開始し、現象が解消するか確認。※ 起動パラメータ -e が SQL Server エラーログの配置パス


    SQL Server ログ - ERRORLOG ファイルの保存場所
    https://sql55.com/column/how-to-find-error-log-file-location.php

    個人的には、OS エラー 32 ではなく、 OS エラー 5 であるため、SQL Server サービス起動アカウントに指定したアカウントの権限で、エラーログ ファイル (ERRORLOG) に対するアクセス権限がないことを疑っています

    ---
    イベントID:17058,MSSQLSERVER 
    initerrlog: エラー ログ ファイル 'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG' を開けませんでした。オペレーティング システム エラー = 5(アクセスが拒否されました。)
    ---




    • 編集済み NOBTA 2021年2月25日 11:00
    • 回答としてマーク KK0108_kk 2021年3月4日 12:11
    2021年2月25日 10:55
  • ちなみに エクスプローラから 'N:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG' にアクセスし、ERRORLOG ファイルを開くことはできますでしょうか?
    2021年2月25日 10:57
  • ご返信いただきありがとうございます。

    そもそも、ERRORLOGファイルを開く事が出来ませんでした。

    ご提案いただいた1,2の手順はまだ実施出来ていないのですが、この場合はファイルが破損しているなど考えられますでしょうか。

    ファイル自体は現状、約20GBあるためメモ帳では容量からも開くことが出来なかったのですがその他のアプリケーションを利用しても開く事が出来ません。

    SQLのERRORLOGの仕様を理解出来ておらず申し訳ないのですがこのファイルは修復する事は可能なのでしょうか?

    また、ERRORLOG.1やERRORLOG.2のように複数ファイル存在しています。

    今回イベントログにアクセス拒否されているのはERRORLOGと数字のついていないものになりますがこのファイルを削除することで改善されたりしますでしょうか。

    2021年2月25日 23:46
  • 「ERRORLOGを開くことができない」とは、「オペレーティング システム エラー = 5(アクセスが拒否されました。)」が発生している状態でしょうか?
    仮に上記の場合、ファイル破損の可能性よりも権限の問題がやはり疑われます。ファイル破損の可能性もゼロではないかとは思いますが。
    まずは、問題の切り分けとして 1の手順を実施されてみたほうがよいかと思います。

    なお、仮に ERRORLOG が破損していた場合、残念ながらERRORLOGを修復することはできないかと思います。
    しかしながら、SQL Server サービス起動アカウントが、エラーログファイルの配置パスに対して フル コントロール権限が付与されている場合、ERRORLOG ファイルが該当のパスに存在していない場合は、自動的に新規作成されるため、エラーログファイル(ERRORLOG, ERRORLOG.*)を削除しても問題ないかと思います。
    ただ、実際にエラーログファイルを削除する場合は、事前に空き容量が十分にあるディレクトリに退避させておくと良いのではないかと思います。

    [補足]
    エラーログが 20GBと肥大化している場合、SQL Server プロセスで何か問題が発生した際の調査に使用することが難しくなるかと思いますので、該当の環境で定期的にエラーログを「sp_cycle_errorlog」を実行し、ファイルサイズが大きくなりすぎないよう、手動でローテーションさせたほうがよいかもしれません。

    sp_cycle_errorlog (Transact-SQL)
    https://docs.microsoft.com/ja-jp/sql/relational-databases/system-stored-procedures/sp-cycle-errorlog-transact-sql?view=sql-server-ver15
    2021年2月26日 2:30


  • お世話になっております。

    進捗あったのでご連携させていただきます。
    ただ、サービスは開始できたものの別の問題も発生しております、、、。

    ERROLOGを開けなかったのは、恐らくファイルサイズが大きすぎたせいでした。
    ポップアップで、「ファイルを開くのに時間がかかりすぎた」といったメッセージが出ており、
    イベントログには何も出力されていませんでした。

    ご案内いただいた1の手順を実施してみたのですが改善は見られなかったです。
    2の手順を実施する前に、ERROLOGを別のドライブへ退避した後にサービスを起動したらサービスを開始する事が出来ました。
    ご案内いただいたように、自動で作成されておりました。
    上記からも権限には問題なかったのかと考えております。

    ただ、サービスは開始出来たのですが、以下のエラーの発生により該当のDB「SharePointConfig」がSQLから認識されていない状態になります。
    -----イベントログに出力されたエラー-----
    1.MSSQLSERVER17053、O:\MSSQL\Data\SharePoint_Config.mdf:オペレーティングシステムエラー112(ディスクに十分な空き領域がありません。)
    2.MSSQLSERVER1101、データベース'SharePoint_Config'の新しいページを割り当てられませんでした。
     ファイルグループ'PRIMARY'のディスク領域が不足しています。
     ファイルグループ内のオブジェクトの削除、ファイルグループへの新しいファイルの追加、
     またはファイルグループの既存のファイルの自動拡張の設定のいずれかを行って、必要な領域を作成してください。
    3.MSSQLSERVER3314、データベース'SharePoint_Config'でログに記録された操作を元に戻しているときにエラーが発生しました。
     エラーが発生したログレコードIDは(852326:19503:71)です。
     通常、この前に特定のエラーがWindowsイベントログサービスログに記録されます。バックアップからデータベースまたはファイルを復元するか、データベースを修復してください。
    --------------------------------------

    ■ご確認内容
    1.エラー内容から、Oドライブの容量が足りないために'SharePoint_Confifg'が認識されていないものと考えております。
     単純にOドライブの容量を空けられれば復旧するものなのでしょうか。
     3つ目のエラー内容に復元または修復と記載があるのが気になっております。
     また、他のOドライブ内のDBは認識されているため、'SharePoint_Config'のmdfファイルが破損している可能性を危惧しております。

    2.Oドライブの容量の空け方について
     現在、Oドライブの空き容量は約9MBとなり全体容量は90GBになります。(そのうちの55GBをSharePoint_Configにて使用)
      エラーメッセージの2について調べたところ、全体の容量の10%以下になった場合に発生するエラーとの事から約10GBほど空ける必要があると考えております。
     ただし、Oドライブ内はmdfファイルのみ格納されているため、不要ファイルは存在しません。
     他のmdfファイルについてはそれぞれ約1GB~5GBほどのファイルが複数存在しております。
     シュリンクを試みるために、ディスク使用量のレポートを確認したのですが全て予約済みの領域を使用済みの領域に数MBの差異しかないため、シュリンクは効果的ではないと考えています。
     上記から、不要なDBを探し、一時的にデタッチをし、Oドライブから該当のmdfファイルを退避することでOドライブの容量を確保しようと考えているのですが、考え方に問題はないでしょうか。

    3.Mドライブの容量について
     はじめの投稿にも記載させていただいているのですが、Mドライブ(トランザクションログ:LDFファイル)についてもひっ迫しております。
     1.8GB/72GBとなっており、仮にOドライブの容量を確保出来たとしてもMドライブの容量不足で同様のエラーメッセージが出力されるのではないかと考えております。
    2021年3月1日 0:25

  • 2.Oドライブの容量の空け方について
     現在、Oドライブの空き容量は約9MBとなり全体容量は90GBになります。(そのうちの55GBをSharePoint_Configにて使用)
      エラーメッセージの2について調べたところ、全体の容量の10%以下になった場合に発生するエラーとの事から約10GBほど空ける必要があると考えております。
     ただし、Oドライブ内はmdfファイルのみ格納されているため、不要ファイルは存在しません。
     他のmdfファイルについてはそれぞれ約1GB~5GBほどのファイルが複数存在しております。
     シュリンクを試みるために、ディスク使用量のレポートを確認したのですが全て予約済みの領域を使用済みの領域に数MBの差異しかないため、シュリンクは効果的ではないと考えています。
     上記から、不要なDBを探し、一時的にデタッチをし、Oドライブから該当のmdfファイルを退避することでOドライブの容量を確保しようと考えているのですが、考え方に問題はないでしょうか。

    SharePoint 関連のデータベースであれば、ご検討されている対策で問題ないかについて、別途 SharePoint 観点からも確認されたほうが良いかと思いますが、Oドライブの空き容量を増やすという対策としては、SharePointのゴミ箱データ、ログ情報などを削除し、データベースのシュリンクを実施する、もしくは、不要なデータベースを十分な空き容量が存在するドライブ(MSFCなのでクラスタ 共有ディスク リソース) へ移動させるということが有効かと思います。

    2021年3月1日 2:35
  • ■ご確認内容
    1.エラー内容から、Oドライブの容量が足りないために'SharePoint_Confifg'が認識されていないものと考えております。
     単純にOドライブの容量を空けられれば復旧するものなのでしょうか。
     3つ目のエラー内容に復元または修復と記載があるのが気になっております。
     また、他のOドライブ内のDBは認識されているため、'SharePoint_Config'のmdfファイルが破損している可能性を危惧しております。

    確実にデータベースが正常な状態で復旧できるという保証はできませんが、OS エラー 112 については、Oドライブの空き容量を空けることで改善します。

    -----イベントログに出力されたエラー-----
    1.MSSQLSERVER17053、O:\MSSQL\Data\SharePoint_Config.mdf:オペレーティングシステムエラー112(ディスクに十分な空き領域がありません。)
    2.MSSQLSERVER1101、データベース'SharePoint_Config'の新しいページを割り当てられませんでした。

    データベースが破損しているかについては、Oドライブの空き容量を空けて、OS エラー 112 を解消後、DBCC CHECKDB コマンドを実行していただくと良いかと思います。
    なお、SharePoint の構成データベースで不整合が確認ができた場合は、SQL Server 観点からのデータベース修復を実施することが出来なくなると思いますので、バックアップからの構成データベースの復元、SharePointサイトの再構成が必要になるかもしれません。

    【第10回】基本から始める SQL Server【整合性チェック】
    https://www.nobtak.com/entry/sqlb11


    2021年3月1日 2:38
  • 3.Mドライブの容量について
     はじめの投稿にも記載させていただいているのですが、Mドライブ(トランザクションログ:LDFファイル)についてもひっ迫しております。
     1.8GB/72GBとなっており、仮にOドライブの容量を確保出来たとしてもMドライブの容量不足で同様のエラーメッセージが出力されるのではないかと考えております。

    以下のURLを参照していただくと良いかもしれません。なお、トランザクション ログのバックアップをこまめに実施することが対策になるかとは思います。

    【INDEX】SQL Server トランザクションログ肥大化 (原因/対処方法)
    https://www.nobtak.com/tlogidx

    エラー 9002、17053 の対処方法 [SQL Server]
    https://www.nobtak.com/entry/tlogsr


    • 編集済み NOBTA 2021年3月1日 3:01
    2021年3月1日 2:56
  • KK0108_kkさん、こんにちは。フォーラムオペレーターのHarukaです。
    MSDNフォーラムにご投稿くださいましてありがとうございます。

    >上記から、不要なDBを探し、一時的にデタッチをし、Oドライブから該当のmdfファイルを退避することでOドライブの容量を確保しようと考えているのですが、考え方に問題はないでしょうか。
    →はい、スペースを解放するためにいくつかの不要なデータベースを移動できます。 ALTER DATABASE MODIFY FILEステートメントを使用して、データベースファイルを移動できます。
    例えば:
    移動するファイルごとに、次のステートメントを実行します。 

    ALTER DATABASE [DB] 
        MODIFY FILE ( NAME = dbname_Data,    
                      FILENAME = 'E:\New_location\ dbname _Data.mdf');   
    GO 
     ALTER DATABASE [DB]   
        MODIFY FILE ( NAME = dbname _Log,    
                      FILENAME = 'E:\New_location\ dbname _Log.ldf');   
    GO 
    

    次に、次のSQLスクリプトを実行して、SQLデータベースをオフラインにします。 

    ALTER DATABASE dbname SET OFFLINE;   

    ファイルを新しい場所に移動します。 これが完了したら、次のクエリを実行してデータベースをオンラインに戻すことにより、データベースをオンラインに設定できます。 

    ALTER DATABASE dbname SET ONLINE;   

    詳細については、ユーザーデータベースの移動をご参照してください。

    また、sharepoint_configデータベース用に十分なディスク容量があることを確認してください。 十分なスペースがあるときに同じエラーが発生する場合、回避策はバックアップからデータベースを復元することです。 
    復元後、データベース用の新しいデータファイルを別の場所のファイルグループに作成して、データベース用のスペースを増やすことができます。 

    どうぞよろしくお願いいたします。


    MSDN/ TechNet Community Support Haruka
    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2021年3月1日 6:41
    モデレータ


  • お世話になっております。

    Oドライブの不要DBのmdfファイルを別のクラスターディスクに移動させることで
    Oドライブの容量を空けたところ、昨日まで出力されていた3種類のエラーは解消されました。
    ただし、該当のSharePoint_Configについては未だにmanagement studioで認識されません。
    DB一覧に表示されず、デタッチされているかのような状態となりアタッチしようにもmdfファイルの候補にも出てこない状態です。
    Oドライブ上には確かにmdfファイルは存在しているのですが、、。

    先日mdfファイルが破損している可能性も考慮してDBCC CHECKDB コマンドをご案内いただきましたが、
    management studioに存在しないのでコマンドも実行出来ない状態です。

    考えられる原因としてMドライブ(トランザクションログ領域)のひっ迫も考えられますが、
    Mドライブの9割をSharePoint_Configのldfファイルが締めており、management studioから認識されない事もあり
    シュリンクやログの切り捨ても実行出来ません。

    現状、Oドライブの容量を空けた事でイベントログにエラーは一つも出力されていない状態となります。
    エラーもないため、現状確認すべき観点の辺りがつかず大変申し訳ございませんが引き続きご協力のほどお願い致します。
    2021年3月1日 23:11

  • Haruka様

    お世話になっております。

    Oドライブの容量を空け、エラーは解消されたのですが
    現状もSharePoint_ConfigはManegementStudioから認識されておりません。

    少し前に詳細も投稿しているのですがこの場合の対処ございましたらご教示いただけますと幸いです。

    宜しくお願い致します。


    2021年3月1日 23:13
  • 以下のコマンドを実行した場合、Sharepoint_Config データベースは表示されますでしょうか?

    もし登録内容が表示された、state が オンラインになっているかを確認していただき、オンラインになっていない場合は、SQL Server エラーログに何かエラーが出力されていないかを確認されると良いかもしれません。

    O ドライブにあるはずの .mdf ファイルが SSMS から参照ができないとのことですが、仮に データベース Sharepoint_Config の登録が該当のSQL Serverインスタンスに登録されていない場合は、アタッチコマンドで明示的にデータベース物理ファイル、トランザクションログファイルのパスを指定することで、データベースをアタッチさせることはできるかと思います。


    https://docs.microsoft.com/ja-jp/sql/relational-databases/databases/attach-a-database?view=sql-server-ver15#to-attach-a-database

    もしくは

    https://docs.microsoft.com/ja-jp/sql/relational-databases/system-stored-procedures/sp-attach-db-transact-sql?view=sql-server-ver15

    select * from sys.databases


    2021年3月2日 14:28


  • NOBTA様

    お世話になっております。

    大変申し訳ございません。
    私が確認するインスタンスを誤っており、該当のSharePoint_Config DBは正常に認識されておりました。
    おかげさまで無事復旧する事が出来ました。
    大変、感謝しております。ありがとうございました。
    2021年3月3日 11:44
  • KK0108_kkさん、こんにちは。フォーラムオペレーターのHarukaです。
    フォーラムに投稿くださいましてありがとうございます。

    本件、NOBTAさんより参考になる投稿が寄せられたようでなによりです。

    [回答としてマーク]機能は設定された投稿が後から参照しやすくなりますので、
    同じ問題でお困りの方のためにも参考になった投稿に設定いただけますと幸いです。

    お手数ですが、ご協力の程どうかよろしくお願いいたします。

    MSDN/ TechNet Community Support Haruka
    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2021年3月4日 2:41
    モデレータ