如何截断数据库日志

先备份数据库

1.清空日志

DUMP TRANSACTION 库名 WITH NO_LOG

2.截断事务日志

BACKUP LOG 数据库名 WITH NO_LOG

3.收缩数据库文件(如果不压缩,数据库的文件不会减小

企业管理器–右键你要压缩的数据库–所有任务–收缩数据库–收缩文件

–选择日志文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

–选择数据文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

也可以用SQL语句来完成

–收缩数据库

DBCC SHRINKDATABASE(客户资料)

–收缩指定数据文件,1是文件号,可以通过这个语句查询到:

select * from sysfiles

DBCC SHRINKFILE(1)

如：shgzts为数据库名

dump transaction shgzts with no_log --截断日志

backup log shgzts with no_log --备份日志

dbcc shrinkdatabase(shgzts,truncateonly) --数据库收缩

有两种情况，可能出现这个问题。一是应用系统给SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。

对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。

对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。

---