Olá, pessoal! Identificar consultas de Linked Server no SQL Server com Extended Events é uma forma eficiente de entender como essas integrações estão sendo utilizadas no ambiente. Este artigo tem por finalidade mostrar uma forma de identificar as consultas que utilizam Linked Server, objeto dentro do SQL Server que serve como “ponte” entre um servidor e outro ou entre uma instância e outra, que pode ser um SQL Server ou outro banco de dados. Existem casos em que o SQL Server, por exemplo, faz consultas com banco de dados Oracle, com joins e outras operações, para retornar dados em uma única query pelo SQL Server.

Neste artigo, você verá 2 ambientes com SQL Server 2017 Developer, mas também pode utilizar o mesmo teste em versões mais recentes, como no SQL Server 2022 ou SQL Server 2025.

Ambiente de teste

Para este caso, vou considerar que o Linked Server já está criado e testado pois o foco será nossa coleta e como utilizá-la. Vamos utilizar o servidor VMSQL01 e o ambiente que chamei de VMSQL02 através do banco dbteste e a tabela Cliente:

Abaixo o script que utilizei, bem simples:

CREATE TABLE Cliente (id INT IDENTITY (1,1), nmcliente varchar(100)) GO   INSERT INTO Cliente (nmcliente) VALUES (‘Empresa 1 LTDA’) GO   SELECT * FROM Cliente GO

Essa coleta que criaremos pode servir tanto para identificar, por exemplo, em um ambiente onde existem 2 ou mais Linked Server’s, quais realmente utilizamos, ou até mesmo para capturar consultas que estão lentas ou que precisam de análise durante um troubleshooting.

Coleta com Extended Events

Vamos criar e utilizar a feature Extended Events (XE), hoje bastante utilizada para coletas e auxílio de análise de desempenho. Para maiores informações, deixo o link da documentação oficial da Microsoft: Quickstart: Extended Events – SQL Server | Microsoft Learn.

O ponto principal dessa coleta é o evento sqlserver.oledb_data_read. Antigamente utilizava-se o SQL Server Profiler, porém, com o avanço da tecnologia foi desenvolvido e aperfeiçoadas as técnicas de coleta, então foi criado o XE para suprir necessidades e garantir um melhor desempenho durante as análises.

Criando a coleta

Para criar essa coleta, podemos utilizar a tela gráfica conforme imagem abaixo:

Também, podemos criar via script, da seguinte forma:

CREATE EVENT SESSION [LinkedServerMonitor] ON SERVER ADD EVENT sqlserver.oledb_data_read( ACTION(package0.process_id,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.nt_username,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_hash_signed,sqlserver.query_plan_hash,sqlserver.query_plan_hash_signed,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)) ADD TARGET package0.event_file(SET filename=N’H:\XE\LinkedServerMonitor.xel’,max_file_size=(50),max_rollover_files=(5)) WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF) GO

Através do script, uma atenção especial para o local de armazenamento. Sugiro que seja armazenado em uma unidade diferente da unidade onde o sistema operacional está instalado, principalmente para algumas coletas específicas. Caso não tenha outro local para armazenar, procure se atentar com algumas variáveis como por exemplo max_file_size e max_rollover_files.

Após criarmos a coleta, podemos habilitar e ela começará a capturar os eventos conforme foram adicionados durante a criação:

Para acompanhar os eventos coletados, podemos utilizar a tela gráfica, através do “Watch Live Data”, mostrando os dados em tempo real, onde teremos uma tela assim:

Agora, para validar nossa coleta, vamos abrir uma nova consulta e utilizar o SELECT abaixo:

select * from SRVVMSQL02.dbteste.dbo.Cliente WHERE nmcliente = ‘Empresa 2 LTDA’

Executando a nossa consulta, teremos um retorno assim:

Voltando a nossa tela de acompanhamento das sessões, podemos ver que temos eventos relacionados ao nosso SELECT:

Veja que temos campos extremamente importantes para um troubleshooting, como por exemplo qual é a consulta, qual é o provider que estamos utilizando, qual a origem do host e qual a aplicação e usuário executando a consulta.

Com esse tipo de consulta conseguimos avaliar se os Linked Server’s que temos em um determinado ambiente realmente são utilizados e quais consultas trafegam por eles. Importante ressaltar que o uso de Linked Server pode afetar o desempenho, deixando as consultas mais lentas e aumentando o tráfego de rede.

Consultas com OPENQUERY

Outra forma de utilizarmos consultas com Linked Server é utilizarmos a cláusula OPENQUERY.

Escrevendo nossa consulta original com OPENQUERY, temos:

select * FROM OPENQUERY(SRVVMSQL02, ‘SELECT * FROM dbo.Cliente WHERE nmcliente = ”Empresa 2 LTDA”’)

Voltando para nossa tela de validação de consultas em execução pelo XE, temos a captura da busca:

Sobre a questão de desempenho, é importante testar e validar as duas formas até porque existem restrições de usabilidade entre elas então dependendo do cenário, haverá problemas de execução. Outro ponto importante é avaliar a quantidade de retorno de dados, independente do método de escrita. As vezes a consulta retorna milhares de linhas, mas será que realmente precisa dessa quantidade no retorno?

Por fim, se você utiliza Linked Server e quer avaliar a usabilidade entre os métodos e melhorar as suas consultas, identificar consultas de Linked Server no SQL Server com Extended Events pode ser um passo importante nesse processo. A CDB conta com especialistas que podem te ajudar com isso e outras questões relacionadas a dados.
Assim, espero que este artigo tenha sido útil para vocês e, até a próxima!

Por Oberdan Schaider