我曾经遇过大数据库日志不能截断的情况。我在数据库上设置了TRUNCAT LOG ON CHECKPOINT，并且也手工地发出DUMP TRAN XXX WITH TRUNCATE ONLY 和DUMP TRAN XXX WITH NO_LOG但是数据库的日志没有被截断。后来，我在一些新建的小库上试验，这些功能是好使的。我重新检查了我的数据库，发现其中有一个表它的空间分配出现了错误。于是我用TRANSFER MANEGER把这个库中其余的对象都传到了一个新库中，日志可以截断了。在建库时把数据库的数据和日志设备分开，经常用DBCC CHKECKDB，DBCC CHECKTABLE（SYSLOGS），DBCC CHECKCATALOG等数据库维护工具，来验证数据库的完整性。另外，我做的程序中也有这种大量的运算处理，它们会产生大量的日志，但是SERVER当有活动事务运行时，它不会把属于这个事务的日志截掉。日志的截断只会去掉日志中的非活动部分。因此，如果一个操作如果产生大量的日志以至会充满日志，那么就必须把它改写或者把它安排在用户连接最少的时候执行。
20%-30%左右就可以了.清除日志应用DUMP,而不是BACKUPDUMP TRAN <DataBase Name> WITH TRUNCATE_ONLY --- 清除已完成事务日志
DUMP TRAN <DataBase Name> WITH NO_LOG --- 完全清除日志清除后可用下列语名查询日志可用空间.Enterprise Manager 中提供的方式(DataBase 名上双击)所得到的数据不准确.dbcc checktable(syslogs)最好的方式是加入计划任务,让SQL自动执行DUMP.
Select Into/Bluk copy =True 永许insert into 和 bulk insert 非记录操作。
Truncate log on checkpoint=True 永许自动截断日志。
Auto shrink=True 日志自动压缩
由于设置了以上选项，等于自动执行了DUMP TRAN <DataBase Name> WITH TRUNCATE_ONLY -DUMP TRAN <DataBase Name> WITH NO_LOG
syslogs数据表不能访问。
如果你做的数据的批量处理，如BCP等操作，SYABSE中有设置这一类操作关闭日志的功能，具体手边无相关资料，你自己查一下，如果你不是批量数据处理，首先建议你将程序分解成多个部分，并给数据库设置阀值管理（我不知SQL SERVER是否有此功能），该功能会在日志达到响应的值时截断日志。但是由于所有的关系型数据库均不对活动的日志进行阶段操作，所以一旦你是单个事务（transaction)造成这情况的话，就只能分而治之了，祝你好运
最小尺寸为512 KB.
设置数据库属性select into/bulkcopy为true，使SQL Server对如下操作
Bulk load operations
SELECT INTO statements
WRITETEXT statements
UPDATETEXT statements
的数据不进行日志处理，但数据库中数据页的分配依然进行了日志处理
设置数据库的属性truncate log on checkpoint为true，
在进行大批量的数据更新的过程中，最好手工执行CHECKPOINT命令以truncate log,无须等到时间间隔。建议使用游标逐行处理数据，以便在中间可插入CHECKPOINT命令。
另外， BACKUP LOG是SQL Server7的标准语法，NO_LOG 与 TRUNCATE_ONLY意义相同
都是Removes the inactive part of the log。语法如下
BACKUP LOG {database_name and @database_name_var}
{
[WITH
{ NO_LOG and TRUNCATE_ONLY }]
}
DUMP是SQL Server6.5及以前版本语法，在SQL Server7中也可用。
那你的日志文件不应该经常长大，你的程序可能有问题，TRANSACTION的嵌套可能太多，在发生checkpoint时提交的太少.日志就不断增多，到达最大容量后，文件也随之增大。
日志本身是不可以取消的。
一个办法是在代理处设置一个日志文件长度的ALERT，再定义一个JOB对应这个ALERT。JOB的内容是DBCC SHRINK DATABASE之类的工作。这样你就不用经常担心这个问题。
Enterprise Manager 中Trucate 无效
大量事务处理时Log满
只能不断加大Log Size
Please say more