none
[SQL SERVER 2008 R2 SP2] Query lenta da applicazione .NET, veloce da SSMS RRS feed

  • Domanda

  • Buongiorno,

    scrivo per un problema riscontrato su un SQL Server 2008 R2 SP2 riguardante una query di ricerca dati (fulltext) che, eseguita dall'applicazione web ASP.NET, a volte, è molto lenta (o addirittura va in timeout), ma che eseguita dalla Management Console è velocissima.

    Su internet ho raccolto il suggerimento di impostare la

    SET ARITHABORT ON

    dall'applicazione e qualcosa sembra migliorato anche se non risolto. Dopo un po' di tempo, le query cominciano a rallentare comunque ed è necessario riavviare l'istanza per riportare tutto nelle condizioni ottimali. In ogni caso, dalla console funziona sempre (anche da una console remota).

    E' possibile che questo comportamento sia dovuto al caching dei piani di esecuzione e probabilmente si può risolvere con una OPTION(RECOMPILE) ma voi cosa ne pensate? 

    Avete avuto problemi simili?

    Sono a disposizione per ulteriori chiarimenti sperando che un esperto di SQL Server possa darmi una dritta.

    Grazie

    domenica 2 giugno 2013 11:55

Tutte le risposte

  • Ciao Ore001.. (:

    Quando esegui il tutto dalla management console, è sempre e costantemente veloce? Hai modo di creare un test di confronto tra i due ambienti (Management/Applicazione ASP.net)

    Stai usando Linq2SQL nella tua applicazione web?

    Gli indici delle tue tabelle sono a posto?

    Se il tutto torna a posto riavviando l'istanza, potrebbe significare che la tua applicazione asp.net usi degli indici obsoleti o delle statistiche non aggiornate (questo credo giustificherebbe il lento degrado delle performance al cambio dei dati nelle tabelle)..  

    domenica 2 giugno 2013 22:33
  • Sì, dalla console sembra sempre veloce ("sembra" perché tutte le prove che abbiamo fatto sono andate bene, ma ovviamente non si possono fare mille query di test ...)

    No, non si usa Linq

    Gli indici e le statistiche sono a posto

    Per il comportamento di cui parli alla fine della tua risposta, con la SET ARITHABORT ON le cose sono migliorate ma a causa del "Parameter sniffing" può essere utile la OPTION (RECOMPILE) ? (anche alla luce di alcuni suggerimenti che ho letto in rete ..)?

    Grazie per la risposta

    lunedì 3 giugno 2013 14:57
  • Sicuramente nel tuo caso usare lo statement OPTION(RECOMPILE) può aiutare in quanto essendo una ricerca full text è difficile che il piano di ricerca risulti uguale tra un'esecuzione e l'altra.

    Il fatto che il tuo sistema torni performante solo dopo un riavvio dell'istanza però potrebbe ricondurre il tuo problema di lentezza alle "wait statistics" (che appunto vengono resettate al riavvio dell'istanza), fondamentalmente una traccia di come si muove la coda dei processi all'interno della coda di esecuzione di sql server.

    Potresti provare a resettarle in un manteinance plan notturno (o quando la tua applicazione non è in uso) usando il comando 

    DBCC SQLPERF (‘sys.dm_os_wait_stats’, CLEAR)
    ;

    e vedere se la tua applicazione continua a tendere al crollo delle performance come stà facendo in questo momento.. magari prova una cosa alla volta, anche se in realtà credo che sia il RECOMPILE che questa pulizia dovrebbero raddrizzare un po le cose.

    Ti lascio inoltre il link ad un ottimo articolo che parla appunto delle wait stats, veramente ben scritto. "Wait statistics or tell me where it hurts".

    Un saluto


    lunedì 3 giugno 2013 21:05
  • Grazie Luca, molto gentile, proverò a seguire i tuoi consigli, uno alla volta e ti farò sapere.

    Grazie anche per l'articolo che non mancherò di leggere.

    martedì 4 giugno 2013 11:38
  • Di nulla, torna a farci sapere com'è andata (;
    martedì 4 giugno 2013 12:20
  • Giusto per completezza, il reset delle statistiche non ha funzionato.

    Premetto che la query iniziava con

    WITH Qualcosa ...

    e il rimedio (o workaround) è stato quello di generare un nome sempre diverso (aggiungendo data e ora con millisecondi) tipo

    WITH Qualcosa20130606101200239 ...

    In questo modo non ci sono più problemi e le query sono eseguite nei tempi previsti.

    Anche se ho compreso, a grandi linee, cause e soluzione, sarei contento se qualche esperto (anche di MS) spiegasse in dettaglio il comportamento di SQL Server se non altro per spiegarlo a chi vorrebbe passare tutto ad altro DBMS in azienda ...

    Saluti

    sabato 8 giugno 2013 13:20
  • Scrivendola così praticamente dovresti avere lo stesso funzionamento dell'OPTION(RECOMPILE), è un po come quando nel web si usa un token numerico per impedire il caching delle pagine.

    lunedì 10 giugno 2013 07:27
  • Sì, è vero, ma avevamo provato l' OPTION(RECOMPILE), sebbene non intensamente, ma non avevamo rilevato grandi miglioramenti; a volte il timeout si verificava (cosa che non succede più con il metodo che ti ho descritto).

    E' possibile che il RECOMPILE sia ritenuto come un "suggerimento" e non come un "obbligo"? E' possibile che la cache dei "piani di esecuzione" abbia comunque una certa priorità ?

    lunedì 10 giugno 2013 14:30
  • Non credo.. ma tu stai usando una query secca o una procedura parametrica?

    Bella pensata il concatenare una stringa comunque.. :)

    Generi per caso tabelle temporanee nella tua sessione? 

    lunedì 10 giugno 2013 22:35