背景：
我最近继承了450多个数据库中的50多个SQL Server。每晚备份大约为8TB，不用说，我们使用的磁盘空间比我们想要的要多。所有数据库均设置为“完全恢复”，并且从未备份过事务日志。我已经遍历了所有SQL Server，并确定了低优先级的服务器，这些服务器仅需要每晚进行备份并且可以接受一天的数据丢失。
题：
我将许多低优先级数据库SIMPLE从切换到恢复模式FULL。现有事务日志会被截断吗（创建检查点时）？一些现有的事务日志为50-100GB；为了继续前进，确定我应该缩小到什么范围的最佳方法是什么？我显然不想让它们那么大。还是随着时间的推移它们会自行收缩（我不认为会收缩）？
Answers:
在从恢复模式切换FULL到SIMPLE恢复模式之前，请先问自己可以承受多少数据丢失。对于在发生灾难的情况下可以恢复上一次数据库备份的数据库，SIMPLE应该可以。如果不是这种情况，请继续使用FULL。
要将LDF文件缩小到尽可能小的大小，请按照Kimberly Tripp此处给出的步骤进行操作：改善事务日志吞吐量的8个步骤
等待数据库活动少的时间
在SSMS中运行：
DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)修改事务日志文件的大小：
ALTER DATABASE db_name
MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)
我将许多数据库从“完全”恢复模式切换到“简单”恢复模式（不需要T日志和时间点恢复）。现有的事务日志会被截断吗（创建检查点时）？
在简单恢复模型中，数据库引擎将发出自动检查点，其频率由恢复间隔（高级服务器配置设置）或日志已满70％确定。
除非发生一些长时间运行的事务，这将延迟日志截断，否则自动检查点将截断T日志的未使用部分。
现有的某些事务日志为50-100GB，这是确定我将其缩减到什么以便进行下一步工作的最佳方法是什么。我显然不想让它们那么大。
如果您将具有50-100GB T日志的数据库的数据库恢复模型设置为FULL，则必须开始进行频繁的T日志备份。请记住，在完全恢复模式下，一旦建立了日志备份链，即使自动检查点也不会导致日志截断。
作为最后的选择，您可以截断日志文件，然后立即进行完整备份，然后开始进行T日志备份，以便在发生灾难时可以进行时间点恢复。
还是随着时间的流逝它们会自行收缩（我不认为会收缩）？
正如@TomTom指出的那样，它是手动操作。
阅读：
我们无法回答许多问题。一段绳子有多长？
现有的某些事务日志为50-100GB，这是确定我将其缩减到什么以便进行下一步工作的最佳方法是什么。
只要他们需要。我建议不要缩水。截断原木，一周后再回来查看所用空间，然后决定。但是您必须回答这一问题。
每晚备份大约为8TB，不用说，我们使用的磁盘空间比我们想要的更多。
那么为什么将它们简化呢？我的意思是，认真。
所有数据库均设置为“完全恢复”，并且从未备份过事务日志。
有点逻辑会告诉您igf一次截断它们，那么无论如何您都将使用较少的空间来备份它们。结果可能是您可以使它们完全处于完全恢复模式。首先尝试一下。如果它们的反弹是低交易量等，那么将来的日志备份可能会很多。
我已经遍历了所有的SQL Server，并确定了低优先级的服务器，这些服务器仅需要每晚进行备份，即使在发生灾难的情况下，也可以损失几天的数据丢失（传真数据库之类的东西）。
是。那是直到您最终出庭并因没有重要的法律文件而蒙混过关。您是否知道传真日志很可能是您保留与业务相关的信息多年的一部分？就像在我的管辖权（10年）中那样。如果您是U股公司，可能会有类似的惊喜（SOX）。否则，如果您想证明自己没有收到传真，那么法庭上的情况将非常糟糕。或确实发送了一个。没有人关心这是否每月发生一次，并且您有更多的近期日志-您未通过法律要求。确保已由非常高的人签名，因为您的业务不重要可能是您解雇的原因。
还是随着时间的流逝它们会自行收缩（我不认为会收缩）？
不，他们不应该那样做。日志大小调整是手动操作，但低容量数据库除外。