fre*_*ler 7 sql-server shrink transaction-log sql-server-2014 recovery-model
标准免责声明：我是一个“非自愿DBA”（在一个不错的那句我看到这篇文章），也做了很多和很多和大量的和大量的和大量的阅读关于这个问题，但我仍然困惑/关注...
我需要将几个 SQL Server 2014 生产数据库的恢复模型从完整更改为简单。
数据库目前设置为完全恢复，并且正在使用SqlBackupAndFTP进行备份，这将每天进行一次完整备份，每天进行 3 个差异备份和 20 个事务备份。这一直运行良好，直到我们与提供基于 FTP 的存储的公司发生了巨大的问题。
大约 3 个月前，我改用运行良好的Attix5 - 但是，我现在发现由于软件的工作方式，事务日志与数据文件一样大（在一种情况下，对于 13Gb 数据文件超过 14Gb ）。
我被建议将恢复模式切换为简单，这样事务日志就不会增长。
我知道使用 Simple Recovery 不会提供时间点恢复- 这绝对没问题，因为完整备份每小时进行一次，我们“很高兴丢失”之前 1-59 分钟内可能发生的任何事情。
我的理解是我应该将恢复模式设置为简单并让备份发生，这将在事务日志中设置一个检查点，允许重新使用空间。
但是，我确实需要将事务日志缩小到合理的大小（这样它就不会占用太多的备份空间），但我一直在读到缩小是一个坏主意。还是我拿错了棍子的一端？
如果我使用以下命令将事务日志缩小到大约 25Mb（对于单个每小时的事务集来说应该足够大），这是否足够？
DBCC SHRINKFILE('log file name',25)
（我真的很抱歉问一些之前似乎被问过无数次的问题，但这不是我可以出错的。）
小智 6
首先我想再次指出，在大多数情况下，不建议对生产数据库进行简单恢复。但是，如果这是您希望更改的最佳方式，我发现在您将数据库放入 SIMPLE 恢复模型后，缩小 LOG 文件的最佳方法如下。这不仅可以实现从日志中释放可用空间，还可以将文件缩小到尽可能小的大小。
正如您所说，缩小通常也不是一个好习惯，但有时它是必要的。有很多关于它的赞成/反对的文章，我同意那些会告诉你永远不要使用DBCC SHRINKDATABASE;总是使用DBCC SHRINKFILE如果你绝对必须做一个收缩。
但是，日志文件确实必须具有合理的大小，即使在 SIMPLE 恢复模型中也是如此，因为这是在事务期间保存信息的地方，并且长时间运行的 SPID 需要更多的日志文件。在众多原因中，其中之一是在出现问题时回滚。正如我上面所说，这些脚本会将您的日志文件减少到其绝对最小的大小，但是因为您至少需要一些日志空间，您应该通过手动重新增长来跟进，并确保您的“自动增长”设置为合理数字; 可以说，总是要避免百分比。将日志缩小到最小大小并手动重新增长它完成了一个非常重要的过程——保持你的 VLF 碎片/计数减少。这是我不会在这里讨论的另一个话题，包括 Brent Ozar 在内的许多站点都可以进行实际统计和测试来说明原因，但如果需要那么大或更大，请始终将日志文件每次增长 8 GB。您在上面提到了 25 MB，我无法想象它足够大。目前我个人管理着一百多个数据库，只有不到 12 个被设置为 64 MB - 所有其他数据库都更大，最高可达 64 GB。您的实际 SQL 活动和查询将决定您的最佳大小应该是多少。至少我会从 512 MB 到 2 GB 并将您的增长设置为相同，直到您知道您的日志文件应该放在什么位置。目前我个人管理着一百多个数据库，只有不到 12 个被设置为 64 MB - 所有其他数据库都更大，最高可达 64 GB。您的实际 SQL 活动和查询将决定您的最佳大小应该是多少。至少我会从 512 MB 到 2 GB 并将您的增长设置为相同，直到您知道您的日志文件应该放在什么位置。目前我个人管理着一百多个数据库，只有不到 12 个被设置为 64 MB - 所有其他数据库都更大，最高可达 64 GB。您的实际 SQL 活动和查询将决定您的最佳大小应该是多少。至少我会从 512 MB 到 2 GB 并将您的增长设置为相同，直到您知道您的日志文件应该放在什么位置。
我发现单独运行每条线路效果最好，确保在进入下一步之前成功。当然，最后一行是将您的日志重新增长到您设置的大小。我有 8 GB，但您可以更改它以满足您的需要。如果您此时不想完全缩小然后重新生长，请删除最后一行并将上面行中的“1”更改为您选择的尺寸。
在你出去缩小你的日志文件之前的最后一件事。
重要提示： 任何时候日志文件通过 SQL 手动或自动增长，基本上整个数据库都会被锁定，直到增长完成。选择一个不会影响活动交易的好时机 - 如果您有“下班后”或维护窗口。如此小的 1 GB 或更少的大小应该相当快并且对最终用户不可见，但这将真正由您的基础架构决定。
USE [DatabaseName]
DBCC SHRINKFILE (N'LogicalName', 0, TRUNCATEONLY)
DBCC SHRINKFILE (N'LogicalName', 1)
ALTER DATABASE [DatabaseName] MODIFY FILE ( NAME = N'LogicalName', SIZE = 8192 MB )