不知何故，它的最小大小为 32GB。
实际的数据库大小约为 2GB。
每天从外部数据源擦除和重新创建数据库，因此根本不需要任何日志，因为它每次都是从头开始重建。
也就是说，我想缩小 LDF 文件，因为它在我的开发机器的 SSD 上占用了大量空间，而且它不需要是数据库本身大小的 16 倍。
我发现我无法将日志缩小到其最小大小 32gb 以下，因此我需要更改最小大小。如果我转到数据库上的属性，我可以更改它，但是当我按 OK 时什么也没有发生。
除了编写数据库脚本以创建并删除它并使用较小的 LDF 重新制作它之外，是否还有其他命令或技术可以用来执行此操作？
@AaronBertrand 是对的，您可能应该在创建阶段更改您的流程来处理它，但我想我会讨论为什么您在收缩时遇到问题。
首先确认您的数据库处于简单恢复模式。根据您所说的，您不需要日志备份，因为数据库每天都从外部源重新加载。
这将使您缩小日志文件。通常这不是推荐的，因为如果日志文件增长到给定的大小可能是有原因的，并且它可能会再次增长，从而导致您出现一系列不同的问题。不过，在您的情况下，您正在从外部源加载并且您的日志文件可能（是否？）不需要它的大小。在这种情况下，将日志文件缩小到“初始”大小所需的大小。
将文件缩小到所需大小后，您现在可以更改属性以使其初始大小更小。当日志文件大于您尝试设置的大小时，您无法执行此操作。这就是您收到错误“指定的大小小于或等于当前大小”的原因。
当然，如果您的加载方法是从另一个 SQL Server 还原，那么这些都无济于事。还原过程将强制 mdf 和 ldf 文件的大小与备份版本相同。那时，您必须将上述步骤添加到过程的末尾，以在每次还原后缩小日志文件。
最后但并非最不重要的是，如果您使用某些 ETL 工具加载数据，则加载本身可能会导致日志大小增加。如果是这种情况，那么您的日志将在您加载后重新增长，您将不得不执行上述步骤以再次将其缩小。但是，这会在一定程度上增加您的加载时间，因为日志文件在每次加载期间都必须重新增长。