本篇主要是上一篇文章的补充篇，上一篇我们介绍了SQL Server服务启动过程所遇到的一些问题和解决方法，可点击查看，我们此篇主要介绍的是SQL Server启动过程中关于用户数据库加载的流程，并且根据加载过程中所遇到的一系列问题提供解决方案。
其实SQL Server作为微软的一款优秀RDBMS，它启动的过程中，本身所带的那些系统库发生问题的情况相对还是很少的，我们在平常使用中，出问题的大部分集中于我们自己建立的用户数据库。
而且，相对于侧重面而言，其实我们更关注的是我们自己建立的用户数据库，假如系统数据库出现问题，甚至实例出现问题，最坏的情况我们重搭环境，但是如果我们应用的用户数据库坏掉了，那可不是重搭环境就能解决的。这牵扯到公司利益问题，问题严重性不言而喻！
闲言少叙，我们速度进入本篇的正题。
上一篇我们介绍了SQL Server实例启动的过程，并且分析了其详细的过程，而在这一流程中，有一个步骤非常关键，就是加载恢复用户数据库的过程，我们来截取这段日志信息：
上面是一个正常启动各个用户库的流程，SQL Server会采用多线程的进行数据库启动，并且在这个过程中进行一致性校验，确保启动的数据库能够正常使用。
而这过程中会发生很多问题，在分析问题之前，我先要介绍SQL Server数据库的几个常见状态：
RECOVERING（恢复中）：
这个状态表示数据在启动完成后，正在发生恢复，也就是上面日志中的 Recovery过程，和其它的关系型数据库一样，SQL Server对所有的数据库行为都是先写事务日志，然后在修改内存中的数据，然后通过后台的一个进程在适当的时候进行写入硬盘（Lazy write），所以在数据库运行过程中，磁盘中的数据并不是最新的，如果这个时候关闭了，在下一次启动过程中SQL Server就要根据事务日志中的记录，将磁盘中的旧的数据改写，改写过程为：
1、重做redo
2、回滚和撤销 undo/rollback
上面的目的就是为了保证数据库一致性。
如果上面的流程发生了问题，就会进去到下面这个状态：
RECOVERY PENDING（挂起还原）：
这个过程就是将恢复数据的过程挂起，挂起的原因基本就是不能正常打开所用的数据库文件。这里先记住这个状态就行，我在后面的内容会再现这个问题，以及给出解决方案。
如果能找到文件或者能打开文件，但是文件有问题，机会出现下面这个状态：
SUSPECT（质疑）：
这个状态，我相信很多用户如果在玩数据库久了的时候，会偶尔遇到，相对于其它状态，这个状态是出现最高的。
原因很简单：数据库文件坏掉了。
当经历了上面的这个几个状态都不出现问题，上面的这几个状态下，数据库都是不能使用的，会进入到下面这个状态：
ONLINE（在线）：
这个状态应该是最期待的了，数据库在线，正常使用，默认都是正常的在线状态。
当然，除了上面几个数据库自己形成的数据库状态，在我们管理员处理数据库的时候也会更改状态，这里我们顺便提一下：
OFFLINE(离线)：有在线状态就有离线状态，很简单，让数据库离线，用户不能使用
RESTORING（还原中）：这个状态很简单，管理员正在还原该数据库，不解释
EMERGENCY（紧急）：这个状态也是管理员用的，就是说明数据库有问题了，它正在尽量解决
以上几个状态中，发生在启动过程中，并且会发生问题就是上面的RECOVERY PENDING（挂起还原）、SUSPECT（质疑）、RECOVERING（恢复中）：
我们依次来看：
RECOVERY PENDING（挂起还原）：
出现这个状态通常的原因是数据库文件找不到，或者文件找到权限访问不到，我们来看该问题报错信息：
在数据库中存储方式中，分为主文件组和辅助文件组和日志文件，为了展示方便我们特意建立了个测试库，来重现该部分问题：
<1>主文件组问题
当不能访问主文件组文件的时候，也就是上面的CnblogsTestDB.mdf文件，会报如下错误：
我们先来看数据库：