Limiti di memoria in SQL Server 2016 SP1

Alcune settimane fa, ho fatto un grosso problema con SQL Server 2016 Service Pack 1. Molte funzionalità precedentemente riservate all'edizione Enterprise sono state rilasciate alle edizioni inferiori e sono rimasto entusiasta di apprendere queste modifiche.

Tuttavia, vedo alcune persone che sono, diciamo, un po' meno eccitate di me.

È importante tenere presente che le modifiche qui non avevano lo scopo di fornire la parità completa delle funzionalità in tutte le edizioni; avevano lo scopo specifico di creare una superficie di programmazione più coerente. Ora i clienti possono utilizzare funzionalità come In-Memory OLTP, Columnstore e compressione senza preoccuparsi delle edizioni di destinazione, ma solo della loro scalabilità. Vengono anche aperte diverse funzionalità di sicurezza che non sembravano avere nulla a che fare con l'edizione. Quello che ho capito di meno era Always Encrypted; Non riuscivo a capire perché solo i clienti Enterprise dovessero proteggere cose come i dati delle carte di credito. Transparent Data Encryption è ancora solo Enterprise, nelle versioni precedenti a SQL Server 2019, perché questa non è realmente una funzionalità di programmabilità (è attiva o meno).

Quindi cosa c'è di veramente vantaggioso per i clienti della Versione Standard?

Penso che il problema più grande che la maggior parte delle persone abbia sia che la memoria massima nella Standard Edition è ancora limitata a 128 GB. Lo guardano e dicono:"Accidenti, grazie per tutte le funzionalità, ma il limite di memoria significa che non posso davvero usarle".

Tuttavia, i cambiamenti di superficie comportano opportunità di miglioramento delle prestazioni, anche se questa non era la loro intenzione originale (o anche se lo era – non ero in nessuno di quegli incontri). Diamo un'occhiata più da vicino a una piccola sezione della stampa fine (dai documenti ufficiali):

Limiti di memoria per Enterprise/Standard in SQL Server 2016 SP1

Il lettore astuto noterà che la formulazione del limite del pool di buffer è cambiata, da:

A:

Questa è una descrizione migliore di ciò che accade realmente nell'edizione Standard:un limite di 128 GB solo per il pool di buffer e altre riserve di memoria possono essere superiori (pensa ai pool come la cache del piano). Quindi, in effetti, un server Standard Edition potrebbe utilizzare 128 GB di pool di buffer, quindi la memoria massima del server potrebbe essere maggiore e supportare più memoria utilizzata per altre prenotazioni. Allo stesso modo, Express Edition è ora correttamente documentato per l'utilizzo di 1,4 GB per il pool di buffer.

Potresti anche notare alcune diciture molto specifiche nella colonna più a sinistra (ad es. "per istanza" e "per database") per le funzionalità che vengono esposte per la prima volta nella Standard Edition. Per essere più precisi:

• L'istanza è limitata a 128 GB di memoria per il pool di buffer .
• L'istanza può avere un aggiuntivo 32 GB allocati agli oggetti Columnstore, oltre il limite del pool di buffer.
• Ogni database utente sull'istanza può avere un aggiuntivo 32 GB allocati a tabelle con ottimizzazione per la memoria, oltre il limite del pool di buffer.

E per essere chiari:Questi limiti di memoria per ColumnStore e In-Memory OLTP NON vengono sottratti dal limite del pool di buffer , a condizione che il server abbia più di 128 GB di memoria disponibile. Se il server ha meno di 128 GB, vedrai queste tecnologie competere con la memoria del pool di buffer e infatti saranno limitate a una % della memoria massima del server. Maggiori dettagli sono disponibili in questo post di Parikshit Savjani di Microsoft.

Non ho hardware a portata di mano per testare l'entità di questo, ma se avessi una macchina con 256 GB o 512 GB di memoria, potresti teoricamente usarla tutta con una singola istanza della Standard Edition, se potessi, ad esempio, diffondere il tuo In -Dati di memoria tra i database in blocchi <=32 GB, per un totale di 128 GB + (32 GB * (n. di database)). Se desideri utilizzare ColumnStore invece di In-Memory, puoi distribuire i tuoi dati su più istanze, ottenendo (128 GB + 32 GB) * (n. di istanze). E potresti combinare queste strategie per ((128 GB + 32 GB ColumnStore) * (n. di istanze)) + (32 GB in memoria * (n. di database * n. di istanze)).

Non sono sicuro se suddividere i tuoi dati in questo modo sia pratico per la tua applicazione; Sto solo suggerendo che è possibile. Alcuni di voi potrebbero già fare alcune di queste cose per sfruttare al meglio la Standard Edition su server con più di 128 GB di memoria.

Con ColumnStore in particolare, oltre a poter utilizzare 32 GB oltre al pool di buffer, tieni presente che la compressione che puoi ottenere qui significa che spesso puoi adattare molto di più a quel limite di 32 GB di quanto potresti con gli stessi dati in tradizionale riga-negozio. E se non puoi utilizzare ColumnStore per qualsiasi motivo (o non si adatta comunque a 32 GB), ora puoi implementare la tradizionale compressione di pagine o righe:ciò potrebbe non consentirti di adattare l'intero database al pool di buffer da 128 GB, ma potrebbe consentire a più dati di essere in memoria in qualsiasi momento.

Cose simili sono possibili in Express (su scala inferiore), dove puoi avere 1,4 GB per il pool di buffer, ma circa 352 MB aggiuntivi per istanza per ColumnStore e circa 352 MB per database per OLTP in memoria.

Ma Enterprise Edition ha ancora molti vantaggi

Ci sono molti altri fattori di differenziazione per mantenere l'interesse per l'Enterprise Edition, oltre ai limiti di memoria illimitati ovunque:dalle ricostruzioni online e dalle scansioni giostre ai gruppi di disponibilità completi e tutti i diritti di virtualizzazione a cui puoi dare una mano. Anche gli indici ColumnStore hanno miglioramenti delle prestazioni ben definiti riservati per Enterprise Edition.

Quindi, solo perché ci sono alcune tecniche che ti permetteranno di ottenere di più dalla Standard Edition, ciò non significa che si adatterà magicamente alle tue esigenze di prestazioni. Come i miei altri post su "farlo con un budget limitato" (ad esempio partizionamento e secondari leggibili), puoi sicuramente dedicare tempo e fatica a mettere insieme una soluzione, ma ti porterà solo così lontano. Lo scopo di questo post era semplicemente dimostrare che con la Standard Edition nel 2016 SP1 puoi andare più lontano di quanto avresti mai potuto fare prima.