Saat Anda membuat database baru di SQL Server, opsi Statistik Pembaruan Otomatis diaktifkan secara default. Biasanya disarankan untuk membiarkan opsi ini diaktifkan. Idealnya, statistik dikelola oleh pekerjaan terjadwal, dan opsi otomatis digunakan sebagai jaring pengaman – tersedia untuk memperbarui statistik jika pembaruan terjadwal tidak terjadi, atau secara tidak sengaja tidak menyertakan semua statistik yang ada.
Beberapa DBA hanya mengandalkan pembaruan otomatis untuk mengelola statistik, dan selama tidak ada masalah kinerja yang terkait dengan statistik yang kedaluwarsa atau sampel yang buruk, hal ini dapat diterima. Jika Anda mengandalkan opsi ini untuk mengelola statistik Anda, dan Anda memiliki beberapa tabel yang sangat besar, mungkin ada baiknya menerapkan flag trace 2371. Seperti halnya flag trace, pastikan Anda menguji dengan beban kerja yang representatif sebelum mengimplementasikannya dalam produksi. Anda mungkin sudah menyadari bahwa ada kalanya pembaruan otomatis dapat memengaruhi kinerja sistem. Misalnya, pembaruan statistik dapat menyebabkan lonjakan CPU atau I/O saat tabel atau data indeks dibaca, serta menunda eksekusi kueri saat pembaruan terjadi. Ada opsi basis data lain yang dapat Anda aktifkan untuk mengatasi penundaan kueri itu, dan saya akan membahasnya nanti di pos ini.
Pertanyaan yang sering diajukan kepada saya adalah, "Bagaimana Anda tahu jika pembaruan otomatis pada statistik menyebabkan masalah kinerja?" Salah satu opsi adalah melacaknya, dan mengaitkan pembaruan dengan perubahan kinerja. Ada banyak opsi untuk melacak pembaruan, dan dalam posting ini kami akan meninjau beberapa metode yang tersedia sehingga Anda dapat memilih dan kemudian menerapkan opsi yang paling sesuai dengan metode pemantauan Anda yang ada untuk masalah kinerja.
Pelacakan SQL
Jika Anda menjalankan SQL Server 2008 R2 atau lebih rendah di lingkungan Anda, SQL Trace adalah salah satu metode yang dapat Anda gunakan untuk merekam pembaruan otomatis. Skrip definisi jejak yang digunakan di bawah ini hanya menangkap peristiwa Statistik Otomatis, yang menangkap saat statistik diperbarui secara otomatis, dan saat statistik dibuat secara otomatis. Setelah pelacakan ini berjalan untuk sementara waktu di lingkungan Anda, Anda dapat memuatnya ke dalam tabel dan kemudian meminta output untuk melihat pembaruan apa yang terjadi. Skrip yang disertakan di bawah ini menjelaskan contoh menggunakan database sampel statistik bisbol.
Acara yang Diperpanjang
Jika Anda menjalankan SQL Server 2012 atau lebih tinggi, saya sarankan menggunakan Extended Events untuk merekam pembaruan otomatis. Seperti skrip SQL Trace, skrip definisi sesi yang disertakan hanya menangkap peristiwa Statistik Otomatis – sekali lagi, pembaruan otomatis dan pembuatan otomatis. Setelah sesi XE berjalan beberapa saat, Anda dapat memuat output ke dalam tabel melalui UI dan kemudian menanyakannya untuk melihat pembaruan apa yang terjadi. Skrip yang disertakan berjalan melalui contoh yang sama seperti sebelumnya, tetapi kali ini menggunakan Peristiwa yang Diperpanjang untuk mengumpulkan data.
sys.dm_db_stats_properties
Opsi ketiga yang dapat Anda pertimbangkan untuk memantau pembaruan statistik adalah sys.dm_db_stats_properties DMF, yang hanya tersedia di SQL Server 2008 R2 SP2 dan lebih tinggi, dan SQL Server 2012 SP1 dan lebih tinggi. Sama seperti saya menyukai DMF ini, solusi ini lebih rumit dalam hal memastikan Anda menangkap semua data, dan meninjau hasilnya membutuhkan lebih banyak pekerjaan. Dengan DMF, setiap pembaruan otomatis tidak dilacak, kami hanya memperbarui informasi statistik tren untuk melihat kapan pembaruan terjadi.
Ini adalah tugas sederhana:Anda membuat tabel untuk menyimpan informasi statistik, dan kemudian mengambil informasi dari DMF ke tabel secara teratur. Kuncinya di sini adalah untuk mengetahui seberapa sering untuk menangkap data. Setiap jam mungkin berlebihan, sekali sehari mungkin tidak cukup sering. Saya sarankan memulai dengan pekerjaan Agen SQL yang memotret data DMF setiap empat jam. Biarkan itu berjalan selama beberapa hari, lalu periksa data Anda. Jika statistik diperbarui paling banyak sekali sehari, maka Anda dapat meningkatkan interval menjadi setiap delapan atau dua belas jam. Jika statistik mudah diperbarui setiap empat jam, maka turunkan interval Anda menjadi setiap dua jam – Anda ingin memastikan bahwa Anda merekam setiap pembaruan. Untuk alasan ini, untuk beberapa sistem, sys.dm_db_stats_properties mungkin tidak sepadan dengan usaha; sesi XE atau Trace mungkin lebih sederhana.
Contoh skrip terakhir menjelaskan contoh bagaimana Anda akan menggunakan sys.dm_db_stats_properties untuk tren pembaruan statistik. Ketahuilah bahwa skrip ini hanya menangkap informasi statistik untuk satu tabel. Jika Anda mengubah skrip untuk menangkap setiap tabel dalam database, akan ada lebih banyak data untuk dianalisis.
Langkah Selanjutnya
Unduh skrip contoh, dan putuskan metode mana yang harus Anda gunakan untuk melacak pembaruan statistik.
Setelah Anda memiliki data yang ditampilkan saat pembaruan otomatis terjadi, Anda perlu mengaitkannya kembali dengan masalah kinerja yang diketahui. Dengan demikian, jika Anda tidak melacak metrik kinerja apa pun, maka data pembaruan statistik otomatis tidak akan membantu dengan korelasi apa pun. Dengan asumsi Anda memiliki stempel waktu untuk masalah kinerja apa pun, Anda dapat membandingkannya dengan StartTime dan EndTime dari Trace, timestamp dari XE, atau last_updated dari sys.dm_db_stats_properties DMF, untuk menentukan apakah pembaruan otomatis memengaruhi kinerja sistem.
Jika Anda tidak dapat membuat korelasi apa pun antara pembaruan dan masalah kinerja, maka Anda dapat mengesampingkan pembaruan sebagai penyebab masalah, dan fokus pada area lain. Jika pembaruan adalah penyebab utama, maka Anda memiliki dua opsi:nonaktifkan opsi Statistik Pembaruan Otomatis, atau aktifkan opsi Pembaruan Statistik Otomatis Secara Asinkron. Keduanya memiliki kelebihan dan kekurangan yang harus Anda pertimbangkan sebagai DBA.
Menonaktifkan Statistik Pembaruan Otomatis
Jika Anda memilih untuk menonaktifkan opsi statistik pembaruan otomatis, dua hal terpenting yang perlu diketahui adalah:
- Anda benar-benar harus mengelola statistik Anda melalui tugas pemeliharaan atau tugas khusus.
- Kueri tidak akan dikompilasi ulang saat Anda memperbarui statistik di SQL Server 2008 R2 dan di bawahnya.
Saya melihat item kedua sebagai tantangan yang lebih besar – saya adalah pendukung besar untuk mengelola statistik dan berharap bahwa itu adalah sesuatu yang dilakukan DBA. Masalah yang lebih besar adalah, meskipun memperbarui statistik biasanya menyebabkan kueri dikompilasi ulang (untuk memanfaatkan statistik yang diperbarui), hal ini tidak terjadi saat Anda menonaktifkan opsi statistik pembaruan otomatis. Saya telah menulis tentang ini sebelumnya, dan menyarankan untuk meninjau informasi ini jika Anda tidak terbiasa dengan perilaku ini. Lihat juga postingan tindak lanjut untuk mengetahui opsi untuk mengatasinya.
Secara umum, ini bukan jalan yang saya rekomendasikan. Ada kasus tepi yang sangat spesifik di mana ini mungkin sesuai, tetapi saya lebih suka melihat DBA melakukan pembaruan manual (melalui pekerjaan terjadwal) untuk menghindari pembaruan otomatis, dan membiarkan opsi diaktifkan sebagai tindakan keamanan.
Mengaktifkan Statistik Pembaruan Otomatis Secara Asinkron
Saat Anda mengaktifkan opsi Auto Update Statistics Asynchronously, jika statistik telah dibatalkan dan kueri yang menggunakan statistik tersebut dijalankan, statistik tidak akan diperbarui hingga setelah kueri selesai – pembaruan tidak sinkron. Manfaatnya di sini adalah pembaruan tidak akan memengaruhi kueri yang dijalankan; kekurangannya adalah kueri akan menggunakan rencana yang ada, yang mungkin bukan lagi rencana yang optimal. Apakah paket tersebut masih optimal akan bergantung pada beban kerja Anda (mis. beban kerja pelaporan dengan kueri yang berjalan lama). Sebagai DBA, Anda harus mempertimbangkan pro dan kontra dari mengaktifkan opsi ini, dan menentukan apa yang terbaik untuk database Anda. Perhatikan bahwa jika Anda menjalankan SQL Server 2008 hingga 2012, ada kebocoran memori yang terkait dengan pengaturan ini. Microsoft memang memiliki Pembaruan Kumulatif yang menyediakan perbaikan, tetapi jika Anda belum menerapkannya, Anda menghadapi keputusan lain:terapkan CU sehingga Anda dapat mengaktifkan opsi, atau tidak menerapkan CU dan tidak mengaktifkan pilihan.
Ringkasan
Satu-satunya cara untuk mengetahui apakah pembaruan otomatis ke statistik memengaruhi kinerja kueri adalah dengan melihat pembaruan terjadi pada saat yang sama dengan masalah, atau merekam saat pembaruan terjadi dan menghubungkan data dengan informasi tambahan yang Anda tangkap tentang masalah kinerja. Opsi terakhir memungkinkan Anda untuk proaktif – bahkan jika Anda tidak mengalami masalah kinerja, mungkin ada baiknya untuk mengetahui seberapa sering pembaruan otomatis terjadi. Pembaruan yang sering mungkin berarti Anda perlu mengunjungi kembali pekerjaan Agen yang mengelola statistik secara manual. Secara umum, biarkan opsi untuk memperbarui statistik secara otomatis diaktifkan, tetapi miliki metode untuk mengelola statistik dan gunakan opsi tersebut sebagai jaring pengaman.
