SQL Server 2008日志不会截断

我认为自己是一个非常有经验的SQL人.但我没有做这两件事:

减小分配日志的大小.

截断日志.

DBCC sqlperf(logspace)

收益:

Database Name   Log Size (MB)   Log Space Used (%)  Status
ByBox       1964.25     30.0657         0

以下内容不适用于SQL 2008

DUMP TRANSACTION ByBox WITH TRUNCATE_ONLY

运行以下操作也没有任何作用

DBCC SHRINKFILE ('ByBox_1_Log' , 1)
DBCC shrinkdatabase(N'bybox')

我试过备份了.我也试过设置数据库的属性 - '恢复模型'为'FULL'和'SIMPLE'以及上述所有内容的组合.我还尝试将兼容性设置为SQL Server 2005(我使用此设置,因为我想匹配我们的生产服务器)和SQL Server 2008.

无论我尝试什么,日志仍然是1964.25 MB,使用30%,这仍然在增长.

我希望日志能够回到0%附近并将日志文件大小减少到100 MB,这就足够了.我的数据库必须恨我; 它只是忽略了我要求它做的关于日志的一切.

还有一点需要注意 生产数据库有很多复制表,当我使用以下内容在开发框上执行恢复时,我关闭了这些表:

-- Clear out pending replication stuff
exec sp_removedbreplication
go
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL,
     @numtrans = 0, @time = 0, @reset = 1
go

试:

SELECT log_reuse_wait, log_reuse_wait_desc
FROM sys.databases
WHERE NAME='bybox'

返回

log_reuse_wait  log_reuse_wait_desc
0   NOTHING

我该如何解决这个问题？

---

看着这个并将恢复模型设置为FULL,我尝试了以下方法:

USE master
GO

EXEC sp_addumpdevice 'disk', 'ByBoxData', N'C:\\bybox.bak'

-- Create a logical backup device, ByBoxLog.
EXEC sp_addumpdevice 'disk', 'ByBoxLog', N'C:\\bybox_log.bak'

-- Back up the full bybox database.
BACKUP DATABASE bybox TO ByBoxData

-- Back up the bybox log.
BACKUP LOG bybox TO ByBoxLog

返回:

Processed 151800 pages for database 'bybox', file 'ByBox_Data' on file 3.
Processed 12256 pages for database 'bybox', file 'ByBox_Secondary' on file 3.
Processed 1 pages for database 'bybox', file 'ByBox_1_Log' on file 3.
BACKUP DATABASE successfully processed 164057 pages in 35.456 seconds (36.148 MB/sec).

Processed 2 pages for database 'bybox', file 'ByBox_1_Log' on file 4.
BACKUP LOG successfully processed 2 pages in 0.056 seconds (0.252 MB/sec).

完善!但事实并非如此.

DBCC SHRINKFILE('ByBox_1_Log',1)现在返回

DbId    FileId  CurrentSize MinimumSize UsedPages   EstimatedPages
7   2   251425  251425  251424  251424

和DBCC SQLPERF(LOGSPACE)仍然报告30%的使用率.

我想我可能不得不辞职,因为SQL Server 2008中可能存在错误,或者我的日志文件已经以某种方式损坏.但是,我的数据库处于良好的工作状态,这让我觉得有一个错误(想到的是颤抖).

1> John..：

---

在我的情况下,我有一个650 MB的数据库,在SQL Server 2008中有一个370 GB的日志文件.无论我尝试什么,我都无法让它缩小.我尝试了所有列出的答案,但仍然无效.

最后,我在其他地方发现了一个非常简短的评论.这是运行:

BACKUP LOG DatabaseName TO DISK = N'D:\Backup\DatabaseName_log.bak'
GO
DBCC SHRINKFILE('MyDatabase_Log', 1)
GO

这导致日志文件从37 GB减少到1 MB.呼!

---

+1可能会迟到,但很简单,对我有用!谢谢.

---

**谢谢你**直截了当.当我得到一篇关于为什么练习不好而不是回答问题的论文时,让我感到疯狂.**注意:**我试过这个并且遇到消息_'无法收缩日志文件,因为位于文件末尾的逻辑日志文件正在使用中.'我必须在恢复模式发布之前将恢复模式设置为SIMPLE空间.在释放磁盘空间后,我将其更改回FULL.

2> 小智..：

---

我找到了DBCC SHRINKFILE(Transact-SQL)(MSDN).

以下示例将AdventureWorks数据库中的日志文件缩小为1 MB.要允许DBCC SHRINKFILE命令收缩文件,首先通过将数据库恢复模型设置为SIMPLE来截断该文件.

USE AdventureWorks;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks
SET RECOVERY FULL;
GO

3> 小智..：

---

谨防改变恢复模式的含义!!

现在,对于所有考虑使用脚本的生产DBA,还有一个更清醒的想法:

在更改恢复模式从完全简单......没有后顾之忧,如果你在开发/是QA环境.但是,如果您处于生产环境中,您有责任确保在出现问题时完全恢复数据,您可能需要仔细研究BOL在执行此操作时所说的内容(请参阅BOL:"管理数据库" " - >"事务日志管理" - >"恢复模型和事务日志管理"):

数据库可以随时切换到另一个恢复模型.但是,从简单的恢复模型切换是不寻常的.请注意,如果你批量操作过程中切换到完整恢复模式,从最少日志批量操作变为完整日志记录,反之亦然记录.

从简单恢复模型切换后

如果从完整或大容量日志恢复模型切换到简单恢复模型,则会中断备份日志链.因此,我们强烈建议您备份日志立即切换,它允许你将数据库恢复到该点之前.转换后,你需要采取定期进行数据备份,以保护您的数据和截断事务日志的非活动部分.

切换到简单恢复模型后

如果从完整或大容量日志恢复模型切换到简单恢复模型,则会中断备份日志链.因此,我们强烈建议您在切换之前立即备份日志,这样您就可以恢复数据库.切换后,您需要定期进行数据备份以保护数据并截断事务日志的非活动部分.

真？" 我们强烈建议您备份日志立即切换,它允许你将数据库恢复到这一点了. "我不明白为什么这一点的信息珍闻是隐藏在一个名为节"切换到简单恢复模式后"做最'正常的人’认为他们可以继续前进,打开它,然后继续或回来,并改变它后阅读.

胡言乱语

To Microsoft: So, please correct me if I'm wrong, if I fail to do the t-log backup BEFORE changing from FULL to SIMPLE and lo and behold my database gets corrupted somehow (ever heard of Murphy's law?) right before I'm able to take a backup... then I'm screwed, right? If switching the recovery model of my****production****database from FULL to SIMPLE is something that can break the backup log chain such that if I fail to take a transaction log backup before doing it (like it suggests above) I'm potentially going to lose data那么为什么你不明白,在一个闪烁的MARQUEE中,它比你看起来更大？你应该真的抓住我的衬衫,抓住我引起我的注意(可以这么说)并警告我这个UPFRONT的重要性!

4> 小智..：

---

另一种减少日志文件大小的简单方法是:

备份日志

完整备份数据库

收缩日志文件

再次备份日志

再次收缩日志文件

这样,您不必修改任何数据库参数,并且您的日志文件大小为1 MB.

5> HardCode..：

---

我总是讨厌SQL Server处理日志文件物理收缩的方式.请注意,我总是通过企业管理器/ SQL Server Management Studio完成此操作,但是当您收缩/截断日志文件时,日志文件的物理大小似乎不会减少,直到对数据库进行完全备份之后数据文件,然后再次备份日志文件.我永远无法确定确切的模式,但你可以试着看看具体的顺序是什么.但是,它始终涉及对数据文件进行完整备份.

6> Simon Hughes..：

---

找到了解决方案!

我向数据库添加了大量数据,因此强制日志扩展.然后,我删除了不需要的数据,以使我的数据库恢复原状.

备份和瞧,完美的0%日志.

因此解决方案是使日志扩展.