我有适当的工作来修剪用于历史和日志的表格，以保持它们的修剪。 我想确保我不会忽略日志文件。
如何以及我应该怎样做以保持日志文件的检查？
我每晚都在运行的SQL脚本是：
declare @DBname varchar(500) set @DBname = 'E:\Database\backup\PMIS_backup_' + convert(varchar(MAX), getdate(), 23 ) +'.bak' BACKUP DATABASE [PMIS] TO DISK = @DBname WITH NOFORMAT, NOINIT, NAME = @DBname, SKIP, REWIND, NOUNLOAD, STATS = 10 数据库处于简单恢复模式。
如果数据库处于简单恢复模式，并且日志文件没有逐渐变大，那我就不用担心了。 如果有任何forms的维护计划经常进行大量的重新索引，那么这个机会就会很大。
如果日志文件变得更大，您将需要找出原因。 您可以运行DBCC SQLPERF（LOGSPACE）以查看有多less日志文件正在使用 – 如果一直很高，请检查master.sys.databases中的log_reuse_wait_desc列，以了解为什么不重复使用它所需的空间。 如果使用率很低，那么可能会有一些一次性事务做了大量工作，导致日志文件增长。 如果这是一个会定期发生的交易，那么不断缩小和增长日志文件只会损害性能，所以放在任何尺寸的地方都可以提供舒适的工作空间。 另一方面，如果日志文件是数据文件大小的很多倍，那么这可能是不必要的。
你在做事务日志备份吗？ 每次成功时，SQL都会从日志中删除不活动的事务，而这样做可以使事务日志文件的大小保持可pipe理性。
执行日志文件的备份后，您需要收缩日志文件。
每次从表中删除logging时，都会从数据文件中删除数据，但该操作会logging在日志文件中（因此名称为—)。
将数据库configuration为完全恢复模式时，日志文件将无限制地附加到备份之前。 查看MSDN：事务日志物理体系结构了解更多信息。
另外，如果您没有进行常规事务日志备份（大概是因为您不需要即时恢复），则应考虑使用简单恢复模式。 当然，您应该首先备份和收缩日志文件，然后将数据库的恢复模式更改为简单。