聘请SqlServer OLTP专家，我应该寻找什么样的经验或要求？ [关闭]

Question

我正在使用我正在研究的OTLP项目遇到Db性能问题。另一位开发人员和我已经达到了我们累积的绩效知识的最后阶段，并寻求一个人加入团队，以帮助我们加快申请。

对于某些背景，我们已经完成了模式更改以对数据进行非规范化，优化每个查询，运行多个数据库调优顾问以使我们的索引恰到好处，调整MSSql的服务器选项。

我们不需要有人进来告诉我们加入可能很慢而且死锁是什么，我们需要一个在完成上面列出的所有步骤后知道该怎么做的人。

任何人都有聘请OLTP DBA分享的任何提示或经验吗？在面试过程中我们可以向DBA提出什么样的问题？

这是一个奇怪的情况，我们知道我们需要一个比当前团队更了解的人，但我们不知道要问什么问题，因为我们不知道接下来的步骤是什么。这有意义吗？

Answer 1

好的，这告诉了我一些事情：

  

对于某些背景，我们已经完成了模式更改以对数据进行非规范化，优化每个查询，运行多个数据库调优顾问以使我们的索引恰到好处，调整MSSql的服务器选项。

您已经匹配或超过了90％自称为DBA的人能够做到的事情。

问题是很多DBA并不是真正的程序员，他们更多的是在系统管理方面。您需要一名DBA程序员，他不仅非常擅长TSQL，而且还了解您的其他编程语言。

我将大部分时间花在像这样的数据库调优问题上，而且解决方案通常涉及从前端到数据库模式的重大重新设计。您不能孤立地解决这些问题，如果没有对整个架构的完全控制（并且完全理解），您将永远无法获得所需的性能。

你可能是这项工作的最佳人选，你可能会更聪明地聘请某人从繁忙的工作中解脱出来，这样你就可以集中精力解决OLTP的性能问题。

Answer 2

在这里你必须要小心，你最终可能会雇用一个Guru DBA，让他显着提高数据库性能，并且仍然存在根植于其架构的应用程序问题。

一些想法：

1. 采用您优化的最复杂查询，将其提供给具有QA的候选DBA，并让他/她再次优化它。让他们描述他们做了什么以及他们是如何做到的。

2. 确保此人了解硬件，何时使用多个文件组，raid阵列，数据分区，64对32位性能等...

3. 寻找具有某些软件架构背景的人。

4. 向他们询问一些更难的SQL服务器问题，例如。什么是OVER声明？ GUID是不错的主键，为什么，int identity更可取？

Answer 3

在您自己的优化之前将数据库稍微调整一下并将其交给他们。看看他们是否可以将其调整为与您所做的更改相比表现更好或更好。

问他们为什么选择这种技术。

参考参考资料，了解他们最有可能与您的环境相匹配的环境。

Answer 4

一位优秀的DBA将能够在面试中告诉您他们接下来要采取的步骤。你应该更多地关注这里的思维过程，而不是解决问题的方法。当DBA提供了一些解决方案时，请返回并测试它们并询问它们为什么要以这些方式解决问题。

这种方法可以很快将男性与男性区分开来。

Answer 5

您与db的最高性能有多接近？使用此技术创建无法解决的OLTP问题非常容易。正如埃里克所说，整体架构的重新设计可能是有序的。更多ram，只需添加更多内存：）

Answer 6

当然，如果没有看到数据库，很难说什么是最佳的优化方式。鉴于您所做的事情，您可能需要聘请数据库设计师 - 具有设计和调整您所拥有的大小范围的数据库的经验。在询问他们如何解决问题时，看看面试官是否会首先查看效果不佳的查询并运行探查器以查看正在发生的事情并识别它们。这个人应该能够回答有关参数嗅探的具体问题以及如何避免它，可以使用哪些方法来避免游标，为什么需要更新统计信息，什么使得查询可以理解。我会在性能调优中看到一些常见的事情。网络是否最大化（有时它不是数据库），整体设计是否经过深思熟虑，您使用的SQl代码通常表现不佳吗？如果你的所有搜索都允许使用通配符作为第一个字符，那么甚至不可能让它们变快。如果您的联接使用多列自然键，则它们应该比它们应该更慢。您是否在一个字段中存储了多条信息，从而导致大量操作以获取数据？你在使用游标吗？你在使用功能吗？你不应该重用代码吗？您是否总是返回所需的最少信息？你关闭连接了吗？你有僵局吗？你的桌子行太宽了吗？您是否在特定表中有太多记录（清除旧记录或将它们放到存档数据库中会产生巨大差异）？你的代码有多少是面向行而不是面向设置？这些是有经验的数据库人员会看到的事物的例子，因此他们应该在访谈中讨论的事情类型。

一些不好的代码示例（你知道你已经优化了什么）可以让你对他们如何调整它们的方法有一个很好的了解。你想要一个有条不紊且具有深度SQL知识的人。

有一些关于性能调整的好书 - 我建议在面试之前先让它们熟悉它们。