主页 / dba / 问题 / 164302
Accepted
BradC
Asked: 2017-02-15 08:25:58 +0800 CST

主数据库已损坏，实例无法启动 - 我的选择是什么？

  • 772

帮助！我的主数据库已损坏，我什至无法使 SQL 实例联机！我有哪些选择可以让我的服务器备份？

我确实有master的备份，但是MSDN页面“Restoring master Database”要求我以单用户模式启动实例，我做不到！

（注意：我将这个问题未指定 SQL 版本，以便成为更广泛适用的参考。DBA.SE 上有一些类似的问题，但没有涉及服务器无法启动的问题。）

sql-server corruption

3 个回答

  1. Best Answer

    以下是我将调查的一些途径。不要做所有这些（其中一些是实现相同目的的不同技术），但值得考虑：

    1.直接查看SQL错误日志

    直接浏览到包含 SQL 错误日志的文件夹并将最新的日志加载ERRORLOG到记事本中，以获取有关 SQL 实例无法启动的原因的更多详细信息。也许您会发现问题根本不在于主数据库。

    2.尝试以单用户模式启动实例

    这是SQL server 启动选项的完整列表，包括-m（单用户模式）和-f（最小配置模式）。如果有问题，其他选项允许您指定主数据库的路径。

    如果您能够启动实例，请按照您链接的用于恢复主数据库的 MSDN 文章中的步骤或Thomas LaRock 的详细演练中的步骤进行操作。

    如果另一个应用程序总是抢先获得单个用户连接，请首先禁用 SQL 代理，使其无法启动。其次，看这个问题的思路，使用-m"Application Name"参数指定应用程序名称。

    3. 恢复master到另一个实例并复制它的文件

    我只发现另一个提到这种未记录的技术，但我在上周末成功地使用了它，所以它可能值得一试。

    如果您无法在单用户模式下启动实例，但您有另一个 SQL 实例运行完全相同的 release 和 build，请尝试将最后一个已知良好的主数据库备份从您的死服务器恢复到另一个实例：

    • 恢复为不同的名称，当然（master_please_god_let_this_work），WITH MOVE所以你不会master在你的好服务器上覆盖
    • 恢复WITH NORECOVERY。不确定这是必要的，但让我感觉更好，因为我知道另一台服务器不会改变恢复的主服务器中的任何内容
    • 将其设置为离线：ALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
    • 将恢复的 MDF 和 LDF 文件从正常服务器复制到死服务器
    • 根据需要重命名master.mdf和mastlog.ldf文件，以用恢复的版本替换坏的主文件
    • 交叉手指并启动实例
    • 可选：在恢复的服务器上重新恢复主服务器。不确定这是必要的，因为我们非常小心地不更改master.

    4.重建系统数据库

    如果您没有另一个运行相同版本的实例，或者如果您不习惯使用 #3 中列出的未记录过程，或者如果您没有备份master（为什么没有备份？？），您可以从原始安装磁盘重建 SQL 系统数据库：

    Setup.exe /ACTION=REBUILDDATABASE /...

    完成后，您可以按照之前链接的步骤master从上次的良好备份中恢复。您还需要恢复最近的备份msdb以保留所有作业、作业计划和作业历史记录。

    5. 将所有 USER 数据库恢复到新的（或现有的）SQL 实例

    如果您已经有另一个现有实例正在运行（适当的 SQL 版本，足够的磁盘空间），我可能会在我处理上述其他故障排除步骤时从最近的备份开始数据库恢复，以防万一我需要它们。

    如果您的新（或重新安装的）实例可以访问同一个磁盘，那么将它们简单地附加为新数据库会更快：

    CREATE DATABASE foo 
ON (FILENAME = 'D:\data\foo.mdf'),
   (FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;

    6.重新做任何更改master

    一旦成功恢复master（通过上述任何技术），您需要调查可能丢失的任何更改，如果它们是在您刚刚恢复的备份之后进行的：

    • 安全更改
    • 新数据库（文件仍将在磁盘上，只需附加它们）
    • 服务器范围的设置

    没有神奇的方法可以找到这些，如果你有这些更改，你必须回到你自己公司的文档跟踪来进行这些更改。

    • 15

  2. 我只是想添加一个我刚刚遇到的可能的问题和解决方案 - 我在累积更新（SQL2016 CU12）失败期间遇到了类似的情况，并且事件查看器和错误日志中的消息说“无法恢复主数据库。SQL Server 是无法运行。从完整备份中恢复 master，修复或重建它。”，但我最终发现，如果我只是重新运行 CU 可执行文件，它会检测到升级状态为“未完全安装”并允许我简单地运行再次更新，之后它成功完成，主数据库和所有其他数据库都没有问题地打开。

    • 2

  3. 我还想提一下，我遇到了同样的问题，开始了恢复我的主人的道路（没有 .bak 文件让我放慢了速度，即使我有 master.mdf 和 mastlog.ldf 的备份副本）。当“sqlservr -m”失败时，我检查了SQL错误日志，发现了这些错误，

    错误：2775，严重性：17，状态：12。

    服务器不支持代码页 65001

    搜索“错误 2775”，我在 msdn 中找到了一个线程，这导致我在 StackExchange DBA 部分找到了最终解决方案，

    启动 SQL Server 2017 服务时出错。错误代码 3417

    简短的回答？Windows 2019 Server 的操作系统更新以某种方式引入了区域设置更改，该更改激活了“Beta：UTF8 支持”。通过关闭此设置并重新启动服务器，SQL Server 已备份并运行。

    这可能不是对所有人都适用的解决方法，但如果 SQL Server 服务无法启动，则在您更新 Windows 后，很容易检查此设置是否是原因。

    • 1

相关问题