半夜收到报警短信，服务器磁盘空间不足，爬起来检查一番，发现由于索引重建导致，而且该磁盘下仍有自动增长的数据文件，由于该服务器上其他盘符有剩余空间，于是打算将该磁盘下的数据文件限制增长，并新增几个数据文件在其他有空闲空间的磁盘下，于是操作步骤如下：

第一步：检查Alwayson各辅助节点的相同盘符是否同样有磁盘空间(可以使用EXEC master..xp_fixeddrives来查看)

第二步：检查各辅助节点下是否存在对应文件夹，没有的手工创建

第三步：在主节点对数据库上新增数据文件。

三步打完手工，顺便检查了下其他服务器，准备回去梦周公的时候，短信又报警了，Alwasyon数据延迟，而且是在同步模式的辅助节点上延迟，顿时小手一哆嗦，差点把电脑给摔了，立马排查原因，辅助节点磁盘空间充足，对应目录也已创建成功，并且其中一个数据库的新增文件已在辅助节点上创建，但还有一个数据库的新增文件没有创建出来，也是怀疑当前时间索引维护导致大量日志积压从而引起Alwasyon延迟，于是果断关闭主节点上的索引维护，继续使用Alwasyon控制面板观察，发现辅助节点的重做队列大小在逐渐增大，看来关闭索引维护并没啥卵用，继续排查问题。。。

问题的表象是日志重做队列在增大，既然排除主节点“生产”大量日志的情况，那么就是辅助节点“消费”这些日志出现问题，接着排查IO压力，辅助节点IO还算正常，唯一导致IO压力的就一个完整备份作业在执行，完整备份作业，这和日志重做似乎没啥冲突，但是别忘了刚才的操作是新增数据文件，罪魁祸首及时完整备份。由于数据库比较大，完整备份需要花费几十分钟才能完成，为保证完整备份能备份所有数据文件的数据，SQL SERVER会在完整备份期间会阻止对数据库新增文件，而辅助节点上“重做”日志便是对数据库新增文件，于是完整备份“阻塞”日志重做，并给我们一个日志“重做”速率赶不上日志“生成”速率的假象。

总结：在Alwasyon的场景下新增数据文件，不仅要考虑辅助节点上的磁盘空间和对应文件目录的问题，还应该检查一下辅助节点是在运行完整备份，并且在操作结束后，一定要注意检查对应文件是否在辅助节点上创建，并Alwayson的同步状态是否正常。

PS: 如果辅助节点处于异步模式，且在辅助节点上没有对应盘符或文件目录，辅助节点重做"新增文件"这部分日志便会出错，导致对应数据库数据库"挂起"，处于未同步状态，此时辅助节点不会再向主节点发送"请求"，此时观察日志发送队列大小和日志重做队列大小没有任何意义。

PS2: 如果搭建了日志传送，那么还需要考虑新增文件对日志传送的影响，可能需要手动还原特定日志来指定新增文件的还原路径

--================================================================

大半夜干活不容易，没个妹子提神怎么行