1、有用的 SQL 语句关键是要在截断日志之前做一次完整备份。做完整备份的时候，用参数 WITH NO_LOG；然后执行收缩数据库的操作。BACKUP DATABASE ado TO DISK = NC:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupado0427inrunning.bak WITH NOFORMAT, NOINIT, NAME = Nado-完整数据库备份 , SKIP, NOREWIND, NOUNLOAD, STATS = 10 ;BACKUP LOG ado TO DISK = NC:Program FilesMicr
2、osoft SQL ServerMSSQL.1MSSQLBackupado0427inrunning.bak WITH NO_LOG;GOUSE ado;GO DBCC SHRINKDATABASE(Nado);执行结果为：SQL Server 事务日志的收缩和截断SQL Server 中事务日志的作用：持续记录数据库所有的事务和这些事务对数据库所做的修改;一旦数据库出现灾难事件，就需要事务日志来进行近期数据的恢复操作。但是，在此条件下受益的同时也要付出相应的代价：在活动数据库中，事务日志会消耗大量的存储空间，假如你不做任何的干预，事务逻辑日志将会一直增长，直到塞满存储这些日志文件的所有可用空
3、间。下面我们来详细介绍 SQL Server 提供的两个用来平衡事务日志对空间巨大需求的操作：收缩事务日志和截断事务日志。日志收缩截断日志虽然确实从日志文件中清除了事务，但它并不会真正的减小物理日志文件的大小。SQL Server 希望事务日志最终会扩展到其截断前的大小，所以截断不会释放已经分配给日志的硬盘空间。如果你的日志在某一时刻人为地扩展到某个大小，却再也无法恢复到这个大小的话可就麻烦大了。在这种情况下，要释放硬盘物理空间做其他用途，就要手动进行事务日志文件收缩操作。你可以使用下面的 T-SQL 命令实现日志文件的收缩：DBCC SHRINKFILE(,)上面命令中的 desired_s
4、hrink_size 指的是你想要回收的硬盘空间大小 (以 MB 为单位)。你可以在执行完事务日志截断操作之后立即回收大部分的磁盘空间。日志截断截断事务日志操作就是清除事务日志文件中的非活动记录。在一般的情况下，SQL Server能够自动执行截断操作，不需要人工干预管理。截断的频率取决于数据库的使用程度。你每进行一次完整恢复模式或大容量日志恢复模式的数据库备份，SQL Server 就会截断一次事务日志。如果是在简单恢复模式下(不能还原事务日志)，SQL Server 会在每个检查点之后截断事务日志。你也可以通过间接的方式手动驱使 SQL Server 执行事务日志截断操作，需要运行备份操作
5、，不过你可以给 SQL Server 下指示，表明你只想执行事务日志的备份操作，不做执行其他任何操作。通过以下的 T-SQL 命令仍然可以达到上述效果：BACKUP LOG WITH TRUNCATE_ONLY; 截断数据库日志方法1. 为什么要截断数据库日志日志文件很重要，它记录用户对数据库的所有操作，在发生故障时，可以以此回复。但日志文件的大小到达一定程度时，会影响数据库性能。经常的，日志文件会大于数据库主文件本身，长时间不截断，甚至会达到 10-20 倍之多。如果 ERP 用户操作越频繁，相差会越大。比如，数据库文件为 1G，而日志文件可能会有 10G。一般 3-6 个月检查一次日志文件
6、的大小。如果发现，日志文件比数据库文件大 35 倍，应该考虑截断数据库日志。在截断之前，锐减使用最简单的方法：务必做一次“完整备份”！2. 检查日志文件的大小方法有多种。3. 截断日志文件在查询分析器中，使用 SQL 语句：BACKUP LOG database_name | database_name_varWITH NO_LOG | TRUNCATE_ONLY 例：backup log “database_name” with no_log4. 收缩数据库做完第三个步骤之后，数据库的日志文件的大小将会被缩小，有可能只有 1M 左右的大小。具体缩小到一个什么程度，得看数据库的日志文件在数据库
7、创建时的大小。截断数据库的命令 DBCC SHRINKDATABASEDBCC SHRINKDATABASE 收缩指定数据库中的数据文件和日志文件的大小。语法：DBCC SHRINKDATABASE ( database_name | database_id | 0 ,target_percent , NOTRUNCATE | TRUNCATEONLY ) WITH NO_INFOMSGS 例子：收缩 ado 的数据库文件和日志文件USE adoGODBCC SHRINKDATABASE(Nado )GO参数：database_name | database_id | 0 要收缩的数据库的名称
8、或 ID。如果指定 0，则使用当前数据库。target_percent 数据库收缩后的数据库文件中所需的剩余可用空间百分比。NOTRUNCATE 通过将已分配的页从文件末尾移动到文件前面的未分配页来压缩数据文件中的数据。target_percent 是可选参数。文件末尾的可用空间不会返回给操作系统，文件的物理大小也不会更改。因此，指定 NOTRUNCATE 时，数据库看起来未收缩。NOTRUNCATE 只适用于数据文件。日志文件不受影响。TRUNCATEONLY 将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动。数据文件只收缩到最近分配的区。如果与 TRUNCATEONLY
9、 一起指定，将忽略 target_percent。TRUNCATEONLY 只适用于数据文件。日志文件不受影响。WITH NO_INFOMSGS 取消严重级别从 0 到 10 的所有信息性消息。压缩日志及数据库文件大小1.清空日志 DUMP TRANSACTION 库名 WITH NO_LOG 2.截断事务日志： BACKUP LOG 数据库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩 ,数据库的文件不会减小 企业管理器-右键你要压缩的数据库-所有任务- 收缩数据库- 收缩文件 -选择日志文件- 在收缩方式里选择收缩至 XXM,这里会给出一个允许收缩到的最小 M 数,直接输入这个
10、数,确定就可以了 -选择数据文件- 在收缩方式里选择收缩至 XXM,这里会给出一个允许收缩到的最小 M 数,直接输入这个数,确定就可以了 也可以用 SQL 语句来完成 -收缩数据库 DBCC SHRINKDATABASE(客户资料) -收缩指定数据文件,1 是文件号,可以通过这个语句查询到 :select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件 a.分离数据库: 企业管理器-服务器- 数据库- 右键-分离数据库 b.在我的电脑中删除 LOG 文件 c.附加数据库: 企业管理器-服务器- 数据库- 右键-附加数据库 此法将生成新的 LO
11、G，大小只有 500 多 K 或用代码： 下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。 a.分离 EXEC sp_detach_db dbname = pubs b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db dbname = pubs, physname = c:Program FilesMicrosoft SQL ServerMSSQLDatapubs.mdf 5.为了以后能自动收缩,做如下设置: 企业管理器-服务器- 右键数据库- 属性-选项-选择“ 自动收缩“ -SQL 语句设置方式 : EXEC sp_dbopt
12、ion 数据库名 , autoshrink, TRUE 6.如果想以后不让它日志增长得太大 企业管理器-服务器- 右键数据库- 属性-事务日志 -将文件增长限制为 xM(x 是你允许的最大数据文件大小) -SQL 语句的设置方式 : alter database 数据库名 modify file(name=逻辑文件名,maxsize=20) - 如何使 Microsoft SQL Server 的日志文件不会增大？ 作者：怡红公子 来源：开发者俱乐部 加入时间：2002-12-11 当易软件站 如何缩小 MSSQL 的日志文件已经是一个经常性的问题了，不过这个问题在精华区已经有不少答案了，我这
13、里也不再赘述。 现在我们讨论一下治本的问题，即如何使日志文件不再增大？ 先介绍一个简单的方法。 就是把数据库的故障还原模型设置为“简单”(SQL2K)。这样它就会在 Checkpoint 的时候截断日志。 具体操作方法是： 1、在 Enterprise Manager 中右键点数据库， “属性|选项|故障还原”，选择“简单”就可以了，如果是 SQL7，在“属性|选项 ”中有一个“trunc. log on chkpt. ”，选中就可以了。 2、如果不想用 Enterprise Manager，在 Query Analyser 或者 isql 里面执行 EXEC sp_dboption your
14、_dbname, trunc. log on chkpt., TRUE 就可以了 但是，要注意的是，这样做了之后，虽然日志不会增大，但是也意味着你一旦出现误操作，将不会有利用日志恢复的机会。(如何利用日志来恢复请参见精华区的 FAQ) 所以，绝对不建议在生产数据库上截断日志，除非你有充足的理由和足够的把握，或者 承担责任的不是你。 既然这种方法不安全，下面我将介绍一种安全的方法。 大家都知道，SQL Server 在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务，因此在恢复过程中不再使用。相反，事务日志的活动部分包含仍在运行但尚未完成的事务。SQL Server 将重新使用事务日志中这些截断的非活动空间，而不是任由事务日志继续增大并占用更多的空间。 所以，我们备份事务日志就可以使日志文件不再增大了。 但是呢，日志文件一直放着也不是个办法，删除呢，又会失去恢复的可能性。 我们可以结合完全备份来做。做过完全备份之前的事务日志就可以删除了。 比如说，一个备份计划，每天一次完全备份，保留 7 天内的，每 15 分钟一次事务日志备份，保留 2 天的。 用数据库维护计划向导可以很方便的建立备份计划，不过一定要记得设置保留多久的备份哦，否则硬盘空间被备份给占满了就坏事了。
