none
Stored procedure lenta RRS feed

  • Domanda

  • Salve a tutti

    La stessa stored procedure eseguita in locale sulla mia workstation (che non penso sia più potente del server) è molto più veloce rispetto al server di produzione, magari sql server express ha qualche impostazione che devo controllare?

    il server di produzione ha le seguenti caratteristiche:

    TIPO Dell PowerEdge R220
    CPU Intel® Xeon® E3-1231v3
    4x 3.4GHz
    RAM 16GB (DDR3) - (Fino a 32GB)
    HD 2x 3TB (SATA 7.2k rpm)
    RAID Dell PERC H310 0,1,5,10,50 hardware no cache

    Grazie a tutti

    sabato 7 novembre 2015 10:39

Risposte

  • Mi dispiace, ma con queste informazioni non è possibile aiutarti. Da un sistema ad un altro, al di là delle caratteristiche della macchina, cambiano tante altre cose. Inoltre, la logica interna della procedura non è di certo trascurabile. Infine, il database della workstation (express) sarà diverso da quello del tuo server.

    L'unica cosa che posso consigliarti è profilare la tua procedura, statement per statement (puoi usare il SQL Query Profiler) e verificare cosa "va lento". Di più non so dirti.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    lunedì 9 novembre 2015 13:25
    Moderatore

Tutte le risposte

  • Ciao Massimo,

    al di là delle caratteristiche della macchina e dell'installazione, dovresti passarci anche qualche info in più. Ad esempio:

    • il numero delle righe coinvolte nei due ambienti è pressochè lo stesso?
    • ci mandi il piano di esecuzione di entrambe?
    • hai altri processi che girano sul server?
    • hai molto traffico sul server su cui lanci la query, e quindi hai molta concorrenza?
    • In generale le altre query come performano?

    Cerca di essere più dettagliato anche sul tipo di operazione che fai, passaci il comando in modo da poter confrontare il più possibile la tua situazione sulla workstation e quella sul server


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    lunedì 9 novembre 2015 07:42
    Moderatore
  • Ciao, non posto la stored perchè è molto complessa e comunque non avrebbe senso spiegare il funzionamento, quello che posso dire è che si tratta di windows server 2012 e non ha funzioni particolare è un web server con qualche sito. Quello che faccio e prendere la stored dalla mia workstastion ed eseguirla sul server tramite copia e incolla.
    lunedì 9 novembre 2015 08:33
  • Mi dispiace, ma con queste informazioni non è possibile aiutarti. Da un sistema ad un altro, al di là delle caratteristiche della macchina, cambiano tante altre cose. Inoltre, la logica interna della procedura non è di certo trascurabile. Infine, il database della workstation (express) sarà diverso da quello del tuo server.

    L'unica cosa che posso consigliarti è profilare la tua procedura, statement per statement (puoi usare il SQL Query Profiler) e verificare cosa "va lento". Di più non so dirti.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    lunedì 9 novembre 2015 13:25
    Moderatore
  • Ma la logica non ha così importanza, nel senso che comunque rimane uguale anche sul server, la stored fa delle elaborazioni di dati non accede a servizi o oggetti particolari che possano avere performance diverse tra workstation e server. Anche sul server ho sql server express.

    Praticamente se faccio il backup del db sul server e lo porto in locale sempre su sql express, eseguo la stessa stored procedure i tempi risposta cambiano notevolmente.

    Sicuramente la soluzione migliore è quella di snellire la stored, senza dubbio. Mi chiedevo solo se esisteva per caso qualche parametro in sql server che potesse incidere sulla performance di una stored, e soprattutto mi aspettavo che su un server le performance sarebbero state migliori.


    lunedì 9 novembre 2015 14:32
  • Il problema è che così non posso capire cosa sia lento. Prova a profilarla e vedi che succede.. Cosa si ferma e dove, quali sono i wait time che hai e dove, parti dall'utilizzo del profiler per capire cosa succede intanto.

    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    lunedì 9 novembre 2015 14:56
    Moderatore
  • Per far capire meglio il problema ho fatto un backup di del database di produzione e ho fatto un restore dello stesso sulla mia workstaion, dopodichè ho eseguito una semplice query "select * from myview" su entrambi i sistemi e il risultato è il seguente: il tempo di risposta sul server è di 13 secondi mentre sulla mia workstaion è di 1 secondo, la query restituisce 31300 rows.

    Dimenticavo di dire che: la query è eseguita con sql server management studio in entrambi i sistemi e la versioni di entrami i sql server express è 12.0.2269, insomma il i 2 sistemi sono perfettamente allineati.

    A questo punto posso dire che la stored non centra proprio nulla.

    Ho monitorando le attività del disco durante l'esecuzione della query e ho notato delle differenze: il database in oggetto si chiama Gesman e vediamo che sul server durante l'esecuzione della query si attiva una piccola attività di scrittura sul file ldf del database mentre si attiva nessun tipo di attività di lettura

    mentre nella mia workstation lo scenario è molto diverso, vediamo innanzitutto che viene chiama in causa anche il file mdf del database e poi ce un'attività importante in lettura e inscrittura.

    se avete qualche consiglio sono tutto orecchie :)

    grazie

    sabato 5 dicembre 2015 18:53
  • Prova a mostrare il piano di esecuzione delle due query nelle due workstation e a postarcelo qui. Portrebbe essere che sul tuo server si abbia una parallelizzazione a differenza della workstation.

    Oppure, poterbbe essere che le statistiche non siano correttamente aggiornate, il che puoi notarlo facendo un semplice raffronto tra la stima delle righe coinvolte nell'operazione che impiega più tempo nell'esecuzione (lo vedi dal piano)

    Oppure, potresti avere una frammentazione molto marcata sul server, il che lo vedi dalle proprietà dell'indice (fragmentation) o andando a leggere la tabella sys.dm_db_index_physical_stats.

    Parti pure postandoci i due piani di esecuzione.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    sabato 5 dicembre 2015 23:28
    Moderatore
  • Sinceramente non avevo mai sentito la possibilità di creare dei piani di esecuzione quindi non neanche leggerli, comunque li ho salvati in formato XML.
    xml locale

    xml produzione


    domenica 6 dicembre 2015 13:39
  • Io vedo i due piani con lo stesso nome "local.xml" e sono identici, sei sicuro che siano uno locale ed uno di produzione?

    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    giovedì 10 dicembre 2015 15:31
    Moderatore
  • Hai ragione scusa, ho corretto i link di produzione.
    venerdì 11 dicembre 2015 07:42
  • Ok, ho controllato, in locale hai:

    

    e quella parte in produzione non è in quella posizione, ma gestita "dopo". Sei proprio certo che le query siano identiche? Perchè a me sembra che in un caso (locale) faccia la riduzione dei set su cui lavori prima e che quindi filtri più record in anticipo rispetto alla produzione, situazione in cui sembra che lo scan dei dati sia molto più oneroso. Non mi piacciono tanto quegli hash match, perchè di solito SQL li sceglie quando non sa che altro fare (non sceglie Merge e Loop), ma per quello puoi fare due conti anche dopo. 

    Ora però, visto che non vedo per niente la query poichè è la select su una vista, dovresti passarmi lo script della vista vwapp e poi anche il risultato di questo script:

    SET STATISTICS IO ON;
    SET STATISTICS TIME ON;
    
    select * from gesman.dbo.vwapp;
    
    SET STATISTICS IO ON;
    SET STATISTICS TIME ON;

    Trovi i risultati nel tab Messages (Messaggi). E attenzione ad usare le "SELECT *", cerca di evitarle, e mi sbilancio anche se non mi piace, ma sempre in get.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    mercoledì 16 dicembre 2015 10:14
    Moderatore