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

分区维护作业执行失败，错误信息如下：
数据库 'XXX' 的事务日志已满。若要查明无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列。 [SQLSTATE 42000] (错误 9002) 语句已终止。 [SQLSTATE 01000] (错误 3621). 该步骤失败。
查看 sys.databases 数据库恢复模式为SIMPLE，日志重用等待为NOTHING
合并分区(merge range)对事务日志的影响
提取分区维护作业代码，取其中合并分区语句，直接在查询窗口执行，并在另一窗口查看日志使用情况

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

查看数据库文件使用情况

主数据文件和日志文件保存在F盘，两文件大小接近200G，而F盘的总大小只有200G
合并分区(merge range)对事务日志的影响
就是说，合并分区时产生了"大量"事务，填满事务日志，日志文件虽然有设置自动增长，但F盘的可用空间(8.94M)显然不够其一次增长(200M/次)
最终导致语句异常终止，在ERRORLOG中会有9002错误

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

View Code