直接使用DBCC SHRINKFILE,BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止

本文介绍在 SQL Server 2008 中如何进行日志备份及使用简单恢复模式来收缩数据库日志文件。由于 TRUNCATE_ONLY 选项已被废弃,文章提供了详细的步骤说明如何通过改变恢复模式来实现日志文件的截断和收缩。

注意  
BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止。使用完整恢复模式或大容量日志恢复模式时,如果必须删除数据库中的日志备份链,请切换至简单恢复模式。有关详细信息,请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。
 

有关常规日志截断的详细信息,请参阅事务日志截断。

http://msdn.microsoft.com/zh-cn/library/ms186865.aspx 
 
liyihongcug
 
SQL SERVER 2008 中 BACKUP LOG WITH TRUNCATE_ONLY 已不再被支持,要收缩数据库日志,首先需要通过将数据库恢复模式设置为 SIMPLE 来截断该文件。

语句如下:

USE DATABASENAME; GO

-- Truncate the log by changing the database recovery model to SIMPLE.

ALTER DATABASE DATABASENAME SET RECOVERY SIMPLE;

GO

-- Shrink the trun cated log file to 1 MB.

DBCC SHRINKFILE (DATABASENAME_Log, 1); GO

-- Reset the database recovery model.

ALTER DATABASE DATABASENAME SET RECOVERY FULL; GO

也可以通过图形界面来完成。

通过先备份日志,然后再收缩日志文件,如下: back database mydb to disk='mydb_bak'; dbcc shinkfile(mydb_log,10);--收缩至10m

<think>嗯,用户的问题是关于使用DBCC SHRINKFILE命令收缩SQL Server事务日志文件的。首先需要确认用户的具体需求。用户提到"Shrinking a SQL Server transaction log file using DBCC SHRINKFILE command",核心是操作方法注意事项。 根据引用内容,引用[1]提供了DBCC SHRINKFILE的基本语法,这是关键的操作依据。引用[2]引用[3]则强调了事务日志收缩的风险注意事项,尤其是引用[2]提到"Shrinking a database is an expensive operation",说明需要谨慎操作。 接下来需要整理操作步骤。首先,用户需要备份事务日志,这是收缩前的必要准备,因为事务日志备份会截断不活动的部分,释放空间。然后才是执行DBCC SHRINKFILE命令,指定日志文件名目标大小。这里要注意语法中的target_size参数,以及TRUNCATEONLYNOTRUNCATE选项的区别。 注意事项部分尤为重要。频繁收缩日志文件会导致物理文件碎片,影响性能,而且自动收缩(auto-shrink)功能不被推荐,引用[2]也提到了这一点。此外,用户需要理解为什么日志文件会增长,可能是由于未提交的事务或大量操作,解决根本原因比反复收缩更重要。 可能用户遇到的问题是日志文件过大,但直接收缩可能不是最佳解决方案。应该建议用户检查恢复模式,如果是完整模式,需要定期备份日志来控制大小。同时,收缩后设置合适的大小避免自动增长,也是关键步骤。 最后,生成相关问题需要考虑用户可能的后续疑问,比如如何监控日志增长原因,或者如何设置警报预防空间不足。还要包括收缩后的维护策略,以及不同恢复模式的影响。这些问题能帮助用户全面管理事务日志,而不仅仅是执行收缩操作。</think>以下是关于使用 `DBCC SHRINKFILE` 收缩 SQL Server 事务日志文件的详细说明及注意事项: --- ### **核心步骤** 1. **备份事务日志** (释放未活动空间) 先备份日志以截断不活动的虚拟日志文件(VLF),这是收缩的前提: ```sql BACKUP LOG [YourDatabaseName] TO DISK = N'D:\Backup\YourLogBackup.trn'; ``` 2. **执行收缩命令** 使用 `DBCC SHRINKFILE` 指定日志文件的逻辑名目标大小: ```sql -- 语法:DBCC SHRINKFILE (logical_log_name, target_size_in_MB) DBCC SHRINKFILE (N'YourDatabase_Log', 100); -- 将日志收缩到100MB ``` 3. **可选参数** - `NOTRUNCATE`:将释放的空间保留在文件中(不返还给OS) - `TRUNCATEONLY`:仅截断空闲空间到文件末尾,不进行页移动 - `EMPTYFILE`:清空文件并迁移数据到同文件组的其他文件 --- ### **关键注意事项** [^2][^3] 1. **收缩是昂贵操作** - 频繁收缩会导致**物理文件碎片**,增加 I/O 开销。 - 可能阻塞其他操作,影响性能。 2. **根本原因分析** 日志文件增长通常由以下原因引起: - **未提交的长事务**(检查 `sys.dm_tran_database_transactions`) - **完整恢复模式下缺少日志备份**(需定期执行 `BACKUP LOG`) - **大容量操作**(如批量插入、索引重建) 3. **避免自动收缩** ❌ 不要启用数据库的 `AUTO_SHRINK` 选项: ```sql ALTER DATABASE [YourDB] SET AUTO_SHRINK OFF; -- 默认应为OFF ``` 自动收缩会在后台频繁触发,严重消耗资源[^2]。 --- ### **最佳实践** 1. **预防性维护** - 设置合理的**日志初始大小****增长值**(避免默认的10%增长) - 在维护窗口执行收缩操作 ```sql ALTER DATABASE [YourDB] MODIFY FILE ( NAME = N'YourDatabase_Log', SIZE = 1024MB, -- 初始大小 FILEGROWTH = 256MB -- 固定增长值 ); ``` 2. **监控日志空间** 使用查询跟踪日志使用情况: ```sql SELECT name AS [File Name], size/128.0 AS [Allocated Size (MB)], FILEPROPERTY(name, 'SpaceUsed')/128.0 AS [Used Space (MB)] FROM sys.database_files WHERE type_desc = 'LOG'; ``` 3. **长期解决方案** - **定期日志备份**:完整恢复模式下必须执行。 - **优化大事务**:拆分大批量操作。 - **切换恢复模式**:若允许数据丢失,可改用简单模式(不推荐生产环境)。 --- ### **示例场景** ```sql -- 1. 备份日志 BACKUP LOG [SalesDB] TO DISK = 'E:\Backups\SalesDB_Log.bak'; -- 2. 收缩日志到200MB DBCC SHRINKFILE (N'SalesDB_Log', 200); -- 3. 验证结果 SELECT name, size/128 AS [Size (MB)], FILEPROPERTY(name, 'SpaceUsed')/128 AS [Used (MB)] FROM sys.database_files WHERE type_desc = 'LOG'; ``` > ⚠️ **警告**:若收缩后日志文件立即再次增长,说明存在未解决的根本问题。此时应优先分析日志增长原因而非重复收缩[^3]。 --- ### **相关问题** 1. 如何定位导致事务日志增长的具体查询或事务? 2. 在简单恢复模式下收缩事务日志有何不同? 3. 频繁收缩事务日志会对数据库性能产生哪些长期影响? 4. 如何配置事务日志备份策略以控制其大小? 5. 使用 `DBCC SHRINKFILE` 后,为什么日志文件的物理大小未改变? [^1]: DBCC SHRINKFILE 语法参考 [^2]: 事务日志收缩的性能风险 [^3]: 事务日志维护的综合策略
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值