Tingkat kompatibilitas ALTER DATABASE (Transact-SQL)
Berlaku untuk: SQL ServerAzure SQL Database Azure SQL Managed Instance
Mengatur perilaku pemrosesan Transact-SQL dan kueri agar kompatibel dengan versi mesin SQL yang ditentukan. Untuk opsi UBAH DATABASE lainnya, lihat MENGUBAH DATABASE.
Untuk informasi selengkapnya tentang konvensi sintaks, lihat Konvensi sintaks transact-SQL.
Sintaks
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
Argumen
database_name
Nama database yang akan dimodifikasi.
COMPATIBILITY_LEVEL { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
Versi SQL Server yang kompatibel dengan database. Nilai tingkat kompatibilitas berikut dapat dikonfigurasi (tidak semua versi mendukung semua tingkat kompatibilitas yang tercantum di atas):
Produk | Versi Mesin Database | Penetapan tingkat kompatibilitas default | Nilai tingkat kompatibilitas yang didukung |
---|---|---|---|
Database Azure SQL | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
Instans Terkelola Azure SQL | 16 | 150 | 160, 150, 140, 130, 120, 110, 100 |
SQL Server 2022 (16.x) | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
SQL Server 2019 (15.x) | 15 | 150 | 150, 140, 130, 120, 110, 100 |
SQL Server 2017 (14.x) | 14 | 140 | 140, 130, 120, 110, 100 |
SQL Server 2016 (13.x) | 13 | 130 | 130, 120, 110, 100 |
SQL Server 2014 (12.x) | 12 | 120 | 120, 110, 100 |
SQL Server 2012 (11.x) | 11 | 110 | 110, 100, 90 |
SQL Server 2008 R2 (10.50.x) | 10.5 | 100 | 100, 90, 80 |
SQL Server 2008 (10.0.x) | 10 | 100 | 100, 90, 80 |
SQL Server 2005 (9.x) | 9 | 90 | 90, 80 |
SQL Server 2000 (8.x) | 8 | 80 | 80 |
Penting
Nomor versi mesin database untuk SQL Server dan Azure SQL Database tidak sebanding satu sama lain, dan lebih merupakan nomor build internal untuk produk terpisah ini. Mesin database untuk Azure SQL Database didasarkan pada basis kode yang sama dengan mesin database SQL Server. Yang terpenting, mesin database di Azure SQL Database selalu memiliki bit mesin database SQL terbaru. Azure SQL Database sersi 12 lebih baru dari SQL Server versi 15.
Praktik terbaik untuk meningkatkan tingkat kompatibilitas database
Untuk alur kerja yang direkomendasikan untuk meningkatkan tingkat kompatibilitas, lihat Menjaga stabilitas performa selama peningkatan ke SQL Server yang lebih baru. Selain itu, untuk pengalaman terbantu dalam meningkatkan tingkat kompatibilitas database, lihat Meningkatkan Database dengan menggunakan Asisten Penyetelan Kueri.
Keterangan
Untuk semua penginstalan SQL Server, tingkat kompatibilitas default dikaitkan dengan versi Mesin Database. Database baru diatur ke tingkat ini kecuali model
database memiliki tingkat kompatibilitas yang lebih rendah. Untuk database yang dilampirkan atau dipulihkan dari versi SQL Server sebelumnya, database mempertahankan tingkat kompatibilitas yang ada, jika setidaknya minimal diizinkan untuk instans SQL Server tersebut. Memindahkan database dengan tingkat kompatibilitas yang lebih rendah dari tingkat yang diizinkan oleh Mesin Database secara otomatis mengatur database ke tingkat kompatibilitas terendah yang diizinkan. Ini berlaku untuk database sistem dan pengguna.
Perilaku berikut diharapkan untuk SQL Server 2017 (14.x) ketika database dilampirkan atau dipulihkan, dan setelah peningkatan di tempat:
- Jika tingkat kompatibilitas database pengguna adalah 100 atau lebih tinggi sebelum peningkatan, tingkat tersebut tetap sama setelah peningkatan.
- Jika tingkat kompatibilitas database pengguna adalah 90 sebelum peningkatan, dalam database yang ditingkatkan, tingkat kompatibilitas diatur ke 100, yang merupakan tingkat kompatibilitas terendah yang didukung di SQL Server 2017 (14.x).
- Tingkat
tempdb
kompatibilitas database , ,model
msdb
, dan Sumber Daya diatur ke tingkat kompatibilitas default untuk versi Mesin Database tertentu. - Database
master
sistem mempertahankan tingkat kompatibilitas yang dimilikinya sebelum ditingkatkan. Ini tidak akan memengaruhi perilaku database pengguna.
Untuk database yang sudah ada sebelumnya yang berjalan pada tingkat kompatibilitas yang lebih rendah, selama aplikasi tidak perlu menggunakan penyempurnaan yang hanya tersedia dalam tingkat kompatibilitas database yang lebih tinggi, ini adalah pendekatan yang valid untuk mempertahankan tingkat kompatibilitas database sebelumnya. Untuk pekerjaan pengembangan baru, atau ketika aplikasi yang ada memerlukan penggunaan fitur baru seperti Pemrosesan Kueri Cerdas dan beberapa Transact-SQL baru, rencanakan untuk meningkatkan tingkat kompatibilitas database ke yang terbaru yang tersedia. Untuk informasi selengkapnya, lihat Tingkat kompatibilitas dan peningkatan Mesin Database.
Catatan
Jika tidak ada objek dan dependensi pengguna, umumnya aman untuk meningkatkan ke tingkat kompatibilitas default. Untuk informasi selengkapnya, lihat Rekomendasi - database master.
Gunakan ALTER DATABASE
untuk mengubah tingkat kompatibilitas database. Pengaturan tingkat kompatibilitas baru untuk database berlaku saat USE <database>
perintah dikeluarkan, atau login baru diproses dengan database tersebut sebagai konteks database default.
Untuk menampilkan tingkat kompatibilitas database saat ini, kueri compatibility_level
kolom dalam tampilan katalog sys.databases .
Database distribusi yang dibuat di versi SQL Server sebelumnya dan ditingkatkan ke RTM SQL Server 2016 (13.x) atau Paket Layanan 1 memiliki tingkat kompatibilitas 90, yang tidak didukung untuk database lain. Ini tidak berpengaruh pada fungsionalitas replikasi. Meningkatkan ke paket layanan dan versi SQL Server yang lebih baru akan mengakibatkan tingkat kompatibilitas database distribusi ditingkatkan agar sesuai master
dengan database.
Untuk menggunakan tingkat kompatibilitas database 120 atau lebih tinggi untuk database secara keseluruhan, tetapi ikut serta dalam model estimasi kardinalitas SQL Server 2012 (11.x), yang memetakan ke tingkat kompatibilitas database 110, lihat MENGUBAH KONFIGURASI CAKUPAN DATABASE, dan khususnya kata kuncinya LEGACY_CARDINALITY_ESTIMATION = ON
.
Keterangan untuk Azure SQL
Tingkat kompatibilitas default adalah SQL Server 2022 (160) untuk database yang baru dibuat di Azure SQL Database.
Tingkat kompatibilitas default adalah SQL Server 2019 (150) untuk database yang baru dibuat di Azure SQL Managed Instance.
Microsoft tidak secara otomatis memperbarui tingkat kompatibilitas database untuk database yang sudah ada. Terserah pelanggan untuk melakukan atas kebijakan mereka sendiri.
Microsoft sangat menyarankan agar pelanggan berencana untuk meningkatkan ke tingkat kompatibilitas terbaru untuk menggunakan peningkatan pengoptimalan kueri terbaru. Untuk tips tentang cara menilai perbedaan performa kueri Anda yang paling penting antara dua tingkat kompatibilitas yang berbeda di Azure SQL Database, lihat Meningkatkan Performa Kueri dengan Tingkat Kompatibilitas 130 di Azure SQL Database. Artikel ini mengacu pada tingkat kompatibilitas 130 dan SQL Server, tetapi metodologi yang sama berlaku untuk peningkatan ke tingkat 140 atau lebih tinggi di SQL Server dan Azure SQL Database.
Tidak semua fitur yang bervariasi menurut tingkat kompatibilitas didukung di Azure SQL Database.
Menemukan tingkat kompatibilitas saat ini
Untuk menentukan tingkat kompatibilitas saat ini, kueri compatibility_level
kolom sys.databases.
SELECT name, compatibility_level FROM sys.databases;
Untuk menentukan versi Mesin Database yang tersambung dengan Anda, jalankan kueri berikut.
SELECT SERVERPROPERTY('ProductVersion');
Tingkat kompatibilitas dan peningkatan mesin database
Tingkat kompatibilitas database adalah alat berharga untuk membantu modernisasi database dengan memungkinkan Mesin Database SQL Server ditingkatkan sambil mempertahankan status fungsi yang sama untuk menghubungkan aplikasi dengan mempertahankan tingkat kompatibilitas database pra-peningkatan yang sama. Ini berarti bahwa dimungkinkan untuk meningkatkan dari versi SQL Server yang lebih lama (seperti SQL Server 2008 (10.0.x)) ke SQL Server atau Azure SQL Database (termasuk Azure SQL Managed Instance) tanpa perubahan aplikasi (kecuali untuk konektivitas database). Untuk informasi selengkapnya, lihat Sertifikasi Kompatibilitas.
Selama aplikasi tidak perlu menggunakan penyempurnaan yang hanya tersedia dalam tingkat kompatibilitas database yang lebih tinggi, ini adalah pendekatan yang valid untuk meningkatkan Mesin Database SQL Server dan mempertahankan tingkat kompatibilitas database sebelumnya. Untuk informasi selengkapnya tentang menggunakan tingkat kompatibilitas untuk kompatibilitas mundur, lihat Sertifikasi Kompatibilitas.
Tingkat kompatibilitas dan prosedur tersimpan
Saat prosedur tersimpan dijalankan, prosedur tersebut menggunakan tingkat kompatibilitas database saat ini tempat database ditentukan. Saat pengaturan kompatibilitas database diubah, semua prosedur tersimpannya dikompresi ulang secara otomatis.
Menggunakan tingkat kompatibilitas untuk kompatibilitas mundur
Pengaturan tingkat kompatibilitas database memberikan kompatibilitas mundur dengan versi SQL Server yang lebih lama dalam apa yang berkaitan dengan perilaku Transact-SQL dan pengoptimalan kueri hanya untuk database yang ditentukan, bukan untuk seluruh server.
Dimulai dengan mode kompatibilitas 130, rencana kueri baru apa pun yang memengaruhi perbaikan dan fitur telah sengaja ditambahkan hanya ke tingkat kompatibilitas baru. Ini telah dilakukan untuk meminimalkan risiko selama peningkatan yang timbul dari penurunan performa karena perubahan rencana kueri yang berpotensi diperkenalkan oleh perilaku pengoptimalan kueri baru.
Dari perspektif aplikasi, gunakan tingkat kompatibilitas yang lebih rendah sebagai jalur migrasi yang lebih aman untuk mengatasi perbedaan versi, dalam perilaku yang dikontrol oleh pengaturan tingkat kompatibilitas yang relevan. Tujuannya masih harus meningkatkan ke tingkat kompatibilitas terbaru pada beberapa titik waktu, untuk mewarisi beberapa fitur baru seperti Pemrosesan Kueri Cerdas, tetapi untuk melakukannya dengan cara yang terkontrol.
Untuk informasi selengkapnya, termasuk alur kerja yang direkomendasikan untuk meningkatkan tingkat kompatibilitas database, lihat Praktik Terbaik untuk meningkatkan tingkat kompatibilitas database.
Fungsionalitas yang dihentikan yang diperkenalkan dalam versi SQL Server tertentu tidak dilindungi oleh tingkat kompatibilitas. Ini mengacu pada fungsionalitas yang dihapus dari Mesin Database SQL Server. Misalnya,
FASTFIRSTROW
petunjuk dihentikan di SQL Server 2012 (11.x) dan diganti denganOPTION (FAST n )
petunjuk. Mengatur tingkat kompatibilitas database ke 110 tidak akan memulihkan petunjuk yang dihentikan. Untuk informasi selengkapnya tentang fungsionalitas yang dihentikan, lihat Fungsionalitas mesin database yang dihentikan di SQL Server.Melanggar perubahan yang diperkenalkan dalam versi SQL Server tertentu mungkin tidak dilindungi oleh tingkat kompatibilitas. Ini mengacu pada perubahan perilaku antara versi Mesin Database SQL Server. Perilaku T-SQL biasanya dilindungi oleh tingkat kompatibilitas. Namun, objek sistem yang diubah atau dihapus tidak dilindungi oleh tingkat kompatibilitas.
Contoh perubahan melanggar yang dilindungi oleh tingkat kompatibilitas adalah konversi implisit dari jenis data datetime ke datetime2 . Di bawah tingkat kompatibilitas database 130, ini menunjukkan peningkatan akurasi dengan memperhitungkan milidetik pecahan, menghasilkan nilai yang dikonversi yang berbeda. Untuk memulihkan perilaku konversi sebelumnya, atur tingkat kompatibilitas database ke 120 atau lebih rendah.
Contoh perubahan yang melanggar yang tidak dilindungi oleh tingkat kompatibilitas adalah:
- Nama kolom yang diubah dalam objek sistem. Di SQL Server 2012 (11.x) kolom
single_pages_kb
disys.dm_os_sys_info
diganti namanya menjadipages_kb
. Terlepas dari tingkat kompatibilitas, kueriSELECT single_pages_kb FROM sys.dm_os_sys_info
akan menghasilkan kesalahan 207 (Nama kolom tidak valid). - Objek sistem yang dihapus. Di SQL Server 2012 (11.x)
sp_dboption
dihapus. Terlepas dari tingkat kompatibilitas, pernyataanEXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE';
akan menghasilkan kesalahan 2812 (Couldn't find stored procedure 'sp_dboption'
).
Untuk informasi selengkapnya tentang perubahan yang melanggar, lihat Melanggar Perubahan pada Fitur Mesin Database di SQL Server 2019, Melanggar Perubahan pada Fitur Mesin Database di SQL Server 2017, Merusak Perubahan pada Fitur Mesin Database di SQL Server 2016, dan Memutus Perubahan pada Fitur Mesin Database di SQL Server 2014.
- Nama kolom yang diubah dalam objek sistem. Di SQL Server 2012 (11.x) kolom
Perbedaan antara tingkat kompatibilitas
Untuk semua penginstalan SQL Server, tingkat kompatibilitas default dikaitkan dengan versi Mesin Database, seperti yang terlihat dalam tabel ini. Untuk pekerjaan pengembangan baru, selalu rencanakan untuk mensertifikasi aplikasi pada tingkat kompatibilitas database terbaru.
Sintaks Transact-SQL baru tidak terjaga oleh tingkat kompatibilitas database, kecuali ketika mereka dapat memutus aplikasi yang ada dengan membuat konflik dengan kode Transact-SQL pengguna. Pengecualian ini didokumentasikan di bagian berikutnya dari artikel ini yang menguraikan perbedaan antara tingkat kompatibilitas tertentu.
Tingkat kompatibilitas database juga memberikan kompatibilitas mundur dengan versi SQL Server yang lebih lama, karena database yang dilampirkan atau dipulihkan dari versi SQL Server sebelumnya mempertahankan tingkat kompatibilitas yang ada (jika sama atau lebih tinggi dari tingkat kompatibilitas minimum yang diizinkan). Ini dibahas di bagian Menggunakan tingkat kompatibilitas untuk kompatibilitas mundur dari artikel ini.
Dimulai dengan tingkat kompatibilitas database 130, perbaikan dan fitur baru apa pun yang memengaruhi rencana kueri telah ditambahkan hanya ke tingkat kompatibilitas terbaru yang tersedia, juga disebut tingkat kompatibilitas default. Ini telah dilakukan untuk meminimalkan risiko selama peningkatan yang muncul dari penurunan performa karena perubahan rencana kueri, berpotensi diperkenalkan oleh perilaku pengoptimalan kueri baru.
Perubahan dasar yang memengaruhi rencana ditambahkan hanya ke tingkat kompatibilitas default dari versi baru Mesin Database adalah:
Perbaikan Pengoptimal Kueri yang dirilis untuk versi SQL Server sebelumnya di bawah bendera pelacakan 4199 menjadi diaktifkan secara otomatis dalam tingkat kompatibilitas default versi SQL Server yang lebih baru.
Berlaku untuk: SQL Server (Dimulai dengan versi SQL Server 2016 (13.x)), Azure SQL Database.
Misalnya, ketika SQL Server 2016 (13.x) dirilis, semua perbaikan Pengoptimal Kueri yang dirilis untuk versi SQL Server sebelumnya (dan tingkat kompatibilitas masing-masing 100 hingga 120) menjadi diaktifkan secara otomatis untuk database yang menggunakan tingkat kompatibilitas default SQL Server 2016 (13.x) (130). Hanya perbaikan Pengoptimal Kueri pasca-RTM yang perlu diaktifkan secara eksplisit.
Untuk mengaktifkan perbaikan Pengoptimal Kueri, Anda bisa menggunakan metode berikut:
- Di tingkat server, dengan bendera pelacakan 4199.
- Pada tingkat database, dengan
QUERY_OPTIMIZER_HOTFIXES
opsi di UBAH KONFIGURASI CAKUPAN DATABASE (Transact-SQL). - Pada tingkat kueri, dengan
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
petunjuk kueri dengan memodifikasi kueri. - Pada tingkat kueri, dengan
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
tanpa perubahan kode, menggunakan fitur Petunjuk Penyimpanan Kueri (Pratinjau).
Kemudian, ketika SQL Server 2017 (14.x) dirilis, semua perbaikan Pengoptimal Kueri dirilis setelah RTM SQL Server 2016 (13.x) menjadi diaktifkan secara otomatis untuk database menggunakan tingkat kompatibilitas default SQL Server 2017 (14.x) (140). Ini adalah perilaku kumulatif yang mencakup semua perbaikan versi sebelumnya juga. Sekali lagi, hanya perbaikan Pengoptimal Kueri pasca-RTM yang perlu diaktifkan secara eksplisit.
Tabel berikut ini meringkas perilaku ini:
Versi Mesin Database (DE) Tingkat Kompatibilitas Database TF 4199 Perubahan QO dari semua Tingkat Kompatibilitas Database sebelumnya Perubahan QO untuk versi DE pasca-RTM 13 (SQL Server 2016 (13.x)) 100 hingga 120
130Nonaktif
Aktif
Nonaktif
AktifNonaktif
Diaktifkan
Diaktifkan
AktifNonaktif
Aktif
Nonaktif
Diaktifkan14 (SQL Server 2017 (14.x)) 100 hingga 120
130
140Nonaktif
Aktif
Nonaktif
Aktif
Nonaktif
AktifNonaktif
Diaktifkan
Diaktifkan
Diaktifkan
Diaktifkan
AktifNonaktif
Aktif
Nonaktif
Aktif
Nonaktif
Diaktifkan15 (SQL Server 2019 (15.x)) dan 12 (Azure SQL Database) 100 hingga 120
130 hingga 140
150Nonaktif
Aktif
Nonaktif
Aktif
Nonaktif
AktifNonaktif
Diaktifkan
Diaktifkan
Diaktifkan
Diaktifkan
AktifNonaktif
Aktif
Nonaktif
Aktif
Nonaktif
Diaktifkan16 (SQL Server 2022 (16.x)) dan 12 (Azure SQL Database) 100 hingga 120
130 hingga 150
160Nonaktif
Aktif
Nonaktif
Aktif
Nonaktif
AktifNonaktif
Diaktifkan
Diaktifkan
Diaktifkan
Diaktifkan
AktifNonaktif
Aktif
Nonaktif
Aktif
Nonaktif
DiaktifkanPengoptimal Kueri memperbaiki bahwa mengatasi hasil yang salah atau kesalahan pelanggaran akses tidak dilindungi oleh bendera pelacakan 4199. Perbaikan tersebut tidak dianggap opsional.
Perubahan pada Kardinalitas Estimator yang dirilis di SQL Server dan Azure SQL Database hanya diaktifkan dalam tingkat kompatibilitas default versi Mesin Database baru, tetapi tidak pada tingkat kompatibilitas sebelumnya.
Misalnya, ketika SQL Server 2016 (13.x) dirilis, perubahan pada proses estimasi kardinalitas hanya tersedia untuk database yang menggunakan tingkat kompatibilitas default SQL Server 2016 (13.x) (130). Tingkat kompatibilitas sebelumnya mempertahankan perilaku estimasi kardinalitas yang tersedia sebelum SQL Server 2016 (13.x).
Kemudian, ketika SQL Server 2017 (14.x) dirilis, perubahan yang lebih baru pada proses estimasi kardinalitas hanya tersedia untuk database yang menggunakan tingkat kompatibilitas default SQL Server 2017 (14.x) (140). Tingkat kompatibilitas database 130 mempertahankan perilaku estimasi kardinalitas SQL Server 2016 (13.x).
Tabel berikut ini meringkas perilaku ini:
Versi Mesin Database Tingkat Kompatibilitas Database Perubahan CE versi baru 13 (SQL Server 2016 (13.x)) < 130
130Nonaktif
Diaktifkan14 (SQL Server 2017 (14.x))1 < 140
140Nonaktif
Diaktifkan15 (SQL Server 2019 (15.x))1 < 150
150Nonaktif
Diaktifkan16 (SQL Server 2022 (16.x))1 < 160
160Nonaktif
Diaktifkan1 Juga berlaku untuk Azure SQL Database.
Perbedaan lain antara tingkat kompatibilitas tertentu tersedia di bagian berikutnya dari artikel ini.
Perbedaan antara tingkat kompatibilitas 150 dan tingkat 160
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 160.
Pengaturan tingkat kompatibilitas 150 atau lebih rendah | Pengaturan tingkat kompatibilitas 160 |
---|---|
Kueri berparameter memiliki satu rencana kueri berdasarkan parameter yang digunakan untuk eksekusi pertama. Hanya satu rencana kueri yang di-cache dan digunakan untuk semua nilai parameter. Ini dapat menyebabkan rencana kueri tidak efisien untuk beberapa nilai parameter, juga dikenal sebagai rencana sensitif parameter. | Kueri berparameter dapat memiliki beberapa rencana kueri yang di-cache untuk kategori selektivitas parameter yang berbeda. Pengoptimalan paket sensitif parameter diaktifkan secara default dalam tingkat kompatibilitas 160. Untuk informasi selengkapnya, lihat Pengoptimalan PSP. |
Estimasi kardinalitas hanya menggunakan satu set asumsi model default tentang distribusi data yang mendasari dan pola penggunaan untuk semua database dan kueri. Satu-satunya cara untuk mengubah atau menyesuaikan salah satu asumsi tersebut adalah ketika pengguna melakukan proses manual untuk secara eksplisit menunjukkan asumsi model mana yang harus digunakan, dengan menggunakan petunjuk kueri. Tidak ada penyesuaian internal yang dapat dilakukan pada model default ini setelah rencana kueri dibuat. | Estimasi kardinalitas dimulai dengan serangkaian asumsi model default tentang pola distribusi dan penggunaan data yang mendasarinya, tetapi setelah beberapa eksekusi untuk kueri tertentu, Mesin Database mempelajari kumpulan asumsi model yang berbeda mana yang mungkin menghasilkan perkiraan yang lebih akurat, dan oleh karena itu menyesuaikan asumsi yang digunakan agar lebih sesuai dengan kumpulan data yang dikueri. Umpan Balik CE diaktifkan secara default dalam tingkat kompatibilitas 160. Untuk informasi selengkapnya, lihat Umpan Balik CE. |
Tidak ada penentuan otomatis tingkat paralelisme optimal yang dicoba oleh Mesin Database. Untuk informasi tentang mengontrol tingkat paralelisme maksimum (MAXDOP) secara manual pada tingkat instans, database, kueri, atau beban kerja, lihat Konfigurasi server: tingkat paralelisme maksimum | Tingkat paralelisme (DOP) Umpan Balik meningkatkan performa kueri dengan mengidentifikasi inefisiensi paralelisme untuk kueri berulang, berdasarkan waktu dan waktu tunggu yang berlalu. Jika penggunaan paralelisme dianggap tidak efisien, Umpan Balik DOP akan menurunkan DOP untuk eksekusi kueri berikutnya, dari apa pun yang dikonfigurasi DOP, dan memverifikasi apakah itu membantu. Umpan Balik DOP tidak diaktifkan secara default. Untuk mengaktifkan Umpan Balik DOP, aktifkan DOP_FEEDBACK konfigurasi terlingkup database dalam database. Untuk informasi selengkapnya, lihat Umpan Balik DOP. |
Perbedaan antara tingkat kompatibilitas 140 dan tingkat 150
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 150.
Pengaturan tingkat kompatibilitas 140 atau lebih rendah | Pengaturan tingkat kompatibilitas 150 |
---|---|
Gudang data relasional dan beban kerja analitik mungkin tidak dapat menggunakan indeks penyimpan kolom karena overhead OLTP, kurangnya dukungan vendor atau batasan lainnya. Tanpa indeks penyimpan kolom, beban kerja ini tidak dapat memperoleh manfaat dari mode eksekusi batch. | Mode eksekusi batch sekarang tersedia untuk beban kerja analitik tanpa memerlukan indeks penyimpan kolom. Untuk informasi selengkapnya, lihat mode batch di rowstore. |
Kueri mode baris yang meminta ukuran pemberian memori yang tidak mencukupi yang mengakibatkan tumpahan ke disk mungkin terus mengalami masalah pada eksekusi berturut-turut. | Kueri mode baris yang meminta ukuran pemberian memori yang tidak mencukupi yang mengakibatkan tumpahan ke disk mungkin telah meningkatkan performa pada eksekusi berturut-turut. Untuk informasi selengkapnya, lihat umpan balik pemberian memori mode baris. |
Kueri mode baris yang meminta ukuran pemberian memori berlebihan yang mengalihkan masalah konkurensi mungkin terus mengalami masalah pada eksekusi berturut-turut. | Kueri mode baris yang meminta ukuran pemberian memori berlebihan yang mengakibatkan masalah konkurensi mungkin telah meningkatkan konkurensi pada eksekusi berturut-turut. Untuk informasi selengkapnya, lihat umpan balik pemberian memori mode baris. |
Kueri yang merujuk UDF skalar T-SQL akan menggunakan pemanggilan berulang, kurangnya biaya dan memaksa eksekusi serial. | UDF skalar T-SQL diubah menjadi ekspresi relasional yang setara yang "diinlin" ke dalam kueri panggilan, sering kali menghasilkan perolehan performa yang signifikan. Untuk informasi selengkapnya, lihat T-SQL skalar UDF inlining. |
Variabel tabel menggunakan tebakan tetap untuk perkiraan kardinalitas. Jika jumlah baris aktual jauh lebih tinggi dari nilai yang ditebak, performa operasi hilir dapat menderita. | Paket baru akan menggunakan kardinalitas aktual dari variabel tabel yang ditemui pada kompilasi pertama alih-alih tebakan tetap. Untuk informasi selengkapnya, lihat kompilasi yang ditangguhkan variabel tabel. |
Untuk informasi selengkapnya tentang fitur pemrosesan kueri yang diaktifkan di tingkat kompatibilitas database 150, lihat Apa yang baru di SQL Server 2019 dan Pemrosesan kueri cerdas dalam database SQL.
Perbedaan antara tingkat kompatibilitas 130 dan tingkat 140
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 140.
Pengaturan tingkat kompatibilitas 130 atau lebih rendah | Pengaturan tingkat kompatibilitas 140 |
---|---|
Perkiraan kardinalitas untuk pernyataan yang mereferensikan fungsi bernilai tabel multi-pernyataan menggunakan tebakan baris tetap. | Perkiraan kardinalitas untuk pernyataan yang memenuhi syarat yang merujuk fungsi bernilai tabel multi-pernyataan akan menggunakan kardinalitas aktual dari output fungsi. Ini diaktifkan melalui eksekusi interleaved untuk fungsi bernilai tabel multi-pernyataan. |
Kueri mode batch yang meminta ukuran pemberian memori yang tidak mencukupi yang mengakibatkan tumpahan ke disk mungkin terus mengalami masalah pada eksekusi berturut-turut. | Kueri mode batch yang meminta ukuran pemberian memori yang tidak mencukupi yang mengakibatkan tumpahan ke disk mungkin telah meningkatkan performa pada eksekusi berturut-turut. Ini diaktifkan melalui umpan balik pemberian memori mode batch yang akan memperbarui ukuran pemberian memori dari rencana yang di-cache jika tumpahan telah terjadi untuk operator mode batch. |
Kueri mode batch yang meminta ukuran pemberian memori yang berlebihan yang menghasilkan masalah konkurensi mungkin terus mengalami masalah pada eksekusi berturut-turut. | Kueri mode batch yang meminta ukuran pemberian memori berlebihan yang mengakibatkan masalah konkurensi mungkin telah meningkatkan konkurensi pada eksekusi berturut-turut. Ini diaktifkan melalui umpan balik pemberian memori mode batch yang akan memperbarui ukuran pemberian memori dari rencana yang di-cache jika jumlah yang berlebihan awalnya diminta. |
Kueri mode batch yang berisi operator gabungan memenuhi syarat untuk tiga algoritma gabungan fisik, termasuk perulangan berlapis, gabungan hash, dan gabungan gabungan. Jika perkiraan kardinalitas salah untuk input gabungan, algoritma gabungan yang tidak pantas mungkin dipilih. Jika ini terjadi, performa akan menderita, dan algoritma gabungan yang tidak pantas akan tetap digunakan sampai rencana yang di-cache dikompresi ulang. | Ada operator gabungan tambahan yang disebut gabungan adaptif. Jika perkiraan kardinalitas salah untuk input gabungan build luar, algoritma gabungan yang tidak pantas mungkin dipilih. Jika ini terjadi dan pernyataan memenuhi syarat untuk gabungan adaptif, perulangan berlapis akan digunakan untuk input gabungan yang lebih kecil, dan gabungan hash akan digunakan untuk input gabungan yang lebih besar secara dinamis tanpa memerlukan kompilasi ulang. |
Rencana sepele yang mereferensikan indeks Penyimpan kolom tidak memenuhi syarat untuk eksekusi mode batch. | Rencana sepele yang mereferensikan indeks Penyimpan kolom akan dibuang demi rencana yang memenuhi syarat untuk eksekusi mode batch. |
Operator sp_execute_external_script UDX hanya dapat berjalan dalam mode baris. |
Operator sp_execute_external_script UDX memenuhi syarat untuk eksekusi mode batch. |
Fungsi bernilai tabel multi-pernyataan (TVF) tidak memiliki eksekusi interleaved | Eksekusi interleaved untuk TVF multi-pernyataan untuk meningkatkan kualitas rencana. |
Perbaikan yang berada di bawah bendera pelacakan 4199 di versi SQL Server sebelumnya sebelum SQL Server 2017 sekarang diaktifkan secara default. Dengan mode kompatibilitas 140. Bendera pelacakan 4199 masih akan berlaku untuk perbaikan pengoptimal kueri baru yang dirilis setelah SQL Server 2017. Untuk informasi tentang Bendera Pelacakan 4199, lihat Bendera Pelacakan 4199.
Perbedaan antara tingkat kompatibilitas 120 dan tingkat 130
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 130.
Pengaturan tingkat kompatibilitas 120 atau lebih rendah | Pengaturan tingkat kompatibilitas 130 |
---|---|
INSERT dalam pernyataan INSERT-SELECT berutas tunggal. | INSERT dalam pernyataan INSERT-SELECT multi-utas atau dapat memiliki paket paralel. |
Kueri pada tabel yang dioptimalkan memori menjalankan utas tunggal. | Kueri pada tabel yang dioptimalkan memori sekarang dapat memiliki paket paralel. |
Memperkenalkan estimator Kardinalitas SQL 2014 KardinalitasEstimasiModelVersion="120" | Peningkatan estimasi kardinalitas lebih lanjut (CE) dengan Model Estimasi Kardinalitas 130, yang terlihat dari rencana Kueri. CardinalityEstimationModelVersion="130" |
Mode batch versus Mode Baris berubah dengan indeks Penyimpan Kolom:
|
Mode batch versus Mode Baris berubah dengan indeks Penyimpan Kolom:
|
Statistik dapat diperbarui secara otomatis. | Logika yang secara otomatis memperbarui statistik lebih agresif pada tabel besar. Dalam praktiknya, ini harus mengurangi kasus di mana pelanggan telah melihat masalah performa pada kueri di mana baris yang baru disisipkan sering dikueri tetapi di mana statistik belum diperbarui untuk menyertakan nilai-nilai tersebut. |
Jejak 2371 NONAKTIF secara default di SQL Server 2014 (12.x). | Jejak 2371 aktif secara default di SQL Server 2016 (13.x). Bendera pelacakan 2371 memberi tahu updater statistik otomatis untuk mengambil sampel subset baris yang lebih kecil namun lebih bijaksana, dalam tabel yang memiliki banyak baris. Salah satu peningkatannya adalah menyertakan dalam sampel lebih banyak baris yang disisipkan baru-baru ini. Peningkatan lain adalah membiarkan kueri berjalan saat proses statistik pembaruan berjalan, daripada memblokir kueri. |
Untuk tingkat 120, statistik diambil sampelnya oleh proses utas tunggal. | Untuk tingkat 130, statistik diambil sampelnya oleh proses multi-utas (proses paralel). |
253 kunci asing yang masuk adalah batasnya. | Tabel tertentu dapat dirujuk hingga 10.000 kunci asing masuk atau referensi serupa. Untuk pembatasan, lihat Membuat Hubungan Kunci Asing. |
Algoritma hash MD2, MD4, MD5, SHA, dan SHA1 yang tidak digunakan lagi diizinkan. | Hanya algoritma hash SHA2_256 dan SHA2_512 yang diizinkan. |
SQL Server 2016 (13.x) mencakup peningkatan dalam beberapa konversi jenis data dan beberapa operasi (sebagian besar tidak jarang). Untuk detailnya, lihat Peningkatan SQL Server 2016 dalam menangani beberapa jenis data dan operasi yang tidak biasa. | |
Fungsi STRING_SPLIT ini tidak tersedia. |
Fungsi STRING_SPLIT ini tersedia di bawah tingkat kompatibilitas 130 atau lebih tinggi. Jika tingkat kompatibilitas database Anda lebih rendah dari 130, SQL Server tidak akan dapat menemukan dan menjalankan STRING_SPLIT fungsi. |
Perbaikan yang berada di bawah bendera pelacakan 4199 di versi SQL Server sebelumnya sebelum SQL Server 2016 (13.x) sekarang diaktifkan secara default. Dengan mode kompatibilitas 130. Bendera pelacakan 4199 masih akan berlaku untuk perbaikan pengoptimal kueri baru yang dirilis setelah SQL Server 2016 (13.x). Untuk menggunakan pengoptimal kueri yang lebih lama di SQL Database, Anda harus memilih tingkat kompatibilitas 110. Untuk informasi tentang Bendera Pelacakan 4199, lihat Bendera Pelacakan 4199.
Perbedaan antara tingkat kompatibilitas yang lebih rendah dan tingkat 120
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 120.
Pengaturan tingkat kompatibilitas 110 atau lebih rendah | Pengaturan tingkat kompatibilitas 120 |
---|---|
Pengoptimal kueri yang lebih lama digunakan. | SQL Server 2014 (12.x) mencakup peningkatan substansial pada komponen yang membuat dan mengoptimalkan rencana kueri. Fitur pengoptimal kueri baru ini bergantung pada penggunaan tingkat kompatibilitas database 120. Aplikasi database baru harus dikembangkan menggunakan tingkat kompatibilitas database 120 untuk memanfaatkan peningkatan ini. Aplikasi yang dimigrasikan dari versi SQL Server sebelumnya harus diuji dengan hati-hati untuk mengonfirmasi bahwa performa yang baik dipertahankan atau ditingkatkan. Jika performa turun, Anda dapat mengatur tingkat kompatibilitas database ke 110 atau yang lebih lama untuk menggunakan metodologi pengoptimal kueri yang lebih lama. Tingkat kompatibilitas database 120 menggunakan estimator kardinalitas baru yang disetel untuk pergudangan data modern dan beban kerja OLTP. Sebelum mengatur tingkat kompatibilitas database ke 110 karena masalah performa, lihat rekomendasi di bagian Rencana Kueri dari artikel Apa yang Baru di Mesin Database SQL Server 2014 (12.x). |
Dalam tingkat kompatibilitas yang lebih rendah dari 120, pengaturan bahasa diabaikan saat mengonversi nilai tanggal menjadi nilai string. Perilaku ini hanya khusus untuk jenis tanggal . Lihat contoh B di bagian Contoh . | Pengaturan bahasa tidak diabaikan saat mengonversi nilai tanggal menjadi nilai string. |
Referensi rekursif di sisi EXCEPT kanan klausa membuat perulangan tak terbatas. Contoh C di bagian Contoh menunjukkan perilaku ini. |
Referensi rekursif dalam EXCEPT klausul menghasilkan kesalahan sesuai dengan standar ANSI SQL. |
Ekspresi tabel umum rekursif (CTE) memungkinkan nama kolom duplikat. | CTE rekursif tidak mengizinkan nama kolom duplikat. |
Pemicu yang dinonaktifkan diaktifkan jika pemicu diubah. | Mengubah pemicu tidak mengubah status (diaktifkan atau dinonaktifkan) pemicu. |
Klausa IDENTITY_INSERT SETTING = OFF tabel OUTPUT INTO mengabaikan dan memungkinkan nilai eksplisit disisipkan. |
Anda tidak dapat menyisipkan nilai eksplisit untuk kolom identitas dalam tabel saat IDENTITY_INSERT diatur ke NONAKTIF. |
Ketika penahanan database diatur ke parsial, memvalidasi $action bidang dalam OUTPUT klausul MERGE pernyataan dapat mengembalikan kesalahan kolase. |
Kolase nilai yang dikembalikan oleh $action klausul MERGE pernyataan adalah kolase database alih-alih kolase server dan kesalahan konflik kolase tidak dikembalikan. |
Pernyataan SELECT INTO selalu membuat operasi penyisipan satu alur. |
Pernyataan SELECT INTO dapat membuat operasi penyisipan paralel. Saat menyisipkan sejumlah besar baris, operasi paralel dapat meningkatkan performa. |
Perbedaan antara tingkat kompatibilitas yang lebih rendah dan tingkat 100 dan 110
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 110. Bagian ini juga berlaku untuk tingkat kompatibilitas di atas 110.
Pengaturan tingkat kompatibilitas 100 atau lebih rendah | Pengaturan tingkat kompatibilitas setidaknya 110 |
---|---|
Objek database runtime bahasa umum (CLR) dijalankan dengan versi 4 CLR. Namun, beberapa perubahan perilaku yang diperkenalkan dalam versi 4 CLR dihindari. Untuk informasi selengkapnya, lihat Apa yang Baru dalam Integrasi CLR. | Objek database CLR dijalankan dengan versi 4 CLR. |
XQuery memfungsikan string-length dan substring menghitung setiap pengganti sebagai dua karakter. | Fungsi XQuery panjang string dan substring menghitung setiap pengganti sebagai satu karakter. |
PIVOT diperbolehkan dalam kueri ekspresi tabel umum (CTE) rekursif. Namun, kueri mengembalikan hasil yang salah ketika ada beberapa baris per pengelompokan. |
PIVOT tidak diperbolehkan dalam kueri ekspresi tabel umum (CTE) rekursif. Kesalahan dikembalikan. |
Algoritma RC4 hanya didukung untuk kompatibilitas mundur. Materi baru hanya dapat dienkripsi menggunakan RC4 atau RC4_128 saat database berada dalam tingkat kompatibilitas 90 atau 100. (Tidak disarankan.) Di SQL Server 2012 (11.x), materi yang dienkripsi menggunakan RC4 atau RC4_128 dapat didekripsi dalam tingkat kompatibilitas apa pun. | Materi baru tidak dapat dienkripsi menggunakan RC4 atau RC4_128. Gunakan algoritma yang lebih baru seperti salah satu algoritma AES sebagai gantinya. Di SQL Server 2012 (11.x), materi yang dienkripsi menggunakan RC4 atau RC4_128 dapat didekripsi dalam tingkat kompatibilitas apa pun. |
Gaya default untuk CAST operasi dan CONVERT pada waktu dan jenis data datetime2 adalah 121 kecuali saat salah satu jenis digunakan dalam ekspresi kolom komputasi. Untuk kolom komputasi, gaya defaultnya adalah 0. Perilaku ini berdampak pada kolom komputasi saat dibuat, digunakan dalam kueri yang melibatkan parameterisasi otomatis, atau digunakan dalam definisi batasan.Contoh D di bagian Contoh memperlihatkan perbedaan antara gaya 0 dan 121. Ini tidak menunjukkan perilaku yang dijelaskan di atas. Untuk informasi selengkapnya tentang gaya tanggal dan waktu , lihat CAST dan CONVERT. |
Di bawah tingkat kompatibilitas 110, gaya default untuk CAST operasi dan CONVERT pada waktu dan jenis data datetime2 selalu 121. Jika kueri Anda bergantung pada perilaku lama, gunakan tingkat kompatibilitas kurang dari 110, atau tentukan gaya 0 secara eksplisit dalam kueri yang terpengaruh.Memutakhirkan database ke tingkat kompatibilitas 110 tidak akan mengubah data pengguna yang telah disimpan ke disk. Anda harus memperbaiki data ini secara manual sebagaimana mestinya. Misalnya, jika Anda menggunakan SELECT INTO untuk membuat tabel dari sumber yang berisi ekspresi kolom komputasi yang dijelaskan di atas, data (menggunakan gaya 0) akan disimpan daripada definisi kolom komputasi itu sendiri. Anda harus memperbarui data ini secara manual agar sesuai dengan gaya 121. |
Operator + (Penambahan) dapat diterapkan ke operan tanggal jenis, waktu, datetime2, atau datetimeoffset jika operand lain memiliki tanggalwaktu jenis atau waktu smalldatetime. | Mencoba menerapkan operator penambahan ke operand jenis tanggal, waktu, tanggalwaktu2, atau datetimeoffset dan operan jenis datetime atau smalldatetime akan menyebabkan kesalahan 402. |
Setiap kolom dalam tabel jarak jauh jenis smalldatetime yang direferensikan dalam tampilan yang dipartisi dipetakan sebagai tanggalwaktu. Kolom yang sesuai dalam tabel lokal (dalam posisi ordinal yang sama dalam daftar pilih) harus dari jenis tanggalwaktu. | Kolom apa pun dalam tabel jarak jauh jenis smalldatetime yang direferensikan dalam tampilan yang dipartisi dipetakan sebagai smalldatetime. Kolom terkait dalam tabel lokal (dalam posisi ordinal yang sama dalam daftar pilih) harus berjenis smalldatetime. Setelah memutakhirkan ke 110, tampilan terpartisi terdistribusi akan gagal karena ketidakcocokan jenis data. Anda dapat mengatasinya dengan mengubah tipe data pada tabel jarak jauh menjadi tanggalwaktu atau mengatur tingkat kompatibilitas database lokal menjadi 100 atau lebih rendah. |
SOUNDEX fungsi mengimplementasikan aturan berikut:1) Huruf besar H atau huruf besar W diabaikan saat memisahkan dua konsonan yang memiliki angka yang sama dalam SOUNDEX kode.2) Jika dua karakter pertama character_expression memiliki angka yang sama dalam SOUNDEX kode, kedua karakter disertakan. Jika tidak, jika satu set konsonan berdampingan memiliki angka yang sama dalam SOUNDEX kode, semuanya dikecualikan kecuali yang pertama. |
SOUNDEX fungsi mengimplementasikan aturan berikut:1) Jika huruf besar H atau huruf besar W memisahkan dua konsonan yang memiliki angka yang sama dalam SOUNDEX kode, konsonan di sebelah kanan diabaikan2) Jika satu set konsonan berdampingan memiliki angka yang sama dalam SOUNDEX kode, semuanya dikecualikan kecuali yang pertama.Aturan tambahan dapat menyebabkan nilai yang dihitung oleh fungsi berbeda dari SOUNDEX nilai yang dihitung di bawah tingkat kompatibilitas sebelumnya. Setelah meningkatkan ke tingkat kompatibilitas 110, Anda mungkin perlu membangun kembali indeks, tumpukan, atau batasan CHECK yang menggunakan SOUNDEX fungsi . Untuk informasi selengkapnya, lihat SOUNDEX. |
STRING_AGG tersedia tanpa <order_clause> . |
STRING_AGG tersedia dengan opsional <order_clause> . Untuk informasi selengkapnya, lihat STRING_AGG |
Perbedaan antara tingkat kompatibilitas 90 dan tingkat 100
Bagian ini menjelaskan perilaku baru yang diperkenalkan dengan tingkat kompatibilitas 100.
Pengaturan tingkat kompatibilitas 90 | Pengaturan tingkat kompatibilitas 100 | Kemungkinan dampak |
---|---|---|
Pengaturan QUOTED_IDENTIFIER selalu diatur ke AKTIF untuk fungsi bernilai tabel multistatement saat dibuat terlepas dari pengaturan tingkat sesi. | Pengaturan sesi PENGIDENTIFIKASI QUOTED dihormati saat fungsi bernilai tabel multistatement dibuat. | Medium |
Saat Anda membuat atau mengubah fungsi partisi, literal tanggalwaktu dan smalldatetime dalam fungsi dievaluasi dengan asumsi US_English sebagai pengaturan bahasa. | Pengaturan bahasa saat ini digunakan untuk mengevaluasi literal tanggalwaktu dan smalldatetime dalam fungsi partisi. | Medium |
Klausa FOR BROWSE diizinkan (dan diabaikan) dalam INSERT pernyataan dan SELECT INTO . |
Klausa FOR BROWSE tidak diizinkan dalam INSERT pernyataan dan SELECT INTO . |
Medium |
Predikat teks lengkap diizinkan dalam OUTPUT klausul. |
Predikat teks lengkap tidak diizinkan dalam OUTPUT klausul. |
Kurang Penting |
CREATE FULLTEXT STOPLIST , ALTER FULLTEXT STOPLIST , dan DROP FULLTEXT STOPLIST tidak didukung. Daftar henti sistem secara otomatis dikaitkan dengan indeks teks lengkap baru. |
CREATE FULLTEXT STOPLIST , ALTER FULLTEXT STOPLIST , dan DROP FULLTEXT STOPLIST didukung. |
Kurang Penting |
MERGE tidak diberlakukan sebagai kata kunci yang dipesan. |
MERGE adalah kata kunci yang dicadangkan sepenuhnya. Pernyataan MERGE ini didukung di bawah tingkat kompatibilitas 100 dan 90. |
Kurang Penting |
<dml_table_source> Menggunakan argumen pernyataan INSERT menimbulkan kesalahan sintaks. |
Anda dapat mengambil hasil klausa OUTPUT dalam pernyataan INSERT, UPDATE, DELETE, atau MERGE berlapis, dan menyisipkan hasil tersebut ke dalam tabel atau tampilan target. Ini dilakukan menggunakan <dml_table_source> argumen pernyataan INSERT. |
Kurang Penting |
Kecuali NOINDEX ditentukan, DBCC CHECKDB atau DBCC CHECKTABLE melakukan pemeriksaan konsistensi fisik dan logis pada satu tabel atau tampilan terindeks dan pada semua indeks non-kluster dan XML-nya. Indeks spasial tidak didukung. |
Kecuali NOINDEX ditentukan, DBCC CHECKDB atau DBCC CHECKTABLE melakukan pemeriksaan konsistensi fisik dan logis pada satu tabel dan pada semua indeks non-klusternya. Namun, pada indeks XML, indeks spasial, dan tampilan terindeks, hanya pemeriksaan konsistensi fisik yang dilakukan secara default.Jika WITH EXTENDED_LOGICAL_CHECKS ditentukan, pemeriksaan logis dilakukan pada tampilan terindeks, indeks XML, dan indeks spasial, jika ada. Secara default, pemeriksaan konsistensi fisik dilakukan sebelum pemeriksaan konsistensi logis. Jika NOINDEX juga ditentukan, hanya pemeriksaan logis yang dilakukan. |
Kurang Penting |
Ketika klausul OUTPUT digunakan dengan pernyataan bahasa manipulasi data (DML) dan kesalahan run-time terjadi selama eksekusi pernyataan, seluruh transaksi dihentikan dan digulung balik. | OUTPUT Ketika klausul digunakan dengan pernyataan bahasa manipulasi data (DML) dan kesalahan run-time terjadi selama eksekusi pernyataan, perilaku tergantung pada SET XACT_ABORT pengaturan. Jika SET XACT_ABORT NONAKTIF, pernyataan membatalkan kesalahan yang dihasilkan oleh pernyataan DML menggunakan OUTPUT klausul akan mengakhiri pernyataan, tetapi eksekusi batch berlanjut dan transaksi tidak digulung balik. Jika SET XACT_ABORT AKTIF, semua kesalahan run-time yang dihasilkan oleh pernyataan DML menggunakan klausul OUTPUT akan mengakhiri batch, dan transaksi digulung balik. |
Kurang Penting |
CUBE dan ROLLUP tidak diberlakukan sebagai kata kunci yang dipesan. | CUBE dan ROLLUP adalah kata kunci yang dicadangkan dalam klausul GROUP BY. |
Kurang Penting |
Validasi ketat diterapkan ke elemen jenis XML anyType . | Validasi laks diterapkan ke elemen jenis anyType . Untuk informasi selengkapnya, lihat Komponen Wildcard dan Validasi Konten. | Kurang Penting |
Atribut khusus xsi:nil dan xsi:type tidak dapat dikueri atau dimodifikasi oleh pernyataan bahasa manipulasi data. Ini berarti bahwa /e/@xsi:nil gagal saat /e/@* mengabaikan atribut xsi:nil dan xsi:type . Namun, /e mengembalikan atribut xsi:nil dan xsi:type untuk konsistensi dengan SELECT xmlCol , bahkan jika xsi:nil = "false" . |
Atribut khusus xsi:nil dan xsi:type disimpan sebagai atribut reguler dan dapat dikueri dan dimodifikasi. Misalnya, menjalankan kueri SELECT x.query('a/b/@*') mengembalikan semua atribut termasuk xsi:nil dan xsi:type. Untuk mengecualikan jenis ini dalam kueri, ganti @* dengan @*[namespace-uri(.) != " menyisipkan uri" namespace xsi dan bukan (local-name(.) = "type" atau local-name(.) ="nil". |
Kurang Penting |
Fungsi yang ditentukan pengguna yang mengonversi nilai string konstan XML ke jenis tanggalwaktu SQL Server ditandai sebagai deterministik. | Fungsi yang ditentukan pengguna yang mengonversi nilai string konstan XML ke jenis tanggalwaktu SQL Server ditandai sebagai non-deterministik. | Kurang Penting |
Jenis union dan daftar XML tidak didukung sepenuhnya. | Jenis penyatuan dan daftar didukung sepenuhnya termasuk fungsionalitas berikut: Persatuan daftar Persatuan serikat Daftar jenis atom Daftar serikat |
Kurang Penting |
Opsi SET yang diperlukan untuk metode xQuery tidak divalidasi saat metode terkandung dalam tampilan atau fungsi bernilai tabel sebaris. | Opsi SET yang diperlukan untuk metode xQuery divalidasi saat metode terkandung dalam tampilan atau fungsi bernilai tabel sebaris. Kesalahan dimunculkan jika opsi SET metode diatur dengan tidak benar. | Kurang Penting |
Nilai atribut XML yang berisi karakter akhir baris (pengembalian pengangkutan dan umpan baris) tidak dinormalisasi sesuai dengan standar XML. Artinya, kedua karakter dikembalikan alih-alih satu karakter umpan baris. | Nilai atribut XML yang berisi karakter akhir baris (pengembalian pengangkutan dan umpan baris) dinormalisasi sesuai dengan standar XML. Artinya, semua pemisah baris dalam entitas yang diurai eksternal (termasuk entitas dokumen) dinormalisasi pada input dengan menerjemahkan urutan dua karakter #xD #xA dan #xD apa pun yang tidak diikuti oleh #xA ke satu karakter #xA. Aplikasi yang menggunakan atribut untuk mengangkut nilai string yang berisi karakter akhir baris tidak akan menerima karakter ini kembali saat dikirimkan. Untuk menghindari proses normalisasi, gunakan entitas karakter numerik XML untuk mengodekan semua karakter akhir baris. |
Kurang Penting |
Properti ROWGUIDCOL kolom dan IDENTITY bisa salah dinamai sebagai batasan. Misalnya pernyataan CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) dijalankan, tetapi nama batasan tidak dipertahankan dan tidak dapat diakses oleh pengguna. |
Properti ROWGUIDCOL kolom dan IDENTITY tidak dapat dinamai sebagai batasan. Kesalahan 156 dikembalikan. |
Kurang Penting |
Memperbarui kolom dengan menggunakan penetapan dua arah seperti UPDATE T1 SET @v = column_name = <expression> dapat menghasilkan hasil yang tidak terduga karena nilai langsung variabel dapat digunakan dalam klausul lain seperti WHERE klausul dan ON selama eksekusi pernyataan alih-alih nilai awal pernyataan. Ini dapat menyebabkan arti predikat berubah secara tidak terduga per baris.Perilaku ini hanya berlaku ketika tingkat kompatibilitas diatur ke 90. |
Memperbarui kolom dengan menggunakan penetapan dua arah menghasilkan hasil yang diharapkan karena hanya nilai awal pernyataan kolom yang diakses selama eksekusi pernyataan. | Kurang Penting |
Penetapan variabel diizinkan dalam pernyataan yang berisi operator tingkat UNION atas, tetapi mengembalikan hasil yang tidak terduga. Pelajari selengkapnya dalam contoh E. |
Penetapan variabel tidak diizinkan dalam pernyataan yang berisi operator UNION tingkat atas. Kesalahan 10734 dikembalikan. Temukan penulisan ulang yang disarankan dalam contoh E. | Kurang Penting |
Fungsi ODBC {fn CONVERT()} menggunakan format tanggal default bahasa. Untuk beberapa bahasa, format defaultnya adalah YDM, yang dapat mengakibatkan kesalahan konversi ketika CONVERT() dikombinasikan dengan fungsi lain, seperti {fn CURDATE()} , yang mengharapkan format YMD. |
Fungsi ODBC {fn CONVERT()} menggunakan gaya 121 (format YMD independen bahasa) saat mengonversi ke tipe data ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME, dan SQL_TYPE_TIMESTAMP. |
Kurang Penting |
Intrinsik tanggalwaktu seperti DATEPART tidak mengharuskan nilai input string menjadi literal tanggalwaktu yang valid. Misalnya, SELECT DATEPART (year, '2007/05-30') kompilasi berhasil. |
Intrinsik tanggalwaktu seperti DATEPART mengharuskan nilai input string menjadi literal tanggalwaktu yang valid. Kesalahan 241 dikembalikan ketika literal tanggalwaktu yang tidak valid digunakan. |
Kurang Penting |
Spasi berikutnya yang ditentukan dalam parameter input pertama ke fungsi REPLACE dipangkas saat parameter berjenis karakter. Misalnya, dalam pernyataan SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' , nilai 'ABC ' salah dievaluasi sebagai 'ABC' . |
Spasi berikutnya selalu dipertahankan. Untuk aplikasi yang mengandalkan perilaku fungsi sebelumnya, gunakan RTRIM fungsi saat menentukan parameter input pertama untuk fungsi tersebut. Misalnya, sintaks berikut akan mereproduksi perilaku SQL Server 2005: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>' . |
Kurang Penting |
Kata kunci yang dicadangkan
Pengaturan kompatibilitas juga menentukan kata kunci yang dicadangkan oleh Mesin Database. Tabel berikut ini memperlihatkan kata kunci yang dipesan yang diperkenalkan oleh setiap tingkat kompatibilitas.
Pengaturan tingkat kompatibilitas | Kata kunci yang dicadangkan |
---|---|
130 |
Untuk ditentukan. |
120 |
Tidak ada. |
110 |
WITHIN GROUP , , TRY_CONVERT SEMANTICKEYPHRASETABLE , , SEMANTICSIMILARITYDETAILSTABLE ,SEMANTICSIMILARITYTABLE |
100 |
CUBE , , MERGE ROLLUP |
90 |
EXTERNAL , , PIVOT UNPIVOT , , REVERT ,TABLESAMPLE |
Pada tingkat kompatibilitas tertentu, kata kunci yang dipesan mencakup semua kata kunci yang diperkenalkan pada atau di bawah tingkat tersebut. Jadi, misalnya, untuk aplikasi pada tingkat 110, semua kata kunci yang tercantum dalam tabel sebelumnya dicadangkan. Pada tingkat kompatibilitas yang lebih rendah, kata kunci level-100 tetap nama objek yang valid, tetapi fitur bahasa tingkat 110 yang sesuai dengan kata kunci tersebut tidak tersedia.
Setelah diperkenalkan, kata kunci tetap dicadangkan. Misalnya, pivot kata kunci yang dipesan, yang diperkenalkan dalam tingkat kompatibilitas 90, juga dicadangkan dalam level 100, 110, dan 120.
Jika aplikasi menggunakan pengidentifikasi yang dicadangkan sebagai kata kunci untuk tingkat kompatibilitasnya, aplikasi akan gagal. Untuk mengatasi hal ini, sertakan pengidentifikasi antara tanda kurung siku ([]) atau tanda kutip (""); misalnya, untuk meningkatkan aplikasi yang menggunakan pengidentifikasi EXTERNAL
ke tingkat kompatibilitas 90, Anda dapat mengubah pengidentifikasi menjadi [EXTERNAL]
atau "EXTERNAL"
.
Untuk informasi selengkapnya, lihat Kata Kunci Yang Dicadangkan.
Izin
ALTER
Memerlukan izin pada database.
Contoh
J. Mengubah tingkat kompatibilitas
Contoh berikut mengubah tingkat AdventureWorks2022
kompatibilitas database sampel menjadi 150, default untuk SQL Server 2019 (15.x).
ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO
Contoh berikut mengembalikan tingkat kompatibilitas database saat ini.
SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();
GO
B. Abaikan pernyataan SET LANGUAGE kecuali di bawah tingkat kompatibilitas 120 atau lebih tinggi
Kueri berikut mengabaikan SET LANGUAGE
pernyataan kecuali di bawah tingkat kompatibilitas 120 atau lebih tinggi.
SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO
Hasil ketika tingkat kompatibilitas kurang dari 120: 12 May 2011
Hasil saat tingkat kompatibilitas diatur ke 120 atau lebih tinggi: 12 mei 2011
C. Untuk pengaturan tingkat kompatibilitas 110 atau lebih rendah, referensi rekursif di sisi kanan klausa EXCEPT membuat perulangan tak terbatas
WITH cte AS
(SELECT * FROM (VALUES (1),(2),(3)) v (a)),
r AS
(SELECT a FROM cte
UNION ALL
(SELECT a FROM cte EXCEPT SELECT a FROM r)
)
SELECT a
FROM r;
GO
D. Perbedaan antara gaya 0 dan 121
Ketika tingkat kompatibilitas lebih rendah dari 110, gaya default untuk CAST
dan CONVERT
operasi pada waktu dan jenis data datetime2 adalah 121 kecuali ketika salah satu jenis digunakan dalam ekspresi kolom komputasi. Untuk kolom komputasi, gaya defaultnya adalah 0.
Ketika tingkat kompatibilitas adalah 110 atau lebih tinggi, gaya default untuk CAST
dan CONVERT
operasi pada waktu dan jenis data datetime2 selalu 121. Lihat Perbedaan antara tingkat kompatibilitas yang lebih rendah dan tingkat 100 dan 110 untuk informasi selengkapnya.
Untuk informasi selengkapnya tentang gaya tanggal dan waktu, lihat CAST dan CONVERT.
DROP TABLE IF EXISTS t1;
GO
CREATE TABLE t1 (c1 time(7), c2 datetime2);
GO
INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
GO
SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
GO
Ini mengembalikan hasil seperti berikut ini:
TimeStyle0 | TimeStyle121 | Datetime2Style0 | Datetime2Style121 |
---|---|---|---|
15:15 | 15:15:35.8100000 | 7 Jun 2011 15:15 | 2011-06-07 15:15:35.8130000 |
E. Penetapan variabel - operator UNION tingkat atas
Di bawah pengaturan tingkat kompatibilitas database 90, penetapan variabel diizinkan dalam pernyataan yang berisi operator UNION tingkat atas, tetapi mengembalikan hasil yang tidak terduga. Misalnya, dalam pernyataan berikut, variabel @v
lokal diberi nilai kolom BusinessEntityID
dari penyatuan dua tabel. Menurut definisi, ketika pernyataan SELECT mengembalikan lebih dari satu nilai, variabel diberi nilai terakhir yang dikembalikan. Dalam hal ini, variabel diberi nilai terakhir dengan benar, namun, kumpulan hasil pernyataan SELECT UNION juga dikembalikan.
ALTER DATABASE AdventureWorks2022
SET compatibility_level = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;
Di bawah pengaturan tingkat kompatibilitas database 100 dan yang lebih tinggi, penetapan variabel tidak diizinkan dalam pernyataan yang berisi operator UNION tingkat atas. Kesalahan 10734 dikembalikan.
Untuk mengatasi kesalahan, tulis ulang kueri seperti yang diperlihatkan dalam contoh berikut.
DECLARE @v int;
SELECT @v = BusinessEntityID FROM
(SELECT BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;
Konten terkait
- Jaga stabilitas performa selama peningkatan ke SQL Server yang lebih baru
- Mengubah tingkat kompatibilitas database dan menggunakan Penyimpanan Kueri
- Sertifikasi kompatibilitas
- MENGUBAH DATABASE (T-SQL)
- Meningkatkan database menggunakan Asisten Penyetelan Kueri
- MEMBUAT DATABASE
- Menampilkan atau mengubah tingkat kompatibilitas database
- Petunjuk penyimpanan kueri