自动收缩事务日志!!!!

也谈如何缩小SQL SERVER日志文件

前几天也碰到日志文件过大的问题,数据库实际大小为600M, 日志文件实际大小为33M, 但日志文件占用空间为2.8G!!!
试了多种方式,SHIRNK DATABASE, TRUNCATE LOG FILE, 都没办法将文件缩小。无论如何,这应该算SQL SERVER的一个BUG吧。

后来找到下面的代码,就可以将日志文件缩小到自己想要的大小了。把代码COPY到查询分析器里,,然后修改其中的3个参数(数据库名,日志文件名,和目标日志文件的大小),运行即可(我已经用过多次了)
-----
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
    @MaxMinutes INT,
    @NewSize INT


USE   Marias         -- 要操作的数据库名
SELECT @LogicalFileName = 'Marias_log', -- 日志文件名
@MaxMinutes = 10,           -- Limit on time allowed to wrap log.
    @NewSize = 100             -- 你想设定的日志文件的大小(M)

-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size
FROM sysfiles
WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
    CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
    CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)


DECLARE @Counter   INT,
    @StartTime DATETIME,
    @TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
    @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'

DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE   @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
    AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)
    AND (@OriginalSize * 8 /1024) > @NewSize
BEGIN -- Outer loop.
  SELECT @Counter = 0
  WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
    BEGIN -- update
    INSERT DummyTrans VALUES ('Fill Log')
    DELETE DummyTrans
    SELECT @Counter = @Counter + 1
    END  
  EXEC (@TruncLog)
END  
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
    CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
    CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF

 
数据库事务日志收缩机制是数据库管理系统中用于管理事务日志空间的重要功能。事务日志记录了数据库中所有事务的更改操作,以确保事务的持久性和数据库的恢复能力。然而,日志文件的大小如果无限制增长,将可能导致存储资源浪费和性能下降,因此需要通过日志收缩机制来控制其大小。 ### 事务日志的结构与回绕机制 事务日志通常由多个虚拟日志文件(Virtual Log Files, VLFs)组成,这些虚拟日志文件构成了一个逻辑上的循环结构。当日志记录被写入时,它们从逻辑日志的起点开始,逐步向物理日志文件的末端扩展。当物理日志文件被填满后,日志写入指针会回到日志文件的起始位置,形成“回绕”(wrap-around)现象。这种设计使得事务日志可以重复利用已释放的空间[^1]。 ### 日志截断与收缩机制 事务日志收缩依赖于日志截断(log truncation)过程。日志截断的目的是释放那些不再需要用于恢复的旧日志记录所占用的空间。这一过程的核心概念是 **MinLSN**(Minimum Log Sequence Number),即数据库恢复过程中所需的最早日志记录的日志序列号。所有在 MinLSN 之前生成的日志记录都可以被安全地释放,因为它们所涉及的事务已经提交或回滚,并且其更改已被写入数据文件。 日志截断完成后,数据库管理系统可以将这些被释放的虚拟日志文件空间回收,从而实现日志文件的收缩。在某些数据库系统中,例如 SQL Server日志文件的收缩可以通过显式命令(如 `DBCC SHRINKFILE`)触发,或者在特定条件下自动执行[^1]。 ### 收缩对性能的影响 虽然事务日志收缩有助于控制日志文件的大小,但频繁的日志收缩可能会对数据库性能产生负面影响。收缩操作可能导致日志文件碎片化,增加日志文件重新扩展时的 I/O 开销。此外,频繁的截断和收缩可能影响数据库的恢复效率,因为日志文件的重新分配和初始化需要额外的系统资源。 ### 收缩策略与最佳实践 为了平衡日志文件大小与性能之间的关系,数据库管理员通常会采用以下策略: - **合理设置日志文件的初始大小和增长步长**,避免频繁的自动扩展和收缩。 - **定期监控日志文件的使用情况**,确保日志文件不会因为不合理的截断策略而频繁收缩。 - **结合恢复模型**,例如在 SQL Server 中,选择适当的恢复模式(简单恢复、完整恢复或大容量日志恢复)可以影响日志截断的时机和频率[^1]。 ### 示例:SQL Server 中的日志收缩SQL Server 中,事务日志收缩可以通过以下命令实现: ```sql -- 假设日志文件的逻辑名称为 'YourDatabase_Log' DBCC SHRINKFILE (YourDatabase_Log, 100); -- 将日志文件收缩到 100 MB ``` 该命令会尝试将日志文件的未使用部分释放回操作系统。然而,如果当前日志文件的活动部分(即尚未截断的日志记录)位于文件的末尾,则收缩操作无法减少文件大小。因此,在执行收缩之前,通常需要先进行日志备份以促使日志截断的发生。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值