清除日志：

 
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的日志空间如果设置为无限制增大，是否有自动备份日志的作业在运行？
如果没有的话，每个完成的事务都写到日志文件，就越来越大了。

建个自动备份日志的作业，比如每小时备份一次日志，
然后再找个服务器不忙的时候，把这个巨大的日志文件收缩一下。

这种数据更新频繁的数据库是一定要有自动备份作业的，否则日志文件就不断增大.....