如何解决 orm 查询干扰其他应用程序

Question

嗯，这是假设的场景，但我想了解的是从死后日志（例如 SQL Server Profiler 跟踪）到识别 ORM 情况下的代码的路径。为了让它不会太模糊，请考虑这样的场景：

• SQL Server 2008
• 实体框架作为 ORM

那么，在这种情况下，DBA（也是 VB.Net 开发人员）从日志中诊断哪些代码（在这种情况下，Linq 查询）造成问题的通用路径是什么？在这种情况下，该应用程序正常，但会影响使用相同数据库/服务器的其他应用程序的响应时间。

那会与 Java+Hiberate 进程有很大不同吗？

编辑：我想了解从跟踪到罪魁祸首元查询的路径。如果应用程序中有 SQL，这意味着“在文件中查找”会话（在极端情况下可能带有一些正则表达式）可以将检查任务的目标减少到几十个可疑对象，而不是十分之一甚至数百个源文件。使用 ORM，如何使用 ORM（在这种情况下：EF）到达那个阶段？

Answer 1

我强烈建议在连接中使用元数据，以便追溯到应用程序。在连接字符串中，有一个应用程序名称。还有会话数据可以以CONTEXT_INFO的形式使用

/sf/ask/22644611/

当然，所有这些都需要应用程序更改，但它通常有利于跟踪和审计，因此从一开始就进行烘焙非常有用。