Come posso garantire che gli inserti in SQL Server 2008 R2 vengano prima memorizzati nella cache nella RAM?

Immagina un flusso di dati che è "esplosivo", ovvero che potrebbero arrivare 10.000 eventi molto rapidamente, seguiti da nulla per un minuto.

Il vostro consiglio dell'esperto: come posso scrivere il codice di inserimento C # per SQL Server, in modo tale che ci sia la garanzia che SQL memorizzi immediatamente tutto nella propria RAM, senza bloccare la mia app per più di quanto ci vuole per inserire i dati in detta RAM? Per raggiungere questo obiettivo, conosci qualche schema per l'installazione del server SQL stesso o schemi per configurare le singole tabelle SQL su cui sto scrivendo?

Certo, potrei fare la mia versione, che prevede la costruzione della mia coda in RAM - ma non voglio reinventare l'ascia di pietra paleolitica, per così dire.

Hai provato a scrivere e vedere cosa succede? Hai un collo di bottiglia noto?

Se è necessario impedire che l'app venga bloccata, un modo sarebbe quello di mettere in coda le scritture per rinviare la chiamata al database. Tuttavia, mi aspetto che la coda si cancelli in un secondo o 2: quindi hai bisogno di una coda se questo è OK?

Oppure puoi eseguire lo spooling su una tabella di gestione temporanea e quindi svuotare più tardi? Usiamo questa tecnica per gestire scritture sostenute di milioni di nuove righe al minuto (in realtà utilizziamo un DB di gestione temporanea con recupero semplice): ma non l'abbiamo implementato fino a quando non abbiamo avuto esperienza di scrivere solo righe.

Nota: ogni scrittura in SQL Server eseguirà il disco come parte del protocollo Write Ahead Logging (WAL). Questo vale per la voce t-log per quella scrittura.

La pagina dei dati con la riga andrà su disco ad un certo punto (in base a tempo, utilizzo, pressione della memoria ecc.) Ma generalmente i tuoi dati saranno comunque in memoria. Questo si chiama "Checkpoint" e non sfrutta i dati dalla memoria, cancella solo le modifiche (modificato il 24 nov 2011)

Modificare:

Per tutte le considerazioni, basate sull'ultimo paragrafo sopra, sposta il tuo LDF per questo database su un set dedicato di dischi per maggiori prestazioni. Idem un database di gestione temporanea (uno ciascuno per MDF / LDF). È abbastanza comune avere una dozzina o 3 volumi diversi (tramite una SAN normalmente) per il proprio server di database

A meno che non mi manchi qualcosa, ciò violerebbe i requisiti di Durabilità di ACID ( http://en.wikipedia.org/wiki/ACID ). Cioè, se l'applicazione "scrive" i dati nella RAM e quindi il server si arresta in modo anomalo, i dati vengono persi.

Quindi, quello che cerchi è un sistema non di database che funge da coda per l'eventuale archiviazione in un database o un sistema di database sufficientemente veloce per quello che stai facendo. Suggerirei di provare prima quest'ultimo e vedere se è sufficiente; non prendere in prestito guai.

Ho usato una volta un set di dati per questo. Stavo inserendo le righe nel set di dati al loro arrivo e c'era un altro thread che scaricava le righe ogni 2 secondi circa nel database. È inoltre possibile utilizzare il documento XML per eseguire la cache e quindi passare l'XML al database in una sola chiamata, questo potrebbe essere ancora migliore.

Saluti

Piotr