事务复制导致简单模式的数据库日志经常增长到几十G,有什么好办法?
做了一个事务复制,里面有十几个表,有的数据量较大,运行后发现数据库的日志从晚上一百M到第二天早上可以达到一二十G甚至更多,而数据库的恢复模式是简单,为什么日志增长怎么快?有没有什么好的办法解决,因为日志把磁盘空间都快吃完了,需要手工去截断日志,真的是很麻烦!

------解决方案--------------------
清除日志：


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)
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

把szwzcheck换成你数据库的名字即可，在查询分析器里面运行。
有全角的空格(为了显示好看),你自己把他换一下.


收缩日志：

企业管理器--所有任务--收缩数据库--文件--选日志文件收缩

------解决方案--------------------
把日志固定大小就行了！
------解决方案--------------------
jf
------解决方案--------------------
我幫你ding
jf
------解决方案--------------------
---收缩数据库到10%的可用空间
Use Test
DBCC ShrinkDatabase(Test,10)
---首先截断事务日志,然后再收缩日志文件
Use Test
BackUp Log Test With Truncate_Only
DBCC ShrinkFile(Test,1) ---注意这里单位为M

---LZ,你视自己的情况而定,最好先完全备份一次再进行收缩
------解决方案--------------------
改成简单模式
------解决方案--------------------
复制之前
alter database dbname set recovery bulk_logged
修改数据库恢复模型为

大容量日志记录恢复
大容量日志记录恢复模型提供对媒体故障的防范，并对某些大规模或大容量复制操作提供最佳性能和最少的日志使用空间。下列操作为最小日志记录操作：
1。SELECT INTO。
2。大容量装载操作（bcp 和 BULK INSERT）。
3。CREATE INDEX（包括索引视图）。
4。text 和 image 操作（WRITETEXT 和 UPDATETEXT）。