2015-12-16 12 views
5

Ho una query che sto inserendo in una stored procedure. Quando eseguo la query con variabili locali, la query impiega circa 1 secondo per essere eseguita. Quando inserisco la stessa query all'interno di una procedura memorizzata e richiama l'SP, sono necessari circa 2 minuti per l'esecuzione.SQL Server Query viene eseguito lentamente quando inserito all'interno di una stored procedure

Da precedenti domande in SO, penso che possa essere correlato allo sniffing dei parametri. Quando ho avuto questo problema prima ho dichiarato variabili locali all'interno del mio SP e poi ho usato le variabili locali per tutto il tempo. Questo ha funzionato in passato, ma in questo caso non sembra essermi d'aiuto.

Al momento ho

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

ho anche provato ad aggiungere WITH RECOMPILE come l'aggiunta in modo

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 

WITH RECOMPILE 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

Inoltre, ho provato il OPTION(RECOMPILE) alla fine della mia SP in questo modo:

SELECT * 
    FROM #Output 

OPTION(RECOMPILE) 

END 
GO 

Ho anche provato a utilizzare:

OPTION(OPTIMIZE FOR UNKNOWN) 

Così come:

OPTION(QUERYTRACEON 4136) 

su questa opzione, non ho autorizzazioni appropriate per query di tracciamento.

Nessuna delle 5 correzioni precedenti sembra risolvere il problema poiché la procedura memorizzata impiega ancora tra 2 minuti e 2 minuti e 30 secondi per la stessa query che impiega 1 o 2 secondi all'esterno della stored procedure.

Queste correzioni tutto è venuto da questo articolo 'Different Approaches to Correct SQL Server Parameter Sniffing'

Qualcuno ha avuto problemi simili? Grazie per il tuo tempo!

SQL Server 2008R2

+0

Sembra un parametro di sniffing e non ho altra idea di cosa possa essere. Puoi controllare questo articolo per vedere se offre soluzioni aggiuntive che non hai già provato: http://www.sommarskog.se/query-plan-mysteries.html –

+0

'Ho provato ad aggiungere l'OPZIONE (RECOMPILE) a la fine del mio SP' - dovrebbe essere posizionato dopo la query offendente. Ma se "con ricompilare" non ha funzionato, dubito che questa correzione lo farà. –

+0

Ho avuto esattamente gli stessi sintomi e la creazione di copie locali di params l'ha sempre risolto. L'unica differenza è che ho sempre usato un'istruzione SET anziché un'istruzione SELECT per copiare i valori nelle variabili locali. –

risposta

0

Purtroppo non ho a capire perché la stessa query esattamente avuto così tanti problemi, quando sono immessi all'interno di una stored procedure rispetto ai soli istruzioni SQL.

Come "soluzione" ho trascorso un po 'di tempo a ottimizzare le mie query all'interno dell'SP. Ho realizzato che un tavolo a cui stavo partecipando era molto grande (milioni e milioni di righe) quindi quello che ho fatto è stato prendere i dati rilevanti dalla grande tabella e creato una tabella temporanea per tenerlo, quindi unito alla tabella temporanea (molto più piccola) e quello sembrava fare il trucco. L'SP è in esecuzione in 3-4 secondi ora.

Sono ancora un po 'nuovo di SQL al di fuori delle basi, quindi sto imparando molto. Lascia che questo serva da promemoria per esaminare attentamente le tue domande, c'è spesso margine di miglioramento. Questo sembra un po 'come lo scotch e le graffette, ma il mio problema è stato risolto.

Grazie a tutti per il vostro contributo.

+0

Piuttosto che una tabella temporanea, è probabile che sia meglio aggiungere un indice alla tabella grande che corrisponde alle condizioni di join. –

+0

Vero ma non ho i permessi per farlo, anche se potrei chiedere al nostro team DBA forse. – Soulfire

Problemi correlati