UGISS Community

Ciao a tutti,

a) Ho un server win2003 - 64 bit con su installato sqlserver 2005 64bit

b) Ho un altro server win2003 - 32 bit con i soli strumenti client di connettività

Se eseguo una stored procedure da a) impiego circa 4.30 minuti ad ottenere il recordset (90 righe)

Se eseguo la stessa stored procedure da b) dopo 30 secondi mi va in timeout.

Se copio il contenuto della stored procedure e la eseguo come query normale sia da a) che da b) ottengo le mie belle 90 righe in un secondo.

Ci sto impazzando, qualcuno ha idea di cosa possa essere?

 Grazie ciao marco

se può aiutare:

all'interno della sotred procedure, prima di fare la select cè un controllo sui parametri di input:

if @variabile<=0 set @variabile=NULL

eseguendo la query con

execute nomeprocedura 0,0,0

impiega 4 minuti, o va in timeout

se invece eseguo execute nomeprocedura null,null,null

è istantanea... idee??

ciao marco

Marco Ciao,

puoi postare la definizione della procedura e un esempio di lancio ?

Come è definita la variabile locale @variabile ?

Ciao !

Sergio

ciao, e grazie in anticipo per l'interessamento

inizialmente la procedura era definita cosi: 

 ALTER PROCEDURE [dbo].[S_INDICATORI_P2_1](@TipoSelezione int,@Anno int,@Mese int,@UtenteCapocommessa int,@IDTipoProgetto int,

 IF @IDAsa<=0 set @IDAsa=NULL

IF @Utente_ResponsabileASA<=0 set @Utente_ResponsabileASA=NULL

IF @UtenteCapocommessa<=0 set @UtenteCapocommessa=NULL

IF @IDTipoProgetto<=0 set @IDTipoProgetto=NULL

if @gUtente_supervisor<=0 set @gUtente_supervisor=NULL

IF @TipoSelezione=1

SET NOCOUNT ON

declare @IDTipoProgetto int

declare @Utente_ResponsabileASA int

set @UtenteCapocommessa =@iUtenteCapocommessa

set @IDTipoProgetto =@iIDTipoProgetto

set @IDAsa =@iIDAsa

set @Utente_ResponsabileASA =@iUtente_ResponsabileASA

IF @IDAsa<=0 set @IDAsa=NULL

IF @Utente_ResponsabileASA<=0 set @Utente_ResponsabileASA=NULL

IF @UtenteCapocommessa<=0 set @UtenteCapocommessa=NULL

IF @IDTipoProgetto<=0 set @IDTipoProgetto=NULL

if @gUtente_supervisor<=0 set @gUtente_supervisor=NULL

 ....

bianco:

in pratica ho modificato il nome dei parametri facoltativi, ho dichiarato le variabili internamente alla sp e il tempo di esecuzione della sp è tornato < di un secondo... ma è solo una banale 'pezza' vorrei capire dove/cosa sbaglio, o meglio cosa han cambiato riespetto alla versione 2000 di sql server, che non non mi ha mai dato problemi.. 

Marco Ciao,

premetto che non ho mai fatto prove sulla versione di SQL Server 2005 a 64 bit.

Nella prima versione della [dbo].[S_INDICATORI_P2_1] i paramentri di input (passati come costanti) vengono modificati all'interno della stored procedure stessa... dopo questa modifica la lettura del paramentro probabilmente provoca il time out (ma è una ipotesi ). Io proverei a modificare a prima versione lasciando un solo parametro e dopo l'assegnazione con il SET proverei a stampare con PRINT il valore del parametro...

Faccio un po' di ricerche e se scopro qualcosa ti scrivo...

Ciao!

ciao, il parametro assume il valore null come voluto.

il tempo di esecuzione della sp aumenta all'aumentare del numero delle variabili assegnate.

cmq credo che tu abbia ragione, sembra che al 2005 non piaccia che gli vengano cambiati i valori dei parametri..

..però è strano che a tutte le altre storedprocedure (anche piu complesse di quella in questione) non dia fastidio, le selezioni dove ho parametri facoltativi le ho impostate tutte in modo simile es:

select .... from ... join ...

where (@parametro1 is null or colonna=@parametro1) and

(@parametro2 is null or colonna2 like @parametro2) and

...

sto sollecitando il buon vecchio sistemista ad installare tutte le servicepack e hotfix disponibili; non ha senso questo errore....

installato tutto l'installabile. niente da fare...

Marco,

prova con questa tecnica, che ho imparato dal nostro presidente: mentre la query è in esecuzione, in un'altra connessione, esegui il comando

SELECT * FROM sys.dm_os_waiting_tasks WHERE session_id = <session_id della connessione su cui hai eseguito la stored procedure>

Cosa leggi nel campo wait_type ?

Altrimenti si potrebbe eseguire la stored procedure in debug utilizzando visual studio.

Ciao !

Ciao, ho applicato il database engine tuning advisor,

ho applicato ciecamente quanto mi ha consigliato... e al momento il problema non appare piu, l'esecuzione di sta benedetta storedproc è tornata velocissima ( < 1 secondo).

ora il campo wait_type è = OLEDB, ma come ho detto, ha ripreso a funzionare perfettamente..

ho capito che ho bisogno di un buon corso, o almeno di un buon libro su sql server.

Anche se sembra risolto, vorrei capire il perchè ha risolto. se mancavano degli indici e delle statistiche, la stored proc sarebbe dovuta essere sempre lenta, e non variare il comportamento in base ai parametri passati, no?

ti ringrazio per il tempo che mi hai dedicato, spero di poter ricambiare in qualche modo.

ciao marco

bianco:

ho applicato il database engine tuning advisor

mmm... ma il Database Engine Tuning Advisor ha suggerito l'applicazione di qualche indice che hai creato ? Se sì il miglioramento potrebbe essere dovuto all'utilizzo dei nuovi indici applicati.

Ciao!

bianco:

Ci sto impazzando, qualcuno ha idea di cosa possa essere?

E' un problema conosciuto come "Parameter Sniffing". In SQL Server 2005 è molto meno presente che in SQL 2000, ma in casi rari ancora si presenta.

Un modo per risolvere il problema è quello di dichiarare delle variabili nella stored procedure e quindi di assegnare a tali variabili i valori dei parametri. Nel codice utilizzerai le variabili e non i parametri.

Un pò di link sull'argomento:

http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx

http://blogs.msdn.com/queryoptteam/archive/2006/03/31/565991.aspx 

http://nflanagan.blogspot.com/2006/07/parameter-sniffing.html

bianco:

Se eseguo una stored procedure da a) impiego circa 4.30 minuti ad ottenere il recordset (90 righe)

Se eseguo la stessa stored procedure da b) dopo 30 secondi mi va in timeout.

Questa diverso comportamente dipende dal fatto che su "b" hai impostato un valore di timeout per l'esecuzione delle query nel Management Studio, mentre invece su "a" no.

è vero, mi sembra solo un pò strano che prima (quando girava su un server 32 bit) non avesse mai dato problemi, e che in base al valore dei parametri cambiassero cosi tanto i tempi di risposta, e che tutte le altre (centinaia) di stored procedure che hanno la stessa logica nel confronti dei parametri di input, non abbiano dato problemi.. mah..

grazie mille, li leggo subito