如果问题已经得到回答或者以错误的方式提出，我很抱歉 - 我是开发人员，不是系统或数据库管理员。
问题：SQL Server 2005 Express mdf 文件（大小 370 MB）两个月内没有改变其文件日期（即使在服务器重启后），而 ldf 文件已增长到 56 GB。
数据库在Windows 2003 Webedition Server上运行。
这是一个重要的客户，我不想冒任何风险（所以我没有尝试 Management Studio 中的“收缩”选项，因为担心丢失数据或长时间停机。
我们正在尝试设置一个新的服务器，并尝试恢复最新的.bak 文件，但它现在停留在“执行 90%”一段时间。
可以做什么？ 1. 等待更长时间 2. 网站运行时尝试缩小原始数据库 3. 其他
任何帮助是极大的赞赏。
谢谢，奥拉夫
答案1
另外两个答案完全正确，但我认为根本原因可能没有在这里体现出来：
在完整恢复模式下，SQL Server不将数据写入 mdf（数据）文件...它只写入事务日志。
将这些数据放入数据文件的唯一方法是进行事务日志备份。人们普遍认为，处于完整恢复模式的活动生产数据库应该备份其事务日志每小时至少一次。
之前发布的建议是暂时将数据库切换到简单恢复模式。在此模式下，SQL Server 不会保留事务的数据记录（已编辑，以免混淆有些人) 在任何时间段内都保留在事务日志中。如果进行此更改，SQL Server 将在相当长的时间内进行大量磁盘抖动，因为它会将日志中的事务提交到数据文件。
完成后，您将仍然有一个 56GB 的事务日志文件，您的数据文件会更大。（但不会大很多）。除非您“缩小”事务日志文件，否则它不会变小。
通常情况下，这是你不应该做的事情
但是由于这个数据库很混乱，在上述过程之后将事务日志缩小到数据文件大小的一半可能是一个好主意。
然后...将数据库切换回完整备份，然后立即制定维护计划。
下面一位评论者指出我的回答“完全错误”，因为他挑出了一些小毛病。我可以用那条评论挑出同样的毛病，然后说它也是“完全错误的”。
- 我并不是说 SQL Server 会将您的数据写入事务日志。它写入的内容正如其名称所暗示的那样：事务记录。很抱歉评论者无法通过阅读推断出这一事实；我不认为 OP 有这样的问题，所以我认为没有必要详细说明。
但需要注意的是：“交易记录”是数据。
我做的其他注释清楚地表明我非常清楚事务日志包含什么 - 例如我的陈述，虽然一旦 TL 备份，数据文件就会增长，但它的增长幅度不会像 TL 的大小那么大。
- 我无意表述——也不想真的我想我确实这样做了——改变恢复模式会改变如何SQL Server 将数据写入数据文件。但我确实说过它会影响什么时候数据被写入数据文件。下面的评论者在这里挑剔得令人难以置信——而且用词极其笨拙（不相关）。
需要挑剔的是，恢复模型改变了 SQL Server 对事务日志记录的处理方式。在 中Simple，它将这些事务保存到数据文件中的数据中，并“快速”地将它们从 TL 中删除。在 中Full，它会保留它们，直到 TL 备份完成。
您可能会争辩说，恢复模型与数据文件或向其中写入数据的时间没有关系。但这有点像争辩说踩下汽车的油门不会让汽车行驶得更快，因为，它实际上只会让引擎旋转得更快。
从技术上来说也许是正确的，但对于我们讨论的上下文来说，这完全是无用的附加信息。
答案2
两种选择
- 将恢复模式更改为简单
- 开始进行事务日志备份（并确保您也进行完整的数据库备份。）
你必须做的事：
- 开始阅读这些内容或聘请已经了解这些内容的人（并可以培训您了解您需要知道的内容）。
答案3
运行 swerever 就像开车。如果你不知道自己在做什么...你就会遇到麻烦。就像你一样。
- mdf 文件的日期没有改变
IIRC 当文件关闭时它会发生变化....并且 SQL Server 仅在您关闭它时才会关闭文件。
- ldf 文件变得很大
因为你没有做正确的备份？没有完整和日志备份 - 日志会满的。这是设计使然，我强烈建议你阅读有关备份数据库的资料，否则你将失去这个客户。
要解决眼前的问题，请将数据库恢复模式改为简单模式，这样就不会长期保留任何日志条目。然后在一天或一小时后将日志文件压缩到可管理的级别。这仍然是“您将失去客户”的情况，但至少您的磁盘没有满。
为了不长期失去客户，请确保您对数据库灾难恢复有初级水平的了解，并开始进行备份。