糟糕的内部数据库 – 更换它或夹头硬件？

我不同意这里的每个人。 查看一些硬件。 它便宜，快速，简单，并且会为您提供实施合适的CRM解决scheme所需的时间。 我所提倡的东西不仅仅是这个板子上的每一个人，而且还有一个叠加的东西，这个原因是我曾经是一个项目经理/经理，并且一直在“业务”方面一段时间（业务由于我对这个词的仇恨而引用）。 根据你对软件的描述，这将需要接近一年的时间来重build别的东西。 只是发现/logging业务规则/怪癖，可能需要2个月。 发展也将是令人难以置信的昂贵。 特别是与欺骗性服务器的成本相比。

我实际上就是为了这个原因而为一家公司托pipe一组web应用程序。 内部IT部门不会将其转移到更好的硬件上，因为他们希望在新的平台上重新开发它们。 这个成本大约是将其转移到新硬件的成本的三倍。 不要提到公司可能没有在一年内续约。

你可能不需要做。 我的build议是简单地添加一些索引/键到表中。

成千上万行没有主键或索引的表，也在多表连接中大量使用

在花费大量金钱或时间之前，花几个小时将索引（或主键，如果可以的话）添加到涉及这些连接的任何表中，特别是对where子句中使用的列。 在短短几个小时内，您可以轻松地将性能提高10倍。

磁盘I / O的缺乏意味着查询主要是从RAM中提取的。 如果你突然有热表不再适合内存，并且服务器开始工作磁盘，你可能会遇到不好的事情。 2GB或者RAM现在不是很多，但是回到SQL2000时代，它将会是相当大的。 我猜测应用程序通常操作的数据量比你拥有的RAM小。 您可能需要查看数据文件中“已用”空间的数量。 这会让你知道数据库可能消耗多less内存，最坏的情况。 SQL Server不保留RAM中不需要的数据，但可能很难知道使用哪些表以及何时使用。

超线程并不总是对SQL Server有帮助。 closures它可能会获得更好的性能。 这很难testing，因为它需要重新启动，这是生产服务器上的一大麻烦。

“每分钟有数十万次的查询”转换为每秒数千次的查询。 这听起来很繁忙，但大部分stream量可能只是由光标提取访问。 访问对从SQL有效地检索结果集尤其不利。 通过closuresSQL Server并行设置，您可能会获得更好的性能。

你也想看看阻塞。 投掷硬件遇到阻塞问题并不总是产生希望的戏剧性改善。 如果没有太多的阻塞和查询是由RAM满意的，而不是磁盘，你基本上是依靠处理器的咕噜声，以及它们在内存通道中提取数据的能力。 在那种情况下，更快的硬件应该提供一个很好的改进。 如果你匆匆（为了解决这个问题）慢慢地增长，那可能就足够了。

作为一种解决scheme，添加硬件并不能像数据库一样进行扩展。 如果您的增长激增，您可能会发现您的新硬件挣扎。 另一个想法是成功的应用程序吸引用户。 如果应用程序响应速度更快，那么用户可能会比等待报告完成时需要喝咖啡的情况下运行更多的报告。

如果数据库模式非常糟糕，只需查看表上的索引，就可以获得一些性能优势。 专注于你知道经常被查询的表格。 您可以使用Profiler来查看针对服务器运行的查询，只是告诉它查找读取大量数据（如100,000页）的查询，然后查询不太多的查询。 你提到一些表没有键。 数据中是否有自然键，而不是由约束或唯一索引强制执行？

表中是否有聚簇索引？ 缺乏聚集索引可能会导致各种次要影响。

有很多非聚集索引，有很多列吗？ 这往往是build立许多覆盖索引的尝试，而不是实施更有效的索引策略。 SQL Server可以在查询期间快速构build覆盖索引，如果这样做是有意义的，并且支持非聚簇索引和聚簇索引。

最后，值得一提的是：维护（重build索引和/或更新统计）是否在表上完成？

这是一个商业问题而不是技术问题。

作为企业主：这个系统对企业有多大的战略意义？ 战略越less，我关心和修复它花费的钱就越less，我可以在其他地方用来发展我的业务。

电脑民间吓到我，因为他们都进入一个大房间，争论有关devise，花了我一大笔钱。 保持系统运行！ 这是否意味着性能调整（无需重新devise）或投入更多的硬件，如果停止工作，这只是一个优先事项。

作为一名IT顾问：您的系统是遗留问题，隐藏了运营成本。 我们可以devise一个适合您的系统，这个系统可以扩展并为未来的发展和战略优势提供一个平台。 在这里签字，你所有的梦想将成真。

作为一名IT员工：我可以成为这里的超级英雄，通过优化这件事情来避免即将发生的灾难，从而挽救公司！ 我的经理会给我礼物和赞美，因为我已经为公司挽救了数千人。

我说这两个。

你说现在你在40％左右的CPU？ 你用户抱怨（很多）了吗？ 如果不是，你仍然有呼吸的空间。 更多的记忆可能就足以做一段时间了。

问题的路要走，你有内部软件开发商？ 如果答案是否定的，那么甚至不要尝试重做。 你会完全确定你现在的位置。

假设你有内部开发人员，你的内部开发人员是否有能力做好项目？ 我正在谈论完全的，适当的（现实的）时间表，基本上就像客户的项目一样。 如果没有，那么不要打扰，否则它会回到你现在所在的位置。

在公司变革之前，他们也是自己的客户，并且需要将相同的资源分配给内部项目，那么您最终会到达现在的位置。 在那里，做了这个，得到了整个T恤衫梳妆台。

所以，如果你不能正确地做到这一点，你有两个select是开箱即用的钥匙，你是工作人员会讨厌，因为他们现在你必须适应你购买的系统的模具。 或者它将是可定制的，你仍然需要花费PROJECT时间定制它。

或重构你有什么。 记住，当新手进来时，人们会期望完全相同的function性，所以为什么你必须一次性做所有事情。 如果你重新考虑它，你就有机会弄清楚它是如何工作的，而不是把你的计划变成许多小的子项目。

在没有看到系统的情况下，我可能会在后端看到尽可能多的正常化，并将尽可能多的SQL移入Stored过程。 然后用C＃Forms或者一个webappbuild立一个新的前端。 如果您可以从前端获得业务逻辑和SQL，稍后重新进行操作将会更加轻松。 通过保持你对小项目所做的事情，如果它随时被推到一边或者停下来，你将会取得进展，将会被使用。

这里已经有一些很好的答复了 – 但是我可能只是指出（假设有内部开发人员）相对较less的工作将会产生很大的影响 – 添加主键（您甚至不必将所有查询都更改为使用它们），给你使用的字段添加索引，并调整你的查询，你可以看到一个绝对巨大的增加。 现在购买一些内存来购买你需要修复的时间和空间，然后开始工作。

在“修复或者修理”这个主题上，如果系统的function基本上适合你并且做你需要的function，那么不要重写轮子。 如果你的用户不得不做体操来使用这个东西，因为它不适合你的需求，那就毫不费力。

那么…这是不久前的事了，但是我想我会把结果logging在这里。

最后，我逐行通过VBA来处理另一个问题。 那时我才意识到一些调用获取行集的时间被阻塞了20-30 +秒。

当我挖掘到他们，我发现行集是基于MS Access查询。

这是从另一个Access查询中select数据。

那是从另一个Access查询中select数据。

所有这些看起来像是使用查询devise器一起被拖放到一起。

我经历了前半部分的用户痛点，发现他们完全一样。

因此，我完全删除了链式查询堆栈，并用一个可以用T-SQL编写并直接在服务器上执行的传递查询replace它们中的每一个。

无论如何，这种改善是绝对的巨大，没有人再等待任何问题。

然后我离开了公司。 不知道它是否仍然存在…但我不会错过它。

我发布了一个单独的答案，而不是仅仅追加到代顿的答案上，因为前几个人没有考虑到费用问题：重新培训用户的成本和改变业务stream程的成本以适应一个新的软件程序。 否则，他说什么。

公司开发他们自己的软件的主要原因之一是他们的业务stream程不符合市场上的某些东西。 哪一个很好 – 公司的个人业务stream程是公司带来的价值的重要组成部分，是公司对其余市场的竞争优势。 要用通用的软件取代软件，需要重新训练员工，牺牲竞争优势，否则就必须定制解决scheme以适应业务stream程。 两者都是昂贵和耗时的。 作为一名商业顾问和系统pipe理员，我看到这些成本本身就会杀死小公司。

从你的陈述来看，它看起来像你几乎处理器/软件绑定。 我会做两件事情 – 添加索引（在限制范围内），特别是当前不使用它们的列。 而且我会select最快的一组处理器，因为如果你没有那么多的驱动器读取时间，那么看起来就像是你的约束。

（另外，我会尽可能地升级服务器版本 – 到时候，Access 2000和SQL Server 2000将会有十年的历史，这是计算机年代的旧版！）

这需要重新构build（重新构build）。 从头开始重build系统。 从长远来看，这会节省很多费用（维护费用）。 同时，在它的夹头硬件。 我认为这个问题比技术调查更像是一个“商业案例”。 技术上来说，答案是彻头彻尾的“挑起更大的力量”。 商业上，build立一个新的系统！

技术答案：

你有一大堆build议，说明主键和索引应彻底审查。 Access也非常喜欢在每个表上使用SQL Server TimeStamp aka RowVersion列，因为这样可以减lessAccess花费大量时间来决定在更新logging时是否更改logging。

商业答案：

一个新的CRM解决scheme在培训人员方面有很多工作，你永远不会得到一个完全适合你的业务需求的系统。

我会find一个很好的Access人员，他们在SQL Server上也是非常有知识的，并且让他们花费3到6个月的时间来修正表格并修复用户痛点。 确保这个人在你的用户的工作，尽pipe在一个安静的空间，并可访问。 虽然不太方便。 开发人员不喜欢中断。 小号

基于给出的信息，我会replace系统。 最好使用另一个允许与其他系统灵活集成的CRM（这会危及您的ERP系统 ）。

最棘手的部分将是说服​​pipe理层和用户需要升级。

pipe理

expression你对技术问题，低性能，对拜占庭故障的恐惧等问题。然后提出2个替代CRM。 谈论业务整合，整个企业的ERP战略，最重要的是这将如何使员工更高效和更有利可图。 使用案例研究。 使这个不超过15分钟（除非他们想要更多的信息）。然后你需要说服用户。

用户

培训计划（供应商可能会提供[和pipe理层需要认可]），继续向前20％的用户（电力用户，造成问题的用户）进行沟通，以及确保系统100％运行第一个月（第一个月将创build或打破任何新的IS）。

有很多CRM产品在那里，select一个最适合您的业务需求。

抛硬件只会鼓励更糟糕的devise和pipe理，直到系统如此可怜，即使是最新最好的硬件也不能运行。 现在是时候看一下更好的实施。 首先分析需要什么。 只有当你完全理解了需求，你才能开始寻找实现它们的最佳方式。 一旦你确定你了解了需求，就可以开始考虑是修改你现有的还是从头开始的更好/更具成本效益，可能是完全不同的。

从长远来看，重做数据库可能是最好的select。 投掷更多的硬件会解决你的问题一段时间，但如果你继续使用它，你将不得不在一段时间后扔更多的硬件。

通常，当出现性能问题时，您可以查看硬盘/ RAID上的I / O瓶颈，分片数据库等等，但是对于分片之类的事情，您需要正确devise数据库以利用它。 从它的声音你的应用程序是永远不会能够扩展。

从长远来看，重做数据库和前端软件，以更好地反映您目前的业务需求将长期为您提供更好的服务。 你的用户会感谢你，你的硬件将会持续更长的时间，从长远来看，比起在这个问题上投入庞大的硬件，将会节省更多的钱。

根据你的描述，创build一个全新的定制系统是毫无意义的 – 你将在最开始的地方结束，或者甚至比现在更糟。 所以，除非你能说服某人购买第三方解决scheme，否则最好的办法就是尽可能地重构，然后丢弃硬件。

我想说，你应该做两件事情：1）SQL服务器上的性能分析。 您似乎已经确定服务器端是滞后的来源，所以现在您需要知道哪些查询滞后以及为什么。 在所有的可能性，你可以find一些热点查询来优化，这将给你很大的好处。 哎呀，如果你的客户端每隔几秒钟更新一次，看看你是否可以降低更新速度（屏幕上的列表是否真的需要每5秒更新一次？如果没有，那么15呢？ ）。 愚蠢的东西，如增加刷新定时器可以为您节省大量的开销，如果你能摆脱它。

2）投入更多的硬件。 特别是扔了大量的内存。 你想要这么多的内存，数据库完全适合RAM。 注意你的操作系统和软件版本（Windows版本和他们真正支持的硬件显然有相当多的规则）。 如果你能说服自己有更多的内核可以提供帮助，那么就可以尽可能多地使用CPU和内核。

你提到过RAM和处理器，但不是磁盘。 我承认我已经处理了MS的SQL Server已经有近十年的时间了，但是如果它不能适应内存中的所有事情，它就像其他数据库一样受到磁盘的限制。

我可能会首先尝试用尽可能多的RAM填充机器，然后确保将日志写入到不用于表或索引的磁盘。 然后我试着确保没有表格在同一主轴上有索引。

之后，我会担心数据库级别的调整，但是您需要定义您的testing和优化目标，这样您才不会破坏事情或使查询变得更糟。 虽然你说主键在你的testing数据库中并没有显示出太多优势，但你应该看看你的testing方法 – 主键可以允许一些数据库（不确定MS SQL是否是其中之一）使用logging级别locking而不是表级锁，这可以减less可能不会在仅有less数用户的testing中显示的争用。

首先，我同意凯尔·霍奇森（Kyle Hodgson）的看法，并加上PK。 它很便宜（只有时间），你可能会看到你的查询提高。 如何处理十大最丑陋查询中的连接列索引？ 桌子在哪里扫描？

其次，在数据库中修剪数据呢？ 查询中返回的行数多于真正需要的数量？ 我也同意凯尔对RAM的build议（另外两个GB）。

把所有这些都写进你（Joseph Kern）写的关于你为临时计划提出的build议，同时规划未来。 询问pipe理人员和用户如果当前的CRM应用程序陨石坑并不可用，组织会发生什么情况。 也许这将有助于让他们思考未来。

获取硬件！

不仅如此，如果您使用至强55xx系列芯片，它将会尖叫任何可以抛出的东西。

这只是一个风险/回报的事情 – 你可以花更多的钱和时间让数据库变得更好，或者更快，更便宜地购买你的方式。

考虑翻转3GB的内存开关，并增加2GB的内存。