SQL Server - Forza DB in memoria?

Abbiamo un robusto server Windows 2008 x64 (CPU 4 x 4 core, 32 GB RAM) con SQL Server 2005 a 64 bit. Abbiamo un piccolo database (6 GB) ma molto importante che è un po 'lento ad accedere fino a quando le pagine non sono memorizzate nella cache (l'utilizzo è molto I / O casuale quindi le probabilità sono molto basse una data pagina è in memoria e gli utenti finali lamentarsi della lentezza iniziale). I dischi sono abbastanza veloci (SAS locale da 15 KB) ma immagino che l'app sia scritta in modo un po 'goffo (è una soluzione COTS) quindi mi chiedo se c'è un modo per "forzare" un database in memoria in SQL Server 2005 (2008 non è supportato dal fornitore, quindi non dovremmo ancora aggiornarlo) per evitare il blues iniziale che riempie la cache?

Il mio metodo attuale è che eseguo un SELECT * da ciascuna tabella in uno script per ottenere pagine di dati in memoria ma alcuni oggetti (indici, ricerca di testo completo, ecc.) Non vengono memorizzati nella cache da questo metodo (e modificando lo script per interrogare indici e scrivere opportune clausole WHERE per memorizzare nella cache è il complesso bollire l'oceano).

No, sfortunatamente non c'è modo di forzare un database nella cache. Il tuo metodo di forza bruta è probabilmente il più semplice. Potresti essere in grado di avvicinarti usando gli script di deframmentazione dell'indice con un'impostazione di soglia molto bassa, come dire ricostruisci l'indice se è frammentato dell'1%, in questo modo:

http://sqlserverpedia.com/wiki/Index_Maintenance

Ci vorrà più tempo e comporterà più scritture sul disco, ma avrà l'effetto collaterale di deframmentare gli indici e aggiornare le statistiche, che è comunque una buona idea.

Ok - Non posso commentare la risposta di Brent (ancora, poiché non ho abbastanza ripetizioni) - ma se hai intenzione di seguire il percorso di deframmentazione, non necessariamente ricostruire l'indice - poiché ciò creerà nuovi indici, probabilmente aumentare il database se non c'è abbastanza spazio libero e garantire che il prossimo backup del registro abbia almeno le dimensioni degli indici e che il registro possa contenere anche una tonnellata di record di registro (a seconda del modello di recupero). Se hai intenzione di fare il percorso di deframmentazione, esegui un ALTER INDEX ... RIORGANIZE, che non richiede spazio libero (beh, una pagina 8k) ma leggerà il livello foglia in memoria e opererà solo su frammentato pagine. I livelli non foglia dovrebbero entrare rapidamente dopo alcune query e (a seconda del fan-out) dovrebbero essere molti meno dati rispetto al livello foglia.

Perché in primo luogo gli oggetti del database vengono scaricati dalla cache? Stai riavviando i servizi SQL o stai disattivando / online il database? O vengono espulsi dalla memorizzazione nella cache da altri database?

Saluti,

SCM.

Se il database è così piccolo, potresti metterlo su SSD?

Ho avuto alcuni scenari in cui l'aggiornamento delle statistiche con FULLSCAN su tabelle chiave ha forzato i dati nella cache e reso i miei DML successivi attorno a quelle tabelle molto più velocemente. E questo non è stato il risultato di statistiche obsolete in quanto non ha comportato modifiche nei piani di esecuzione.

Perché non installare una seconda istanza di SQL Server con solo quel database e impostare la memoria minima per quell'istanza su 6 GB?

Ciò garantirà che gli altri vostri database non catturino mai la memoria dal vostro database "piccolo ma molto importante".

Significa anche che puoi portare l'altra istanza offline e il tuo piccolo DB rimarrà in memoria.

Userei il profiler per controllare il tuo sql. Confronta letture "logiche" con letture "fisiche". Il server SQL è intelligente e utilizzerà la RAM necessaria per i risultati più efficienti.

Controlla anche che i tuoi autostati siano aggiornati.

Senza una maggiore idea del tipo di query e delle dimensioni della tabella db, sembra un po 'strano.