In che modo SQL Server gestisce i dati per una query in cui non c'è spazio sufficiente nella cache del buffer?

La mia domanda è: in che modo SQL Server gestisce una query che deve estrarre più volume di dati nella cache del buffer di quanto sia disponibile spazio? Questa query conterrà più join, quindi il set di risultati non esiste già in questo formato sul disco e dovrebbe compilare i risultati. Ma anche dopo la compilazione, richiede ancora più spazio di quello disponibile nella cache del buffer.

Farò un esempio. Supponiamo di avere un'istanza di SQL Server con 6 GB di spazio disponibile nella cache buffer. Eseguo una query con più join che legge 7 GB di dati, in che modo SQL Server è in grado di rispondere a questa richiesta? Memorizza temporaneamente i dati in tempdb? Fallisce? Fa qualcosa che legge i dati dal disco e compila i segmenti alla volta?

Inoltre, cosa succede se sto cercando di restituire 7 GB di dati totali, cambia il modo in cui SQL Server li gestisce?

Sono già a conoscenza di diversi modi per risolvere questo problema, sono solo curioso di sapere come SQL Server gestisce questa richiesta internamente quando viene eseguita come indicato.

Inoltre, sono sicuro che queste informazioni esistano da qualche parte, ma non sono riuscito a trovarle.

Le pagine vengono lette in memoria come richiesto, se non è disponibile memoria libera, la pagina non modificata più vecchia viene sostituita con la pagina in arrivo.

Ciò significa che se si esegue una query che richiede più dati di quanti ne possano contenere in memoria, molte pagine avranno una durata molto breve in memoria, con conseguente I / O elevato.

Puoi vedere questo effetto osservando il contatore "Aspettativa di vita della pagina" in Windows Performance Monitor. Guarda https://sqlperformance.com/2014/10/sql-performance/knee-jerk-page-life-expectancy per alcuni grandi dettagli su quel contatore.

Nei commenti, hai chiesto in particolare cosa succede quando i risultati della query sono più grandi dello spazio buffer disponibile. Prendiamo l'esempio più semplice, select * from some_very_big_table;- supponiamo che la tabella sia di 32 GB e max server memory (MB)sia configurata a 24 GB. Tutti i 32 GB di dati della tabella verranno letti in pagine nel buffer di pagina una alla volta, bloccati, formattato in pacchetti di rete e inviato attraverso il filo. Questo accade pagina per pagina; potresti avere 300 di queste query in esecuzione contemporaneamente e supponendo che non si stia verificando alcun blocco, i dati per ciascuna query verrebbero letti nello spazio del buffer di pagina, una pagina alla volta e inseriti nel filo il più velocemente possibile dal client richiedere e consumare i dati. Una volta che tutti i dati di ciascuna pagina sono stati inviati sul filo, la pagina diventa sbloccata e verrà rapidamente sostituita da un'altra pagina dal disco.

Nel caso di una query più complessa, ad esempio aggregando i risultati di più tabelle, le pagine verranno rimosse in memoria esattamente come sopra come richiesto dal processore di query. Se il processore di query necessita di uno spazio di lavoro temporaneo per calcolare i risultati, lo saprà in anticipo quando compila un piano per la query e richiederà spazio di lavoro (memoria) da SQLOS . SQLOS ad un certo punto (supponendo che non time out ), concedere che la memoria al processore di query, in cui l'elaborazione di query punto riprende. Se il Query Processor commette un errore nella stima della quantità di memoria da richiedere a SQLOS, potrebbe essere necessario eseguire uno "spill to disk"operazione, in cui i dati vengono temporaneamente scritti in tempdb in una forma intermedia. Le pagine che sono state scritte su tempdb verranno sbloccate una volta scritte su tempdb per fare spazio per altre pagine da leggere in memoria. Alla fine il processo di query tornerà ai dati memorizzati in tempdb, paginandoli nell'utilizzo del latching, nelle pagine del buffer contrassegnate come libere.

Sicuramente mi manca un sacco di dettagli molto tecnici nel sommario sopra, ma penso che catturi l'essenza di come SQL Server può elaborare più dati di quanti ne possano contenere in memoria.

Non posso parlare di cosa farebbe esattamente la tua query in questo scenario, ma SQL Server ha diverse opzioni a seconda di quanto è necessario.

• I dati possono "riversarsi" su TempDB, questo sarebbe usando il tuo disco
• Le vecchie pagine possono essere rimosse dalla cache del buffer
• SQL Server può caricare alcune pagine nella cache del buffer, usarle, quindi ruotare nuove pagine

Il modo migliore per scoprire cosa succederebbe è creare lo scenario in un ambiente di sviluppo e scoprirlo.

La mia domanda è come SQL Server gestisce una query che deve estrarre più volume di dati nella cache del buffer, quindi c'è spazio disponibile

Per rispondere a questa parte specifica, lascia che ti dica come viene gestita. Le pagine hanno una dimensione di 8 KB. Quando si esegue una query che richiede un set di dati di grandi dimensioni e che richiede di portare in memoria numerose pagine, SQL Server non porterà tutte le pagine in una volta sola. Individuerà le pagine specifiche e porterà una alla volta singole pagine da 8 KB in memoria, leggerà i dati da essa e ti darà il risultato e questo andrà avanti ora supponiamo che si trovi in ​​una situazione in cui la memoria è inferiore in quel caso le pagine vecchie verranno scaricate il disco come sottolineato da @Max. Come hai indovinato correttamente, questa memoria insufficiente può rallentare le cose, dato che un po 'di tempo sarebbe impiegato nella rimozione di vecchie pagine. Questo è dove checkpoint e Lazywriterentra in scena. Lazywriter è loro per assicurarsi che un po 'di memoria libera sia sempre lì per portare nuove pagine sul disco. Quando viene rilevato un buffer libero basso, viene attivato e crea spazi liberi per essere nuove pagine.

MODIFICARE

Lo capisco, ma la parte che mi sconcerta un po 'è cosa succede se si uniscono \ filtrano i dati e questi risultati superano le dimensioni della cache.

La memoria per l'unione e il filtro viene decisa anche prima dell'esecuzione della query e supponiamo che ci sia davvero un crunch della memoria e che la memoria richiesta per eseguire l'operazione non sia disponibile Il processore SQL Server garantirà la "memoria richiesta" che è

Memoria richiesta: memoria minima necessaria per eseguire l'ordinamento e l'hash join. Viene chiamato richiesto perché una query non si avvia senza questa memoria disponibile. Il server SQL utilizza questa memoria per creare strutture di dati interne per gestire l'ordinamento e l'hash join.

Quindi almeno la query inizierà a funzionare ma durante il runtime è molto probabile che il risultato intermedio venga trasmesso a Tempdb rendendolo lento. Ti consiglio vivamente di leggere Comprensione della concessione di memoria di query