问Server 2016:由于事务日志庞大，无法从.bak文件恢复数据库？

EN

备份数据库时，它会从数据库和事务日志中获取恢复后将数据库置于一致状态所需的所有数据。

当您从备份还原数据库时，它会准确地创建被备份的数据库，所以如果您现在有一个300 on的日志文件，那么它意味着生产服务器上的原始数据库有一个300 on的日志文件。

是的，您现在可以在测试服务器上shrink日志文件，但是首先您应该将数据库放在SIMPLE RECOVERY MODEL中。这不会影响您的生产数据库。

但是，如果您的备份大小仅为145 it，这意味着您的生产数据库有一个问题:有人将其放入FULL RECOVERY MODEL中，而不进行日志备份。从数据库大小可以清楚地看出:当日志文件大于数据文件的300倍时，就会出现错误的恢复模式问题

下面是检查数据库大小的代码：

use yourDB;
select name, type_desc, cast(size * 8. / 1024 as decimal(20,2)) as Mb
from sys.database_files;

更新

...to每天晚上都会设置一个维护计划，这样它就可以对DB进行完整的备份，重新组织/更新索引，并且，每周更新一次statistics.Up，到现在为止，一个夜间备份就足够了。..。无论如何，我应该保留事务日志和完整的恢复模型吗?我应该知道什么才能改进呢？我的意思是，如果我想进行日志备份以减少事务日志，我该怎么办？我应该改变维修计划中的任何设置吗？

你不需要完全恢复模式。现在，您的备份计划假设损失1天的工作对您来说是可以接受的，对于一个小型非关键数据库来说，这是正常的。

当您在simple recovery model中时，最小日志记录的操作(如index rebuild或select into )将被最少地记录，这意味着它们会更快。

如果您需要还原您的数据库，这将是一个简单的还原从一个完整的备份。

您的日志管理将是最小的:它将在检查点上被自动截断。

当您在full recovery model中时，意味着对数据的每一项更改都将被完全记录下来，所有这些更改都将保留在日志文件中，直到您进行日志备份为止。因此，现在发生的情况是，日志文件包含了从第一次完全备份(因为没有进行日志备份)到现在对数据库所做的所有更改。

如果现在备份日志，则在300 of的日志空间为零时，等待的时间将远远超过今天的等待时间。要备份这个日志，您需要足够的磁盘空间，大约300 up。备份完成后，即使尝试缩小日志，日志大小也不会改变，因为日志的活动部分将驻留在最后一个VLF中。

因此，如果您决定坚持完整的恢复模式，即使在进行了这个庞大的日志备份之后，您的日志大小仍然会出现问题。您必须等到日志的活动部分移动到第一个VLF，它可能需要一些时间，因为您的数据库足够小，变化也很小，但您的上一个VLFs是巨大的。在收缩之后，您必须决定多长时间进行日志备份，以及数据库的适当日志文件大小。

那么，谁以及为什么选择完全恢复模式呢？一些HA技术需要它:日志传送、镜像、AOAG。或者是不能允许数据丢失的人。例如，如果您的数据文件今天丢失了，您可以将日志备份(300 by )的尾部恢复到数据库生命的最后一分钟，方法是先还原最后一个晚上的完整备份，然后恢复日志备份。如果没有它，您所能做的就是从昨天的备份中恢复数据库，即恢复的数据库将包含昨天状态下的数据，所有今天的工作都丢失了。

他们在评论中说了些什么？时间点恢复。完全恢复模型允许您将数据库恢复到过去的任何时间点(当然，只有在日志备份链没有损坏的情况下才能恢复数据库)。你真的需要它吗？当你被告知要把你的数据库带到2017-01-04 :45:00时，会不会是一种情况？或者你可以把它带回到2017-01-04 : 00:00:00，你的全部备份时间？如果只是后者，那么您就可以保持简单的恢复模型，并在每天晚上00:00继续备份数据库。

我只是不知道如何在一页中加入值得一本书的材料:)试着从BOL：恢复模型与事务日志管理开始