我有一个Web应用程序，由SQL Server数据库支持，直到昨天才运行良好。现在我遇到了该应用程序的性能问题。我如何知道它是应用程序问题还是数据库问题或硬件问题？
任何人都可以帮助指导我完成基本故障排除的分步过程，以确定性能问题是否与应用程序，数据库或硬件有关？
答案 0 :(得分：1)
在您接近诊断问题之前，这个问题还需要其他问题：
你有源代码吗？您是否知道应用程序出现性能问题时正在执行哪些SQL语句？如果是这样，您可以直接从SQL控制台窗口对DB运行SQL语句，并查看性能问题是否完全在数据库中。
您是否可以访问数据库日志？我不熟悉SQL服务器日志，但我知道Oracle有很多它们，而且它们都很好。
假设数据库似乎响应令人满意，是否涉及网络？这是一个Web应用程序吗？您是否可以访问Web服务器的Web日志？
问题是否仅限于某些用户？有些用户遇到过这个问题，有些用户没有吗？
答案 1 :(得分：1)
运行Profiler。按期限过滤，其中值> 50毫秒，你很可能找到最严重的罪犯。如果语句是SELECT，则将它们复制到查询分析器并运行显示实际执行计划并相应调整（创建索引等）。
答案 2 :(得分：1)
首先要做的事情是......定义所有变更的清单，没有变化太小。
一旦有了更改列表，就会开始逐个备份。
一步一步的细节呃......这是一个艰难的。我一直在寻找明显的东西。如果我看到一些看起来很可疑的东西，我会停止我正在做的事情并进一步调查，否则我会把它放在白板上作为可能的问题。
1）我总是首先创建一个列表，其中包含每个基础架构（防火墙，交换机，数据库，HotFix，Web服务器......）所发生的一切变化。如果某些内容发生了变化，那么我总是要求有关该变化的更多信息。我的猜测是你没有任何这样的信息，而不是我试图让你失望它需要组织一段时间才能达到适当的成熟度水平，他们的操作开始捕获所有的变化。
2）开始查看日志。由于我的所有应用程序都在Windows Server上，因此我首先查看应用程序事件日志。我正在寻找应用程序错误。接下来我转到系统事件日志，我再次寻找错误。接下来我可以对我的IIS日志进行分析....我通常在这些日志中启用了时间字段，因此我专注于长时间运行的请求。
3）接下来我将看一下DB服务器。我将要求我的DBA运行SQL事件探查器以查看需要很长时间的查询。我还要求他们收集有关数据库锁的信息。我还要求他们检查DB的健康状况（索引是最新的，表/索引是否碎片化）。
4）接下来，我有Windows Server Admins收集Web服务器和SQL Server上的性能计数器统计信息。我想查找内存泄漏，IO排队，CPU利用率。
答案 3 :(得分：0)
第一个嫌疑人是代码的变化。如果代码中发生了某些事情并且性能问题与此相关，则这是主要的嫌疑人。
如果没有改变，那么数据库是一个很好的嫌疑人。假设您的标记使用的是MS-SQL，则有两种可能的情况：
数据达到了某个级别，引擎改变了用于执行查询的算法，这个新算法需要不同的索引。
只需要重建索引。从this link开始，重建索引非常简单。
答案 4 :(得分：0)
用户会说：它运行缓慢
老板会说：修理它
网络小伙子会说：这是一个数据库问题
数据库家伙会说：这是一个应用问题
应用程序的人会说：这是一个网络问题