这个旧的 SQL Server 2000 实例有一个 14Gb 的数据磁盘和一个 30Gb 的备份磁盘。
尽管它很旧，但仍有大量用户在进行交易，因此该服务器上唯一数据库的日志文件每天都会填满数据驱动器。
我想我会把它放在简单的恢复中并刷新事务日志，但我想知道它会产生什么影响。
没有 T 日志，您不能使用备份恢复到完整备份时间以外的任何其他时间点，对吗？在对数据库进行此类更改时，我应该注意除此之外最重要的影响是什么？当我不生成 t-logs 时，除了丢失一天的数据（它每天备份到磁带）之外还有什么可能发生？
提前致谢
首先是关于转向
SIMPLE恢复的快速说明。这是一个商业决策。这绝不是一个技术决定。您的企业需要权衡保留成本FULL（这可能意味着具有额外空间的新服务器、归档当前数据以释放一些空间等）与丢失一天或更多数据的成本。一旦他们决定了，你就可以继续了。根据您的问题和评论，我看到了两种情况之一：
您处于
FULL恢复模式但未进行日志备份。此时您需要开始定期进行日志备份。这很可能实际上会为您节省空间。如果您每天进行日志备份以清除日志少于一次（注意：
FULL备份不会释放日志空间），那么您的事务日志可能比需要的要大。整理好备份，然后计算出您的事务日志实际需要多大。很可能它会比当前为您提供额外的备份空间小很多。最坏的情况是比现在更频繁地将备份移动到磁带上。您处于
FULL恢复模式但正在进行日志备份。如果是这种情况，那么您可能需要增加日志备份的频率。这不会产生额外的空间需求，因为日志文件会更小（标题信息有一些小的开销，但并不那么重要）。这将使您的日志更快地清除并保持更小。 假设（这是一个很大的假设）您没有一个或多个需要日志空间的单独事务。如果是这种情况，那么仅更改代码以减小事务的大小就可以让您获得较小的日志文件。即使你切换到
SIMPLE恢复您仍然需要最大的单个事务（或最大的同时事务组合）的日志空间。如果您缩小日志文件并运行需要比可用空间更多空间的事务，它只会再次增加日志。FULL再次在恢复和恢复之间切换SIMPLE是一项业务决策。在没有咨询业务的情况下做出这种决定（然后是错误的）是让自己被解雇的好方法。你是对的，你不能恢复一个数据库，它有一个超过上次完整备份的简单恢复模型。此外，您指出了您应该在完整恢复模式下拥有该数据库的原因：“它仍然有大量用户在进行交易，因此该服务器上唯一数据库的日志文件每天都会填满数据驱动器。” 您真的想丢失大量用户依赖的数据吗？
不。
每小时尝试备份一次事务日志（如果您有足够的空间，则备份 15 分钟）并将 .trn 文件保存在备份驱动器上。如果您每天进行完整备份，请设置清理任务以每隔几天删除 .trn 文件。问题解决了。
这是您应该保持完整恢复模式的另一个原因：假设一名新员工在下午 12:35 将 critical_table 删除到数据库中，并且使用该数据库的应用程序出现故障。您可以在此处进行事务日志备份，将完整备份还原到新数据库**，然后在中午 12:34 的停止时间还原 .trn 并恢复数据！
**如果上次完整备份和您刚刚创建的 tlog 备份之间的日志链断开，您将被砍掉，所以在您确定可以一起恢复之前不要恢复旧数据库。