冒着问一些愚蠢的东西的风险，但谷歌fu不容易得到，但是如何从同义词的基本对象中查询数据库ID（和其他信息）？
有问题的同义词是远程的（指向同一服务器上另一个数据库上的表）。基础对象本身并不固定：每次执行过程时不同数据库上的同一张表。
我想要一个非特定的方法（例如：不想依赖解析base_object_namesys.synonyms 上的列），但如果有人告诉我这是唯一的选择，我会理解的。
既然它引出了一个问题：并发不是问题，只有一个客户端会调用该过程。
在 Profiler 生成的跟踪表中，我尝试使用连接到 sys.allocation_units 的列 ObjectID2 来确定锁的来源。
结果并不好。它标识了许多不在生成跟踪的查询上的表。
谁知道那一栏是什么意思？我的 Google-fu 今天让我失望了。
我用来查找对象的基本查询（最后一个没有au.*, p.*
部分）：
select object_name(p.object_id) AS name, tt.RowNumber, au.*, p.*
from
Trc_Tables_20131210 tt
INNER JOIN sys.allocation_units au
ON tt.ObjectID2 = au.allocation_unit_id AND tt.ObjectID = 0
INNER JOIN sys.partitions p
ON au.container_id = p.hobt_id
WHERE au.type IN (1,3) AND tt.EventClass = 24
编辑：系统健康是学习的一个很好的迹象。但是现在我必须限制自己使用 SQL 分析器跟踪表来研究查询的锁定，因为我无法轻松访问客户的生产服务器。
关于trace：trace中的主要事件是Lock:Acquired。
好吧，这是假设的场景，但我想了解的是从事后日志（比如 SQL Server Profiler 跟踪）识别 ORM 情况下的代码的路径。为了让它不会太模糊，考虑这样一个场景：
- SQL Server 2008
- 作为 ORM 的实体框架
那么，在这种情况下，DBA（也是 VB.Net 开发人员）从日志诊断哪些代码（在本例中为 Linq 查询）造成问题的常见路径是什么？在这种情况下，该应用程序正常，但会影响使用相同数据库/服务器的其他应用程序响应时间。
那会与 Java+Hiberate 进程截然不同吗？
编辑：我想了解从跟踪到元查询的路径。如果应用程序中有 SQL，这意味着“在文件中查找”会话（在极端情况下可能使用某些正则表达式）可以将检查任务的目标减少到几十个可疑文件，而不是十分之一甚至数百个源文件。使用 ORM，如何使用 ORM（在本例中为 EF）进入该阶段？