Sql Server 2008 Express - Tempi esecuzione queries

di il
6 risposte

Sql Server 2008 Express - Tempi esecuzione queries

Buongiorno a tutti,
scrivo qui perché avrei bisogno di alcune informazioni circa le performances di Sql Server.

Nel corso del tempo la quantità di dati che gestiamo nel nostro database, appunto Sql Server 2008 Express, è cresciuta notevolmente e l'incremento è costante. Questa crescita ha comportato un considerevole aumento di tempo nell'esecuzione delle queries perciò abbiamo pensato di passare alla versione a pagamento di SQL. Prima però di fare questo cambio, volevo avere alcuni vostri pareri:
è possibile che la versione a pagamento, in questo caso Sql Server 2014, offra performance migliori da questo punto di vista? Cioè possiamo sperare in una riduzione dei tempi di risposta nell'esecuzione di una query?

Grazie ragazzi,

6 Risposte

  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    Onestamente, nei termini in cui l'hai spiegata, non ci spererei molto; almeno non è sicuramente la prima opzione.

    Di norma questi problemi si verificano perché non è stata fatta una oculata impostazione degli indici nei campi delle tabelle interessate.
    Fino a che contengono pochi dati, le performance non ne risentono.
    Poi, man mano che aumentano, i rallentamente sono sempre più vistosi.

    Non entro nel merito delle chiavi (PK e FK), perché do per scontato che quelle siano state progettate correttamente.

    Ti consiglio
    1) prima di tutto di riesaminare con attenzione gli indici dei campi coivolti nei join delle query, e nelle condizioni di filtro (where).

    2) poi di controllare il piano di esecuzione, che ti rivela gli eventuali colli di bottiglia:

    Visualizzazione dei piani di esecuzione grafici (SQL Server Management Studio)


  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    Grazie Gibra
  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    Il suggerimento è valido. Non ci sono differenze di prestazioni tra Express e "full", solo nella dimensione dei dati gestibili (limitati per Express), più altre funzioni "strane" che nessuno usa mai, o quasi.

    Aggiungerei però lo step 0), cioè l'analisi della selettività degli indice, e il -1, ovvero la determinazione dei piani di accesso ragionevolmente usati ed il relativo pattern.
    Poi c'è la regola -2, ovvero MISURA prima di fare qualsiasi cosa.
  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    +m+ ha scritto:


    Non ci sono differenze di prestazioni tra Express e "full", solo nella dimensione dei dati gestibili
    Ci sono limitazioni nelle funzionalità e limitazioni che possono generare dei colli di bottiglia per quanto riguarda le performance.
    A titolo di esempio, la versione Express di SQL Server ha il limite di 1GB di RAM per il Buffer Pool.
    Ciò significa che in un database di dimensioni non troppo piccole, i dischi si devono far carico della limitazione in questione.
  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    Per l'autore: stai eseguendo l'istanza di SQL Server su macchina dedicata o server virtuale? nel secondo caso devi settare 1 vSocket con 4 vCore e non 4 vSocket da 1 vCore come vedo spesso.
  • Re: Sql Server 2008 Express - Tempi esecuzione queries

    Toki ha scritto:


    +m+ ha scritto:


    Non ci sono differenze di prestazioni tra Express e "full", solo nella dimensione dei dati gestibili
    Ci sono limitazioni nelle funzionalità e limitazioni che possono generare dei colli di bottiglia per quanto riguarda le performance.
    A titolo di esempio, la versione Express di SQL Server ha il limite di 1GB di RAM per il Buffer Pool.
    mmmhhh... direi praticamente di no.
    La limitazione nella memoria implica una lentezza (ipotetica, teorica) per il non-uso della cache, ma è una cosa che capita moolto di rado (eseguire la medesima query più volte).
    C'è poi "sotto" tutto il filesystem etc.etc.

    Nella stragrande maggioranza dei casi (sempre per DB non molto grandi) la differenza tende a zero (mi riferisco ad utilizzo in produzione e non di benchmark più o meno irrealistici).

    Inizierei quindi a fare una stima della dimensione del DB, e poi andrei dei suggerimenti precedenti, poi cambierei l'hardware (aumentando la RAM e con storage più veloce).

    A quel punto, forse, prenderei in considerazione la licenza "full"
Devi accedere o registrarti per scrivere nel forum
6 risposte