SQL Server 2005 Express：mdf文件的date不变，ldf文件变得巨大

另外两个答案是完全正确的，但是我认为这个问题的根本原因可能不在这里：

在完全恢复模式下，SQL Server 不会将数据写入到mdf（数据）文件中 …只能写入事务日志。

将数据存入数据文件的唯一方法是进行事务日志备份。 通常认为，完全恢复模式下的主动生产数据库应该每小时至less备份一次事务日志。

之前发布的build议是暂时将数据库切换到简单恢复模式。 在这种模式下，SQL Server不会在事务日志中保留事务的数据logging（经过编辑，以免混淆某些人 ）一段时间。 如果您执行此更改，SQL Server将花费很多时间对磁盘进行批量处理，因为它会将日志中的事务提交到数据文件中。

完成后，您仍将拥有56GB的事务日志文件，并且您的数据文件将会更大。 （虽然没有那么大，但是）。 事务日志文件不会变小，直到你“缩小”它。

通常，这是你不应该做的事情

但是由于这个数据库是一团糟，在上面的过程之后，把事务日志缩小到数据文件大小的一半可能是个好主意。

然后…将数据库切换回完全备份，并立即制定维护计划 。

下面的一位评论者表示，我的答案是“完全错误的”，是基于被挑选的几个小妞。 我可以用那个评论来select那些相同的尼特，并且说它也是“完全错误的”。

• 我不是故意build议，SQL Server将数据写入事务日志。 它写的是什么名字暗示：交易logging。 我很抱歉，评论者不能通过阅读来推断这一事实; 我不相信OP有这样的问题，所以我不觉得有必要详细说明。

但是应该指出：“交易logging” 是数据 。

我提出的其他说明清楚地表明，我非常清楚事务日志包含哪些内容 – 比如我的声明，尽pipe数据文件将在TL备份后增长，但不会像TL的大小一样增长。

• 我并不是想说明 – 也不是真的认为我这样做 – 更改恢复模型会改变SQL Server将数据写入数据文件的方式。 但是我确实声明， 当数据写入数据文件时会影响它。 下面的评论者正在挑选一个令人难以置信的黑名单 – 用非常笨拙的（不相关的）措辞来这样做。

正在挑选的是，恢复模式改变了SQL Server对事务日志logging的作用。 Simple ，它将这些交易持久化到数据文件中的数据，并将其从“快速”的TL中移除。 在Full ，直到TL备份完成之前，它将保持独立。

因此，您可能会认为恢复模式无关紧要，特别是与数据文件或写入数据时无关。 但是，这就好像争论说，按下汽车上的加速器并不会导致汽车行驶得更快，因为， 它所做的只是让发动机旋转得更快。

也许在技术上是正确的，但在我们所说的上下文中完全没有用处。

两个选项

1. 将您的恢复模式更改为简单
2. 开始进行事务日志备份（并确保您也正在进行完整的数据库备份）。

你必须做的事情：

1. 开始阅读这个东西，或者雇用一个已经知道的人（并且可以训练你需要知道的东西）。

经营一个swerever就像开车。 不知道你在做什么…你遇到了麻烦。 像你一样做。

• mdf文件的date不会改变

IIRC在文件closures时发生更改….而SQL Server只在closures文件时closures文件。

• ldf文件变得巨大

因为你没有做适当的备份？ 没有完整的日志备份 – 日志运行完整。 这是devise，我build议你阅读备份数据库，否则你会失去这个客户。

为了解决眼前的问题，将数据库恢复模式更改为简单，因此不需要长期保存日志条目。 然后在一天或一小时内将日志文件转储到可pipe理的级别。 这是一个“你会把顾客弄糊涂”的情况，但是至less你的光盘没有满载。

为了不让客户长期失去知识，请确保您对satabase的灾难恢复有一个初学者的理解，并开始备份。