我目前不得不处理失控的 SQL Server 事务日志。免责声明：我不是 dba，这不是我的专业领域，所以请耐心等待。
目前，我有一个500MB 的数据库的115GB事务日志文件，该文件（显然）在一段时间内管理不善，无法进入这种状态。
首要任务是在我们用完之前回收这个文件占用的磁盘空间！有人告诉我增加驱动器的大小不是一种选择，即使是暂时的，而且根据过去的增长，我们需要尽快采取行动。
据我了解，最好的方法是将数据库保持在完全恢复模式，但定期备份日志文件，在一段时间内对其进行监控并调整初始大小和增量以适应。一切都好。
鉴于我们在午夜定期进行完整的数据库备份，我是否可以安全地将数据库暂时置于简单恢复模式（在这些备份之一运行后），缩小日志文件以回收（几乎所有）空间和然后使用上述备份策略将其放回完全恢复？
我的想法是，如果这个时候发生了什么事情，我们可以简单地恢复完整备份而不使用日志。
更新
回复一些答案和评论的一些额外细节：
我们确实希望保留进行时间点还原的能力，因此数据库应保持在完全恢复模式。
t-log 文件变得如此大的原因是它从未被备份过。验证为 log_reuse_wait_desc 返回“LOG_BACKUP”。