日期:2014-05-18 浏览次数:20554 次
清除日志: DECLARE @LogicalFileName sysname, @MaxMinutes INT, @NewSize INT USE szwzcheck -- 要操作的数据库名 SELECT @LogicalFileName = 'szwzcheck_Log', -- 日志文件名 @MaxMinutes = 10, -- Limit on time allowed to wrap log. @NewSize = 20 -- 你想设定的日志文件的大小(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 AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)
------解决方案--------------------
高可用性模式下日志应该不会长这么快吧? 毕竟是异步的, 除非你的两台电脑之间的网络不够好, 导致在主数据库上阻塞的事务太多(或者是你的镜像数据库太慢,例如在上面建立了快照数据库)
理论上高安全性才会有这个问题(因为事务要在镜像服务器上同时应用)
------解决方案--------------------
1. 无法删除, 因为镜像要用这些信息, 如果你重建镜像, 当然可以删除, 但似乎过段时间就重建不是什么好主意
2. 没有设置, 也不用设置, 如果日志空间可用, sql 会重用
所以只能建议你找原因, 再想解决办法
------解决方案--------------------
LZ的日志空间如果设置为无限制增大,是否有自动备份日志的作业在运行?
如果没有的话,每个完成的事务都写到日志文件,就越来越大了。
建个自动备份日志的作业,比如每小时备份一次日志,
然后再找个服务器不忙的时候,把这个巨大的日志文件收缩一下。
这种数据更新频繁的数据库是一定要有自动备份作业的,否则日志文件就不断增大.....