【故障现象】
某大数据平台SQLSERVER服务器于2023-04-09 02：00时数据库实例崩溃，手工启动服务不成功，系统报错信息为： “本地计算机上的SQL SERVER（MSSQLSERVER）服务启动后停止。某些服务在未由其他服务或程序使用时将自动停止。”
【原因分析】
实例无法启动，通常不外乎硬盘可用空间、内存资源不足等常见故障所致，然而，本例不符合上述一般状况，以下是排查过程：
首先，用记事本或文字编辑工具打开SQLSERVER错误日志，该文件于%SQLSERVER_HOME%\实例名\LOG目录下，文件名为errorlog.*；
errorlog 日志摘录如下：
Open of fault log failed.
Problem creating symptom dump file due to internal exception.
BEGIN STACK DUMP: ex_handle_except encountered exception C0000005 – Server
terminating.
Unable to create dump because SQLDUMPER library is not available.
其次，筛选出 “事件查看器”中“windows日志”下， “应用程序”事件中
“事件来源”为“MSSQLSERVER”、“事件级别”为【关键、警告、错误】的所有事件记录；
Windows“事件查看器”与MSSQL错误日志均记录如下事件：
数据库“tempdb”的事务日志已满，原因为“ACTIVE_TRANSACTION”。错误：9002，严重性：17，状态：4。
最后，查看系统、用户数据库文件大小，发现TEMPDB数据库日志文件templog.ldf大小接近8GB，数据文件tempdb.mdf大小为11GB，其它数据文件大小基本无异常。结合前两步的日志线索，基本可以断定，系统数据库tempdb存在有超长、超大活动事务，而该事务所需要的日志空间超出了系统给定的最大限定值，最终导致数据库实例崩溃。
至此，故障原因已经找到，下来就是在实例已经无法启动的、临时空间已经“爆满”的前提下，如何能拉起数据库的问题了。
实例无法启动，诸如清空日志、截断日志、收缩日志之类的T_SQL命令全都变成了“纸上谈兵”。废话少说，以下是具体操作。
【解决过程】
一. 在命令行下手工启动数据库。
在命令提示符下，切换到%SQLSERVER_HOME%\binn目录下，执行:
sqlservr –c –f –sMSSQLSERVER
参数涵义，-c是不作为服务，-f是按最小配置，-s指定实例名（可省略）
命令执行后，查看templog.ldf文件，发现从8GB收缩为1MB，tempdb.mdf从11GB缩小为8MB。控制台显示：Service Broker manager has started. Recovery is complete。通过任务管理器，确认数据库实例已经启动，SSMS可登录数据库，于是CTRL-C关闭实例，重启SQLSERVER系统服务，原本以为问题得解，但服务仍然无法启动。啥情况？
命令行重启实例，SSMS登录时报错：服务器处于单用户模式，目前只有一位管理员能够连接(MicrosoftSQL Server，错误: 18461)。猜测有其它用户进程抢先占用了专用连接，具体是哪个用户的哪个进程，还不清楚。
二. 断开其它Administrators组用户，以唯一的超级用户远程登录。
继续在命令行重启实例，登录SSMS管理工具，查看Tempdb的文件属性：数据文件tempdev的属性为：按10%的百分比自增长、最大文件大小为60048M，初始大小为8M，故障当时实际大小为11433M；templog文件按10%的百分比自增长，最大文件大小为8048M，初始大小为1M,故障当时实际大小为8015M。
以Windows身份验证模式登录数据库，验证了故障当时是因为临时日志文件“爆满”而导致实例崩溃，但是，处于“简单”恢复模式下的临时数据库，主要用于存储临时表、Group by、Order by的“中间”结果，究竟什么事务导致临时日志超出了8GB的上限这个问题，还需要做进一步分析。
三. 修改Tempdb的存储参数，推荐增加数据库文件
考虑到操作系统盘的空间预留，更改templog文件的自增长属性。首先，“启用自动增长”、文件增长“按MB”，3MB增长；最大文件大小限制为8192MB；另行添加文件类型为“日志”类的、路径在非系统盘的，文件名为templog_d.ldf的日志文件，其自增长策略设置为：按10MB增长、最大大小为“无限制”或32GB。
注意：无论上述文件大小增么设定，理论上都无法规避实例崩溃的风险，其根本原因在于那个超长、超大的ACTIVE_TRANSACTION所涉及的数据量与SQL执行计划没有得到控制。这属于系统优化的问题，目前暂且将日志文件扩展到非系统盘。
存储参数修改之后，再次尝试重启SQLSERVER系统服务！
故障依旧！这的确很让人费解。
四. 修改数据库登录用户的密码，修改SQLSERVER服务登录身份账户。
服务无法启动，猜测与以“最小化配置”模式启动数据库有关。
微软对“最小化配置”启动数据库的说明如下：最小配置启动 SQL Server
实例会自动将服务器置于单用户模式；只有一个用户可以连接到服务器，并且不会执行
CHECKPOINT 进程；远程访问和预读功能将被禁用；启动存储过程将不运行。
微软建议，以最小配置启动服务器后，应适当更改服务器选项的值，然后停止并重新启动服务器。可是，修改完Templog存储参数后，数据库服务还是无法启动，还有什么可能？莫非微软“留了一手”？
没啥思路，那就继续看系统事件日志。一条“Login Succeeded for user
‘HP/Administrator’。Connection made Using Windows Authentication”日志引起了我的注意，莫非，服务无法启动与“用户认证”有关？
于是，先修改SQLSERVER数据库登录名为“sa”的数据库管理员用户、操作系统管理员帐户的密码，接着修改SQLSERVER服务的登录身份，将“本地系统帐户”改为“此帐户”——计算机名\Administrator帐户及其密码，重启服务，成功。
至此，故障全面搞定！
【问题思考】
故障算是解决了，但却引发出若干值得思考的问题：
-
数据库实例为什么能“纵容”临时日志野蛮扩张，以致于把自身搞崩溃了？莫非存在几个偶发的叠加因素导致崩溃？照理来说，DBMS完全有能力“中断并回滚”该超大事务，回收其资源，向调用者反馈错误，可是却没有，为什么？
-
以“最小化配置”模式启动数据库，是否会影响已注册用户的安全认证？SQLSERVER服务是以“本地系统帐户”来验证登录者身份的，而“本地系统帐户”在数据库有注册且无变更，为什么服务仍然无法启动？
显然，对于上述疑问的回答，需要对数据库的内核原理有更深入地了解，这是一个查阅相关手册与文献，并结合模拟试验的渐进过程。
【案例小结】
其实，这实在算不上一起复杂的case，只不过是在特殊场景下数据库实例的手工恢复罢了。
一般情况下，数据库的实例恢复基本不需要用户干预。可能正因为如此，管理员往往会忽略实例恢复的特殊性。当实例无法启动时，数据库就像是“黑匣子”。作为DBA，你只有从各种日志来判断，有时甚至需要一点点猜测，到底数据库出了什么状况，进而，一步步地排查、分析、验证，当实例能正常启动时，数据库的恢复实际上已经完成了；当服务无法启动时，其实只剩下身份认证这一种可能性了，因为，服务，从根本上说，就是把进程包装后交由操作系统代管的一种信托/总线工作模式。
有人说，世上的DBA分三型：一是“甩手掌柜”型，二是“未雨绸缪”型，三是“没事找事”型。
依我看，“知识越多越反动”，害之大者，莫如三也。
【参考文献】
-
数据库 'tempdb’的日志已满：https://www.zhangjunbk.com/article/6189https://www.zhangjunbk.com/article/6189
-
使用专用管理员连接：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2005/ms189595(v=sql.90)
-
为什么在命令行下使用单用户模式启动sql，但是连接不上：https://social.technet.microsoft.com/Forums/appvirtualization/zh-TW/c740140e-9799-4f2f-8ab6-c8c61236571d/20026201602004022312216292019634892199792035129992213332999225?forum=sqlserverzhchs
-
sqlservser2012数据库报错：用户 ‘sa‘ 登录失败。原因:服务器处于单用户模式。目前只有一位管理员能够连接。 (Microsoft SQL Server，错误:
18461)：https://blog.csdn.net/luholixian/article/details/109031608 -
SQL Server2012无法使用Windows身份验证登陆：https://blog.csdn.net/artechtor/article/details/106854798/
-
SQLserver SA模式和windows模式等登陆失败解决方案（总结）：https://blog.csdn.net/qq_41575002/article/details/129704536
