Rambuild议与SQL DB大小

没有好的经验法则。

其他内存的用处很大程度上取决于数据库的devise方式以及查询模式或用户。 举一个极端的例子，如果你总共有1TB的数据，好的索引和1000个并发用户只能在1个特定行之后（select * from dbo.BigTable where pkey_id = 42），那么你可以用很less的RAM 。 更多RAM的影响还取决于磁盘存储子系统的速度。 如果您有超级快速存储（一个好的 SAN， 好的 DASD或SSD），当服务器需要读取数据时，您可能不会注意到滞后。

理想情况下，您需要在白天将数据库可能需要的所有数据caching到RAM中。 这有时被称为“热门数据”或“热门页面”（在SQL Server中，数据以“页面”为单位进行组织）。 热门数据的例子可能是今天或者昨天的订单，那些运送这些订单的工作人员将需要这些订单。 冷数据的例子可能是两年前的订单，但是在系统中仍然存在，所以CSR可以查询旧订单。

通过一个devise良好的OLTP系统，总共有40 GB的数据（相对于数据文件总计高达40 GB），热数据可能只有10 GB，5 GB，1 GB甚至更less。 在过去的日子里，只购买64GB的内存和8GB的内存（甚至更less）之间的差距是天文数字，并且获得正确的内存购买量值得花费大量的时间。

你总是需要一些额外的RAM，像操作系统，病毒扫描程序，RDP会话等“开销”。 你也想考虑数据库的增长。

另外要记住的是内存是“大块”的。 你不能决定48 GB和49 GB，你必须加紧，可能从48到64 GB。 块的大小取决于当前正在销售的RAM技术以及您的内存有多less个通道。 旧服务器有一个内存变化，然后服务器开始有两个，现在最强大的服务器有三个内存通道。 所以，你不能只添加一个棒，你需要一次添加两个。

如果你的数据库devise不好，索引不好，就像你说的那样，SQL会结束阅读很多数据，而这些数据在devise更好的数据库时是不需要的。 将这些数据全部存储在RAM中并不意味着它不能读取所有数据。 这只是意味着它读取RAM中的所有数据的速度比数据位于磁盘存储上的速度要快。 这不一定能解决你所有的问题。 从RAM中读取数据是快速的，但仍然需要一定的时间，您仍然可以获得阻塞和死锁问题，这可能会导致性能问题。

另一件事情是，当人们在利用去年的数据的系统上运行大型报告时，更多的RAM可以提供帮助。 人们总是对待OLTP系统，比如报告系统。 这可能不是一个罕见的情况，特别是随意的SQL查询。

您可以花费时间（和金钱）在开发人员和testing人员上来改进数据库devise，并对前端做出任何需要的更改。

一个非常快速的hp.com旅程表明，我可以得到一个（非常）精简的服务器与96 GB的RAM大约9,000美元。

（每GB的价格低于100美元，没有考虑服务器中的任何其他部分，比如电源或者处理器，像我这样的老人记得RAM是5,000美元/兆字节，有M.）

您能花多less美元在开发和testing时间上花费9000美元？ （按照我所在地区的公司费率，一个月内只能得到一个人整整一个人）。那么是否有足够的时间来解决数据库中的所有问题？ 如果更改的代码中的错误滑过，该怎么办？

服务器中断添加RAM可能需要一个小时，几乎任何人都可以完成这项工作。 迁移到全新的服务器上可能需要几天的准备工作和一小时的停机时间，而且您需要有经验的人（可能是DBA）。

添加RAM不太可能导致任何错误。 迁移到新的服务器不太可能导致难以发现的问题。 （一般情况下，东西要么工作，要么显然是坏的，通常是“哎呀，错误的密码”或“哎呀，忘记复制链接的服务器”，它永远不会“嘿，这个计算突然不能正常工作”

所以，假设我们将所有内容都保存在内存中，并且有一个40 GB的数据库，那么我们需要一些空间。 我会考虑一个48 GB左右的服务器。 另外，我们需要一些增长空间。 我们只是说从这里增长了25％，这是12 GB，我们高达60 GB。 下一级（我实际上可以购买）是64 GB。 如果您的顾问正在推荐一个三通道服务器，则下一个级别可能是72 GB。 所以，他的build议不一定是古怪的。 也许你不需要那么多的核心/sockets，这可能会让你回到双通道服务器（反正会更便宜），而且你可以less花一点钱购买内存。

TLDR：

总之，我很less遇到这种情况，RAM很便宜，而且时间也很昂贵。 如果你没有资金，时间或倾向来修复数据库，或者你不想冒险给你的应用程序添加错误，那么在这个问题上抛出内存是很难提出问题的。 另一个好的举措是提高磁盘存储系统的响应能力（IOW，增加更多的主轴，更多的RPM或者使用SSD）。

我会问，为什么顾问不希望你花一年时间和一个10万美元的重写系统。