有两种情况，可能出现这个问题。一是应用系统给SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。
对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
jazy 回复于：2003-01-14 13:29:49
好，很精辟！
我觉得这种帖子很好，不只是问问题，而是把自己的经验总结出来和大家分享！！让我们大家一起向月兄学习！！
eastyan 回复于：2003-01-15 09:41:09
支持！
m11andyov 回复于：2003-01-15 12:08:22
建议大家经后处理了什么问题后，可以贴上来，共同讨论以下吗！
坏蛋 回复于：2003-01-16 17:28:51
如果截断时事务没有完成，该事务的日志是不被截断的。比如数据库设置的自动清日志选项，而你提交了一个打的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳的，你需要其它的处理手段来解决这种问题。
jazy 回复于：2003-01-16 20:44:40
这种极端情况还是有可能得，所以，还是要充分估计日志空间的分配！！
jazy 回复于：2003-01-18 09:48:12
希望hawker有时间的话，发一些关于复制方面的贴子，我想有很多人对此感兴趣的！
hawker 回复于：2003-01-17 23:51:23
如果你的数据库使用了复制技术，那么会存在第二截断点问题，如果复制进程由于某种原因无法正常工作，那么会导致ASE的日志充满的问题，你可以使用下面的命令来忽略第二截断点，但是这样做的时候，会导致复制数据不能同步，需要手工同步
dbcc settrunc (ltm, ignore)
go
dump tran database_name with truncate_only
go
bluetune 回复于：2003-01-27 11:14:13
一点补充:
如果由于强行回滚事务被意外中止，会造成数据不一致，需手工使其一致。
yefat 回复于：2003-01-27 09:52:01
这三个东西 看似效果一致但是 有明显差异的
截断有没有建立 检查点 要不要备份
ulingjcj 回复于：2003-01-27 08:39:34
我曾经碰到一个怪问题!
事务早就完成了,但是日志一直清不了!
要等6,7小时甚至10小时才清掉!
tchatcha 回复于：2003-01-26 09:19:12
收藏 
lee2223 回复于：2003-05-05 16:08:06
一点补充：如果出现你提交了一个打的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳时，可以有三种办法解决。
1.重启数据库（最笨的但最有效的），但肯定会有REDO和UNDO恢复时间长。
2.给数据库日志加空间，但必须有足够的空间。
3.找出执行大事物SESSION的ID，KILL它，但也会回滚，而且不定可以KILL得掉。
这是我在工作中总结出来的，望大家指正。
lodi 回复于：2003-05-18 20:22:52
sybase12.5 for win 我想扩大master的空间,我选右键数据库属性，在设备上添加数据和日志空间，可是
显示“Cannot extend the MASTER database onto any device other than 'master'. The ALTER DATABASE was aborted"
不能添加数据和日志空间。只是原来的6M大小
|
