活动报告显示 490 条记录,但存储使用情况报告显示 763,000 条记录

发布于 2025-01-16 22:09:59 字数 143 浏览 2 评论 0 原文

我们正在尝试通过减少与非活动用户相关的任务和事件来释放存储使用量。存储使用情况报告中仅存在 490 个活动,我们看到超过 763,000 条事件记录,大小为 1.5GB。问题是,是什么造成了 1.5GB 的事件以及在哪里可以找到它们,以便我可以删除不需要的记录以释放空间?

We are trying to free Storage Usage by reducing Tasks and Events related to inactive users. Only 490 Activities are present still in the Storage Usage report we see over 763,000 records of Events which is 1.5GB. Question is, what is contributing to 1.5GB of Events and where to find them so that I can remove unwanted records to free space?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

葵雨 2025-01-23 22:09:59

您可能是“已存档的受害者活动”。

您可以像在回收站中一样查询它们:

  • 通过 API(包括开发人员控制台的查询编辑器和工作台),您通常会勾选“包含已删除的记录”或其他内容,因为它是一个 query() 与 queryAll(),不同的 API
  • 调用Apex 您可以输入 所有行< /code> 在查询末尾。

进行快速而肮脏的检查,例如 System.debug([SELECT COUNT() FROM Task LIMIT 50000所有行]); 看看会发生什么?

You might be a victim of "archived activities".

You can query them as if they're in Recycle Bin:

  • via API (including developer console's query editor and Workbench) you typically tick "include deleted records" or something because it's a query() vs queryAll(), different API call
  • in Apex you can put ALL ROWS at the end of the query.

"workbench" utility with selected option to include deleted/archived records

Do a quick and dirty check like System.debug([SELECT COUNT() FROM Task LIMIT 50000 ALL ROWS]); and see what happens?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文