如何调整SQL服务器的大小（RAM，CPU等）

• 4 GB的RAM是这几天的笑话。 所以，不 – 对不起。 我想你是这样做的。 它可以工作，但需要特定的使用模式。 我不会在原则上在4 GB的硬件上运行数据库服务器 – 16 GB的RAM几乎不需要任何开始。
• SCSI RAID 5不是最佳的。 根据使用模式，您应该至less有两个组 – 一个快速写入（日志），一个快速读取（数据）。 我已经使用4个以上的光盘作为操作系统和日志，另一个用于数据。 但是，请注意，分贝数量要大得多。 在你的情况下抛出RAID 5，只是把两个镜像的SSD将是有道理的，因为你的数据只有53 GB。 两块固态硬盘的镜像可能会将IO性能提高100倍。根据当今的标准，内存的帮助很可能会导致IO的限制。 对不起，如果这听起来粗鲁，但一个数据库服务器应该有比开发工作站更多的内存，并根据你在什么样的公司是平等的或低于这个。

有一些标准的方法，或者只是经验和感觉？

经验和感觉。 你也可以前瞻一下，并检查一下两年之后的情况。 例如，SuperMicro在SASconfiguration中具有用于24-72张光盘的NICE服务器。 所以，你可能会得到一个避免使用SAN（更昂贵），并根据需要填写光盘。 其他人得到一个小型服务器，然后用尽选项。 你也可以从一个普通的工作站上testing一些想法。

这是标准的故事，开发者和pipe理者之间有争斗。

不它不是。

一种说法是数据库devise和查询不好，而另一些则说缺less硬件和数据量。

再没有 Dbdevise可以非常客观地衡量。 如：有一些logging和已知的方法（很多开发人员基本上完全无知）。 曾经听说过第五种正常forms？

与查询相同。 我实际上可以看到一个查询是否有效执行。 这里没有真正的灰色地带。 也就是说，可能会有一些权衡，但是如果这被归咎于一个责怪的游戏，那么我可以肯定地说是有错的。

很多时候，开发人员除了“这是一个简单的select”之外什么都不知道，也不知道如何处理数据库，然后尝试抛出硬件问题。 在那里，看到了。 并不总是，但这是一个可能的猜测。

随着RAM的大小，重要的是要知道你的可能的“工作集”是什么，并确保你有足够的内存，乘以几次至less。 您的正常工作集是所有常用的索引和数据页面，并且能够将其全部保存在RAM中，并具有足够的空间以备“更多特殊但仍然不常见”的查询，这将显着减less读取操作所需的磁盘I / O 。

例如，一个10Gb的数据库（比你的数据量要小得多，但理论上保存着你的数据大小）包含大约1Gb的活动数据页面：索引和表格行，可能被常规访问因为用户正在进行正常的业务。 另一个〜4Gb是在大多数正常会话中不读取的较旧数据（因为大多数视图默认只显示最多一个月或三个数据，并且数据，索引和查询已经很好地规划好了，以致较旧的数据页面不是除非用户要求及时查看某些东西（在日常使用中这种情况相对较less），最后的〜5Gb是blob–用户已经附加到logging中的文档，很less被访问即使有了这样大小的数据，我怀疑2Gb RAM足以维持快速访问（我正在谈论的数据库生活在专门用于运行MSSQL的4Gb服务器上，另一台机器作为networking服务器和与应用程序相关的其他服务），所以你可能需要重新考虑你的数据大小的RAM大小 – 现在RAM相对便宜，所以假设你的服务器可以pipe理多达8,12甚至更多16Gb可能会给你一个良好的投资回报performance明智。

对于无法避免磁盘I / O的情况，如果数据看到大量的写入活动，我将远离RAID5和RAID6。 对于大多数读取负载，标准RAID10（或者略微不那么标准的RAID10安排，如Linux RAID10驱动程序和一些硬件解决scheme所提供的那样），对于大多数写入负载来说明显更好，并且提供类似的冗余（任何一个驱动器可能失败）。 如果您不想跳到四个驱动器，则可以尝试使用三驱动器RAID10（大多数IBM控制器称为RAID1E）（如果环境支持）。 另外，TomTombuild议将数组分成两部分是非常值得的。 对于写操作，您可能会发现在两个驱动器的RAID1arrays上的事务日志和另一个上的数据文件的事务日志将显着优于使用RAID10 – RAID10的近RAID0批量读取性能可以很快被数据库写入的随机访问特性（更新可能分布在文件空间上的数据和索引页面，在将数据提交到数据文件之前更新事务日志，并在完成时将其标记为在日志中提交）等等。 将日志和数据文件活动分离到不同的主轴上可以在很多情况下显着提高数据库性能。 如果你有足够的空间存放所需的驱动器，那么如果你的查询和存储过程大量使用临时表，那么保留tempdb（或者你的RDBMS与MS的tempdb等价）等等，也会产生很大的不同。有时可能会令人惊讶的查询计划程序会考虑在你的背后使用tempdb！）。 当然，使用固态硬盘也是随机存取性能的一个答案，不pipe你用哪种arrays安排（或者那些arrays安排）来获得更好的价格/性能比，这主要取决于你的数据库和典型的访问模式。

另外一件事情是：在投入时间+精力+资金来重新安排I / O子系统之前，确保在繁忙时间运行一些性能指标，以确保没有任何严重受CPU限制的坏的程序。 有时候复杂的程序（特别是那些使用游标的程序并不是最优的方法）可以长时间地挂住CPU +内存子系统（增加更多的内存和更好的I / O能力在这里几乎没什么区别），通常可以通过重新思考游标/循环或设法完全删除它们。 自定义SQL跟踪日志logging和Windows性能监视器日志logging（或者使用不同OS + DB组合的人员的等效监视工具）的混合可以帮助您find关键瓶颈的实际情况（内存不足，I / O性能较差比最佳代码，…），你应该试图解决一个问题，直到你相对确定你正在解决正确的问题。

我可以想象，硬件和代码至less在某种程度上都是错误的。

首先，您可以使用SQL事件探查器和dynamicpipe理视图来certificate哪些查询速度慢，为什么速度慢。 使用这些工具在高层次上相当容易，你可以很容易地看到是否CPU限制，磁盘限制，内存限制等。但理解复杂的查询计划和优化是不是你要学习没有放入一些时间。 在SQL性能仪表板中有一个漂亮的索引和缓慢的查询报告，可以帮助您find一些唾手可得的成果。

另一方面，这个服务器硬件是现代标准的积极鞭挞。 我在办公室的个人工作站在各方面都更强大（包括SSD而不是机械磁盘）。 我们在五年前部署了具有> 16 GB RAM的64位数据库服务器。 硬件是任何IT运营中最便宜的部分 – 肯定比在这个问题上花费几十到几百个工时更便宜。

build议：

1. 使用性能监视器来确定你的瓶颈真正在哪里。 硬数字，而不是猜测。 有很多很好的MSDN和其他文章在哪个柜台监测。 通常这是一个磁盘或CPU瓶颈。 如果你看到磁盘队列长度很高，你通常需要更多的内存，而不是更快的磁盘！ 购买尽可能多的RAM，你可以负担得起。 这意味着你需要一个64位的操作系统和64位版本的SQL服务器。 你基本上可以将整个数据库保存在64 GB的服务器上。 缓冲区caching命中率性能计数器在峰值负载时应保持在99％以上。
2. 只有当您确定已经为最频繁的查询正确编制数据库索引时才添加CPU。 一个正确devise和不需要的查询可以在一个写得不好的情况下在执行时间内保存一千倍（而不是一个错字）。 避免嵌套视图，开发人员喜欢因为代码重用而喜欢的视图，但是因为索引经常变得无用，所以要吸引人的是性能。 任何使用游标的开发人员声称他们更快或“唯一的办法”必须立即被解雇。
3. 如果您的工作集大于双路服务器中可用的最大内存，请考虑SSD而不是机械磁盘。 目前，我认为这是192 GB，所以你的数据量还远远不够。
4. 本质上， 做到这一点 。

Havin你厌倦了HP或Del尺寸的工具吗？ 不是所有的都结束了，但至less是一个好的起点。