none
lentezza query RRS feed

  • Domanda

  • Ciao a Tutti
    ho verificato che con un sistem SQL 2008 r2 32 bit exp installato su un 2003 server devo necessariamente eseguire ogni giorno il comando
    use MioDataBase
    go
    EXEC sp_updatestats @resample = 'resample'
    GO
    per evitare che in fase di selezione vi siano dei ritardi impressionanti da 20 sec. a 1 sec.

    Quello che trovo strano è che devo eseguire questo comando anche un paio di volte nell'arco della giornata.

    Che io sappia nelle tabelle interessate, non vi sono indici ne chiavi primarie..

    parliano di tabelle da 7000 record a 70000 record

    Qualche idea ?
    Grazie
    MV

    martedì 16 aprile 2013 19:32

Risposte

  • Il numero di record è troppo basso  per generare quei tempi a prima vista.. hai provato a profilare la query e passarla col Data Execution Plan?

    Bisogna capire da dove vengono quei rallentamenti, il resample delle statistiche le riporta all'ultimo "save game" da quanto ho visto (: .. potresti provare anche a lanciare una volta con l'opzione ALL e vedere se funziona.. se l'update automatico delle statistiche fosse disabilitato si avvierebbe da solo lanciando l'updatestats.

    martedì 16 aprile 2013 20:34
  • Ciao Massimo,

    Il fatto che nelle tabelle tu non abbia né indici, né chiavi primarie, sicuramente non aiuta SQL Server.
    In assenza totale di indici, hai delle "Heap Tables"; supponi di scrivere una query sulla tua tabella da 70000 record che restituisce solo l'ultimo record: SQL Server è costretto a fare 70000 operazioni di lettura sulla tabella per arrivare fino all'ultimo record e restituirlo.

    Il fatto che tu ogni tanto debba fare un sp_updatestats, probabilmente è perché su queste tabelle hai delle operazioni di insert che, ovviamente, modificano la distribuzione dei dati al loro interno. Con un "update stats" tu informi SQL Server sullo stato della distribuzione dei dati nelle tabelle, ma se operazioni di inserimento o aggiornamento modificano questi dati di frequente, la distribuzione cambia.

    In base alle query che vengono fatte su queste tabelle, ti consiglio di creare alcuni indici: vedrai che le prestazioni cambieranno in modo significativo. Poi potremo discutere su quanto spesso riorganizzare gli indici, ma su tabelle così piccole non sarà un grosso problema.

    HTH,


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org


    sabato 27 aprile 2013 08:38

Tutte le risposte

  • Il numero di record è troppo basso  per generare quei tempi a prima vista.. hai provato a profilare la query e passarla col Data Execution Plan?

    Bisogna capire da dove vengono quei rallentamenti, il resample delle statistiche le riporta all'ultimo "save game" da quanto ho visto (: .. potresti provare anche a lanciare una volta con l'opzione ALL e vedere se funziona.. se l'update automatico delle statistiche fosse disabilitato si avvierebbe da solo lanciando l'updatestats.

    martedì 16 aprile 2013 20:34
  • Ciao Massimo,

    Il fatto che nelle tabelle tu non abbia né indici, né chiavi primarie, sicuramente non aiuta SQL Server.
    In assenza totale di indici, hai delle "Heap Tables"; supponi di scrivere una query sulla tua tabella da 70000 record che restituisce solo l'ultimo record: SQL Server è costretto a fare 70000 operazioni di lettura sulla tabella per arrivare fino all'ultimo record e restituirlo.

    Il fatto che tu ogni tanto debba fare un sp_updatestats, probabilmente è perché su queste tabelle hai delle operazioni di insert che, ovviamente, modificano la distribuzione dei dati al loro interno. Con un "update stats" tu informi SQL Server sullo stato della distribuzione dei dati nelle tabelle, ma se operazioni di inserimento o aggiornamento modificano questi dati di frequente, la distribuzione cambia.

    In base alle query che vengono fatte su queste tabelle, ti consiglio di creare alcuni indici: vedrai che le prestazioni cambieranno in modo significativo. Poi potremo discutere su quanto spesso riorganizzare gli indici, ma su tabelle così piccole non sarà un grosso problema.

    HTH,


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org


    sabato 27 aprile 2013 08:38