内部数据库不良-替换它还是卡盘硬件？

所以-我们有一个内部公司数据库，这是通常的工作：管理客户，电话，销售交易和客户协议/方案。

它是Access 2000前端和SQL Server 2000 Standard后端。单服务器，双Xeon 3.2GHz，2GB RAM，Windows Server 2003，整天获得约40％的CPU负载，分布在OS（HT）可见的4个内核上。

后端数据库的设计欠佳，并且在不到10年的时间里有机地增长了，由经验不足的个人维护。它的规范化很差，一些明显的问题包括具有成千上万行的表而没有主键或索引，这些表在系统中使用最频繁的某些部分的多表联接中也大量使用（例如，呼叫管理器应用程序，每天在每个人的第二个监视器上放置8个小时，每隔几秒钟运行一次效率低下的大查询）。

前端并没有更好，它是典型的混乱，包括数百种形式的表格，嵌套的已保存查询，VBA代码中编写不佳的嵌入式SQL，数十个“怪癖”等，并且每当进行更改时，似乎无关的东西就会中断。我们已经选择了一个运作良好的MDB，并且由于我们内部没有Access的重量级人物（也没有计划雇用任何一个），因此现在对此没有更改政策。

该公司现在正在缓慢发展，增加了客户，呼叫等的数量，并发用户的数量也有适度的增加，并且性能最近一直在明显变差（等待在表单之间移动，等待列表填充等）。 ）

Perfmon说：

• 每秒磁盘传输：0到30之间，平均4。
• 当前磁盘队列长度：徘徊在1

SQL Server的探查器每分钟看到数十万个查询。客户端上的CPU使用率几乎为零，表明它正在等待服务器端查询执行。我已经通过数据库引擎优化顾问（DB Engine Tuning Advisor）来处理此工作负载，并将其建议应用于测试备份，但这并没有太大的改变。

顺便说一下，我们在一个子网中混合了100MB和千兆以太网，两层楼有40个ish用户。

问题。

如我所见，我们有两种选择来解决/改善这种情况。

• 我们可以将其报废并将其替换为全新或定制的CRM系统
• 我们可以通过固定硬件来延长该系统的寿命。

我们可以构建具有疯狂性能数字的Intel i7系统，而成本却比更换软件少一个数量级。

最终开发出新系统时，可以将其托管在此设备上，因此不会浪费硬件。一个新的CRM系统不断推陈出新-我至少一年都不会看到这种情况。

对于这种情况的任何想法，特别是如果您自己来过这里的情况，将不胜感激。

谢谢

我将不同意这里的每个人。夹一些硬件。它便宜，快速，容易，将为您提供实施适当的CRM解决方案所需的时间。我之所以提倡这不仅对董事会的每个人都令人反感的原因，而且对stackoverflow也是如此，是因为我一直是项目经理/经理，并且在“业务”方面已经有一段时间了（业务由于我对这个词的仇恨，所以用引号引起来。根据您对软件的描述，将需要大约一年的时间来重建其他软件。仅发现/记录业务规则/问题，可能需要2个月的时间。开发它也将是难以置信的昂贵。特别是与被欺骗的服务器的成本相比。

正因为如此，我实际上将为一家公司托管一组Web应用程序。内部IT部门不会将其转移到更好的硬件上，因为他们想在新平台上重新开发它们。该成本大约是将其迁移至新硬件所需成本的三倍。不太提及该公司可能在一年内没有续签合同。

您可能也不需要这样做。我的建议是简单地向表中添加一些索引/键。

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

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

缺少磁盘I / O意味着查询大部分是从RAM馈送的。如果“突然”使热表不再适合RAM，并且服务器开始处理磁盘，则可能会造成麻烦。如今，2GB或RAM并不多，但在SQL2000时代，它已经相当大了。我猜测应用程序正常处理的数据量小于您拥有的RAM。您可能需要查看数据文件中“已用”空间的数量。这将使您了解最坏情况下数据库可能消耗多少RAM。SQL Server不会将不需要的数据保留在RAM中，但是很难知道使用了哪些表以及何时使用了这些表。

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

“每分钟数十万个查询”转换为每秒数千个查询。听起来很忙，但是其中的大部分流量可能只是Access获取的光标。访问尤其不利于有效地从SQL检索结果集。关闭SQL Server并行化设置，可能会获得更好的性能。

您还想查找阻塞。将硬件扔到阻塞问题上并不能总是带来希望的巨大改进。如果没有太多阻塞，并且RAM而不是磁盘满足查询要求，那么您基本上是在依靠处理器的努力以及它们在内存通道中提取数据的能力。在这种情况下，较快的硬件应提供良好的改进。如果您很着急（克服这个问题）并且成长缓慢，那可能就足够了。

作为解决方案，添加硬件不会像数据库改进那样扩展。如果增长迅速，您可能会发现新硬件陷入困境。另一个想法是成功的应用程序会吸引用户。如果应用程序的响应速度更快，那么与等待报表完成时需要去喝咖啡的用户相比，用户可能会运行更多的报表等。

如果数据库架构确实很差，那么只需查看表上的索引，您可能就能获得一些性能优势。专注于您经常查询的表。您可以使用Profiler来监视针对服务器运行的查询，只需告诉它查找读取大量数据（例如100,000页）的查询，然后处理读取量不大的查询即可。您提到某些表没有键。数据中是否有自然键，只是没有约束或唯一索引来强制执行？

这些表是否具有聚簇索引？缺少聚集索引会导致各种次要影响。

是否有很多非聚集索引，并且列很多？这通常是尝试建立许多涵盖索引，而不是实施更有效的索引策略。SQL Server可以在查询过程中快速有效地构建覆盖索引，前提是这样做是有意义的，并且支持非聚集索引和聚集索引。

最后，值得一问：对表进行维护（重新编制索引和/或更新统计信息）吗？

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

作为企业主： 系统对企业的战略性如何？战略性越差，我就越不会在意和解决它以及花费的任何金钱，就是我可能会在其他地方用来发展我的业务的金钱。

电脑界的人吓我一跳，因为他们都进入一个大房间，争论设计并花了我一大笔钱。保持系统正常运行！无论是性能调优（无需重新架构）还是要添加更多硬件，这都是停止工作的首要任务。

作为一名IT顾问： 您的系统是旧系统，并且隐藏了运营成本。我们可以设计一个适合您的系统，该系统可以扩展并为未来的增长和战略优势提供平台。在这里签名，您的所有梦想都将实现。

作为IT员工： 我可以成为这里的超级英雄，并通过优化事情来避免即将发生的灾难，从而拯救公司！我的经理会为我送上礼物和赞美，因为我将为公司节省数千美元。

我说都做。

现在您说的是40％左右的CPU？您的用户是否在抱怨（很多）？如果没有，您还有呼吸的空间。更多的内存可能足以满足需要一段时间。

对于未来的发展方式，您有内部软件开发人员吗？如果答案是否定的，那么甚至不要尝试重做。您将最终获得现在的状态。

假设您有内部开发人员，您的内部开发人员是否有能力正确执行项目？我说的是完全，正确（相对）的时间表，基本上与客户的项目相同。如果不是，那就不要打扰，否则它将回到您现在的位置。

直到公司放松关系，他们也是自己的客户，并且需要为内部项目提供相同的资源，您才能最终获得现在的状态。到那里去了，做了一个完整的T恤梳妆台。

因此，如果您不能正确执行操作，则有两个选择，即开箱即用的钥匙，您的员工会讨厌，因为现在您必须适应所购买系统的模具。否则它将是可定制的，您仍然需要花费PROJECT时间对其进行定制。

或重构您所拥有的。记住，人们会期望新的功能完全一样，因此这就是为什么您必须采用其他任何方式立即进行所有操作的原因。如果您对其进行重构，则有机会弄清楚它是如何工作的，然后进行临时更改，而是将其计划到许多小型子项目中。

在不了解系统的情况下，我可能会想尽办法在后端进行尽可能多的规范化，将尽可能多的SQL移入存储过程。然后使用C＃Forms或Webapp构建新的前端。如果您可以从前端使用业务逻辑和SQL，则稍后再进行操作会更容易。通过将您对小型项目的操作保留下来，如果它随时被搁置或停止，您将取得可以使用的进度。

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

关于“修复或抛弃它”的主题，如果系统的功能基本上可以为您工作并满足您的需要，请不要重写轮子。如果您的用户因为不符合您的需要而不得不使用它来进行体操运动，那么就不用费劲了。

好吧...这是前一阵子，但我想我已经在这里记录了结果。

最后，我一步一步地介绍了VBA，以解决另一个问题。那时，我意识到一些获取行集的调用被阻塞了20-30秒钟以上。

当我深入研究它们时，我发现行集基于MS Access查询。

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

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

所有这些似乎都已使用查询设计器将它们拖放在一起。

我浏览了前六名用户的痛点，发现它们确实与此完全相同。

因此，我完全删除了链接查询的堆栈，并用一个直通查询替换了每个查询，这些查询可以用T-SQL编写并直接在服务器上执行。

每种情况下的改进绝对是巨大的，没有失败，没有任何人等待查询了。

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

我要发布一个单独的答案，而不是仅在Dayton的答案后面附加一个答案，因为前几个发布答案的人并没有考虑这些成本：重新培训用户的成本以及更改业务流程以适应该成本的成本一个新的软件程序。否则，他说了什么。

公司开发自己的软件的主要原因之一是，他们的业务程序与市场上的产品不匹配。太好了-公司的个别业务流程是公司带来的价值的重要组成部分，并且是公司在其余市场中所具有的竞争优势。要用通用软件替换软件，将需要您重新培训人员并牺牲竞争优势，或者必须定制解决方案以匹配您的业务流程。两者都是昂贵且费时的。作为业务顾问和系统管理员，我已经看到这些成本使小公司自己丧命。

从您的陈述来看，您似乎受处理器/软件的束缚。我要做两件事-添加索引（在限制范围内），尤其是到当前不使用索引的列。我会选择最快的处理器，因为如果没有那么多的驱动器读取“峰值”，那似乎就是绑定的地方。

（此外，我会尽可能升级服务器版本-到您将其安装到位时，Access 2000和SQL Server 2000将使用十年了。这在计算机时代已经很旧了！）

这需要彻底的重组（重新架构）。从头开始重建系统。从长远来看，这将为您节省很多（维护的间接费用）。在此期间，请夹住硬件。我认为这个问题更多是“业务案例”，而不是技术询问。从技术上讲，答案是完全“给它更多的力量”。从业务角度出发，构建新系统！

技术答案：

您有大量的建议说明主键和索引应该被彻底检查。Access还真的很喜欢在每个表上使用SQL Server TimeStamp或RowVersion列，因为这样可以减少Access在决定更新记录时是否花费很多时间来决定是否更改了记录。

业务答案：

新的CRM解决方案在培训人员方面需要进行大量工作，而且您永远都不会获得完全适合您的业务需求的系统。

我会找到一个很好的Access人员，他在SQL Server上也非常有知识，并让他们花3或6个月来规范化表并解决用户的痛点。确保此人作为您的用户在saem地板上工作，尽管它们在安静的空间中并且可访问。虽然不太方便。开发人员不喜欢打扰。小号

根据给定的信息，我将替换系统。最好使用另一个CRM，该CRM可以与其他系统进行灵活集成（这会损害您的ERP IS）。

最棘手的部分将是说服​​管理层和用户进行升级。

管理

表达您对技术问题，性能低下，担心拜占庭式故障等的担忧。然后介绍2种替代CRM。讨论业务集成，业务的整体ERP战略，最重要的是，这将如何使员工提高生产力和利润。用例研究。将其设置为不超过15分钟（除非他们需要更多信息）。然后，您需要说服用户。

用户数

培训计划（供应商可能会提供[并且管理层需要批准）计划，与您的前20％用户（高级用户，造成麻烦的用户）持续沟通以及坚定地承诺保持系统100％正常运行第一个月（第一个月将产生或破坏任何新的IS）。

现在有很多CRM产品，请选择最适合您业务需求的产品。

抛弃硬件只会鼓励更糟糕的设计和管理，直到系统变得如此可怜，以至于即使在最新最好的硬件上也无法很好地运行。现在是时候考虑一​​个更好的实现了。首先分析需要什么。只有完全了解需求，您才可以开始寻找实施需求的最佳方法。一旦确定要理解的要求，便开始考虑修改现有内容或从头开始（可能完全不同）是否更好/更具成本效益。

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

通常，当出现性能问题时，您会查看诸如硬盘/ RAID上的I / O瓶颈，分片数据库等问题，但是对于诸如分片之类的事情，您需要适当地设计数据库以利用它。从它的声音来看，您的应用程序将永远无法扩展。

从长远来看，重做数据库和前端软件以更好地反映您当前的业务需求从长远来看将为您提供更好的服务。您的用户将感谢您，您的硬件将持续更长的时间，并且从长远来看，与在问题上投入大量硬件相比，它将节省更多的钱。

根据您的描述，创建一个全新的定制系统是没有意义的-您将最终从起点开始，甚至可能比现在更糟。因此，除非您可以说服某人购买第三方解决方案，否则您最好的选择是尽可能地重构并投入硬件。

我要说的是，您应该做两件事：1）在SQL Server上进行性能分析。您似乎已经将服务器端标识为延迟的来源，因此现在您需要知道哪些查询滞后以及原因。在所有可能的情况下，您都可以找到一些热点查询进行优化，从而为您带来巨大的好处。哎呀，如果您的客户端每隔几秒钟更新一次，请查看是否可以降低其更新速率（屏幕上的列表是否真的需要每5秒钟更新一次？30可以吗？如果不行，那么15左右呢？ ）。如果您可以避免使用笨拙的操作，例如增加刷新计时器，则可以节省很多开销。

2）投入更多的硬件。特别是向它扔大量的公羊。您需要太多内存，数据库完全适合RAM。密切注意您的操作系统和软件版本（Windows版本及其实际支持的硬件显然有很多规则）。如果您可以说服自己更多的内核会有所帮助，那么请尽可能多地投入CPU和内核。

您刚才提到了RAM和处理器，但没有提到磁盘。我承认，自从我处理MS的SQL Server以来已经有将近10年的时间了，但是如果它不能容纳所有内存，那么它与磁盘的绑定就和其他任何数据库一样多。

我可能首先尝试为计算机填充尽可能多的RAM，然后确保将日志写入未用于表或索引的磁盘。然后，我将尝试确保没有表在同一主轴上具有其索引。

之后，我会担心数据库级别的调整，但是，这样一来，您将需要定义测试和优化目标，以免破坏事务或使查询恶化。尽管您说主键在测试数据库中没有显示太多优势，但是您应该查看测试方法-主键可以允许某些数据库（不确定MS SQL是否是em之一）使用记录级锁定，而不是表级锁定，这可以减少争用，只有几个用户才能在测试中不显示争用。

首先，我同意Kyle Hodgson并添加PK。它很便宜（仅时间），您可能会发现查询量有所增加。十大最丑陋的查询中的联接列索引如何处理？表格扫描在哪里？

其次，如何修剪数据库中的数据？查询中返回的行是否超过实际需要的行？我也同意Kyle关于RAM的建议（多两个GB）。

在规划未来的同时，将所有这些内容都写到您的建议书（约瑟夫·科恩）中。询问管理人员和用户，如果当前的CRM应用程序崩溃并无法使用，对组织会发生什么情况。也许这将帮助他们思考未来。

获取硬件！

如果您购买Xeon 55xx系列芯片，那么锡不仅非常便宜，而且它还会为您提供任何可以出售的东西。

这只是风险/回报的事情-您可以花很多钱和很多时间来改善数据库，也可以更快，更便宜地购买数据库。

考虑翻转3GB内存开关并添加另外2GB内存。