快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

无法启动的SQL Server实例

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

每个人的SQL Server噩梦:实例将无法启动。如果您遇到这样的问题,请保持冷静,按照盖尔的建议进行操作,您很快就会恢复运行。同时,请练习这些步骤以便做好准备!

SQL Server服务将无法启动……提示不祥的音乐。在这种情况下,DBA的深夜,周末丢失和凌晨3点的冷比萨饼立即引起了人们的注意。

许多问题可能会阻止SQL Server服务启动,本文将研究更常见的问题,并希望提供一种摆脱噩梦的方法。我涵盖:

  • 服务帐户密码不正确或帐户被锁定或禁用
  • 主数据库文件损坏或丢失
  • 模型数据库文件损坏或丢失
  • 无法建立 tempDB
  • 无法打开错误日志

在深入探讨各种可能的原因之前,我们将从一些基本的故障排除步骤开始,这些步骤将有助于确定原因。

常见症状和初步故障排除

第一个也是最明显的症状是SQL Server服务未运行,并且出现错误提示您尝试重新启动它。

1722-1-0c051a8c-8fd5-4253-b295-0ee9026b6

图1:无用的错误

或者,如果您尝试从命令提示符下启动服务,则…

1722-nightmarefigure2.png

图2:另一个无用的错误

这些消息均不能帮助确定启动失败的原因。哦,以防万一图2中的消息引起了您的希望,通过运行无法获得更多帮助NET HELPMSG 3547。它仅给出相同的“发生服务特定错误”消息。

您应该开始查找原因的第一个地方是SQL Server错误日志。Windows应用程序事件日志也可以,但我更喜欢SQL错误日志,因为我可以一次看到所有消息,而不必一一点击。

SQL错误日志只是磁盘上的一个文本文件。如果不确定其位置,请在SQL Server配置管理器中检查SQL Server服务的启动参数,如图3所示。

1722-2cef17a8-c42c-4ade-8306-ef85f2a2767

图3:SQL Server启动参数

-e参数是我们需要的参数,就我而言,我可以看到我的错误日志应该在文件夹中:

“ C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\

这是SQL Server 2008默认实例错误日志的默认位置。要查找启动失败的原因,请导航至该文件夹,然后在记事本中打开最新的错误日志文件(称为ERRORLOG),然后向右滚动至底部。

如果SQL Server至少在失败之前启动了启动例程,则它将记录遇到的任何阻碍服务完全启动的错误。没有相关错误日志条目的两种情况是:

  • 服务遇到登录失败(服务帐户密码无效或帐户被锁定或禁用)
  • 错误日志文件的定义位置不存在,或者SQL帐户对此没有权限。

在第一种情况下,SQL Server甚至不会启动启动例程,因此不会记录任何内容。在第二种情况下,它无处可写日志条目。如果在SQL错误日志中没有找到任何内容,则需要检查Windows事件日志以找出原因,我们将在后面的部分中再次讨论这种情况。但是,在这种情况下,将出现错误日志,并且日志中的最后一条消息如下所示:

从消息中可以看到我的master数据库有问题,我可以在那里进行故障排除工作。这种方法消除了在紧急情况下尝试解决所有问题的根本问题,这是一种“方法论”,浪费时间并且可能在过程中造成更大的破坏,从而避免了任何麻烦。

完成基本的疑难解答的第一步,现在是时候深入研究导致SQL Server启动失败的各种可能原因以及建议的解决方案。

密码错误或服务帐户被锁定或禁用

我已经看到这种情况是在管理员将SQL Server服务帐户配置为要求定期更改密码的情况下发生的,并且在DBA或开发人员知道SQL Server服务帐户密码并有时使用它的情况下,通常会避免“不便的”安全策略例如那些禁止开发人员具有对生产服务器的sysadmin访问权限的开发人员。

如果有人更改了服务帐户密码,但没有使用新密码更新SQL Server服务,则SQL Server将运行良好,直到下次重新启动它为止,此时我们将在图1和图2中看到错误消息。 2。

此外,如果用户反复错误输入密码,或者服务(SQL或可能使用同一帐户的任何其他服务)反复尝试提交旧密码,则在更改密码后,该帐户最终将被锁定。和以前一样,这对正在运行的SQL Server无效,但是下次服务尝试启动时,它将无法这样做。

这是查看SQL Server错误日志无效的情况之一。最新的日志文件(Errorlog)仅包含重新启动之前的消息,并且没有任何问题的迹象。如果我模拟此问题并查看错误日志,则日志中的最后一条消息为:

这些消息只是记录了服务启动失败之前SQL Server的最后一次关闭,并且该日志中没有任何内容指示任何问题。然而,由于缺乏错误消息是,本身是有用的,因为它消除了许多潜在原因导致记录的消息。

下一个要查看的地方(是否是安全问题)是Windows事件日志,特别是系统日志(不是安全日志)。如果我去那里查看管理工具 | 事件查看器),并过滤错误,则会看到以下内容:

1722-1-cc6f515b-d19f-42d1-871d-6167aebab

图4:事件日志中的有用错误

明确表明错误的密码导致了问题!其他可能的消息是:

  • 登录失败:帐户当前已禁用。
  • 登录失败:帐户被锁定。

解决这些问题的方法非常简单。如果密码错误,请更改SQL服务使用的密码以匹配该帐户的真实密码,或者重置该帐户密码(如果未知),然后将所有使用该密码的服务更改为正确的密码。如果该帐户被禁用或锁定,则启用或解锁该帐户。

为防止出现此类问题,我建议您为SQL Server服务帐户使用非常复杂的密码,然后不要将密码设置为过期。没有人可以使用服务帐户,尤其是开发人员或管理员,没有人可以使用SQL Server服务。通常,我建议不同的SQL Server实例和服务使用不同的服务帐户。如果可能,请设置SQL Server服务帐户以禁止交互式登录。

主数据库文件丢失或无法访问

SQL Server在启动过程中需要做的第一件事就是打开和恢复master数据库,以便它可以加载配置设置以及找到并打开其他系统数据库和所有用户数据库。如果master由于某种原因,SQL Server找不到数据库文件,则它将无法启动。

如果有人错误地修改了启动参数(在启动参数之间忘记“;”是常见的错误),则SQL Server可能会在错误的位置查找master文件。或者,该位置可能是正确的,但由于例如驱动器故障或SQL Server服务帐户无权访问指定的文件或文件夹而无法访问。在每种情况下,启动都会失败。

在这种情况下,SQL Server错误日志将保存有用的信息。错误日志中的最后一条消息将类似于以下内容之一:

要么:

此处的关键是消息的第一部分,即操作系统错误代码,在第一种情况下为错误2,在第二种情况下为错误5。在第一个示例中,描述没有用,但是Internet搜索“操作系统”。错误2”将迅速显示这表示“ 文件未找到”,表明master.mdf文件不存在。在第二个示例中,“访问被拒绝”错误表示SQL Server没有对该mastlog.ldf文件的权限。

其他常见错误包括“ 错误3:找不到文件夹 ”和“ 错误32:文件正在被另一个进程使用 ”。

这里的第一步是确定master数据和日志文件发生了什么。是否有人将启动参数更改为指向错误的位置?如果是这样,我们需要更改启动参数,使其指向数据库文件的正确位置。您可以在Service Control Manager应用程序的服务属性下找到启动参数,如图3所示。该-d参数指定数据文件-l的位置,并指定日志文件的位置。

它们所在的驱动器是否可用?它们是否位于可访问的文件夹中?文件在那里吗?如果在每种情况下答案都是“是”,则尝试再次启动SQL Server,因为错误可能是暂时的。如果这行得通,那么您仍然需要调查问题发生的原因(可能是配置错误的防病毒扫描程序;也许磁盘需要花费一些时间才能上线)并进行纠正,以免再次发生。

如果文件不在预期的位置,可能是由于驱动器故障或某人意外删除了文件,那么我们需要从备份中还原它们(每个人的确都有系统数据库的备份,对吗……?)

因此,转到联机丛书和“还原主数据库”页面(http://msdn.microsoft.com/en-us/library/ms190679.aspx),该页面告诉我们要还原master数据库,必须首先重新启动使用-m标志在单用户模式下创建实例。

1722-6d9d4734-9577-486f-afc0-0343778ce87

图5:尝试使用-m标志重新启动SQL Server

或不…!没有master数据库,即使带有-m标志,SQL也不会启动。为了还原master数据库的备份,我们将必须:

  1. 重建所有系统数据库
  2. 以单用户模式启动SQL Server
  3. 恢复的备份master,以及备份modelMSDB(重建系统数据库重建所有的人,这就是为什么我们需要恢复modelMSDBmaster

顺便说一句:除了定期备份系统数据库外,我还希望为两个主要系统数据库(mastermodel)中的每个文件制作一次性的安装后副本。这不是因为复制数据库文件是一种很好的备份策略,而是因为它使从这种情况下恢复变得更容易,因为这意味着如果系统数据库文件完全消失,我将放下文件。这使我可以启动实例并还原系统数据库的备份。

联机丛书很好地记录了重建所有系统数据库的过程(http://msdn.microsoft.com/zh-cn/library/dd207003.aspx)。该工具说的不多,但是可以完成工作。

1722-669c696e-1609-41da-90c9-b892da281e3

图6:重建系统数据库

一旦完成,启动SQL Server的单用户模式(-m)和恢复mastermodelmsdb从备份,每个联机图书条目。

  • 还原master:http : //msdn.microsoft.com/en-us/library/ms190679.aspx
  • 还原modelmsdb:http : //msdn.microsoft.com/zh-cn/library/ms190749%28v=sql.105%29.aspx

主数据库文件损坏

仅查找master数据库文件是不够的。SQL Server必须能够打开数据库,对其进行恢复并使其联机。严重损坏可能会导致master数据库无法联机,从而导致SQL Server启动失败。

与前面的情况一样,最后的SQL Server错误日志将包含描述问题的错误。错误日志中的最终消息将如下所示:

也许这样:

根据损坏的类型以及文件的损坏部分,您可能会看到不同的消息。关键是在master数据库中发现了一些致命的损坏,并且每种情况下的解决方案与上一部分中丢失文件的描述相同。重建系统数据库,以单用户模式重新启动SQL Server并还原所有系统数据库的备份。

模型数据库文件丢失,无法访问或损坏

在启动过程中,一旦SQL打开并恢复了master数据库,就需要使其他系统数据库联机(从开始)TempDB。但是,SQL Server不能TempDB像其他系统数据库那样简单地找到并打开文件并运行崩溃恢复。TempDB与实例中的其他数据库不同,它不是要永久存储数据。因此,日志记录的工作方式有所不同TempDB;对于此数据库,SQL Server无法前滚事务,这是正常崩溃恢复的一部分。因此,TempDBSQL Server必须将其返回到已知状态,而不仅仅是数据库在启动时恢复,而不仅仅是在启动时进行恢复model。发生的情况是该SQL Server:

  1. 找到并打开现有tempDB数据和日志文件
  2. 将其文件大小设置为tempDB系统目录中指定的文件大小
  3. tempDB使用model,复制分配页,位图等来重新创建或“清除”(这些术语在文档和错误日志中可互换使用)。

如果TempDB文件不存在(请参阅下一部分),SQL将根据model数据库文件(与创建用户数据库时的情况类似)创建文件,TempDB并根据系统目录中指定的文件大小对其进行大小调整。

所有这些都是有点漫长的说法,为了干净启动,SQL Server需要清除TempDB。为此,SQL Server需要modelmodel模板一样使数据库联机(打开和恢复)。如果model数据库文件丢失或损坏,则清除操作TempDB将失败并且SQL Server启动将失败。但是,我希望上面更详细的解释可以帮助您理解在解决与相关问题的启动问题时看到的消息model

SQL错误日志将包含解释该问题的消息,它们与丢失或损坏的master数据库文件非常相似,只是针对model文件。

Model 数据库文件丢失:

Model 数据库文件损坏:

启动数据库“模型”。

请注意,在每种情况下,我们都会遇到model与无法创建问题有关的错误TempDB

如果model文件丢失,我们需要找出发生了什么情况。驱动器是否无法联机(或在SQL启动后联机)?是否有人不小心重命名或移动了文件?如果我们能够以与model前面针对丢失或无法访问的master文件所述类似的方式使文件可供SQL Server访问,那么这将解决问题。

如果model文件损坏,则我们需要还原的备份model。让我们看看联机丛书对还原有何评价model

“还原模型或msdb与执行用户数据库的完整数据库还原相同。”

好吧,这很有用…… 不是!如果没有SQL Server model,SQL Server就不会启动,因此我们不能像用户数据库那样直接还原它。

让我们尝试从命令行使用traceflag 3608(http://sqlserverpedia.com/wiki/Trace_Flags)启动SQL Server 。该跟踪标志告诉SQL Server master在启动时仅恢复数据库,因此SQL Server将保持model关闭状态(以及其他系统数据库);它不会尝试恢复model或清除TempDB,因此损坏的model文件不应导致SQL Server启动失败。

果然,SQL Server启动。太好了,现在让我们启动SQLCMD并还原model,如图7所示。

1722-8450f6f8-b210-4f61-a561-61b76b6a34e

图7:model使用traceflag 3608启动SQL Server之后尝试还原

那不是我想要看到的。让我们看一下错误日志(从命令行启动该错误日志时,SQL Server还将其打印到控制台),并查看错误报告。

我们这里有一个经典的catch-22。以前,虽然以有限的“ master仅-模式” 运行,但我们还是启动了SQL Server 。但是,当我们发出RESTORE命令时,SQL Server甚至没有尝试执行它,首先尝试清除TempDB(不是因为它需要TempDB执行还原操作,而是使其余系统数据库联机的一部分)。要清除TempDB,SQL Server尝试启动model,因为其中一个或多个model文件已损坏或丢失,所以它无法执行。因此,该过程在还原model启动之前失败。

由于问题似乎已经清除TempDB,因此让我们回到开始并尝试重新启动SQL Server,但是这次改为使用traceflag 3609,它告诉SQL Server TempDB在启动时不要清除,而只是从现有文件中恢复它。 。这不是您通常无法正常运行的事情,因为先前的关闭可能会TempDB处于不一致的状态(请记住,因为TempDBSQL Server无法前滚事务,这是正常崩溃恢复的一部分)。但是,从灾难中恢复可能很有用。

这次SQL Server甚至无法启动。通过使用traceflag 3609,我们指定SQL Server在启动时应TempDB从现有文件中恢复,但不要尝试清除它。但是,它仍然尝试model与其他系统数据库一起恢复(因为这次我们没有告诉它不这样做),并且恢复失败model导致SQL再次关闭。

奇怪的是,错误日志仍然抱怨无法创建TempDB,尽管它不需要这样做。也许这只是恢复失败时的默认消息model

好吧,如果一个traceflag无法完成任务,那么也许两个会:

这指示SQL Server不要恢复以外的任何数据库master,也不要清除TempDB,而只是从其现有文件中恢复该数据库。换句话说,如果SQL确实需要TempDB稍后再上线,它将不会尝试清除它,这是需要的model。这次,当我们单独使用traceflag 3608时,SQL Server可以正常启动。

现在,还原model

1722-199fbe57-d95c-4dc3-8d05-cc3c0cf70a3

图8:model使用跟踪标志3608和3609启动SQL Server之后的还原

这次恢复工作正常,但让我们看看错误日志报告了什么:

错误日志显示SQL Server已启动,TempDB但是由于先前启动SQL Server时使用了traceflag 3609,它只能恢复TempDB;它没有尝试清除它。顺便说一句,这是您唯一一次看到“ 恢复正在数据库’tempdb’中写入检查点 ”消息,因为恢复通常不会在上运行TempDB。请注意,如果TempDB文件也被损坏或丢失,则可能导致SQL Server关闭。

关键点在于,这次是RESTORE导致SQL Server尝试启动的命令model(对于正在还原的任何数据库都会执行的操作),而不是尝试清除TempDB。这样,现有的,已损坏的model数据库已被标记为“正在还原”,因此SQL Server不会尝试对其进行恢复,不会注意到损坏,因此还原可以完成。从某种意义上说,还原从这一点开始,就像还原任何用户数据库一样。恢复model完成后,我们可以在没有任何跟踪标志的情况下将SQL Server作为服务重新启动,它将正确启动。

正如我所描述的,这个过程听起来有些复杂,只是因为我想弄清楚为什么我们需要两个traceflag。实际上,此还原方法非常快捷:从命令行使用traceflags启动SQL,还原model备份,终止正在运行的SQL实例,然后重新启动服务。

不过,一种更简单的方法可能是model从同一版本的另一个SQL实例(最好也是Service Pack)复制文件,并使用这些文件代替丢失或损坏的文件。这样可以使SQL正常启动,然后我们可以简单地model从备份中还原。如果我们有model数据库文件的备份,我们同样可以很好地使用它们。

另一种办法是重建系统数据库(如前所述),然后恢复的备份mastermodelmsdb。这需要一点时间,因为需要还原三个备份,但是效果很好。

TempDB位置不存在

如上一节所述,要启动,SQL Server必须能够TempDB联机。丢失或损坏TempDB文件在这里不是一个大问题,因为SQL Server可以根据需要重新创建TempDB数据库model。但是,该TempDB文件夹必须存在。

如果有人更改了TempDB数据库,并为此指定了无效的文件位置,或者存储的驱动器TempDB发生故障,或者在SQL Server服务停止时有人更改了文件夹名称,则SQL将无法重新启动。

与大多数系统数据库问题一样,SQL Server将错误消息记录到错误日志中,如下所示:

如前所述,找不到操作系统错误3。可能是文件夹C:\ SQLData不存在,也可能是驱动器根本不存在。

与以前的情况一样,遇到此错误的第一步是确定原因。驱动器发生故障了吗?SQL Server服务后,驱动器是否联机?有人重命名目录了吗?简而言之,我们是否可以通过更改或添加目录来快速解决问题?在上面的示例中,目录不存在的可能性比C:驱动器不存在的可能性更大(请参见操作系统正在运行),因此重新创建该目录将允许SQL Server启动。

如果驱动器发生故障,则可以将SAN LUN临时映射(甚至添加外部驱动器)到该驱动器号,以允许SQL Server启动。SQL Server启动后,我们可以TempDB使用ALTER DATABASE命令更改文件的定义位置,然后重新启动SQL Server,将TempDB文件放置到新位置。

如果不可能,那么我们需要在不清除SQL Server的情况下启动SQL Server,TempDB以便我们可以指定一个可以工作的新位置。如上一节所述,我们可以使用traceflag 3608

SQL从“ master-only”配置开始,这并不奇怪,我们可以通过SQLCMD连接并将TempDB数据库的定义位置更改为确实存在且SQL Server有权访问的文件夹。

1722-44b7def8-329f-4093-94eb-54a014cfed4

图9:更改TempDB以更改文件位置

假设我们正确指定了新位置,我们现在可以停止SQL Server的命令行实例,重新启动服务,SQL Server将TempDB在其新位置重新创建文件。

缺少错误日志位置

这是一个非常有趣且意外的错误!SQL Server启动需要做的一件事是查找并循环错误日志。它使用-e启动参数(如果已指定)查找错误日志,或者如果该参数不存在,则在注册表中查找。一旦获得位置,它将重命名现有的错误日志文件(Errorlog变为Errorlog.1Errorlog.1变为Errorlog.2,依此类推),创建一个新文件,Errorlog然后开始将启动进度记录到该文件中。

如果为错误日志指定的目录不存在,则启动将失败,并且将没有错误日志告诉您失败的原因。

错误日志目录可能丢失的主要原因有两个:

  • 驱动器故障(如果错误日志位于与SQL Server二进制文件不同的驱动器上)
  • 对服务启动参数的不正确修改,以便SQL Server查找不存在的位置

第一个暗示这是SQL Server无法启动的原因是缺少新的错误日志。通过在SQL Server配置管理器中检查SQL Server服务的启动参数,我们可以找出SQL Server期望在哪里找到错误日志,如图3前面所示。如果为该-e参数指定的位置不存在,则为很大的提示表明问题是缺少错误日志目录。该位置也可能存在,但是SQL Server服务不具有访问该位置的权限,在这种情况下,该位置将存在,但是从上次启动尝试开始将没有错误日志。

为了确认问题是缺少错误日志,我们可以检查Windows事件日志,特别是应用程序日志,如果存在,则可以找到图10所示的错误消息。

1722-28e0005c-be84-47db-8fa3-a3554aa8020

图10:检查Windows事件日志中是否缺少错误日志消息

如前所述,找不到操作系统错误3是old。错误5将ermission否认,并错误32名意味着该Errorlog文件是由另一个进程使用SQL时试图打开它,可能由错误配置的防病毒扫描引起的。

再次,正确的解决方案取决于问题的确切性质。如果我们要处理配置错误的防病毒扫描程序,该程序在SQL尝试访问文件时正在读取文件,那么解决方法可能很简单,例如重新启动服务并修复防病毒配置以确保问题不会再次发生。

如果SQL Server服务没有访问该文件夹的权限,则我们授予必要的权限,然后重新启动SQL Server服务。危机过去后,我们可以找出谁删除了许可以及原因,也许是安全管理员加强安全性或实施新的组策略。

如果问题是文件夹或驱动器丢失,则可以修改-e启动参数指定的值,使其指向存在的位置,该位置应允许SQL Server服务启动。如果仅缺少该文件夹,我们可以重新创建该文件夹并分配正确的权限。SQL Server无需查找旧的错误日志文件即可启动。它只需要文件夹在那儿。

结论

在本文中,我们深入研究了可能导致SQL实例无法启动的一些问题,包括属于系统数据库的文件丢失,帐户问题和错误日志丢失。我们调查了这些问题的原因以及解决这些问题的方法,并使SQL重新启动并运行。

每个DBA都必须如此迅速地排除故障并解决,这一点至关重要。我鼓励负责生产SQL Server实例的任何人启动VM并解决这些问题和解决方案。重命名属于master数据库的文件;腐败model; 删除TempDB文件夹并尝试从各种情况中恢复。

这样,如果发生这样的问题,您将立即知道如何进行操作以及如何使事情快速有效地恢复运行。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638