截断事务日志
如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。在某个即时点，必须删除恢复或还原数据库时不再需要的旧日志记录，以便为新日志记录腾出空间。删除这些日志记录以减小逻辑日志的大小的过程称为截断日志。
永远不能截断事务日志的活动部分。日志的活动部分是在任何时间恢复数据库所需的日志部分，因此必须有回滚所有未完成的事务所需的日志映像。这部分必须始终在数据库中，因为一旦服务器发生故障，在服务器重新启动时必须用它恢复数据库。日志活动部分起点处的记录由最小恢复日志序号 (MinLSN) 标识。
为数据库选择的恢复模式决定了在数据库内，必须在活动部分之前保留的事务日志量。虽然 MinLSN 之前的日志记录对恢复活动事务没有作用，但在使用日志备份将数据库还原到故障点时，必须用这些记录前滚修改。如果由于某种原因丢失了数据库，则可以通过还原上次的数据库备份，然后还原自该数据库备份后的每个日志备份来恢复数据。这意味着这些日志备份必须包含自数据库备份后所写入的每个日志记录。当维护事务日志备份序列时，日志记录直到写入日志备份时才能被截断。
MinLSN 之前的日志记录只用于维护事务日志备份序列。
在简单恢复模式中，不维护事务日志序列。MinLSN 之前的所有日志记录可以随时被截断，但在处理 BACKUP 语句时除外。NO_LOG 和 TRUNCATE_ONLY 是只对使用简单恢复模式的数据库有效的 BACKUP LOG 选项。
说明 tempdb 数据库始终使用简单恢复模式，不能切换到其它恢复模式。日志截断始终发生在 tempdb 中的检查点上。
在完全恢复模式和有日志记录的大容量恢复模式中，维护事务日志备份序列。MinLSN 之前的逻辑日志部分直到复制到某个日志备份时才能被截断。
日志截断在下列情况下发生：
执行完 BACKUP LOG 语句时。
在每次处理检查点时（如果数据库使用的是简单恢复模式）。这包括 CHECKPOINT 语句所产生的显式检查点和系统生成的隐式检查点。例外情况是如果检查点发生在 BACKUP 语句仍活动时，则不截断日志。有关自动检查点间隔的更多信息，请参见检查点和日志的活动部分。
事务日志在内部分成若干称为虚拟日志文件的部分。虚拟日志文件是截断的单元。当截断事务日志时，删除包含 MinLSN 的虚拟日志文件头之前的所有日志记录。有关虚拟日志文件的更多信息，请参见事务日志物理构架。
1:截断事务日志：
BACKUP LOG 数据库名 WITH NO_LOG
2:清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
再：
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
3: 删除LOG
1：分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG文件
3：附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的LOG，大小只有500多K
再将此数据库设置自动收缩
或用代码：
下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。
EXEC sp_detach_db @dbname = 'pubs '
EXEC sp_attach_single_file_db @dbname = 'pubs ',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf '
4: 如果想以后不让它增长
企业管理器--服务器--右键数据库--属性--事务日志--将文件增长限制为xM(x是你允许的最大数据文件大小)
--SQL语句的设置方式:
alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)
5.设置为自动收缩
企业管理器--服务器--右键数据库--属性--选项--选择 "自动收缩 "
逻辑日志是日志的记录.物理日志是记录日志的文件.
联机帮助上有说明:
日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。
减小大小的单位是一个虚拟日志文件。例如，如果有个600MB的日志文件被分成了6个100MB的虚拟日志，则该日志文件的大小只能按100MB递减。比如，文件可以减小到500MB或400MB，但不能减小到433MB或525MB。
不能释放容纳逻辑日志部分的虚拟日志。如果某个日志文件中的所有虚拟日志都容纳了逻辑日志部分，则不能收缩该文件，直到截断操作在物理日志的末端将一个或更多的虚拟日志标记为不活动。
当收缩任何文件时，必须从文件的末端开始释放空间。当收缩事务日志文件时，从文件的末端开始释放足够的虚拟日志以将日志减小到用户所要求的大小。用户指定的target_size四舍五入为下一个最大的虚拟日志边界大小。例如，如果用户为包含6个100MB虚拟日志文件的600MB文件指定325MB的target_size，则删除最后两个虚拟日志文件，因此新的文件大小为400MB。
在SQLServer2000中，DBCCSHRINKDATABASE或DBCC SHRINKFILE 操作试图立即将物理日志文件收缩到所要求的大小（以四舍五入的值为准）：
如果虚拟日志中的逻辑日志部分没有超出 target_size 标记，则释放 target_size 标记之后的虚拟日志，并且成功完成 DBCC 语句，不出现任何信息。
如果虚拟日志中的逻辑日志部分超出 target_size 标记，则SQL Server 2000释放尽可能多的空间并发出一条信息。该信息告诉您需要执行什么操作以获得文件末端超出虚拟日志的逻辑日志部分。执行完该操作后，可以重新发出DBCC语句以释放剩余的空间。
例如，当执行target_size为275MB的DBCC SHRINKFILE语句时，假设有一个包含6个虚拟日志的600MB日志文件，其逻辑日志从第3个虚拟日志开始，到第4个虚拟日志结束：
将立即释放第5个和第6个虚拟日志，因为它们没有容纳逻辑日志部分。然而，为达到指定的target_size，还应释放第4个虚拟日志，但无法释放，因为它容纳了逻辑日志的末端部分。在释放第5个和第6个虚拟日志之后，SQL Server 2000用虚记录填充第4个虚拟日志部分。这将日志文件的末端强制为第1个虚拟日志。在大多数系统中，起始于第4个虚拟日志的所有事务将在几秒钟内提交，这意味着日志的所有活动部分都移动到了第1个虚拟日志，并且日志文件现在看起来像下面这样：
DBCC SHRINKFILE 语句还发出一条信息，指出它不能释放所要求的全部空间，并告诉您可以执行BACKUP LOG语句以便释放剩余的空间。一旦日志的活动部分移动到第1个虚拟日志，BACKUP LOG语句将截断第4个虚拟日志中的整个逻辑日志：
因为第4个虚拟日志不再容纳逻辑日志的任何部分，如果现在执行同一个target_size为275MB的DBCC SHRINKFILE语句，则会释放第4个虚拟日志，并且物理日志文件的大小会减小到所要求的大小。