Nenhum plano de consulta para procedimento no SQL Server 2005

Question

Temos um banco de dados SQL Server com 150-200 Procs armazenados, todos os quais produzem um plano de consulta visível em sys.dm_exec_query_plan, exceto um. De acordo com http://msdn.microsoft.com/en-us/library/ms189747.aspx:

Sob as seguintes condições, nenhuma saída do showplan é retornada na coluna Query_plan da tabela retornada para sys.dm_exec_query_plan:

• Se o plano de consulta especificado usando o Plan_Handle foi despejado do cache do plano, a coluna Query_plan da tabela retornada será nula. Por exemplo, essa condição pode ocorrer se houver um atraso de tempo entre quando a alça do plano foi capturada e quando foi usada com sys.dm_exec_query_plan.
• Algumas instruções transact-sql não são armazenadas em cache, como declarações de operação a granel ou declarações contendo literais de cordas maiores que 8 kb de tamanho. O XML Showplans para tais instruções não pode ser recuperado usando SYS.DM_EXEC_QUERY_PLAN, a menos que o lote esteja executando atualmente porque eles não existem no cache.
• Se um lote transact-sql ou procedimento armazenado contiver uma chamada para uma função definida pelo usuário ou uma chamada para o SQL dinâmico, por exemplo, usando EXEC (String), o XML ShowPlan compilado para a função definido pelo usuário não estiver incluído na tabela retornada por sys.dm_exec_query_plan para o lote ou procedimento armazenado. Em vez disso, você deve fazer uma chamada separada para sys.dm_exec_query_plan para o identificador de plano que corresponde à função definida pelo usuário.

E depois..

Devido a uma limitação no número de níveis aninhados permitidos no tipo de dados XML, SYS.DM_EXEC_QUERY_PLAN não pode retornar planos de consulta que atendam ou excedam 128 níveis de elementos aninhados.

Estou confiante de que nenhum deles se aplica a este procedimento. O resultado nunca tem um plano de consulta, não importa qual seja o tempo, então eu não se aplica. Não há literais longas de cordas ou operações em massa, então 2 não se aplica. Não há funções definidas pelo usuário ou SQL dinâmico, então 3 não se aplica. E há pouco ninho, então o último não se aplica. De fato, é um proc, muito simples, que estou incluindo na íntegra (com alguns nomes de tabela alterados para proteger os inocentes). Observe que as travessuras que afetam os parâmetros postdate o problema. Isso ainda acontece mesmo se eu usar os parâmetros diretamente na consulta. Alguma idéia de por que não tenho um plano de consulta visível para este PROC?

ALTER PROCEDURE [dbo].[spGetThreadComments] 
    @threadId int, 
    @stateCutoff int = 80, 
    @origin varchar(255) = null, 
    @includeComments bit = 1, 
    @count int = 100000
AS

if (@count is null)
begin
    select @count = 100000
end

-- copy parameters to local variables to avoid parameter sniffing
declare @threadIdL int, @stateCutoffL int, @originL varchar(255), @includeCommentsL bit, @countL int
select @threadIdL = @threadId, @stateCutoffL = @stateCutoff, @originL = @origin, @includeCommentsL = @includeComments, @countL = @count

set rowcount @countL

if (@originL = 'Foo')
begin
    select * from FooComments (nolock) where threadId = @threadId and statusCode <= @stateCutoff 
    order by isnull(parentCommentId, commentId), dateCreated
end
else
begin       
    if (@includeCommentsL = 1)
    begin
        select * from Comments (nolock) 
            where threadId = @threadIdL and statusCode <= @stateCutoffL
            order by isnull(parentCommentId, commentId), dateCreated
    end
    else
    begin
        select userId, commentId from Comments (nolock) 
            where threadId = @threadIdL and statusCode <= @stateCutoffL
            order by isnull(parentCommentId, commentId), dateCreated
    end
end

Answer 1

Hmm, talvez as mesas não sejam realmente mesas. Eles poderiam ser visões ou outra coisa.

Answer 2

tente colocar dbo. Ou qualquer que seja o esquema na frente de todos os nomes da mesa e verifique novamente.

Veja este artigo:

http://www.sommarskog.se/dyn-search-2005.html

Citação do artigo:

Como você pode ver, refiro-me a todas as tabelas em notação de duas partes. Isto é, também especificado o esquema (que no SQL 7/2000 a linguagem normalmente é chamado de proprietário.) Se eu deixasse de fora o esquema, cada usuário receberia sua própria versão privada do plano de consulta