DMF sys.dm_exec_sql_text not showing DBID

Question

I have got this query from

http://technet.microsoft.com/en-us/library/ms181929.aspx

SELECT s2.dbid, 
    s1.sql_handle,  
    (SELECT TOP 1 SUBSTRING(s2.text,statement_start_offset / 2+1 , 
      ( (CASE WHEN statement_end_offset = -1 
         THEN (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
         ELSE statement_end_offset END)  - statement_start_offset) / 2+1))  AS sql_statement,
    execution_count, 
    plan_generation_num, 
    last_execution_time,   
    total_worker_time, 
    last_worker_time, 
    min_worker_time, 
    max_worker_time,
    total_physical_reads, 
    last_physical_reads, 
    min_physical_reads,  
    max_physical_reads,  
    total_logical_writes, 
    last_logical_writes, 
    min_logical_writes, 
    max_logical_writes  
FROM sys.dm_exec_query_stats AS s1 
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
WHERE s2.objectid is null 
ORDER BY s1.sql_handle, s1.statement_start_offset, s1.statement_end_offset;

When i execute it the dbid field is returned as null. Why this behave like this? I want to limit queries from one database but it seems not working.

Many thanks prior to your answers.

Answer 1

1) This behavior is available in SQL2005 -> SQL2008R2.

2) Why sys.dm_exec_sql_text.dbid has (sometimes) NULLs ?

• Within SQL2005 -> SQL2008R2 dbid is NULL "for ad hoc and prepared SQL statements" (see MSDN for SQL Server 2008 R2).
• Within SQL 2012 "For ad hoc and prepared SQL statements, the ID of the database where the statements were compiled" (see MSDN). So, starting from SQL2012 dbid will return a non-NULL value including "ad hoc and prepared SQL statements".

3) To solve this problem in SQL2008 -> SQL2008R2 I used sys.dm_exec_plan_attributes (see MSDN)

SELECT ..., ISNULL(s2.dbid,CONVERT(SMALLINT,att.value)) AS my_dbid, ...
FROM sys.dm_exec_query_stats AS s1 
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2 
CROSS APPLY sys.dm_exec_plan_attributes(s1.plan_handle) att
WHERE att.attribute='dbid

Answer 2

I found this this post on Microsoft connect. It explains that dbid can be null in the following way:

Sql_handle is a hash value which identifies SQL text of the batch being submitted to the server. Since it identifies just the text, it can be submitted against different databases and still be the same. Thus, sql_handle cannot uniquely identify which database this batch/query was submitted against for an ad-hoc statement.

Stored procedure, on other hand, always have the database it resides in and thus we can populate this column.