在实例启动的过程，恰巧有一个库显示了上面我们提到的一个状态：RECOVERING（恢复中），我顺便把图给截图了，当然出现这个情况很正常，有时候刷新一下就正常，其它用户库没有显示是因为库太小，恢复时间太短，我们捕捉不到。
我们来看，上面我们建立的测试库CnblogsTestDB已经不能访问了，我们来看一下Error中的错误信息：
错误信息很明显，说这个该文件不能访问，并且确切的说出了这个为操作系统错误，那我们看操作系统的错误记录：
可以看到在Windows系统日志中也能看到该部分错误信息。
解决方案：
此问题的解决方法还是很简单的，一般主要是因为权限问题，只需要将数据库管理员账户组，提权到可读写权限就可以，然后重启服务:
上面的情况是找到数据库文件，但是不能打开数据库文件，当然还有可能是直接找不到数据库文件，系统会报出如下错误：
会给出17204错误，报找不到文件错误
解决方案：
a、如果能找到数据文件最好了，拷贝到错误制定的路径下既可以，然后重启实例
b、不能找到文件了，那就得只能删除该库，重新新建同名库，从备份文件中还原
一般上述问题发生在物理存储出现了故障，当然不排除某些软件操作，比如杀毒软件、还有人为误删等原因。如果没有备份，这可能是一个很大的遭难，基本可以确定的完全还原的可能性不高！所以记住：备份数据库的重要性！
<2>辅助文件组问题
上面的出现问题的文件为数据库的主文件组，当我们数据库在承载到一定数据量的情况下，我么采取多个辅助文件组来容纳数据，下面我们来看一下辅助文件组的问题：
同样的提示的辅助文件组不能正常打开，或者找不到相关的辅助文件组，遇到这样的问题我们怎么解决呢?
其实SQL Server数据库辅助文件存储的主要为数据库的数据内容信息，关于本库的一些架构信息是放在主（primary）文件组中，所以我们可以先这样
解决方案：
a、我们将打不开或者不能访问的数据库文件（辅助文件）设置成离线，然后先将能够正常的数据文件上线，确保除了损坏的那部分文件的其它库信息能正常访问，我们通过以下代码更改：
ALTER DATABASE CnblogsTestDB MODIFY FILE(NAME=CnblogsTestDB2,OFFLINE)
GO
ALTER DATABASE CnblogsTestDB set ONLINE
GO