SQL 2012事务日志备份不会截断日志
我是数据库pipe理的初学者，请耐心等待。 我有一个小的数据库500MB与一个非常大的事务日志（19GB）。 我想保持在“完全恢复”模式，所以请不要build议“简单”恢复模式。
我一直在研究如何减小事务日志的大小，我试图实现这些build议，但日志大小不会改变。
首先，这是我所做的：我有一个每日备份任务，备份维护计划内的所有数据库。 这是一个“完整”的备份types，它似乎运作良好。 我看到每天备份一个类似于数据库本身大小的文件。
现在我有一个完整的备份，我已经开始做一个手动的“事务日志”types的备份，其中的选项“截断事务日志”。
备份在几秒钟内完成，创build一个大小为几兆字节的文件，但事务日志的大小保持不变。
我究竟做错了什么？
您的事务日志备份会截断日志，因为它正在现有日志文件中腾出空间来处理更多事务。 如果要缩小日志文件，则需要在SSMS中select“缩小文件”选项。 右键单击数据库以查找该选项。
如果您缩小的文件大小不够大，请根据您的数据库有多less事务以及备份日志的频率，再次增长。 您可能需要更频繁地运行日志备份以防止这种情况发生。
这听起来像你没有运行事务日志备份（除了手动运行的时候）。 如果是这样，不仅是因为你的交易日志正在增长，而且你还没有得到完全恢复的好处。 请安排定期的事务日志备份。 （每小时将是一个好的开始。）
好，首先要明白的是为什么日志文件是它的大小。 你说数据是500MB，你确定吗？ 这是一个非常小的数据文件相比，日志文件。 如果这是真的，那么LOG就是一个理由。
所以你必须弄清楚为什么你已经运行数据到数据库？ 任何运行数据的ETL / DTS进程，重build索引等和大型事务运行？ 你有没有检查，有没有未提交的交易？ （请select@@ trancount）
您可以通过检查log_reuse_wait和log_reuse_wait_desc来检查日志的当前状态。
SELECT [log_reuse_wait_desc] FROM [master]。[sys]。[databases] WHERE [name] = N'Company';
日志的非活动部分只能在日志备份中捕获到所有日志logging之后才能被截断。 维护日志链需要一系列日志序列号（LSN）不间断的日志logging。 假设存在以下情况，备份事务日志时会截断日志：
自上次备份日志以来，检查点发生了。 检查点是必不可less的，但不足以在完整恢复模型或大容量日志恢复模型下截断日志。 在检查点之后，日志至less保持不变，直到下一个事务日志备份。
2.没有其他因素阻止日志事务。
通常，在定期备份的情况下，日志空间会定期释放以供将来使用。 但是，诸如长时间运行的事务等各种因素都会暂时阻止日志截断。
BACKUP LOG语句不指定WITH COPY_ONLY。
来源： https ： //technet.microsoft.com/en-us/library/ms189085(v=sql.105).aspx
如果日志文件的大小需要缩小并缩小，那么它只会再次增长，而且本身是一个代价高昂的过程，因为数据库正在写入日志，并且需要文件增长，除非您立即启动文件初始化为sql服务器服务帐户进程将等待文件的增长，然后它会写，如果是这样的GB块，你将有更大的问题来处理。
所以，现在你需要看看数据库的活动，如果你每天只运行一个日志备份，这对于数据库的活动来说可能是不够的，在我的组织里，我每隔15分钟备份一次到每1小时并且在某些情况下，每隔5分钟在特定的Db上进行。 这使得日志不能增长太多（日志已经在一些服务器中被预先设定），我们也运行紧张的RTO / RPO。
现在正如joeqwerty所说，除非你在恢复点方面有一个严格的SLA，否则它可能不值得在FULL或BULK-Logged中运行，如果你所做的只是运行一个完全备份，那么你就浪费了时间。公司不关心数据丢失，不打架，用它工作。
如果您关心的只是日志的大小，而不是转录点恢复，请备份日志并缩小日志，然后切换到“简单”。
你说不build议简单的恢复，但我不认为你完全明白你在做什么完全恢复。