合并分区(merge range)对事务日志的影响

分区维护作业执行失败，错误信息如下：
数据库 'XXX' 的事务日志已满。若要查明无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列。 [SQLSTATE 42000] (错误 9002) 语句已终止。 [SQLSTATE 01000] (错误 3621). 该步骤失败。
查看 sys.databases 数据库恢复模式为SIMPLE，日志重用等待为NOTHING

提取分区维护作业代码，取其中合并分区语句，直接在查询窗口执行，并在另一窗口查看日志使用情况

日志使用很快涨到100%，合并分区语句终止，之后马上回落

查看数据库文件使用情况

主数据文件和日志文件保存在F盘，两文件大小接近200G，而F盘的总大小只有200G

就是说，合并分区时产生了"大量"事务，填满事务日志，日志文件虽然有设置自动增长，但F盘的可用空间(8.94M)显然不够其一次增长(200M/次)
最终导致语句异常终止，在ERRORLOG中会有9002错误

合并分区为什么会生成如此多的事务？
TableA、TableA_Trun建立在同一个分区方案(分区函数采用的是RANGE RIGHT)之上。过期数据删除作业每天将TableA中33天前的数据Switch到TableA_Trun；分区维护作业每十天合并35天前的分区，并新增一个月后的分区。当前库中有10张表采用此方案

TableA、TableA_Trun的数据分布情况


TableA_Trun中为什么还有8月7、8、9号的数据(Switch分区每天都会操作，先清空Trun表，然后Switch33天前的数据)。核实是上周五调整某些表，导致过期数据删除作业在9月10、11、12号执行失败，也就是今天此作业执行前TableA表中还有8月7、8、9号数据，之后进行Switch分区，就将8月7、8、9、10号数据都Switch到TableA_Trun表中。
分区维护作业对应的合并语句

alter partition function [Fun_Date]() merge range ('20160807')
alter partition function [Fun_Date]() merge range ('20160808')
alter partition function [Fun_Date]() merge range ('20160809')

对于第一条合并语句，它要合并2016-08-07，由于分区函数使用RANGE RIGHT，它属于右边界的(partition_number=2)。参考听风吹雨博客SQL Server 合并（删除）分区解惑

结论：删除的这个边界值（boundary_value）属于哪个分区，那么就会删除这个分区，再向邻近的分区合并。邻近的意思是以这个边界值为临界点的两个分区。

就是说删除2016-08-07边界值，会删除第二个分区，第二个分区中的数据向第一个分区合并。由于TableA_Trun(10张)在第二个分区都有大量数据，导致合并时生成大量日志。
解决方法
1、清空TableA_Trun表，再合并分区
2、收缩数据文件，释放磁盘空间，再合并分区
显然方法1影响小，且易于操作。我也是优先采用此方法合并了分区。
收缩数据文件可能遇到的问题
1、收缩数据文件引起事务日志增长，不幸导致事务日志已满。最初收缩的量调小点(比如200M/次)，如果能释放空间给操作系统，基本就没什么问题。
2、任何少量的收缩都导致事务日志已满。只能在有足够剩余空间的其他磁盘为数据库添加日志文件，待收缩完成后，再删除多余的日志文件。