PEMBARUAN untuk Statistik

Beberapa rilis terakhir dari SQL Server telah memperkenalkan banyak fitur baru, serta peningkatan fungsionalitas yang ada. Salah satu area mesin yang mudah diabaikan adalah statistik. Lagi pula, statistik masih dibuat dengan cara yang sama, masih memberi tahu Anda tentang distribusi data, masih digunakan oleh Pengoptimal Kueri… apa bedanya? Fungsi dasar statistik tetap sama – tetapi cara penggunaannya oleh Pengoptimal Kueri berubah bergantung pada Penaksir Kardinalitas yang Anda gunakan. Ada juga beberapa perubahan penting terkait dengan pembaruan statistik dan fungsionalitas baru telah ditambahkan seputar melihat informasi statistik. Secara keseluruhan, perubahan ini di seluruh rilis terbaru dapat menyebabkan variasi dalam perilaku SQL Server yang tidak Anda harapkan.

Catatan:Posting ini paling berlaku untuk SQL Server 2012 dan lebih tinggi, tetapi beberapa detail untuk rilis sebelumnya disertakan untuk referensi (dan kesenangan).

SQL Server 7.0

Jumlah langkah dalam histogram dibatasi hingga 300. Dalam SQL Server 6.5 dan sebelumnya, histogram akan memiliki jumlah langkah yang dapat ditampung pada halaman 2K, berdasarkan ukuran kolom pertama di kunci.
Opsi database 'perbarui statistik secara otomatis' diperkenalkan; statistik sebelumnya hanya diperbarui secara manual.

SQL Server 2000

Jumlah langkah dalam histogram dikurangi dari 300 menjadi 200 (secara teknis 201, jika Anda menyertakan langkah untuk NULL, dengan asumsi kolom pertama dalam kunci mengizinkan NULL).

SQL Server 2005

Pembaruan statistik yang menggunakan FULLSCAN dapat berjalan secara paralel.
Trace Flags 2389 dan 2390 diperkenalkan di SP1 untuk membantu masalah Ascending Key, dijelaskan dalam posting, Ascending Keys dan Auto Quick Correct Statistics. Contoh mendetail dari skenario ini tersedia di postingan saya Trace Flag 2389 dan Cardinality Estimator yang baru.
Opsi instans 'Secara Otomatis Perbarui Statistik Secara Asinkron' diperkenalkan. Perhatikan bahwa agar ini berlaku, opsi 'Perbarui Statistik Secara Otomatis' juga harus diaktifkan. Jika Anda tidak jelas tentang apa yang dilakukan opsi ini, tinjau dokumentasi di Opsi ALTER DATABASE SET. Ini adalah pengaturan yang direkomendasikan Glenn (seperti yang tercantum dalam posnya yang dirujuk di bawah), tetapi saya pikir penting untuk menyadari potensi masalah, seperti yang tercantum dalam Bagaimana Pembaruan Otomatis pada Statistik Dapat Mempengaruhi Kinerja Kueri.

Catatan: Ada kebocoran memori terkait pengaturan ini di SQL Server 2008 hingga SQL Server 2012; silakan lihat posting Glenn Perbaikan Terbaru Penting untuk SQL Server 2008 untuk detail lebih lanjut.

SQL Server 2008

Statistik yang difilter diperkenalkan, dan ini dapat dibuat secara terpisah dari indeks yang difilter. Ada beberapa batasan di sekitar indeks yang difilter sehubungan dengan Pengoptimal Kueri (lihat posting Tim Chapman The Pains of Filtered Indexes dan posting Paul White Pembatasan Pengoptimal dengan Indeks yang Difilter), dan penting untuk memahami perilaku penghitung yang melacak modifikasi (dan sehingga dapat memicu pembaruan otomatis). Lihat posting Kimberly Indeks yang difilter dan statistik yang difilter mungkin menjadi sangat ketinggalan zaman untuk detail lebih lanjut, dan saya juga merekomendasikan untuk memeriksa prosedur tersimpannya yang menganalisis kemiringan data dan merekomendasikan tempat Anda dapat membuat statistik yang difilter untuk memberikan informasi lebih lanjut ke Pengoptimal Kueri. Saya telah menerapkan ini untuk beberapa pelanggan besar yang memiliki VLT dan distribusi miring di seluruh kolom yang sering digunakan dalam predikat.
Dua tampilan katalog baru, sys.stats dan sys.stats_columns, ditambahkan untuk memberikan wawasan yang lebih mudah tentang statistik dan kolom yang disertakan. Gunakan dua tampilan ini sebagai ganti sp_helpstats, yang tidak digunakan lagi dan memberikan lebih sedikit informasi.

SQL Server 2008R2 SP1

Trace Flag 2371 tersedia, yang dapat digunakan untuk mengurangi jumlah modifikasi yang diperlukan agar terjadi pembaruan otomatis pada statistik. Sebagai pengingat, saya penggemar pembaruan statistik secara teratur melalui pekerjaan terjadwal dan membiarkan pembaruan otomatis diaktifkan sebagai keamanan.

SQL Server 2008R2 SP2

Fungsi sys.dm_db_stats_properties disertakan, yang menyediakan informasi yang sama yang ditemukan di header DBCC SHOW_STATISTICS, serta kolom modifikasi yang dapat digunakan untuk melacak perubahan dan secara terprogram menentukan apakah pembaruan diperlukan. Ingat preferensi saya untuk menggunakan pekerjaan untuk memperbarui statistik? Pekerjaan itu menjadi jauh lebih pintar dengan DMF ini…sekarang saya dapat melihat untuk melihat berapa banyak data yang telah dimodifikasi dan HANYA memperbarui statistik jika persentase tertentu dari data telah berubah. Licin.

SQL Server 2012

Memperbarui statistik tidak akan menyebabkan rencana menjadi tidak valid JIKA tidak ada baris yang berubah. Ini adalah salah satu yang mengejutkan banyak orang, dan Kimberly memiliki posting yang menyenangkan, Apa yang menyebabkan rencana itu menjadi sangat salah – haruskah Anda memperbarui statistik?, yang menjelaskan petualangannya dalam mencari tahu ini.

SQL Server 2012 SP1

DBCC SHOW_STATISTICS hanya memerlukan izin SELECT – sebelumnya mengharuskan pengguna untuk menjadi anggota sysadmin, atau anggota peran basis data db_owner atau db_ddladmin. Ini dapat dinonaktifkan secara global dengan trace flag 9485.
Termasuk sys.dm_db_stats_properties (lihat catatan SP2 2008R2 di atas)

SQL Server 2012 SP2

Pembaruan Kumulatif 1 memperkenalkan perbaikan terkait dengan kunci menaik yang tidak diidentifikasi dengan benar bahkan dengan tanda pelacakan 2389 dan 2390 yang digunakan. Ini membutuhkan tanda jejak 4139 selain CU1, seperti yang dicatat dalam KB 2952101.

SQL Server 2014

Penaksir Kardinalitas baru diperkenalkan, diimplementasikan dengan menyetel mode kompatibilitas basis data ke 120, atau dengan menggunakan tanda jejak 2312. Jika Anda belum membaca apa pun tentang CE baru, saya sarankan untuk memulai dengan dokumentasi Estimasi Kardinalitas dan kemudian membaca Joe Buku putih Sack, Mengoptimalkan Rencana Kueri Anda dengan Pengukur Kardinalitas SQL Server 2014, untuk detail mendalam.
Perilaku dari Trace Flags 2389 dan 2390 untuk ascending keys sekarang diimplementasikan melalui mode kompatibilitas database. Jika mode kompatibilitas database Anda diatur ke 120 (atau lebih tinggi di rilis yang lebih baru), Anda tidak perlu menggunakan Trace Flags 2389 dan 2390 untuk SQL Server untuk mengidentifikasi statistik yang memiliki kunci menaik.
Statistik tambahan diperkenalkan untuk partisi, dan dapat dilihat melalui sys.dm_db_incremental_stats_properties DMF baru. Statistik tambahan menyediakan cara untuk memperbarui statistik untuk partisi tanpa memperbaruinya untuk seluruh tabel. Namun, informasi statistik tambahan dari statistik inkremental tidak digunakan oleh Pengoptimal Kueri, tetapi digabungkan ke dalam histogram utama untuk tabel.
CU2 menyertakan perbaikan yang sama yang disebutkan di atas untuk SQL Server 2012 SP2 yang juga memerlukan tanda pelacakan 4139.

SQL Server 2014 SP1

Trace flag 7471 di-porting kembali ke CU6, awalnya tersedia di SQL Server 2016 seperti yang disebutkan di bawah ini.

SQL Server 2016

Trace flag 2371 tidak lagi diperlukan untuk mengurangi ambang batas untuk pembaruan otomatis statistik jika mode kompatibilitas database diatur ke 130. Lihat Mengontrol perilaku Autostat (AUTO_UPDATE_STATISTICS) di SQL Server.
Pembaruan statistik dapat berjalan secara paralel saat menggunakan SAMPEL, bukan hanya FULLSCAN. Ini terkait dengan mode kompatibilitas (harus 130), tetapi berpotensi memberikan pembaruan yang lebih cepat dan dengan demikian mengurangi masa pemeliharaan. Aaron Bertrand berbicara tentang peningkatan ini di posnya, Peningkatan potensial untuk pembaruan statistik:MAXDOP.
Trace flag 7471 diperkenalkan di CU1 untuk memungkinkan beberapa perintah UPDATE STATISTICS berjalan secara bersamaan untuk satu tabel dan Jonathan memberikan beberapa contoh bagus tentang bagaimana ini dapat digunakan dalam posnya Peningkatan Dukungan untuk Pembuatan Ulang Statistik Paralel.

SQL Server 2016 SP1

Opsi petunjuk kueri ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS diperkenalkan, bersama dengan argumen FOR HINT, yang setara dengan flag trace 4139.
DMF sys.dm_db_stats_histogram diekspos di CU2, yang merupakan alternatif keluaran histogram dari DBCC SHOW_STATISTICS. Informasi di keduanya sama, gunakan apa yang lebih mudah bagi Anda atau lebih sesuai dengan masalah yang perlu Anda selesaikan.
Opsi PERSIST_SAMPLE_PERCENT diperkenalkan di CU4, yang dapat digunakan untuk memaksa laju pengambilan sampel yang sama untuk digunakan setiap kali statistik diperbarui ke depan, dan contoh perilaku ini dapat ditemukan di pos, Laju pengambilan sampel statistik yang bertahan.

SQL Server 2017

Opsi PERSIST_SAMPLE_PERCENT tersedia di CU1 (lihat entri SP1 2016 untuk info tambahan).
Atribut StatsInfoType dan OptimizerStatsUsageType ditambahkan ke Paket Kueri, yang mencantumkan statistik yang digunakan selama pengoptimalan kueri. Ini tersedia di CU3 dan terikat dengan versi CE (120 dan lebih tinggi). Ini sangat keren! Saya belum memiliki kesempatan untuk bermain dengan ini, tetapi untuk mendapatkan informasi ini sebelumnya, Anda harus menggunakan tanda jejak yang tidak berdokumen.
CU3 juga memperkenalkan opsi MAXDOP untuk CREATE STATISTICS dan UPDATE STATISTICS, yang dapat digunakan untuk mengganti nilai MAXDOP untuk instans atau database.
Satu tambahan lagi di CU3:atribut UdfCpuTime dan UdfElapsedTime dapat ditemukan di Rencana Kueri, yang mewakili statistik eksekusi untuk UDF bernilai skalar.

Ringkasan

Jika Anda ingin meningkatkan ke rilis yang lebih baru, atau jika Anda baru saja meningkatkan versi, perhatikan bagaimana perubahan ini memengaruhi solusi Anda. Kami memiliki banyak klien yang menghubungi kami setelah memutakhirkan dari 2005/2008/2008R2 ke 2014 atau 2016, mengeluhkan masalah kinerja. Dalam banyak kasus, pengujian yang memadai tidak diselesaikan sebelum peningkatan.

Ini adalah sesuatu yang sangat kami fokuskan ketika kami membantu peningkatan klien. Di luar langkah-langkah untuk memindahkan instans produksi dari satu versi ke versi lain dengan sedikit waktu henti, kami ingin memastikan bahwa hari setelah pemutakhiran adalah hari yang membosankan bagi DBA dan pengembang.

Kami tidak hanya menguji proses pemutakhiran, kami menguji seperti apa sistem setelah pemutakhiran. Apakah tanda jejak yang sama dari lingkungan lama diperlukan di lingkungan baru? Pengaturan database apa yang perlu disesuaikan? Apakah kinerja kueri berubah – menjadi lebih baik atau lebih buruk? Jika Anda tidak tahu jawaban atas pertanyaan-pertanyaan itu sebelum Anda meningkatkan produksi, maka Anda menyiapkan diri untuk satu hingga beberapa hari pemadaman kebakaran, panggilan Sev 1, makan di meja Anda, kurang tidur dan siapa yang tahu apa lagi .

Luangkan waktu terlebih dahulu untuk memahami dampak fitur baru dan perubahan fungsi yang tercantum di atas, rencanakan peningkatan, dan uji sebanyak mungkin.