Isso é algo que me incomodou, embora nunca tenha causado nenhum problema real, pois geralmente posso localizar essas informações por outros meios, mas alguém pode explicar por que NULL
pode ser retornado nas colunas dbid
, objectid
, e number
do sys.dm_exec_sql_text
DMV, mas ainda produz resultados na text
coluna? Entendo por que a saída retornaria inversamente (por exemplo, todas as colunas, mas text
geraria dados), mas já vi esse comportamento várias vezes em várias versões do SQL Server e a documentação não parece implicar que isso seja possível ou Só estou lendo errado.
Aqui está um exemplo da consulta que estou executando:
SELECT TOP 100
t.*
, s.*
, c.*
FROM sys.dm_exec_query_stats s
LEFT JOIN sys.dm_exec_connections c
ON c.most_recent_sql_handle = s.sql_handle
CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) t
WHERE s.execution_count > 1 AND DATEDIFF (second, creation_time, GETDATE()) > 0
AND t.dbid IS NULL
Aqui está uma amostra de um dos resultados da text
coluna que implica que isso não está relacionado a objetos temporários, que é o que eu normalmente acho que é a causa.
select * from [dbo].[Map_ProviderSpecialty]
Que situação está ocorrendo onde essas colunas estão retornando NULL
valores?
Isso é por design a partir de agora. Há um item de conexão sobre este problema que está fechado a partir de agora.
sys.dm_exec_query_stats coluna DBID NULL para SQL dinâmico - por Theo Ekelmans
Mas no final há um comentário:
Há também algumas soluções alternativas na seção de comentários e também conforme mencionado por @sp_BiltzErik no comentário acima.
Faz sentido para mim que dbid e objectid possam ser NULL para SQL não executados por meio de um procedimento armazenado. Por exemplo, qual banco de dados e objeto deve representar a seguinte consulta ad hoc?
Meu palpite é que, por design, o SQL não quer lidar com a tentativa de tomar uma decisão sobre qual dos três bancos de dados escolher para representar a instrução nos resultados de sys.dm_exec_sql_text().