SQL Server 2000数据库的事务日志文件过大，如何将其缩小

拷獯穑涸赟QL Server中，所有对数据库执行的更新 *** 作都会记录在数据库的事务日志文件中，除非将数据库设为可自动收缩的或手动 的对数据库进行了收缩，否则事务日志文件将一直增长，直到达到事先设定的日志文件增长上限或用尽所有可用的磁盘空间。如果当前的数据库文件或日志文件过大，可以使用以下两个命令对其进行收缩：DBCC SHRINKDATABASE：收缩指定数据库的所有数据和日志文件的大小DBCC SHRINKFILE： 收缩数据库的某个指定数据或日志文件的大小 这两个命令可以释放数据库中的空闲空间，并将数据库或指定的数据库文件收缩到指定的大小，但收缩后的数据文件或日志文件的大小不会小于档中现存的有效数据所占空间的大小。 关于这两个命令的具体使用方法，可以参考SQL Server 2000联机丛书中的相应主题。另外，也可在SQL Server企业管理器中执行数据库收缩，同样是调用的以上两个命令，效果类似。 在使用以上命令收缩日志文件的时候需要注意，已写入数据库但未被截断的事务日志记录是不会被收缩的，因为虽然这部分日志记录的信息已经写入数据库文件，但在使用事务日志备份进行数据库还原的时候，还将用到其中的信息。 对于使用简单恢复模型的数据库，事务日志会在每次处理检查点（CheckPoint）时自动被截断。对于使用完全恢复模型或大容量日志记录恢复模型的数据库，事务日志只有在执行日志备份（BACKUP LOG）时才会被截断，这时事务日志中记录的信息被写入事务日志备份文件，而它们所占用的这部分空间被标记为可用（即被截断）。 截断事务日志并不会使日志文件变小，但可以将其中的部分空间释放供以后写入新的日志记录使用。若要减少日志文件的物理大小，则要使用上面提到的DBCC SHRINKDATABASE和DBCC SHRINKFILE命令。 在执行BACKUP LOG语句的时候，还可以使用WITH NO_LOG（或WITH TRUNCATE_ONLY，含义相同）参数，这时并不真正备份事务日志，而只是截断事务日志中的非活动部分（这和普通的BACKUP LOG语句作用相同）。这适合于剩余磁盘空间不够进行事务日志备份或不打算保留事务日志中的非活动部分用于数据库恢复的情况。 为避免事务日志文件增长过快以致用尽所有磁盘空间的现象发生，一种办法是将数据库设为使用简单恢复模型，这样可以使SQL Server周期性的自动截断事务日志的非活动部分，并回收其占用的空间供以后写入事务日志记录使用。但这将使数据库无法利用事务日志备份还原到实时点，降低了数据库的可靠性，因此一般不应用于生产型数据库。 对于生产型数据库，推荐的做法是使用完全恢复模型，并定期进行数据库的完全备份和事务日志备份。例如每周执行一次完全备份，每天执行一次事务日志备份，这可以通过SQL Server企业管理器中的数据库维护计划向导很方便的实现（一般可以设为在每天夜里业务不繁忙的某个时刻自动执行备份）。 通过定期执行数据库的事务日志备份，可以避免日志文件的迅速增大，而使其保持一个比较稳定的大小。虽然数据库备份文件也会占用很多磁盘空间，但随时可以将这些文件移到其他磁盘上或在不需要它们的时候将其删除，而且可以在出现故障或误 *** 作的时候方便的进行数据库的还原。 由于数据文件的大小是随数据库中数据量的增长而增长的，数据库中已删除的数据所占的空间可以供新插入的资料使用；而在定期执行了事务日志的备份后，我们可以将日志文件的大小控制在一个比较合理的范围。因此，一般不需要对数据库进行收缩，也不推荐将数据库设为自动收缩模式。建议仅在以下情况下执行数据库的收缩：1、磁盘空间不足2、数据文件很大，但其中只包含较少量的数据（可能是以前有大量数据，但后来删除了很多），并且预期今后数据库中的数据量也不会很大。3、由于长期未进行事务日志备份，导致事务日志文件过大。减小事务日志文件大小的另一种方法是：首先在该数据库中执行CHECKPOINT命令，然后将该数据库分离（Detach），再将与其对应的数据库日志文件（ldf文件）改名或删除或移动到其他目录下，然后执行sp_attach_single_file_db存储过程或在企业管理器中重新将其附加（Attach）。由于找不到原来的日志文件，SQL Server将自动为该数据库建立一个大小只有504K的日志文件。但这种方法必须暂时将数据库脱机，因此一般不适宜在生产环境中使用。如果当前数据库的事务日志文件过大，必须对其进行收缩的话，建议参照以下步骤：1、建议首先备份数据库（但不是必需的）：BACKUP DATABASE database_name TO backup_device

2、备份事务日志：BACKUP LOG database_name TO backup_device如果不需要当前事务日志中的记录进行数据库还原或没有足够的空间进行事务日志备份的的话，也可仅执行以下命令截断事务日志：BACKUP LOG database_name WITH NO_LOG

3、收缩日志文件：DBCC SHRINKFILE (log_file_name)其中log_file_name是事务日志文件的逻辑名称，可以在企业管理器中数据库属性的“事务日志”页中看到（如Northwind数据库的默认事务日志文件逻辑名称为Northwind_log）。4、如果日志文件仍然较大的话，可以尝试重复执行一次BACKUP LOG WITH NO_LOG和DBCC SHRINKFILE命令。5、如果这时仍没有明显的效果，请执行DBCC OPENTRAN (database_name)检查当前数据库中是否存在长时间未提交的活动事务。有必要的话，可以断开这些连接并重新尝试截断事务日志和收缩日志文件。6、日志文件收缩完成后，建议立即执行一次数据库的完全备份并根据实际需要制定适当的数据库备份计划。

1、右击数据库选择，打开Files窗口

2、Files窗口，File type 选择 Log，单击OK完成日志收缩。

按以上方法 *** 作没有效果，原因是数据库的恢复模式不是简单模式，只需要将恢复模式改为简单模式即可用以上 *** 作来收缩日志，方便又好用。

将数据库恢复模式改为简单模式方法：

1、右击数据库选择属性，d出窗口如下图，选择Options选项，将 Recovery Model 改为 Simple 即可。

按如下方法 *** 作也可收缩日志：

1、当数据库恢复模式为简单时。使用dbcc shrinkfile (logfile_name,target_size)命令来完成。如

use mydb

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m

2、当数据库恢复模式为完全时。可以先将数据库模式改为简单模式，再使用上述方法来进行。

use master

alter database mydb set recovery simple

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m

也可以直接备份事务日志文件后再收缩：

use master

backup log mydb to disk='d:/ddbak'

use mydb

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m;

3、通过分离数据库，然后再删除事务日志文件，再附加mdf数据文件，也可以达到某种意义上的事务日志收缩。

以下是有关日志文摘

对于每一个数据库来讲，都需要至少一个事务日志文件。事务日志文件是整个数据库的血液，如果没有事务日志的话，那么将无法进行任何 *** 作。

事务日志有什么东西？

事务日志记录着在相关数据库上的 *** 作，同时还存储数据库恢复(recovery)的相关信息。

事务日志与数据库恢复(recovery)是密切相关的，其实数据库在启动时，便会进行相关的恢复(recovery) *** 作，如下所示。当然，在数据库还原时，也可以指定手工恢复(recovery)任何在数据库上的改变，如果在事务日志内被标记为已提交，并用一个LSN(LOG SEQUENCE NUMBER)来标识，同时相关改变就会体现在数据文件上，而被标记为未提交的改变将不会体现在数据文件上。

2010-01-12 18:31:4872 spid7s Recovery is complete This is an informationa message only No user action is required

事务日志文件还存储着数据库需要回滚的相关信息。在SQL Server数据库上，默认是隐式提交的，也就是说在查询分析器里面进行的每一个 *** 作，在 *** 作完成后，都是默认已经commit，但如果通过指定begin tran 和rollback tran的命令来标识事务时，rollback tran就需要使用事务日志内的相关信息才可以回滚。当然，如果SQL Server遇到相关错误时，如死锁，那么也会产生一个内部回滚，这些都需要用到事务日志文件。

为什么要收缩事务日志？

收缩日志的原因有很多种，有些则是考虑空间不足，有些则是应用程序限制导致的，一般情况下，是不建议对事务日志进行其他改变的，如需要控制事务日志的大小，则可以通过安排事务日志备份来解决。如果确定事务日志包含将不再使用的未使用空间，则可以通过减少事务日志的大小，以便回收过多空间。但这种情况对于一个DBA来讲，应该要尽量避免。

仅当数据库处于联机状态，而且至少一个虚拟日志文件可用时，收缩才会发生。在某些情况下，直到下一个日志截断后，才能收缩日志。

事务日志收缩的原理:

每个事务日志由多个虚拟日志文件组成(virtual log file)虚拟日志文件没有固定的大小，也没有固定的个数。在创建事务日志文件或者扩展事务日志文件时，SQL SERVER便会自动创建合适大小的虚拟日志文件，DBA无法控制虚拟日志文件的大小和个数。在扩展日志文件后，虚拟文件的大小是现有日志大小和新文件增量大小之和。因此，如果在创建数据库时，对数据库指定了比较小的初始大小，又指定了比较小的日志增长量，随着事务日志的自动扩展，虚拟日志文件个数会越来越多，从而影响了数据库性能。因此，在创建数据库时，尽量指定比较合适的初始事务日志大小，同时指定合理的事务日志增长量，这点可以参考数据文件的标准。如果大于10G或者更大的话，则指定固定的增长量，如果比较小，则指定按百分比的增长量来进行。

详情参考

>

USE crmdb --crmdb 是数据库名称

GO

ALTER DATABASE crmdb

SET RECOVERY SIMPLE;--设置简单恢复模式

GO

DBCC SHRINKFILE (crmdb_Log, 10);--crmdb_Log数据库日志文件，10是收缩到多大（日志最后大小）

GO

ALTER DATABASE crmdb

SET RECOVERY FULL;--恢复为原模式

GO

好像不可以，需要单独进行截断日志的 *** 作：

BACKUP LOG WITH TRUNCATE_ONLY

执行收缩 *** 作：在数据库右键-任务-收缩-文件。在文件类型选择日志，点击确定，待执行完毕后。或者 dbcc shrinkdatabase(db_name)

--此为数据文件、数据库日志文件收缩 *** 作语句

--保存时间：2017-1-9

--使用说明：

--“DataBase”为数据库名称，在进行数据收缩 *** 作前，先做好数据备份

--将语句中的“DataBase”替换为需要进行数据收缩的数据库名称，如：test

--在进行数据库收缩的时候，要留出 *** 作时间，期间不要进行任何用户 *** 作

--确认无误后，执行语句，即可进行数据收缩！

use master

go

alter database DataBase set recovery simple with NO_WAIT

go

alter database DataBase set recovery simple

go

declare @name varchar(20)

declare @sql varchar(100)

select @name = name from sysdatabase_files where type = 1

set @sql = 'DBCC SHRINKFILE (N'''+ @name +''' , 11, TRUNCATEONLY)'

exec(@sql)

go

dbcc shrinkdatabase(DataBase)

go

alter database DataBase set recovery full with NO_WAIT

go

--设置恢复模式（'SIMPLE'表示简单；'FULL'表示完整）

alter database DataBase set recovery full

go

--设置数据库兼容性级别为sql 2008

alter database DataBase set compatibility_level = 100

go

以上就是关于SQL Server 2000数据库的事务日志文件过大，如何将其缩小全部的内容，包括:SQL Server 2000数据库的事务日志文件过大，如何将其缩小、sql server 2008 r2如何收缩数据库和文件、为什么SQL2005数据库的事务日志文件收缩不了高手帮帮忙等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！