通过在SQL03上“查找CPU消耗前十的查询”（脚本如下所示）时发现，第一名是一个奇怪的语句。

SELECTTOP(10)SUBSTRING(ST.text,(QS.statement_start_offset/2)+1,((CASEstatement_end_offsetWHEN-1THENDATALENGTH(st.text)ELSEQS.statement_end_offsetEND-QS.statement_start_offset)/2)+1)ASstatement_text,execution_count,total_worker_time/1000AStotal_worker_time_ms,(total_worker_time/1000)/execution_countASavg_worker_time_ms,total_logical_reads,total_logical_reads/execution_countASavg_logical_reads,total_elapsed_time/1000AStotal_elapsed_time_ms,(total_elapsed_time/1000)/execution_countASavg_elapsed_time_ms,qp.query_planFROMsys.dm_exec_query_statsqsCROSSAPPLYsys.dm_exec_sql_text(qs.sql_handle)stCROSSAPPLYsys.dm_exec_query_plan(qs.plan_handle)qpORDERBYtotal_worker_timeDESC





语句展开为：

SELECT"Tbl1012"."FMSKU""Col1060","Tbl1012"."FMID""Col1063","Tbl1012"."ToID""Col1067"FROM"ARCHIVE"."dbo"."Log""Tbl1012"WITH(NOLOCK)WHERE"Tbl1012"."ToLotnum"=@P1AND"Tbl1012"."TransactionType"='MV'AND"Tbl1012"."ReasonCode"='PG'AND"Tbl1012"."FMLocation"like'STAGE%'COLLATEChinese_PRC_CI_ASAND"Tbl1012"."ToLocation"like'STAGE%'COLLATEChinese_PRC_CI_AS


发现该语句里的表别名和列别名很奇怪。

于是，开启了SQL03上的Profiler跟踪。在“General”标签页，选择Standard模板。在“Events Selection”标签页，选择需要跟踪的事件类，勾选“Show all columns”，这里最关键的几列务必要选择：HostName、SessionLoginName和DatabaseName。然后点击“Column Filters…”，TextData在Like过滤条件中输入%Tbl1012%。开启跟踪。


根据捕获的输出结果，来源主机为SQL01，会话登录名为ARCHIVE，数据库名为master。

于是，在SQL01上开启Profiler跟踪。在“General”标签页，选择TSQL_SPs模板。在“Events Selection”标签页，务必选择“SP:StmtStarting”事件类，勾选“Show all columns”，务必选择：LineNumber、SessionLoginName和SourceDatabaseID。点击“Column Filters…”，TextData的Like过滤条件输入%STAGE3%。开启跟踪。

LineNumber

包含存在错误的行的行号。对于涉及 Transact-SQL 语句的事件，像SP:StmtStarting，LineNumber包含的是存储过程或批处理中语句的行号。

参见：https://msdn.microsoft.com/zh-cn/library/ms190762(v=SQL.100).aspx



从捕获的输出中，我们可以知道该语句出自SP的2223行附近。于是，找到该SP的2223行得到验证。



然后通过该LinkedServer的“Local Login”和“Remote User”的对应关系进一步验证了。



总结

含有LINKEDSERVER的查询的别名在远端被内部命名为TBLxxxx\COLxxxx。