tom*_*ing 39 hardware database-performance sql-server microsoft-access
所以 - 我们有一个内部公司数据库，通常的东西：管理客户、电话、销售交易和客户协议/计划。
它是一个 Access 2000 前端和一个 SQL Server 2000 Standard 后端。单台服务器、双 Xeon 3.2GHz、2GB RAM、Windows Server 2003，整天获得大约 40% 的 CPU 负载，分布在操作系统 (HT) 可见的 4 个内核上。
后端数据库设计不佳，已经有机增长超过 10 年，由不那么熟练的人员维护。它被严重规范化，一些明显的问题包括具有数万行没有主键或索引的表，这些表也大量用于系统中一些最常用部分的多表连接（例如呼叫管理器应用程序，每天在每个人的第二台显示器上运行 8 小时，每隔几秒钟运行一次低效的大查询）。
前端也好不到哪里去，它是典型的由数百个表单、嵌套保存的查询、VBA 代码中编写不当的嵌入式 SQL、数十个“怪癖”等组成的典型混乱，并且每当进行更改时，一些无关的东西似乎都会中断。我们已经确定了一个运行“足够好”的 MDB，现在有一个不变的政策，因为我们内部没有 Access 重量级人物（也没有计划雇用一个）。
公司现在正在缓慢增长，增加客户、呼叫等数量，同时并发用户数量适度增加，最近性能明显变差（等待在表单之间移动，等待列表填充等） )
Perfmon 说：
SQL Server 的探查器每分钟看到数十万个查询。客户端上的 CPU 使用率几乎为零，表明它正在等待服务器端查询执行。我已经通过 DB Engine Tuning Advisor 处理了这个工作负载，并将其建议应用于测试备份，但这并没有产生太大的不同。
顺便说一下，我们有 100MB 和千兆以太网的混合，都在一个子网上，两层楼有 40 个用户。
对问题。
在我看来，我们有两种选择来解决/改善这种情况。
我们可以用比更换软件低一个数量级的成本来构建具有疯狂性能数字的 Intel i7 系统。
当最终开发出一个新系统时，它可以托管在这个盒子上，因此不会浪费硬件。一个新的 CRM 系统不断被推迟、关闭、关闭——我认为这种情况至少在一年内不会发生。
对这种情况的任何想法，特别是如果您亲自来过这里，将不胜感激。
谢谢
Day*_*own 21
我将不同意这里的每个人。把一些硬件放在上面。它便宜、快速、简单，并且可以为您争取实施适当的 CRM 解决方案所需的时间。我提倡的原因不仅是这个董事会，而且是 stackoverflow 上的几乎每个人都讨厌的东西，是因为我一直是项目经理/经理，并且已经在“业务”方面工作了一段时间（业务由于我对这个词的憎恨而用引号引起来）。根据您对软件的描述，重建其他软件需要将近一年的时间。仅仅发现/记录业务规则/怪癖，可能需要 2 个月。开发成本也将令人难以置信。尤其是与被欺骗的服务器的成本相比时。
正是出于这个原因，我实际上正准备为一家公司托管一组 Web 应用程序。内部 IT 部门不会将其转移到更好的硬件上，因为他们想在新平台上重新开发它们。该成本大约是将其迁移到新硬件的成本的三倍。更不用说该公司可能不会在一年内续签合同。
Bee*_*eep 15
您可能也不需要这样做。我的建议是简单地向表中添加一些索引/键。
包含数万行没有主键或索引的表，在多表连接中也大量使用
在花费大量金钱或时间之前，花几个小时为这些连接中涉及的任何表添加索引（如果可以，也可以添加主键）......特别是对于 where 子句中使用的列。您可以在短短几个小时内轻松地将性能提高 10 倍。
缺少磁盘 I/O 意味着查询主要来自 RAM。如果您“突然”让您的热表不再适合 RAM 并且服务器开始工作磁盘，您可能会遇到麻烦。现在 2GB 或 RAM 不是很多，但在 SQL2000 时代它已经相当可观了。我猜应用程序通常操作的数据量小于您拥有的 RAM。您可能想查看数据文件中“已用”空间的数量。这将使您了解数据库在最坏情况下可能消耗多少 RAM。SQL Server 不会将不需要的数据保留在 RAM 中，但可能很难知道使用了哪些表以及何时使用。
超线程并不总是对 SQL Server 有帮助。关闭它可能会获得更好的性能。很难测试，因为关闭和打开它需要重新启动，这对生产服务器来说是一个很大的麻烦。
“每分钟数十万次查询”转化为每秒数千次查询。这听起来很忙，但大部分流量可能只是 Access 获取的游标。Access 在从 SQL 高效检索结果集方面尤其糟糕。通过关闭 SQL Server 并行化设置，您可以获得更好的性能。
您还想寻找阻塞。将硬件投入阻塞问题并不总能产生预期的显着改进。如果没有太多阻塞并且查询由 RAM 而不是磁盘满足，则您基本上依赖于处理器的咕噜声，以及它们跨内存通道提取数据的能力。在这种情况下，更快的硬件应该提供良好的改进。如果你赶时间（为了解决这个问题）并且成长缓慢，那可能就足够了。
作为一种解决方案，添加硬件的扩展性不如数据库改进。如果您的增长激增，您可能会发现新硬件陷入困境。另一个想法是成功的应用程序会吸引用户。如果应用程序的响应速度更快，用户可能更有可能在其上运行更多的报告等，而不是在等待报告完成时需要去喝咖啡。
如果数据库架构真的很糟糕，您可以通过查看表上的索引来获得一些性能优势。专注于您知道经常被查询的表。您可以使用 Profiler 来查看针对服务器运行的查询，只需告诉它查找读取大量数据（例如 100,000 页）的查询，然后处理读取不多的查询。您提到某些表没有键。数据中是否存在自然键，只是不受约束或唯一索引强制执行？
表有聚集索引吗？缺乏聚集索引会导致各种次要影响。
是否有很多非聚集索引，有很多列？这通常是尝试构建许多覆盖索引，而不是实施更有效的索引策略。如果这样做有意义并且支持非聚集索引和聚集索引，SQL Server 可以在查询期间有效地动态构建覆盖索引。
最后，值得一问：是否对表进行了维护（重新索引和/或更新统计信息）？
这是一个商业问题而不是一个技术问题。
作为企业主： 系统对企业的战略意义如何？战略性越低，我就越不关心和修复它以及花费的任何钱，就是我可以在其他地方使用的钱来发展我的业务。
计算机人员吓到我了，因为他们都进了一个大房间，讨论设计并花费了我一大笔钱。保持系统运行！这是否意味着性能调整（无需重新架构）或投入更多硬件，这只是它停止工作时的优先事项。
作为 IT 顾问： 您的系统是遗留系统并且隐藏着运营成本。我们可以设计一个适合您的系统，该系统将扩展并为未来的增长和战略优势提供平台。在这里签到，你所有的梦想都会成真。
作为一名 IT 员工： 我可以成为这里的超级英雄并通过优化这件事来避免迫在眉睫的灾难来拯救公司！我的经理会送我礼物和赞美，因为我已经为公司节省了数千美元。
嗯……这是很久以前的事了，但我想我应该在这里记录一下结果。
最后，我一行行地通过VBA来处理另一个问题。就在那时，我意识到一些获取行集的调用阻塞了 20-30 秒以上。
当我深入研究它们时，我发现行集基于 MS Access 查询。
那是从另一个 Access 查询中选择数据。
那是从另一个 Access 查询中选择数据。
所有这些看起来都像是使用查询设计器拖放到一起的。
我浏览了前六个用户痛点，发现它们都与此完全相同。
因此，我完全删除了链式查询堆栈，并将每个查询替换为单个传递查询，该传递查询可以用 T-SQL 编写并直接在服务器上执行。
在每种情况下，改进绝对是巨大的，毫无疑问，并且不再需要等待任何人的询问。
然后我就离开了公司。不知道它是否还在那里……但我不会想念它。