相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

我是一家大公司的 JR DBA。我是 6 个月前被聘用的，我学东西的速度非常快（我是这里唯一的 DBA）。

老 DBA 将服务器和 SQL Server 实例留给我处理。

这是一个非常棒的结构（集群等）。

但是，他使用脚本和大量编程来进行备份、清理任务和所有其他 DBA 任务。一切都很好。我在这里和那里修复了一些东西，但一切都非常好。

我正在自己学习 SQL Server，并且正在阅读有关MAINTENANCE PLAN.

使用它是一个不错的选择吗？如果我被新公司录用，使用维护计划是一个不错的选择（对我来说，看起来太“简单”了，不想看起来像一个糟糕的 DBA）。

谢谢。

（作为补充，他使用脚本将数据库名称放在一个表上，然后他使用脚本查找该表并将其用于作业。我可以通过一个简单的维护计划来做到这一点。但他是一名高级 DBA。他告诉我他喜欢它，使用维护计划不是问题。我只是想要一些意见）

最好不要对自动增长设置使用百分比文件增长吗？

以下建议对 500GB 以下的数据库使用百分比值增长，但是否建议这样做？

http://performance-expert.blogspot.ie/2012/06/tuning-autogrow-settings-of-sql-server.html

如果磁盘空间有限或无法调整数据库大小，则应将 >autogrowth 值配置为固定百分比。例如，对于 500 GB 以下的数据库，将自动增长值配置为 >10%，如果数据库超过 500 GB，则配置为固定的兆字节数。

谢谢！

更新：下面我在一些数据库上添加了 Autogrowth 的快照。对此有什么建议吗？

还有什么是预测数据库大小的最佳方法？

我们正面临日志驱动器 ( E :) 经常被填满的问题。

我们的 DBMS 是设置了 AOAG 的 SQL Server 2014 SP1。

我们有每周维护任务：

1. 重建索引（运行接近 1 小时）
2. 更新统计信息（运行 Cloe 到 30 分钟）
3. 检查数据库运行接近 30 分钟
4. 完整备份运行接近 4 小时
5. 差速运行接近 2 小时

我们没有看到任何繁重的事务处理。

但是我们可以看到E:被填满了。

以下是自动增长设置：

• 10% 无限增长。

注意：由于这是 AOAG 环境，我们每 30 分钟安排一次事务日志备份。

我的问题：

• 在这种情况下，是什么让E:被填满了？

• 为什么我的日志没有被截断？

• 在这种情况下，我们需要扩展 E: 吗？

• 截断我的日志的行动计划应该是什么？

截至目前，在我们决定下一个扩展驱动器的计划之前，我们不时缩小文件以释放空间。

请建议。