Come migliorare le prestazioni delle query vergini in MS SQL Server?

Ho un sito Web ASP.NET che esegue la propria memorizzazione nella cache indipendente di dati e che i dati non cambiano per lunghi periodi di tempo, quindi non è necessario interrogare SQL Server una seconda volta con la stessa query. Devo migliorare le prestazioni delle prime query (vergini) che vanno a quel SQL Server. Alcune query elaborano così tanti dati che potrebbero causare l'utilizzo di SQL Server tempdb. Non utilizzo variabili della tabella temporanea o tabelle temporanee, quindi SQL Server decide di utilizzare tempdbda solo ogni volta che è necessario.

La mia dimensione di db è di 16 GB, ho 32 GB di RAM fisica disponibile sul mio server.

Comprendo che la strategia di memorizzazione nella cache di MS SQL Server tenta di mantenere i dati nella RAM per accelerare le prestazioni di query simili se necessitano di caricare nuovamente gli stessi dati. Inoltre, proverà a utilizzare la RAM disponibile anziché tempdb per accelerare le prestazioni senza causare l'accesso al disco.

Suppongo che quando arriva la query che deve archiviare qualcosa in tempdb SQL Server e non c'è abbastanza RAM disponibile, SQL Server ha 2 opzioni:

1) per scaricare alcuni dati memorizzati nella cache e utilizzare la RAM risparmiata anziché tempdb per evitare scritture su disco

2) conservare i dati memorizzati nella cache per query future e iniziare a utilizzare tempdb, che rallenta le scritture.

Non so quale scelta farà SQL Server in questa situazione, ma vorrei che diventasse la scelta n. 1 perché mi preoccupo solo delle prestazioni delle query per la prima volta (vergine), perché non invio mai più la stessa query a SQL Server (anche se posso inviare una domanda simile).

Qual è la strategia di memorizzazione nella cache di SQL Server per questo scenario?

In che modo bilancia l'utilizzo della RAM tra evitare tempdb per le query vergini e la velocità delle query seconde?

È possibile configurare SQL Server in modo tale da fare la scelta n. 1? Se sì allora come?

In quale altro modo è possibile migliorare le prestazioni di tutte le query vergini SQL?

Poiché non conosco la strategia di memorizzazione nella cache di SQL Server, voglio posizionare il database sul disco RAM. Ciò assicurerà che qualsiasi query vergine abbia un'alta velocità di caricamento dei dati non memorizzati anche se SQL Server fa sempre la scelta n. 1. Il rischio è che SQL Server possa iniziare a utilizzare più tempdb con meno RAM disponibile (solo 16 GB rimanenti dopo aver usato 16 GB per il disco RAM) se continua a fare la scelta n. 2, che rallenterà le query vergini che causano lo spargimento tempdb.

Sono interessato alla soluzione per SQL 2008 R2, ma immagino che sia probabilmente la stessa per SQL 2008, SQL 2005 e potrebbe essere SQL 2000.

chiarimenti:

Non ci sono altre applicazioni in esecuzione su quella casella, è dedicata a SQL Server . Il sito Web funziona su una scatola separata.

È SQL Server 2008 R2 Standard Edition 64 bit su Windows Server 2008 R2 Enterprise 64 bit.

Eseguo solo query di sola lettura e il database è impostato per essere di sola lettura .

Supponiamo che ci siano già buoni indici . Questa domanda riguarda SQL Server che fa la scelta n. 1 contro la scelta n. 2, come lo fa, se esiste un modo per controllarlo e se il disco RAM lo aiuta a fare la scelta giusta per le query vergini.

La tua domanda può essere sostanzialmente riformulata come "Come funziona la concessione della memoria della query?". Una buona lettura sull'argomento è capire la concessione della memoria del server SQL . Prima che una query venga avviata, potrebbe essere necessaria una concessione di memoria per ordinamenti, hash e altre operazioni che richiedono molta memoria. Questa concessione di memoria è una stima . In base allo stato corrente del sistema (numero di richieste in esecuzione e in sospeso, memoria disponibile ecc.) Il sistema concede alla query una concessione di memoria fino alla quantità richiesta. Una volta concessa la memoria, la query avvia l'esecuzione (potrebbe essere necessario attendere nella temuta coda "semaforo delle risorse" prima di ottenere la concessione). All'esecuzione è garantita la concessione di memoriadal sistema. Questa quantità di memoria può essere condivisa con le pagine di dati (poiché possono sempre scaricarsi su disco) ma mai con altri utilizzi di memoria (cioè non può essere soggetta a "furto"). Pertanto, quando la query inizia a richiedere memoria impegnata dalla propria concessione, il motore distribuirà quella che si chiama "strategia n. 1": le pagine di dati possono essere sfrattate (svuotate se sporche) al fine di dare alla query la memoria promessa. Ora se la stima era corretta e la concessione era pari al 100% della memoria richiesta, la query non dovrebbe "riversarsi". Ma se la stima non era corretta (si riduce a stime di cardinalità, quindi è soggetta a statistiche non aggiornate) o se la query non ha ottenuto l'intera sovvenzione richiesta, la query "si spargerà". Questo è quando tempdb entra in scena e le prestazioni di solito i carri armati.

L'unica manopola che hai a disposizione per controllare qualcosa in questo processo è il Resource Governor . Poiché RG può essere utilizzato per specificare un'impostazione MIN per un pool, può essere utilizzato per riservare memoria per un determinato carico di lavoro in modo che ottenga effettivamente la concessione di memoria richiesta. Ovviamente, dopo aver effettuato le opportune indagini che dimostrano che le riduzioni di memoria sono il colpevole, e ovviamente dopo che è stato valutato l'impatto su altri carichi di lavoro. E testato, ovviamente.

Ora torniamo alla domanda originale. Se la tua indagine è corretta (un grandissimo if) vorrei sottolineare due problemi:

• si esegue query di produzione che richiedono assegnazioni di memoria per un sito Web . Questo è un grande no-no. Le assegnazioni di memoria sono indicative di query analitiche che non hanno spazio per soddisfare le richieste HTTP.
• le tue query non sono probabilmente eventi che ottengono la concessione di memoria richiesta. Ancora una volta, ancora di più un no-no per un carico di lavoro critico per la latenza come lo sono i siti web.

Quindi quello che mi dice è che hai un problema progettuale e architettonico fondamentale. I siti Web sono guidati dalla latenza e dovrebbero creare un carico di lavoro come OLTP, senza assegnazioni di memoria e senza pressione sulla memoria per le query. Per non parlare di sversamenti. Le query analitiche devono essere eseguite in processi offline e archiviare i risultati preelaborati per una rapida disponibilità quando le richieste HTTP li desiderano.

Ciò che non hai menzionato è il tipo di query eseguite sul database e se esistono indici corretti per accelerare le prestazioni delle query.

È inoltre necessario assicurarsi che ci siano altre applicazioni in esecuzione nella stessa casella. Anche se la scatola ha 32 GB di RAM, hai impostato qualsiasi impostazione di memoria massima sul server di database per porre un limite artificiale. Se ci sono app in esecuzione sullo stesso server, SQL e le altre app potrebbero competere per le risorse e notare che SQL ha molta fame di memoria.

SQL Server utilizzerà tempdb per l'ordinamento interno o hash join / aggregati o operatori di spool ecc. E non è possibile controllare questo comportamento. Quello che puoi fare è limitare la quantità di dati restituiti.

Hai controllato le statistiche di attesa in questa casella? Ogni volta che SQL Server è in attesa di una risorsa, SQL Server monitorerà la risorsa di attesa e la ricerca di tali informazioni aiuta.

Guarda le domande diagnostiche di Glenn Berry e sarà un buon inizio per te.

Guarda anche PARAMETERIZATION FORCED come menzionato in http://weblogs.sqlteam.com/dang/archive/2009/06/27/Forced-Parameterization-A-Turbo-Button.aspx

Questa domanda al momento si presenta come una soluzione alla ricerca di un problema. Hai deciso che la soluzione è un disco RAM e vuoi che qualcuno convalidi tale scelta. Spiacente, non succederà.

Se hai misurato e osservato una fuoriuscita in tempdb, sarà quasi sicuramente dovuto a un'operazione di ordinamento o hash e a una concessione insufficiente della memoria della query. A seconda del volume di dati da elaborare, ciò può essere inevitabile, ma buone probabilità che la query e / o l'indicizzazione possano essere migliorate per evitarlo.

Dai un'occhiata a Buffer Management per capire meglio come SQL Server gestisce la memoria e SQL Server Memory Management Spiegato per alcuni strumenti di base e query DMV per capire dove è allocata la tua memoria.

In quale altro modo è possibile migliorare le prestazioni di tutte le query vergini SQL?

Questo è un argomento importante. Pubblica la query e il piano e otterrai un feedback mirato.