SQL Server 2008日志不会截断

Question

我认为自己是一个非常有经验的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:\<path here>\bybox.bak'

-- Create a logical backup device, ByBoxLog.
EXEC sp_addumpdevice 'disk', 'ByBoxLog', N'C:\<path here>\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中可能存在错误，或者我的日志文件已经以某种方式损坏。 但是，我的数据库处于良好的工作状态，这让我觉得有一个错误（想到的是颤抖） 。

Answer 1

在我的情况下，我有一个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。 呼！

Answer 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

Answer 3

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

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

在您将恢复模式从简单变为简单之前......如果您处于开发/ QA环境中，则无需担心。 但是，如果您处于生产环境中，您有责任确保在出现问题时完全恢复数据，您可能需要仔细研究BOL在执行此操作时所说的内容（请参阅BOL：“管理数据库” “ - >”事务日志管理“ - >”恢复模型和事务日志管理“）：

数据库可以随时切换到另一个恢复模型。 但是，从简单的恢复模型切换是不寻常的。 请注意，如果在批量操作期间切换到完全恢复模型，则批量操作的日志记录会从最小日志记录更改为完全日志记录，反之亦然。

从简单恢复模型切换后

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

切换到简单恢复模型后

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

真？ “ 我们强烈建议您在切换之前立即备份日志，这样您就可以恢复到目前为止的数据库。 ”我无法理解为什么这个小小的信息隐藏在名为“切换到简单恢复模型之后的部分”中“让大多数”普通人“认为他们可以继续进行切换，然后继续或回来后再更改它。

胡言乱语

致微软：所以，如果我错了，请纠正我，如果我在从FULL变为SIMPLE之前没有做t-log备份，并且看到我的数据库在某种程度上被损坏（曾经听说过Murphy定律吗？）就在我之前我能够备份......然后我搞砸了，对吧？ 如果将我的****生产****数据库的恢复模型从FULL切换到SIMPLE会破坏备份日志链，这样如果我在执行之前未能进行事务日志备份（如上所述） 我可能会丢失数据 ，然后为什么不明白，在一个闪烁的MARQUEE中，它比你看起来更大？ 你应该真的抓住我的衬衫，抓住我引起我的注意（可以这么说）并警告我这个UPFRONT的重要性！

Answer 4

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

• 备份日志
• 完整备份数据库
• 收缩日志文件
• 再次备份日志
• 再次收缩日志文件

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

Answer 5

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

Answer 6

找到了解决方案！

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

备份和瞧，完美的0％日志。

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

Answer 7

这听起来有点愚蠢，但我发现我必须执行两个完整的数据库和日志文件备份才能收缩数据库。

使用SQL Server Management Studio时 ，在执行完整数据库备份后执行完整事务日志备份后，缩小文件页面会显示大量可用空间，但不会截断日志文件。

但是，当我运行数据库和日志文件的第二次完整备份时，我发现事务日志的完整备份要小得多，因为它似乎只是备份自上次备份以来的新更改。

完成第二次备份后，我再次在管理工作室中运行收缩工具。 它仍然显示有足够的​​可用空间，但是这次当我单击OK时，日志文件的大小会减小。

所以，尝试以下方法。

1. 对数据库和日志文件进行完整备份。 如果在收缩工具中检查，您应该会看到日志文件中现在有足够的可用空间。 但是，单击“确定”不会删除可用空间。

2. 对数据库和日志文件进行第二次完整备份。 您应该发现数据库的完整备份与第一次完整备份的大小相似。 完整事务日志备份的大小应该小得多。

3. 在日志文件上运行收缩工具，运气好的话，日志文件应该减小。 我最后一次这样做，它从180 GB减少到12 MB，缩小工具表明文件中仍有10 MB的可用空间。

Answer 8

我终于找到了日志文件收缩问题的解决方案。 所有以前的选项都不适用于我，并没有将日志文件缩小到所需的大小。 我找到的解决方案是：

• 备份数据库
• 将恢复模式设置为简单
• 使用SQL Server Management Studio分离数据库
• 删除日志文件
• 附加没有日志文件的数据库。 在“添加屏幕”的下半部分，您会看到一行表示缺少日志文件
• 单击此行的删除，然后单击确定以进行附加
• 将恢复模式设置回完全

Answer 9

试试跑步

DBCC OPENTRAN

检查是否有任何未结交易。

Answer 10

我知道你的意思 - SQL服务器可能会有点令人抓狂。 这是一些尝试的示例代码。 实质上，它会截断日志文件， 然后尝试收缩文件。 让我知道它是如何工作的。 另一件事......你不会有未提交的交易，不是吗？

Use YourDatabase
GO

DBCC sqlperf(logspace)  -- Get a "before" snapshot
GO  

BACKUP LOG BSDIV12Update WITH TRUNCATE_ONLY;  -- Truncate the log file, don't keep a backup
GO

DBCC SHRINKFILE(YourDataBaseFileName_log, 2);  -- Now re-shrink (use the LOG file name as found in Properties / Files.  Note that I didn't quote mine).
GO

DBCC sqlperf(logspace)  -- Get an "after" snapshot
GO

更新： Simon注意到他在BACKUP命令上收到错误。 当我之前回答时，我没有意识到SQL Server 2008中已经停止使用“Truncate_only”。 经过一些研究后，收缩日志文件的建议步骤是（a）将恢复模型更改为简单，然后（b）使用DBCC ShrinkFile缩小文件，如上所述。 不幸的是，你提到你已经尝试将恢复模型设置为Simple，所以我假设你之后也运行了DBCC Shrinkfile。 这个对吗？ 请告诉我。

Answer 11

这可能是一种痛苦，它可能有很多东西。 你要确定的第一件事是没有“卡住”的交易。 如果您的事务永远不会关闭，则无法缩小日志。 运行“DBCC OPENTRAN”以查找运行时间最长的事务。

另外，请确保重新组织（我认为这是正确的术语）并在缩小之前将所有内容移动到文件的开头。

Answer 12

阅读答案我几乎不相信它们是由DBA编写的。 基本黄金法则：

1. 在执行任何维护（包括缩小日志）之前的任何数据库中，都应执行完整备份。

2. 在整个维护期间，当该特定数据库上没有其他任何事情发生时，执行任何数据库维护，包括收缩。 如果有必要，暂停非本质申请。 始终牢记健康的数据库是与之交互的任何应用程序的灵魂。

在这之后，以下用于收缩数据库事务日志的命令在SQL Server 2005及更高版本的SQL Server版本上始终可以正常工作：

USE DatabaseName
GO
-- Truncate the Transaction log
ALTER DATABASE DatabaseName SET RECOVERY SIMPLE
CHECKPOINT
ALTER DATABASE DatabaseName SET RECOVERY FULL
GO
-- Shrink the Transaction Log as recommended my Microsoft.

DBCC SHRINKFILE ('database_txlogfilelogicalname', [n -size to shrink in MBytes])
GO
 -- Pass the freed pages back to OS control.
DBCC SHRINKDATABASE (DatabaseName, TRUNCATEONLY)
GO
-- Tidy up the pages after shrink
DBCC UPDATEUSAGE (0);
GO
-- IF Required but not essential
-- Force to update all tables statistics
exec sp_updatestats
GO

Answer 13

SQL Server 2012 ：我遇到了一个问题，即没有日志文件（以及所有已经在SIMPLE恢复中）都会缩小。

这对我有用......我重新启动了SQL Server实例（因为我可以）并且每个坏男孩都缩小了。

随着重新开始，随着收缩而遏制的是什么。 这仅适用于紧急情况（或者当它是您的服务器时），而不是常规的长期解决方案。

Answer 14

我终于得出结论，SQLServer 2008中存在一个错误。

我已经尝试了一切，我能想到的每一个组合。 我已备份数据库，删除它，重新创建它，恢复它。 完全相同的问题。

我也跑了：

DBCC CHECKDB
DBCC UPDATEUSAGE (bybox)

所有检查都没问题。

我只能说下一个服务包。

Answer 15

请运行：

SELECT name, log_reuse_wait, log_reuse_wait_desc FROM sys.databases

并查看你的问题数据库的log_reuse_wait是什么，如果它是复制，这是错误你需要这个值0,2或4