Molto spesso succede di trovarsi in situazioni per cui il tempo di esecuzione dello stesso comando lanciato da Management Studio e direttamente da applicativo sia totalmente differente.Ed è qui che nascono domande come "Ma perchè se lancio da SSMS l'esecuzione è istantanea mentre sul log dell'applicazione vedo un tempo ingiustificabile?".
Una delle parti più legate alla problematica è sicuramente quella che parla delle SET OPTION ed in particolare della ARITHABORT option:
"You might see where this is getting at. Your application connects with ARITHABORT OFF, but when you run the query in SSMS, ARITHABORT is ON and thus you will not reuse the cache entry that the application uses, but SQL Server will compile the procedure anew, sniffing your current parameter values, and you may get a different plan than from the application. So there you have a likely answer to the initial question of this article. There are a few more possibilities that we will look into in the next chapter, but the by far most common reason for slow in the application, fast in SSMS in SQL 2005 and later is parameter sniffing and the different defaults for ARITHABORT."
Vi invito a dare una letta a questo articolo, perchè non si sofferma solo sulle motivazioni possibili, spiega anche molto bene come il motore di SQL Server si muove per ricavare piani di esecuzione.
Stay Tuned! 