好吧，显然我还是很喜欢我的供应商。昨晚，我很幸运地与我们的一个应用程序团队和他们的供应商一起参加了一次故障排除电话会议。他们在数据库性能上有问题。通常，当我接到这类电话时，我更喜欢躲在那里而不是真正参与其中，因为供应商通常都很愚蠢，我真的很难不生气。当我说一些事情时，他们通常会忽略我，而应用程序团队通常站在供应商一边，因为这是他们的产品，他们应该最了解。但是，大多数情况下，它只与SQL知识有关，而与他们的产品无关。
总之，我在这里，我在听这个技术支持的家伙，我们叫他" asdf "因为它很容易打字，做出一个又一个离谱的索赔。这个家伙显然比我更了解SQL，因为他能够通过非常少的信息来明确诊断问题(多次)。再说一次，我一直只是在潜伏，因为我认为除非必要，否则我不参与对每个人都是最好的。这正是我今天想说的…在他们有足够的信息做出这样的断言之前，他们会做出疯狂的假设和诊断问题。并不是供应商是最有罪的，但由于这些天我要挑供应商的毛病，我们将继续讨论这个问题。
这就是所发生的事情，我希望你们可以用它作为一个模板来学习如何避免对系统进行故障检修。
供应商要求我运行拉到版本信息和倾倒的是告诉他，有多少用户是包装盒上的进程表的脚本。然后，他使用了以推测，问题是索引碎片。我说的很少，继续听。因此，他们问他，如果他确信这是问题，他肯定说。因此，他们要求我重建索引。我说没问题。它花了大约6分钟，他们又开始测试。问题是仍然存在，高科技被搞糊涂了，为什么没有工作，所以他看了剧本结果再次大胆地宣称，我们的缓存/命中率不够高。这是在20世纪90年代低，他说，这应该是至少95。于是他问，如果这是一个改变我愿意让服务器上，而不首先在开发测试它。交换去或多或少是这样的：
“你的缓存/命中率不够高”。
我:“OK”。
如果不先在dev中进行测试，你愿意在prod中做出这样的改变吗?
我:“我愿意做出什么样的改变?”
"缓存/命中率。"
我:“哦，我明白了。让我看看我能做什么。我会查几件事。哦，等等，问题来了。我不小心把缓存旋钮设置成一团糟。在这里，我把它改成闪电速度，看看效果是否更好。”
你在说什么?我只是让你把缓存命中率调高一点。”
我:“我怀疑我们能否马上给服务器增加内存。这个系统已经运行了一段时间，但没有增加活动，所以我怀疑内存是问题所在。”
等一下，没人让你加内存，我说的是缓存命中率，不是内存。
我:“提高这个比率的唯一方法就是增加内存，所以你让我增加内存了。”
Asdf:“不，这不是改变它的唯一方法。我之前做过，如果你喜欢的话，我可以查找设置。”
我:“是的。事实上，我希望你能找到这个设置。”
(虽然我提醒了他几次，但他一直没有回复)
好了，回到这个故事。在我们用完隐藏/命中大道后，他把目光转向索引。索引不能正确配置，他说。其他人会说，好吧，我们怎么解决这个问题。他说，DBA需要分析索引以确保它们对应用程序足够有效。我还是什么也没说……相信我，这是最好的。然后，几乎和他想到索引的想法一样快，有人说查询从不同的位置快速返回，那么这仍然表明索引问题吗?他说不，一定是和网络有关的。(注意到我还是什么都没说吗?) So he had them run a ping between all the different locations and they returned well within normal parameters. That's when he jumped back onto the index raft but quickly jumped back off when he remembered a hotfix for a Windows memory leak. We have to apply this patch right now, he declares. So they run and get someone from the server team who applies this patch completely untested on a prod box. Now we test again and still have the same issue. I honestly think he forgot about the index solution because he went straight to MaxDOP. We've got 16 CPUs on that box and the MaxDOP is set too high. It has to be lowered right now before the world explodes. I did ask a small question... how do you know the MaxDOP is too high? What should it be for your app? It should be set to 1 he said. Anything higher is too much. But how do you know it's too high now? Because that's the only thing it could be. Well, it's already at 1 now, so what would you like me to set it to? WAIT, we have a log that tells us how long the queries are taking. Hey you there... app guy, go check your log and see how long your queries are taking. Ok so they're taking 50secs and timing out. So the queries are taking 50secs in the DB, and that's way too long so the DBA needs to fix the indexes. They're probably not as efficient as they can be so just get him to iron them out and you'll be ok.
不幸的是，我回到这里，它是这样的:
你无法知道查询是在数据库中运行了50秒还是在网络中，等等。你只知道，它花了50秒的时间来取回数据。”
不，日志显示查询花费了50秒。DB的时间。”
“但是你不可能知道。您所收集的全部是往返统计数据。你不能说查询在数据库中花费了很长时间。”
“是的，我们可以。这就是问题所在。”
“但你声称，到目前为止，你脑子里闪过的一切都是问题所在。我坐在这里，听你在电话中摸索着，抓住你能找到的每一根稻草，在没有任何支持的情况下胡言乱语。现在你说我必须调优你产品的索引。你的产品，直到今天都运行良好。”
“没有别的解释了。”
“当然有。我可以向你保证，除非你去那里并物理地删除一个索引，索引是好的。哦，顺便说一句，我注意到你的填充因子设置为100%，所以我将它们改为80%，这样在主要窗口之间就有了一些喘息的空间。”
“是的，你应该正确地设置它们，你想要我把我们的维修指南发给你，让你看看我们的最佳做法是什么?”
“这个指南是否讨论了适合你的应用程序的填充因子?”
“是的。它给出了完整的建议。”
“这个DB是怎么安装的?”是我们自己创造了这个图式吗?”
“不，应用程序创建所有表和所有东西。”
“但是如果我们想的话，我们可以换桌子，对吗?”我可以改变数据类型和列名吗?”
“不，它必须留的方式是或应用程序将停止工作。”
“但是你让我们创建所有我们自己的指标。为什么不系统附带的表已经创建的索引？”
“它确实有索引。这些是我们创建的索引。”
“所以你是在告诉我你在我们的系统上安装了一个索引不符合你的最佳实践指南的DB ?”为什么不先用自己的最佳实践来创建DB呢?
(没有什么)
伙计，这不是反问。为什么您创建的索引没有遵循您希望我们遵循的最佳实践呢?”
(没有什么)
当所有的尘埃落定后，结果是有一个问题与交换机之间的一些客户端和数据库有问题。
好吧，我知道这篇文章有点长了，所以我现在就给你做个总结。我希望看到更多的供应商花费时间和精力来培训他们的员工掌握基本的故障排除技术。现在他们中的很多人就相当于读茶叶。