如何阻止 Kentico 事件日志变得庞大？答案

【问题标题】：How to stop Kentico Event Log from getting huge?如何阻止 Kentico 事件日志变得庞大？
【发布时间】：2019-03-13 15:50:04
【问题描述】：

刚刚检查了我的 Kentico 数据库（Azure 托管），它膨胀到了 21GB。这发生在最近，因为 4 个月前它刚刚超过 1GB。

检查了表格，我的事件日志表有超过 2,000,000 个条目！！！

最近没什么变化，我在设置->系统->事件日志下的设置还是一样的：

事件日志大小：1000

由于全局变量也设置为 1000，通常我在事件日志表中有 2000 个左右的条目。

有人知道这里发生了什么吗？以及如何阻止它发生？

【问题讨论】：

【解决方案1】：

如果您启用了在线营销并拥有一个受欢迎的网站，那么 OM_ 表中将会有大量数据。但是 20GB 听起来还是很大，是否有很多资产文件被添加到内容树中，比如视频？另外，数据库是否设置为记录所有事务？什么样的日志文件比较流行？错误或信息日志？您是否有一些可以生成大量日志的自定义代码？

您还可以通过电子邮件向 Kentico 支持人员发送“检查大表”SQL 脚本，该脚本可以帮助您找出哪些是大表。

【讨论】：

Rui，不是那样的，视频和所有媒体都存储在文件系统中。除了我们升级到 Kentico 12 之外，最近没有什么真正改变。而且由于日志很大，我什至无法通过 Kentico 访问它们——它超时了。我们还有一个包含完全相同数据的临时站点 - 数据库只有 1.5GB。
我的问题是为什么事件日志这么大？我认为 Kentico 应该只保留 2000 条左右最新的日志条目？为什么要保留 2,000,000 个？
升级前是否有数据库副本？那里有多少事件日志？升级过程中是否发生了一些事情，日志刚刚跳到一个巨大的数字，现在删除旧日志的任务很难处理数据（例如超时），所以日志一直在增长？
瑞，升级过程中没有发生任何异常。升级后（2018 年 12 月 21 日），EventLog 有 2132 个事件。我的下一次备份是在升级后大约一个半月（2019 年 2 月 11 日）EventLog 有 2075 条记录。现在（2019 年 3 月 13 日），超过 200 万。所以最近他们似乎并没有因为某种原因被删除。
我可以直接进入 Azure 中的查询编辑器并删除记录或截断 dbo.CMS_EventLog 表吗？我假设这不会以任何方式搞砸 Kentico？

【解决方案2】：

您还应该研究其他一些领域。从 Kentico 的角度来看，拥有 2MM 事件日志记录不会导致数据库大小增加 20GB，因为事件日志是非常少的数据。

查看分析、版本历史记录、电子邮件队列、网络场和计划任务表。还要检查回收站。您是否正在与任何其他系统集成或通过 API 插入/更新大量数据？如果是这样，这可能会导致大量事务日志文件堆积。使用 Azure SQL，我不知道有什么方法可以清理它们。

我的建议是检查其他表，而不仅仅是事件日志。也许通过 SSMS 手动查询事件日志并查看前 100 个事件是什么，这可能会帮助您找到问题。如果需要，您也可以通过 UI 或使用 SSMS 手动截断表来清除日志。

【讨论】：

好吧，我将数据库导入本地机器，当我用 SSMS 检查 CMS_EventLog 表时，它告诉我这张表的数据空间是 20,773.461 MB - 所以看起来这张表确实增加了数据库大小约为 20GB。我知道我可以清除它，但首先为什么会发生这种情况以及如何发生以及如何阻止它再次发生？
正如我之前提到的，Kentico 应该清除旧记录并保留最多 2000 条记录，而不是 200 万条。
我会深入研究事件日志并查看其中的错误/事件。如果由于大小而无法处理事件日志以将其清除，它将失败并继续向其添加记录。因此，Kentico 方面的处理是一个问题，因为记录太多且没有足够的马力来处理它。
我可以直接进入 Azure 中的查询编辑器并删除记录或截断 dbo.CMS_EventLog 表吗？我假设这不会以任何方式弄乱 Kentico？
我从未在 Azure 中使用过查询编辑器，因此无法评价它的性能。但是，是的，您可以截断表格而不会对“搞砸 Kentico”产生任何负面影响。