数据库像疯了一样增长 - 我该怎么办？

Question

我有一个 Epicor 9 ERP 数据库，我最近负责（新工作）。服务器正在运行带有 SQL Server 2008 R2 64 位的 Server 2008 R2。主要生产数据库在 7 个月前（上线）从 16GB 开始，并稳步增长到 80GB+。他们确实安排了一项维护工作，在每个星期天晚上缩小所有数据库，限制为 50 MB，可用空间为 10%。

按照目前的增长速度，服务器的驱动器空间将在不到 90 天的时间内达到最大值，我将被迫升级服务器或将数据库移至 SAN。整体系统性能很差，系统很慢。

当我运行“顶级表的磁盘使用情况”报告时，我看到以下内容：

• 记录数：115,117,737
• 保留 (KB)：83,609,584
• 数据 (KB)：81,867,248
• 索引 (KB)：52,263,296
• 未使用 (KB) 1,742,336

我正在等待 Epicor 关于适当照顾和喂养他们的系统的回音，但索引似乎使用了大量的空间。如前所述，我最近才接管了这个系统，我正在努力尽快弄清楚。

任何帮助，将不胜感激。

编辑：警告任何阅读本文的人。删除了重复索引，如这里的答案中所述，由测试 Epicor 9 数据库完成。E9 显然以非标准方式使用索引。它有一个 Progress 层，用于优化 Progress 和 4GL（又名 ABL）代码的索引。我不能肯定地说这是导致问题的原因，但它似乎是最有可能的罪魁祸首。尝试登录 E9 测试会出现“需要运行 SQL 脚本”错误，并且数据库似乎卡在 ALTER 状态。

Answer 1

查看Kimberly Tripp 撰写的这篇博客删除重复索引并使用脚本检查您是否有完全冗余/重复的索引

Answer 2

If the indexes are growing like crazy, my gut feeling tells me that it is some bad or unnecessary indexes that are killing the disk space here.

I work with DB2 (as opposed to SQLServer) but I believe the concepts should be the same.

In our case we look to see what the index cardinality is. In other words, how many unique values are there per the columns in the index? The more unique values you have the better. If you have an index over a status field that only has two or three values and you have millions of records, the index has to be continually rebuilt. Kill those indexes as those will take lots of disk space, plus kill performance of your apps when doing INSERTs or UPDATEs.

Also check for redundant indexes (ie the same columns are used over and over again in different indexes). I can't speak for SQLServer, but at least in DB2, redundant indexes are worthless and just chew up disk space. DB2's Query Optimizer will only use one of the indexes and disregard the rest.

再次......我来自不同的产品，但我相信思维模式是相同的。分析索引和它们使用的数据，看看哪些是真正需要的。删除一些索引可能会为您节省不少。