Berapa banyak waktu yang Anda habiskan untuk memecahkan masalah kinerja sebagai Administrator Basis Data atau Pengembang? Apakah Anda pernah melacaknya? Sebagai persentase total rata-rata hari Anda, ini mungkin tidak terlihat seperti banyak waktu, tetapi ketika masalahnya serius, Anda dapat menghabiskan waktu berjam-jam untuk melacaknya dan bekerja melalui analisis akar masalah. Terkadang masalahnya hilang dan Anda tidak tahu asal usul yang sebenarnya. Dan bahkan lebih buruk? Ketika Anda harus melawan masalah ini di tengah malam atau di akhir pekan. Anda tidak hanya berebut untuk memecahkan masalah, tetapi Anda juga kehilangan waktu luang pribadi Anda. Bagaimana kita meringankan itu? Bagaimana cara kami meluangkan waktu dan upaya kami, dan memperbaiki kinerja pada saat yang bersamaan?
Fitur Penyetelan Otomatis di SQL Server 2017 Enterprise Edition dan Azure SQL Database adalah langkah pertama dalam mengurangi waktu yang dihabiskan para profesional data untuk memecahkan masalah dan memecahkan masalah kinerja. Fitur ini mencakup Koreksi Rencana Otomatis dan Manajemen Indeks Otomatis (hanya tersedia di Azure SQL Database), yang diaktifkan secara independen. Pada postingan kali ini saya ingin fokus pada fitur Automatic Plan Correction. Dengan Koreksi Rencana Otomatis, jika SQL Server menemukan bahwa kueri telah mundur secara signifikan, itu akan memaksa rencana bagus terakhir yang diketahui untuk kueri untuk menstabilkan kinerja. Pada dasarnya, daripada Anda, DBA atau Pengembang, yang dipanggil pada akhir pekan tentang kinerja sistem, SQL Server akan menanganinya untuk Anda. Kedengarannya terlalu mudah, bukan? Mari kita lihat.
Di Bawah Selimut
Pertama, penting untuk memahami bahwa Koreksi Rencana Otomatis menggunakan Penyimpanan Kueri, sehingga harus diaktifkan untuk database. Kedua, Koreksi Rencana Otomatis hanyalah pemaksaan rencana otomatis. Sementara Penyimpanan Kueri dipasarkan sebagai perekam penerbangan untuk database Anda yang melacak teks kueri, rencana, statistik waktu proses, dan statistik tunggu, ini juga memungkinkan Anda memaksakan rencana kueri untuk memungkinkan kinerja yang konsisten. Koreksi Rencana Otomatis adalah pemaksaan rencana tanpa campur tangan Anda.
Mengaktifkan Koreksi Paket Otomatis
Seperti disebutkan, Penyimpanan Kueri harus diaktifkan terlebih dahulu untuk database pengguna. Ini dapat dilakukan di SSMS, dengan T-SQL, dan dengan REST API untuk Azure SQL DB. Perhatikan bahwa Penyimpanan Kueri diaktifkan secara default untuk database di Azure, dan telah diaktifkan sejak Q4 2016.
Mengaktifkan Penyimpanan Kueri melalui SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Mengaktifkan Query Store menggunakan T-SQL
Kode di atas adalah T-SQL default dari SSMS jika Anda membuat skrip. Di Azure SQL Database Anda tidak menjalankan pernyataan USE. Jika Anda ingin mengubah salah satu opsi default, harap baca postingan Pengaturan Penyimpanan Kueri saya tentang opsi tersebut dan pertimbangan untuk nilai alternatif.
Setelah Query Store diaktifkan, Anda dapat menggunakan Azure Portal, T-SQL, atau EST API untuk mengaktifkan Automatic Plan Correction di Azure SQL Database ((dan C# dan PowerShell sedang dikerjakan). Ini hanya dapat diaktifkan dengan T-SQL di SQL Server 2017.
Mengaktifkan Koreksi Paket Otomatis di Portal Azure
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Mengaktifkan Koreksi Rencana Otomatis di T-SQL
Perhatikan bahwa Koreksi Rencana Otomatis akan diaktifkan secara default untuk database baru di Azure dalam waktu dekat. Mulai Januari 2018, Penyetelan Otomatis sedang diaktifkan untuk Azure SQL Databases yang belum mengaktifkannya, dengan pemberitahuan yang dikirim ke administrator sehingga opsi dapat dinonaktifkan jika diinginkan.
Cara Kerjanya
Dengan Koreksi Rencana Otomatis diaktifkan, SQL Server memantau kinerja kueri menggunakan data Penyimpanan Kueri. Ini mencari perubahan yang signifikan* dalam kinerja CPU** dengan jangka waktu 48 jam***. Perhatikan tanda bintang dalam kalimat itu… itu disengaja:
- *Ambang batas untuk apa yang merupakan perubahan signifikan tidak didokumentasikan karena Microsoft berhak mengubahnya.
- **Metrik yang digunakan untuk menentukan perubahan kinerja (CPU) tidak didokumentasikan karena Microsoft berhak mengubahnya. Artinya, Microsoft dapat mempertimbangkan dimensi tambahan untuk melihat kinerja jika itu akan lebih baik/berkinerja lebih baik daripada CPU saja.
- ***Jangka waktu di mana data kinerja kueri dibandingkan tidak didokumentasikan karena alasan yang sama, Microsoft berhak mengubahnya.
- Catatan:sementara item yang disebutkan di atas tidak didokumentasikan, saya mengonfirmasi dengan individu yang sesuai di Microsoft bahwa informasi ini dapat dibagikan dengan melanggar NDA apa pun. Sangat penting untuk memahami bahwa nilainya tidak tetap dan dapat berubah, dengan harapan nilai tersebut akan berubah untuk meningkatkan keandalan fitur.
Kurangnya dokumentasi dan kemungkinan perubahan ambang batas mungkin membuat frustasi bagi beberapa individu, tetapi inilah yang sangat penting untuk diingat:
Microsoft menangkap terabyte data telemetri operasional dari SQL Azure Databases setiap hari, dan data tersebut sangat penting untuk fitur otomatis yang sedang dikembangkan. Data ini mencakup hal-hal seperti query_id, query_plan_id, dan query_hash, dan Microsoft TIDAK menangkap query_text atau query_plan (mereka tidak melihat data Anda yang sebenarnya). Microsoft tidak hanya mengarsipkan telemetri operasional atau menggunakannya untuk pemecahan masalah, mereka juga menambang data tersebut dan menggunakannya untuk mengembangkan algoritme dan model yang memungkinkan SQL Server membuat keputusan yang independen dan cerdas.
SQL Server dapat memanfaatkan banyak data di penyimpanan kueri yang merinci kinerja kueri, dan koreksi rencana otomatis dimulai dengan membandingkan kinerja saat ini untuk kueri dengan kinerja sebelumnya untuk menentukan apakah ada regresi dalam kinerja. Apakah kinerjanya turun, atau memburuk, dan jika ya, apakah turun drastis?
Jika ada regresi dalam kinerja kueri, maka SQL Server akan memaksa rencana bagus terakhir yang diketahui untuk kueri itu, yang tentu saja ditarik dari Query Store. Tapi itu tidak berhenti di situ. SQL Server kemudian terus memantau kinerja – masih menggunakan Query Store – untuk mengonfirmasi bahwa rencana paksa masih merupakan rencana yang baik untuk kueri tersebut, yang berarti bahwa kueri dengan rencana paksa berkinerja lebih baik daripada versi yang diturunkan. Jika kueri itu tidak berkinerja lebih baik, maka itu akan membatalkan rencana. Sebuah rencana juga dapat dibatalkan jika ada kompilasi ulang, atau jika pemaksaan gagal.
Siklus ini berlanjut; jika kueri memiliki rencana paksa, dan kemudian rencana itu tidak dipaksakan karena salah satu alasan yang disebutkan di atas, rencana yang sama dapat dipaksakan lagi nanti, atau mungkin ada rencana lain yang dipaksakan untuk kueri itu di lain waktu. Ini adalah proses berkelanjutan yang terjadi selama Anda mengaktifkan opsi Koreksi Rencana Otomatis untuk database. Sekarang, yang menarik adalah Anda dapat melihat informasi yang sama yang ditangkap oleh fitur ini dan menggunakannya untuk memaksa rencana secara manual. Artinya, di SQL Server 2017 Enterprise Edition dan di Azure SQL Database, data ini dikumpulkan di sys.dm_db_tuning_recommendations DMV bahkan ketika fitur Koreksi Rencana Otomatis tidak diaktifkan, sehingga Anda dapat memeriksa data tersebut dan mengikuti rekomendasinya untuk memaksa rencana untuk pertanyaan spesifik Anda sendiri. Perhatikan bahwa jika Anda memaksakan rencana menggunakan rekomendasi dari sys.dm_db_tuning_recommendations, itu tidak akan pernah dibatalkan secara otomatis. Selanjutnya, jika Anda mengaktifkan Koreksi Rencana Otomatis, dan Anda memaksakan rencana secara manual, itu tidak akan pernah dibatalkan secara otomatis. Hanya paket yang dipaksakan dengan fitur Koreksi Paket Otomatis yang akan dibatalkan secara otomatis.
Apakah saya benar-benar akan membiarkan SQL Server memiliki kendali?
Jika Anda skeptis dan bertanya-tanya apakah Anda benar-benar dapat mempercayai SQL Server untuk membuat keputusan yang memaksa, inilah yang saya sarankan untuk Anda ingat:
- Fitur ini dikembangkan dengan sejumlah besar data yang diambil dari hampir dua juta Database Azure SQL. Ini adalah fitur baru di SQL Server 2017, tetapi membuatnya menjadi ketersediaan global pada tahun 2016 di Azure, jadi fitur ini benar-benar telah tersedia selama lebih dari setahun, dan telah disempurnakan.
- Para insinyur telah membuat perubahan pada algoritme dari waktu ke waktu, karena mereka telah menangkap lebih banyak data. Ini mungkin tidak menemukan setiap regresi yang terjadi – karena regresi mungkin tidak cukup parah, tetapi saya berani bertaruh bahwa banyak dari Anda lebih suka memiliki kekuatan fitur ini lebih jarang daripada terlalu sering.
- Selain itu, jika sebuah rencana dipaksakan tetapi akhirnya menyebabkan masalah, kemampuan SQL Server untuk memulihkan dari itu dan membatalkan paksa rencana tersebut sangat andal dan terjadi dengan sangat cepat.
Ringkasan
Anda mungkin tidak nyaman dengan gagasan SQL Server yang menangani masalah kinerja untuk Anda. Tetapi apakah ketidaknyamanan itu karena Anda pikir itu akan membuat keputusan yang buruk? Atau apakah Anda khawatir tentang otomatisasi mengambil alih pekerjaan Anda? Pertanyaan yang cukup langsung, saya tahu. Jika yang pertama, maka rekomendasi saya adalah melihat data yang diambil di sys.dm_db_tuning_recommendations (tanpa mengaktifkan Koreksi Rencana Otomatis) dan melihat apa yang ingin dilakukan SQL Server. Apakah itu sejalan dengan apa yang akan Anda lakukan? Apakah itu menemukan regresi yang mungkin Anda lewatkan? Jika Anda tidak ingin mengaktifkan fitur tersebut karena Anda takut tiba-tiba tidak akan cukup, saya mendorong Anda untuk membaca posting terbaru Conor Cunningham, Bagaimana kecepatan cloud membantu DBA SQL Server. Microsoft tidak mencoba membuat Anda kehilangan pekerjaan. Mereka hanya mencoba menangani buah yang menggantung rendah sehingga Anda dapat fokus pada tugas yang lebih penting.
