web-dev-qa-db-ja.com

SQL Server 2008r2は、Windowsの更新、エラーログ、WMIプロバイダーのエラーの後に起動しません

Windows 2008 R2ボックスにSQL Server 2008 R2インスタンスがあり、Windowsがほぼ1年間更新されていない（わかっている）、昨夜のWindowsパッチが適用され（保留中の約100）、今朝のSQL Server始まらない。

イベントビューアのエラーは次のとおりです。

initerrlog：エラーログファイル 'D：\ Program Files\Microsoft SQL Server\MSSQL10_50.SQL1\MSSQL\Log\ERRORLOG'を開けませんでした。オペレーティングシステムエラー= 5（このエラーのテキストを取得できませんでした。理由：15105）。

多くのリンク（例： SQLServerCentral ）によると、これは何らかの権限の問題であるように見えます。 SQL Serverが使用するように構成されているサービスアカウントは、ネットワークサービスアカウントです。これをADで確認しましたが、OKで、パスワードは正しいようです（その点では、機能していたときに、昨日から何も変更されていません）。 ：

  • ボックスでサービスアカウントをローカル管理者にした（一時的）

  • サービスアカウントがサーバーのSQL Serverグループにも追加されていることを確認します

  • エラーログフォルダーに対するサービスアカウントへの明示的なアクセス許可（フルコントロール）次に、プログラムファイルフォルダー全体（フルコントロール）

そして、私はまだ同じエラーが発生します。

次に、Configuration Managerで使用するサービスアカウントを（ネットワーク管理者（テストのためだけに知っている）またはローカルサービスアカウントに）変更しようとしました。これらの変更を適用すると、WMIプロバイダーエラーが発生します。

WMIプロバイダーエラー[WMIプロバイダーエラーコードの呼び出し：0x800742a2]

WMI Provider Error

私はこれに少し戸惑い、以前にそのようなものを見たことがありません。

誰かが何が起こっているのか、私が見逃したことを試すための他のアイデアを持っていますか？

編集1：

追加するために、WMIエラー MS Support 、 SQLServerCentral を検索するときに最初のヒットを確認しましたが、それでもアクセス許可の問題を示唆しているようです。アクセス許可の問題に関連する上記のすべてを再確認しましたが、それがどのように問題であるのかわかりません（サービスアカウントはローカル管理者（！）であり、ボックスのSQL Serverグループにあり、すべてに対して明示的なフルコントロールを持っています）プログラムファイル）。このWMIエラーがレッドニシンなのか、それともまったく別の問題なのか、気になります。

編集2：

起動を妨げていたERRORLOGファイルに何か問題があったようですが、アクセス許可の問題ではありません。ファイル自体の削除（まあ、他の場所へのコピー）によってSQLが強制されたように見えるため、ファイル自体の破損や何か新しいものを生成するサーバーとそれは正常に起動しました。エラーログファイルの何が問題なのかわからない（ファイルを開いて調査できるかどうかを確認します）。WMIプロバイダーのエラーが何なのかわかりません。サービスがオンラインになっているため、完全にテストすることはできません。それから、計画的なダウンタイムの後で、WMIプロバイダーが起動するかどうかを再試行します（これを適切に更新する/回答として追加します）。

編集3（最終更新）：

すべての症状は誤解を招くようで、この種の問題の通常の原因（権限）はこの場合の原因ではなく、それはERRORLOGファイル自体の問題であり、それを削除（再作成）することで問題が解決し、サービスが登場した。これを説明する answer を追加しました。しかし、これは私がこの原因を持っているこれらの症状を見つけることができる唯一のケースのようであり、それが許可への多くのケースであり、私は上記へのリンクを含めました、この質問の answer は入ります上の詳細。したがって、今後この問題が発生する場合は、ERRORLOGファイル自体をチェックアウトする前に、これらの手順（権限の問題を最初に確認する）に従うことをお勧めします。

sql-serversql-server-2008-r2error-logconfiguration-manager
3
Ian_H

これが最終的な更新/修正です：

この問題はかなり独特で、指摘された問題はすべて誤解を招くものであったと思われます。これらはすべて権限の問題につながり、問題ではないことが判明しました。別の回答で強調されているように、ほとんどの場合、それが問題になるようです。

この場合、ERRORLOGファイル自体に問題があったようです。その場所からファイルを削除すると、SQL Serverが起動時に新しいファイルを生成し、サービスが正しく起動したように思われます。

後で構成マネージャーで設定の変更をテストしましたが、WMIプロバイダーエラーの兆候はなかったため、これも誤解を招くようでした。 ERRORLOGファイル自体にアクセスするのではなく、それ自体に問題があるように思われます。そのERRORLOGファイルを調べて、何が問題であるかを見つけて（そして必要に応じて更新して）いるかどうかを確認しますが、今のところ問題は解決されているようです。

まとめ：

ほとんどの場合、これらの症状はおそらくアクセス許可の問題であり、元の質問の同様の問題へのリンクがあり、@ hot2useによる回答で詳しく説明されています。

ただし、（まれに発生する可能性が高く、この場合に発生したこともあります）、問題はERRORLOGファイル自体の問題であり、ファイルへのアクセス許可ではなく、削除（または単にどこかに移動）するだけでSQL Serverサービスが起動して、新しいERRORLOGファイルを生成します。

追加情報/リンク：

元の投稿からの同様の問題へのリンク：-

SQLServerCentral | MsSupport | SQLAuthority

WMIプロバイダーに関する別の種類の問題（同様の症状があると思われる）：- MsSupport

アクセス許可エラーについて詳しく説明しているこの質問の回答へのリンク。これは、多くの場合、これらの症状の原因です（今回だけではありません！）：- AnswerByHot2use

0
Ian_H

Microsoftの記事による公式のソリューションは次のとおりです。

この問題を回避するには、SQLServer2005MSSQLUser $ ComputerName $ InstanceNameドメイングループにドメインユーザーアカウントを追加します。

これを行うには、次の手順に従います。
1。 [スタート]ボタンをクリックし、[管理ツール]をポイントして、[Active Directoryユーザーとコンピューター]をクリックします。
2。 Active Directoryユーザーとコンピュータースナップインで、[ユーザーをクリックします。
3。 SQLServer2005MSSQLUser $ ComputerName $ InstanceNameをダブルクリックします。
4。 プロパティダイアログボックスで、-メンバータブをクリックします。
5。 メンバータブで追加をクリックします。
6。 ユーザー、連絡先、コンピューター、またはグループの選択ダイアログボックスで、ドメイン名\ユーザー名の形式でユーザーを入力します選択するオブジェクト名を入力してください =、次に[〜＃〜] ok [〜＃〜]をクリックします。 7. Propertiesダイアログボックスで、-[〜＃〜] ok [〜＃〜]をクリックします。

参照

SQL Server構成マネージャー

SQL Server構成マネージャーを実行して設定を変更すると、構成マネージャーは、行われた構成の変更に基づいて、ファイルとディレクトリに対する権限を追加および削除します。

このため、Microsoftは、構成の変更は常にSQL Server構成マネージャーで行う必要があると述べています。

重要
SQL Server構成マネージャーなどのSQL Serverツールを常に使用して、SQL ServerまたはSQL Serverエージェントサービスが使用するアカウントを変更するか、アカウントのパスワードを変更します。 SQL Server構成マネージャーは、アカウント名の変更に加えて、Windowsレジストリでのアクセス許可の設定などの追加の構成を実行して、新しいアカウントがSQL Serverの設定を読み取れるようにします。 Windows Services Control Managerなどの他のツールはアカウント名を変更できますが、関連する設定は変更しません。サービスがレジストリのSQL Server部分にアクセスできない場合、サービスは正しく開始されない可能性があります。

参照：SQL Server Configuration Manager （Microsoft Docs）

実行する実際の手順

あなたのケースでは、いくつかのステップを実行した可能性がありますが、正しい順序ではありません。以下を試してください：

  1. 開くSQL Server構成マネージャー
  2. SQL Server（INSTANCE）サービスアカウントを、サービスを実行させたくないユーザーに設定します。
  3. インスタンスのSQL Server（INSTANCE）サービスを再起動します（失敗するはずです）
  4. 閉じるSQL Server構成マネージャー
  5. SQL Serverサービスを実行するサービスアカウントを指定したグループに追加します（投稿の冒頭で詳しく説明しているように、手順1〜7）。
  6. 開くSQL Server構成マネージャー
  7. SQL Server（INSTANCE）サービスアカウントをSQLServer2005MSSQLUser $ ComputerName $ InstanceNameグループに追加したユーザーに設定します。
  8. 再起動SQL Server（INSTANCE）インスタンスのサービス

これが機能しない場合、SQL Server Program Files構造のあるレベルでACL（権限）が壊れている可能性があります。

SQL ServerアカウントとACL

サービスはまだ開始されておらず、アクセス許可（ACL）の問題である可能性がありますか？

次に、ファイル/フォルダの権限を修正する必要がある場合があります。 SQL Serverアカウントと必要な権限の完全なリストは、次の完全なドキュメントに記載されています。

MSSQLServerがドキュメントで参照されているすべての場所で、SQL Server（INSTANCE）を実行するアカウントに置き換えます。

たとえば、ドキュメントのSQL Serverサービスアカウント用に作成されたアクセス制御リストの確認セクションを確認する場合は、YourServiceAccountが以下にアクセスできることを確認してください。

サービスアカウント|ファイルとフォルダ|アクセス
 -------------------- + ----------------------- --- + --------------- 
 MSSQLServer | Instid\MSSQL\backup |フルコントロール
 | Instid\MSSQL\binn |読み取り、実行
 | Instid\MSSQL\data |フルコントロール
 ....

MSSQLServerの代わりにYourServiceAccountを使用してください。

参照：

1
John aka hot2use