我是DB管理的初学者,所以请原谅我。我有一个很小的DB 500 DB和一个非常大的事务日志(19 DB)。我想保持在“完全恢复”模式,所以请不要建议“简单”恢复模式。
我一直在研究如何减少事务日志的大小,我正在尝试实现这些建议,但是日志大小并没有改变。
首先,下面是我所做的工作:我每天都有一个备份任务,用于备份维护计划中的所有数据库。这是一个“完全”的备份类型,它似乎运行良好。我看到每天备份一个文件,类似于DB本身的大小。
现在我有了一个完整的备份,我已经开始执行一种手动的“事务日志”类型的备份,它的选项是“截断事务日志”。
备份在几秒钟内完成,创建一个大小为几兆字节的文件,但事务日志的大小保持不变。
我做错了什么?
发布于 2016-11-07 18:50:52
您的事务日志备份正在截断日志,因为它在现有日志文件中为更多事务腾出空间。如果要收缩日志文件,则需要在SSMS中选择“收缩文件”选项。右击数据库以找到该选项。


如果您将其缩小到的文件大小不够大,根据您的数据库有多少事务以及备份日志的频率,它将再次增长。为了防止这种情况,您可能需要更频繁地运行日志备份。
听起来您根本没有运行事务日志备份(除了手动运行一次)。如果是这样的话,这不仅是事务日志增长的原因,而且您也没有得到完全恢复的好处。请定期安排事务日志备份。(每小时一小时将是一个好的开始。)
发布于 2016-11-08 08:18:01
好的,首先要理解的是为什么日志文件是它的大小。你说数据是500 is,你确定吗?与日志文件相比,这是一个非常小的数据文件。如果是这样的话,日志就是它的大小,这是有原因的。
所以你必须找出你一直在数据库中运行数据的why..have?是否有ETL/DTS处理正在运行数据、重建索引等以及正在运行的大型事务?您是否检查过没有未提交的事务?(选择@@trancount)
您可以通过检查log_reuse_wait和log_reuse_wait_desc来检查日志的当前状态。
从主控.系统.数据库中选择日志_再利用_等_描述,其中名字 =N‘’Company‘;
在日志备份中捕获所有日志记录之前,日志的非活动部分无法被截断。这是维护日志链所必需的--一系列日志记录具有完整的日志序列号序列(LSNs)。当您备份事务日志时,假设存在以下条件,日志将被截断:
1.自从上次备份日志以来,出现了一个检查点。检查点对于在完整恢复模型或大容量日志恢复模型下截断日志是必要的,但还不足够。在检查点之后,日志保持不变,至少直到下一次事务日志备份。
2.没有任何其他因素妨碍日志交易。
通常,在定期备份的情况下,日志空间将定期释放,供以后使用。但是,各种因素,例如长时间运行的事务,可以暂时防止日志截断。
备份日志语句没有使用COPY_ONLY指定。
来源:https://technet.microsoft.com/en-us/library/ms189085(v=sql.105).aspx
如果日志文件确实需要这样大小,并且您需要缩小它,那么它只会再次增长,而这本身就是一个代价高昂的进程,因为数据库正在编写日志,并且需要文件增长,除非您为sql服务器服务帐户打开了即时文件初始化,否则进程将等待文件的增长,然后它将写入,如果这样做对GB块,您将有更大的问题要处理。
所以现在您需要查看数据库的活动,例如,如果您每天只运行一个日志备份(例如,这可能不足以支持DB的活动),在我的组织中,我每15分钟进行一次备份,在某些情况下,每5分钟备份一次特定Db的备份。这使得日志不会增长到很多(日志在某些服务器中已经预先设置),我们也在运行严格的RTO/RPO。
现在,正如joeqwerty所指出的,除非您在恢复点方面有一个严格的SLA,否则它可能不值得在完整或批量日志中运行,您将浪费您的时间,如果您所做的只是运行一个完整备份日报,而公司不关心数据丢失,不要与之抗争,使用它。
如果您只关心日志的大小,而不是转录点恢复,那么备份日志并缩小日志,然后切换到Simple。
你说不要建议简单的恢复,但我认为你不完全明白你在做什么,完全恢复。
https://serverfault.com/questions/813646
复制相似问题