Batas memori di SQL Server 2016 SP1

Beberapa minggu yang lalu, saya membuat kesepakatan yang cukup besar tentang SQL Server 2016 Service Pack 1. Banyak fitur yang sebelumnya dicadangkan untuk Enterprise Edition dilepaskan ke edisi yang lebih rendah, dan saya sangat senang mengetahui tentang perubahan ini.

Meskipun demikian, saya melihat beberapa orang yang, katakanlah, sedikit kurang bersemangat daripada saya.

Penting untuk diingat bahwa perubahan di sini tidak dimaksudkan untuk memberikan paritas fitur yang lengkap di semua edisi; mereka untuk tujuan khusus menciptakan area permukaan pemrograman yang lebih konsisten. Sekarang pelanggan dapat menggunakan fitur seperti In-Memory OLTP, Columnstore, dan kompresi tanpa mengkhawatirkan edisi yang ditargetkan – hanya tentang seberapa baik skalanya. Beberapa fitur keamanan yang tampaknya tidak ada hubungannya dengan edisi juga dibuka. Yang paling tidak saya pahami adalah Always Encrypted; Saya tidak dapat memahami mengapa hanya pelanggan Perusahaan yang perlu melindungi hal-hal seperti data kartu kredit. Enkripsi Data Transparan masih hanya untuk Perusahaan, pada versi yang lebih lama dari SQL Server 2019, karena ini sebenarnya bukan fitur yang dapat diprogram (baik aktif atau tidak).

Jadi, apa gunanya bagi pelanggan Edisi Standar?

Saya pikir masalah terbesar yang dimiliki kebanyakan orang adalah bahwa memori maksimal di Edisi Standar masih terbatas pada 128GB. Mereka melihat itu dan berkata, "Wah, terima kasih untuk semua fiturnya, tetapi batas memori berarti saya tidak bisa benar-benar menggunakannya."

Namun, perubahan luas permukaan membawa peluang peningkatan kinerja, bahkan jika itu bukan niat awal mereka (atau bahkan jika itu – saya tidak ada di salah satu pertemuan itu). Mari kita lihat lebih dekat bagian kecil dari cetakan kecil (dari dokumen resmi):

Batas memori untuk Perusahaan/Standar di SQL Server 2016 SP1

Pembaca yang cerdik akan melihat bahwa kata-kata batas kumpulan buffer telah berubah, dari:

Kepada:

Ini adalah deskripsi yang lebih baik tentang apa yang sebenarnya terjadi di Edisi Standar:batas 128GB hanya untuk kumpulan buffer, dan reservasi memori lainnya dapat melebihi dan melebihi itu (pikirkan kumpulan seperti cache paket). Jadi, pada dasarnya, server Edisi Standar dapat menggunakan kumpulan buffer 128GB, maka memori server maksimal bisa lebih tinggi dan mendukung lebih banyak memori yang digunakan untuk reservasi lainnya. Demikian pula, Edisi Ekspres sekarang didokumentasikan dengan baik untuk menggunakan 1,4 GB untuk kumpulan buffer.

Anda mungkin juga melihat beberapa kata yang sangat spesifik di kolom paling kiri (misalnya "per instance" dan "per database") untuk fitur yang sedang diekspos di Edisi Standar untuk pertama kalinya. Untuk lebih spesifik:

• Instance dibatasi hingga 128GB memori untuk kumpulan buffer .
• Instance dapat memiliki tambahan 32 GB dialokasikan untuk objek Columnstore, melebihi batas kumpulan buffer.
• Setiap database pengguna pada instance dapat memiliki tambahan 32 GB dialokasikan untuk tabel dengan memori yang dioptimalkan, melebihi batas kumpulan buffer.

Dan untuk lebih jelasnya:Batas memori untuk ColumnStore dan OLTP Dalam Memori ini TIDAK dikurangi dari batas kumpulan buffer , selama server memiliki lebih dari 128 GB memori yang tersedia. Jika server memiliki kurang dari 128GB, Anda akan melihat teknologi ini bersaing dengan memori buffer pool, dan pada kenyataannya dibatasi hingga % dari memori server maks. Rincian lebih lanjut tersedia di posting ini dari Microsoft's Parikesit Savjani.

Saya tidak memiliki perangkat keras yang berguna untuk menguji sejauh mana ini, tetapi jika Anda memiliki mesin dengan memori 256GB atau 512GB, Anda secara teoritis dapat menggunakan semuanya dengan satu instance Edisi Standar, jika Anda dapat – misalnya – menyebarkan In Anda -Data memori di seluruh database dalam potongan <=32GB, dengan total 128GB + (32GB * (# database)). Jika Anda ingin menggunakan ColumnStore alih-alih In-Memory, Anda dapat menyebarkan data Anda ke beberapa instance, memberi Anda (128GB + 32GB) * (# instance). Dan Anda dapat menggabungkan strategi ini untuk ((128GB + 32GB ColumnStore) * (# instans)) + (32GB In-Memory * (# database * # instans)).

Apakah memecah data Anda dengan cara ini praktis untuk aplikasi Anda, saya tidak yakin; Saya hanya menyarankan itu mungkin. Beberapa dari Anda mungkin sudah melakukan beberapa hal ini untuk mendapatkan penggunaan yang lebih baik dari Edisi Standar di server dengan memori lebih dari 128 GB.

Dengan ColumnStore secara khusus, selain diizinkan untuk menggunakan 32GB selain kumpulan buffer, perlu diingat bahwa kompresi yang bisa Anda dapatkan di sini berarti Anda sering kali dapat memasukkan lebih banyak ke dalam batas 32GB itu daripada yang bisa Anda lakukan dengan data yang sama di tradisional toko baris. Dan jika Anda tidak dapat menggunakan ColumnStore karena alasan apa pun (atau tetap tidak dapat masuk ke 32GB), Anda sekarang dapat menerapkan kompresi halaman atau baris tradisional – ini mungkin tidak memungkinkan Anda untuk memasukkan seluruh database Anda ke dalam kumpulan buffer 128GB, tetapi mungkin memungkinkan lebih banyak data Anda berada di memori pada waktu tertentu.

Hal serupa dimungkinkan di Express (pada skala yang lebih rendah), di mana Anda dapat memiliki 1,4 GB untuk kumpulan buffer, tetapi tambahan ~352MB per instans untuk ColumnStore, dan ~352MB per database untuk In-Memory OLTP.

Tetapi Edisi Perusahaan masih memiliki banyak keuntungan

Ada banyak pembeda lain untuk tetap menarik dalam Enterprise Edition, selain dari batas memori tak terbatas di sekitar – mulai dari pembangunan kembali online dan pemindaian komidi putar hingga Grup Ketersediaan penuh dan semua hak virtualisasi yang dapat Anda gunakan. Bahkan indeks ColumnStore memiliki peningkatan kinerja yang terdefinisi dengan baik yang disediakan untuk Edisi Perusahaan.

Jadi hanya karena ada beberapa teknik yang akan memungkinkan Anda untuk mendapatkan lebih banyak dari Edisi Standar, itu tidak berarti itu akan secara ajaib menskalakan untuk memenuhi kebutuhan kinerja Anda. Seperti posting saya yang lain tentang "melakukannya dengan anggaran terbatas" (mis. mempartisi dan sekunder yang dapat dibaca), Anda tentu saja dapat menghabiskan waktu dan upaya untuk mengumpulkan solusi, tetapi itu hanya akan membawa Anda sejauh ini. Inti dari postingan ini hanyalah untuk menunjukkan bahwa Anda dapat melangkah lebih jauh dengan Edisi Standar di SP1 2016 daripada sebelumnya.