Tingkat Kompatibilitas dan Estimasi Kardinalitas Primer

Pengantar

Antara tahun 1998 dan awal 2014, SQL Server menggunakan satu penaksir kardinalitas (CE), tetapi akan memperkenalkan tingkat kompatibilitas database baru dengan setiap versi utama baru dari SQL Server, (dengan pengecualian SQL Server 2008 R2). Tingkat kompatibilitas asli untuk SQL Server ditunjukkan oleh versi SQL Server utama di Tabel 1:

Tabel 1:Versi SQL Server dan Tingkat Kompatibilitas Asli

Antara SQL Server 7.0 dan SQL Server 2012, tidak ada koneksi antara tingkat kompatibilitas database dan penaksir kardinalitas yang akan digunakan kueri dalam database tersebut. Ini karena hanya ada satu penaksir kardinalitas, yang menerima pembaruan besar pada tahun 1998. Tingkat kompatibilitas database hanya digunakan untuk kompatibilitas fungsional mundur dan untuk mengaktifkan/menonaktifkan beberapa fitur baru di setiap versi baru SQL Server (lihat ini Jawaban Stack Exchange untuk contoh bagaimana perilaku berubah antara 80 dan 90, mungkin perubahan yang paling mengganggu). Tidak seperti versi file database SQL Server, Anda dapat mengubah tingkat kompatibilitas database kapan saja, ke tingkat kompatibilitas apa pun yang didukung, dengan perintah ALTER DATABASE sederhana.

Secara default, jika Anda membuat baru database di SQL Server 2012, tingkat kompatibilitas akan diatur ke 110, tetapi Anda dapat mengubahnya ke tingkat yang lebih awal jika diinginkan. Jika Anda memulihkan cadangan database dari contoh SQL Server 2008 ke contoh SQL Server 2012, itu akan memutakhirkan versi file database, tetapi akan meninggalkan tingkat kompatibilitas di tempat yang telah ada pada contoh SQL Server 2008 (kecuali 80, yang akan dapatkan upgrade ke 90, versi minimum yang didukung oleh SQL Server 2012). Selain mengetahui perbedaan mendasar antara versi file database dan tingkat kompatibilitas database, sebagian besar DBA dan pengembang tidak perlu terlalu khawatir tentang tingkat kompatibilitas database sebelum SQL Server 2014 dirilis. Dalam banyak kasus, sebagian besar database tidak pernah memiliki tingkat kompatibilitas yang berubah setelah migrasi ke versi baru SQL Server. Ini biasanya tidak menyebabkan masalah apa pun kecuali Anda benar-benar membutuhkan fitur atau perilaku baru yang berubah di tingkat kompatibilitas database terbaru.

Perubahan SQL Server 2014

Keadaan lama ini berubah secara radikal dengan dirilisnya SQL Server 2014. SQL Server 2014 memperkenalkan penaksir kardinalitas "baru" yang diaktifkan secara default ketika database berada di tingkat kompatibilitas 120. Dalam buku putih klasik, “Mengoptimalkan Paket Kueri Anda dengan Penaksir Kardinalitas SQL Server 2014,” Joe Sack menjelaskan latar belakang dan perilaku perubahan ini pada bulan April 2014. Dalam banyak kasus, sebagian besar kueri Anda berjalan lebih cepat saat menggunakan kardinalitas baru estimator, tetapi cukup umum untuk mengalami beberapa kueri yang memiliki regresi kinerja utama dengan estimator kardinalitas baru. Jika itu terjadi, SQL Server 2014 tidak memiliki banyak opsi untuk mengurangi masalah kinerja yang disebabkan oleh CE baru. Whitepaper Joe mencakup opsi tersebut dengan sangat detail, tetapi pada dasarnya, Anda terbatas pada tanda pelacakan tingkat instans atau petunjuk kueri tingkat kueri untuk mengontrol penaksir kardinalitas mana yang digunakan oleh pengoptimal kueri, kecuali jika Anda ingin kembali ke tingkat kompatibilitas 110 atau lebih rendah .

Perubahan SQL Server 2016

SQL Server 2016 memperkenalkan opsi konfigurasi cakupan database, yang memberi Anda kemampuan untuk mengontrol beberapa perilaku yang sebelumnya dikonfigurasi di tingkat instans, menggunakan perintah ALTER DATABASE SCOPED CONFIGURATION. Di SQL Server 2016, opsi ini termasuk MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING, dan QUERY_OPTIMIZER_HOTFIXES. Ada juga opsi CLEAR PROCEDURE_CACHE yang memungkinkan Anda menghapus seluruh cache paket untuk satu database.

Yang paling relevan dalam konteks ini adalah LEGACY_CARDINALITY ESTIMATION dan QUERY_OPTIMIZER_HOTFIXES opsi konfigurasi cakupan basis data. LEGACY_CARDINALITY ESTIMATION memungkinkan CE lama terlepas dari pengaturan tingkat kompatibilitas database. Ini setara dengan trace flag 9481, tetapi hanya memengaruhi database yang bersangkutan, bukan seluruh instance. Ini memungkinkan Anda menyetel tingkat kompatibilitas database ke 130 untuk mendapatkan sejumlah manfaat fungsional dan kinerja, namun tetap menggunakan seluruh database CE lama (kecuali diganti dengan petunjuk kueri tingkat kueri).

Opsi QUERY_OPTIMIZER_HOTFIXES setara dengan bendera pelacakan 4199 di tingkat basis data. SQL Server 2016 akan mengaktifkan semua hotfix pengoptimal kueri sebelum SQL Server 2016 RTM saat Anda menggunakan tingkat kompatibilitas pangkalan data 130 (tanpa mengaktifkan bendera pelacakan 4199). Jika Anda mengaktifkan TF 4199 atau mengaktifkan QUERY_OPTIMIZER_HOTFIXES, Anda juga akan mendapatkan semua hotfix pengoptimal kueri yang dirilis setelah SQL Server 2016 RTM.

SQL Server 2016 SP1 juga memperkenalkan petunjuk kueri USE HINT yang lebih mudah digunakan, dipahami, dan diingat daripada petunjuk kueri QUERYTRACEON yang lebih lama. Ini memberi Anda kontrol yang lebih mendetail atas perilaku pengoptimal yang terkait dengan tingkat kompatibilitas database dan versi penaksir kardinalitas yang sedang digunakan. Anda dapat meminta sys.dm_exec_valid_use_hints untuk mendapatkan daftar nama PETUNJUK PENGGUNAAN yang valid untuk build SQL Server yang Anda jalankan.

Perubahan SQL Server 2017

Fitur pemrosesan kueri adaptif baru telah ditambahkan di SQL Server 2017, dan diaktifkan secara default saat Anda menggunakan tingkat kompatibilitas database 140.

Microsoft sedang mencoba untuk menjauh dari terminologi lama "CE Baru" dan "CE Lama", karena sebenarnya ada perubahan dan perbaikan untuk pengoptimalan kueri di setiap versi utama SQL Server yang baru. Karena itu, tidak ada lagi "CE Baru". Sebagai gantinya, Microsoft ingin merujuk ke CE70 (CE default untuk SQL Server 7.0 hingga SQL Server 2012), CE120 untuk SQL Server 2014, CE130 untuk SQL Server 2016, CE140 untuk SQL Server 2017, dan CE150 untuk SQL Server 2019. Dimulai dengan SQL Server 2017 CU10, Anda dapat menggunakan fungsionalitas USE HINT untuk mengontrol ini dengan petunjuk kueri. Misalnya:

/*...query...*/ OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'));

… akan menjadi petunjuk kueri yang valid untuk memaksa penduga kardinalitas CE130 untuk kueri tertentu.

Perubahan SQL Server 2019

SQL Server 2019 menambahkan lebih banyak peningkatan kinerja dan perubahan perilaku yang diaktifkan secara default saat database menggunakan mode kompatibilitas 150. Contoh utama adalah skalar UDF inlining. Contoh lainnya adalah fitur pemrosesan kueri cerdas, yang merupakan superset dari pemrosesan kueri adaptif di SQL Server 2017.

Ada lima opsi USE HINT baru, termasuk cara menonaktifkan mode batch atau menonaktifkan umpan balik pemberian memori adaptif, seperti yang ditunjukkan pada Tabel 2:

Tabel 2 :Opsi PETUNJUK PENGGUNAAN baru

Dan ada juga enam belas opsi konfigurasi cakupan basis data baru (mulai CTP 2.2) yang memberi Anda kontrol tingkat basis data untuk lebih banyak item yang juga dipengaruhi oleh tanda pelacakan atau tingkat kompatibilitas basis data. Ini memberi Anda kontrol yang lebih halus dari perubahan tingkat yang lebih tinggi yang diaktifkan secara default dengan tingkat kompatibilitas database 150. Ini tercantum dalam Tabel 3:

Tabel 3 :Opsi konfigurasi cakupan database baru

Kesimpulan

Bermigrasi ke SQL Server versi modern (artinya SQL Server 2016 atau yang lebih baru) secara signifikan lebih rumit daripada dengan SQL Server versi lawas. Karena perubahan yang terkait dengan berbagai tingkat kompatibilitas database dan berbagai versi penaksir kardinalitas, sebenarnya sangat penting untuk memikirkan, merencanakan, dan menguji secara aktual ke tingkat kompatibilitas database yang ingin Anda gunakan pada versi baru SQL Server yang Anda sedang memigrasikan database Anda yang ada ke.

Proses pemutakhiran yang disarankan Microsoft adalah memutakhirkan ke versi SQL Server terbaru, tetapi tetap mempertahankan tingkat kompatibilitas basis data sumber. Kemudian, aktifkan Penyimpanan Kueri di setiap database dan kumpulkan data dasar tentang beban kerja. Selanjutnya, Anda menyetel tingkat kompatibilitas database ke versi terbaru, lalu menggunakan Penyimpanan Kueri untuk memperbaiki regresi kinerja dengan memaksakan rencana bagus terakhir yang diketahui.

Anda benar-benar ingin menghindari migrasi "buta" yang serampangan di mana Anda tidak menyadari cara kerjanya dan bagaimana beban kerja Anda akan bereaksi terhadap perubahan ini. Mengubah tingkat kompatibilitas basis data ke versi yang sesuai dan menggunakan opsi konfigurasi cakupan basis data yang sesuai, bersama dengan petunjuk kueri yang sesuai jika benar-benar diperlukan, sangat penting dengan versi SQL Server modern.