通过在SQL03上“查找CPU消耗前十的查询”（脚本如下所示）时发现，第一名是一个奇怪的语句。
SELECT TOP ( 10 )
SUBSTRING(ST.text,( QS.statement_start_offset /2 ) + 1,
(( CASE statement_end_offset
WHEN -1 THENDATALENGTH(st.text)
ELSE QS.statement_end_offset
END- QS.statement_start_offset) / 2 ) + 1)
ASstatement_text ,
execution_count ,
total_worker_time / 1000 AStotal_worker_time_ms ,
(total_worker_time / 1000 ) / execution_count
ASavg_worker_time_ms ,
total_logical_reads ,
total_logical_reads / execution_count ASavg_logical_reads ,
total_elapsed_time / 1000 AStotal_elapsed_time_ms ,
(total_elapsed_time / 1000 ) / execution_count
ASavg_elapsed_time_ms ,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY total_worker_time DESC
语句展开为：
SELECT "Tbl1012"."FMSKU""Col1060","Tbl1012"."FMID" "Col1063","Tbl1012"."ToID""Col1067"
FROM "ARCHIVE"."dbo"."Log" "Tbl1012" WITH (NOLOCK)
WHERE "Tbl1012"."ToLotnum"=@P1
AND "Tbl1012"."TransactionType"='MV'
AND "Tbl1012"."ReasonCode"='PG'
AND "Tbl1012"."FMLocation"like 'STAGE%' COLLATE Chinese_PRC_CI_AS
AND "Tbl1012"."ToLocation"like 'STAGE%' COLLATE Chinese_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。
