至此,故障原因已经找到,下来就是在实例已经无法启动的、临时空间已经
“爆满”的前提下,如何能拉起数据库的问题了。
实例无法启动,诸如清空日志、截断日志、收缩日志之类的 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 登录时报错:服务器处于单用户模式,目前只有一位
管理员能够连接(Microsoft SQL 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;另
评论