由于事务日志大小，我的数据库自动增长出现了一些问题。我已经实施了一个数据库维护程序，其中事务日志将定期截断，因此这种情况应该不会再发生，但我需要在数据库进入自动增长状态时通知用户。它确实记录在我的数据库日志中，但我需要找到在屏幕上直观显示某些内容的方法。这个特定的系统有一个应用程序和一个本地数据库，它们都驻留在用户的机器上，因此在数据库所在的屏幕上弹出某种弹出窗口是理想的选择。有什么想法可以实现这一点吗？
更新说明：我宁愿不使用任何第三方软件。操作系统是 Windows Server 2003，我使用的是 MS SQL Server 2005。
更新：新的潜在解决方案是，由于事务日志永远不应达到需要自动增长的状态，因此我可能能够完全禁用自动增长。不过，为了让这样做更轻松，我想知道如果需要自动增长但被禁用会发生什么？在这种情况下，旧的事务日志会被覆盖吗？
答案1
回复您的评论：
@HopelessNoob 问题是，如果它需要增长，那么我希望它能够增长。我该怎么做才能不影响性能？在自动增长期间，整个数据库都会锁定，没有办法改变这种情况，对吗？部分问题是系统每天运行 24 小时，所以我不可能一夜之间就让数据库增长。问题是，我可以尽我所能确保自动增长不会发生，但我仍然被要求在自动增长发生时通知用户，所以我必须满足该要求。
和：
@hot2use 我如何设置自动增长以使其不会影响系统？我的印象是，在这种状态下整个数据库都会锁定，而且没有办法解决这个问题。您说得对，我确实在日志中看到了 5144。这不是常见的事情，但它是一个非常关键的系统，我需要避免自动增长，如果发生这种情况，请确保用户不要重置系统，因为这会导致数据丢失。
您可以减少自动增长对 mdf 的性能影响 - 进入本地安全策略并添加perform volume maintenance tasks- 但这不适用于 ldf 的增长。（这称为“即时文件初始化”。
我建议你尝试手动“预调整”数据库的大小，这样就不会发生自动增长。保留它，以防你猜错了，但不要缩小事务日志。还要定期执行日志备份，并可能为日志文件添加一些空间。（但不要太过分。例如，如果在 4GB 日志文件的高负载下自动增长频繁发生，请将其预调整为 10GB 并更频繁地备份日志，看看是否有帮助。）
另外，请查看您的自动增长设置。如果数据库非常大，按固定量增长可能比按百分比增长更能获得更好的性能。（再次强调，不要太疯狂。按 MB 增长对任何人都没有好处。我只是说，如果数据库是 2TB，而您按 10% 自动增长，那可能需要一段时间。）
除此之外，Steve Mangiameli 还说了其他话。
至于通知用户，如果您已经在允许脚本执行的服务器上运行任何类型的监控，您可能能够编写一些检查文件大小的程序。（这是个笨拙的办法，但它会按照用户的要求去做。）
根据您的编辑进行了编辑：
更新：新的潜在解决方案是，由于事务日志永远不应达到需要自动增长的状态，因此我可能能够完全禁用自动增长。不过，为了让这样做更轻松，我想知道如果需要自动增长但被禁用会发生什么？在这种情况下，旧的事务日志会被覆盖吗？
不可以。交易将会失败。
答案2
您要做的事情很糟糕。您很少会截断日志，如果有的话。日志增长是正常的。如果您遇到意外的大量日志增长，则说明您遇到了代码或用户问题。如果您处于简单模式并且不需要事务备份，只需安排定期的夜间备份，日志就会被重用。如果您处于完整恢复状态，请安排定期的事务日志备份和夜间完整备份，这样就可以解决问题。
用这种方式管理日志比定期截断日志要好得多。
答案3
我认为@Katherine Villyard 总结得很好。
您可以从现有数据库中做出一些假设。让数据库的事务日志大小保持原样（或在该异常事务期间变得尽可能大），并确保在数据库设置中关闭“Auto_shrink”选项。
布拉德利：
当设置为 ON 时，数据库文件将定期收缩。SQL Server 可以自动收缩数据文件和日志文件。AUTO_SHRINK 仅在数据库设置为 SIMPLE 恢复模式或备份日志时才会减小事务日志的大小。
当设置为 OFF 时，在定期检查未使用空间时数据库文件不会自动收缩。
这是我发现的一篇文章自动收缩——关闭它！以及同一篇文章SQL Server 数据库引擎博客
您必须跟踪数据库的事务日志使用情况以及导致数据库的 tlog 增长并相应调整其大小的事件。