quando non è rimasta memoria fisica per i dati, SQL Server sposta i dati già esistenti in TEMPDB
L'articolo a cui ti sei collegato è nella migliore delle ipotesi fuorviante e errato in alcuni punti. Penso che l'autore stesse tentando di semplificare eccessivamente alcune cose complicate, e nel farlo è andato un po 'troppo lontano.
In questo modo SQL Server non sposta i dati dalla memoria (il pool di buffer) in tempdb. Utilizza una strategia di memorizzazione nella cache "utilizzata meno di recente" (in generale), quindi se è presente pressione della memoria e è necessario estrarre nuovi dati nella memoria, SQL Server eliminerà i dati LRU dal pool di buffer per accogliere i nuovi dati. Questo comportamento è spesso monitorato da un contatore di perfoni chiamato "Aspettativa di vita della pagina" (PLE) :
La definizione di PLE è il tempo previsto, in secondi, in cui una pagina di file di dati letta nel pool di buffer (la cache in memoria delle pagine di file di dati) rimarrà in memoria prima di essere espulsa dalla memoria per fare spazio a dati diversi pagina del file. Un altro modo di pensare a PLE è una misura istantanea della pressione sul pool di buffer per liberare spazio per le pagine lette dal disco. Per entrambe queste definizioni, è meglio un numero più alto.
Durante l'esecuzione della query, SQL Server può utilizzare tempdb per determinate operazioni. Questo di solito viene eseguito se le stime sono errate, ma una memoria disponibile insufficiente può influenzare questo comportamento.
Alcune delle operazioni che possono "riversare" su tempdb in questo modo sono l'hashing delle righe (per join o aggregati, ecc.), L'ordinamento delle righe in memoria e il buffering delle righe durante l'esecuzione di query parallele.
Le query degli utenti possono anche utilizzare esplicitamente tempdb (con tabelle temporanee globali o locali) e implicitamente utilizzare tempdb (con snapshot o leggere i livelli di isolamento di snapshot impegnati).
Nessuna di queste situazioni sembra adattarsi davvero alla dichiarazione che hai citato.
quando non è rimasta memoria fisica sufficiente, il sistema operativo può utilizzare il FILE PAGINA e spostare i dati dalla memoria fisica ad esso
Questo può sicuramente accadere ed è al di fuori del controllo di SQL Server per la maggior parte. C'è una manopola che puoi ruotare per cercare di prevenire alcuni tipi di paging a livello di sistema operativo, ovvero attivare "Blocca pagine in memoria" (LPIM) :
Questo criterio di Windows determina quali account possono utilizzare un processo per conservare i dati nella memoria fisica, impedendo al sistema di eseguire il paging dei dati nella memoria virtuale su disco.
Quindi cosa possiamo impedire di essere cercapersone su disco?
Prima di SQL Server 2012, le pagine allocate tramite un componente chiamato "Allocatore pagina singola" erano bloccate in memoria (non era possibile eseguire il paging). Ciò includeva il pool di buffer (pagine del database), la cache delle procedure e alcune altre aree di memoria.
Vedi Fun with Locked Pages, AWE, Task Manager e Working Set ... per i dettagli, in particolare la sezione "4. Ora so che SQL Server su x64 può usare" Locked Pages ", che cosa è esattamente bloccato?" Ulteriori letture correlate sono disponibili qui: Grandi dibattiti su SQL Server: blocco delle pagine in memoria
In SQL Server 2012 e versioni successive, non esiste un "allocatore di pagine singole" (gli allocatori di pagine singole e multiple sono stati uniti, per uno sguardo approfondito alla memoria - SQL Server 2012/2014 ). I dettagli di ciò che, esattamente, possono e non possono essere cercati non sono documentati in dettaglio ovunque io abbia visto. Puoi utilizzare una query come questa per vedere cosa è bloccato:
select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'
Per lo stesso articolo di supporto MS, è inoltre possibile utilizzare DBCC MEMORYSTATUSper vedere quanta memoria è "bloccata".
Come nota a margine, è possibile vedere le prove che il set di lavoro di SQL Server è stato impaginato dal sistema operativo nel registro degli errori. Ci saranno messaggi che assomigliano a questo:
2019-09-02 10: 19: 27.29 spid11s Una parte significativa della memoria di processo del server sql è stata pagata. Ciò può comportare un peggioramento delle prestazioni. Durata: 329 secondi. Set di lavoro (KB): 68780, impegnato (KB): 244052, utilizzo memoria: 28%.