Mengapa penyetelan kinerja SQL sangat penting untuk manajemen basis data?
Karena dapat menghemat uang Anda waktu besar. Bersabarlah dengan saya dan Anda akan melihat caranya.
Penyetelan kinerja SQL dan manajemen basis data — menghubungkan titik-titik
Sebagian besar profesional basis data menghabiskan waktu mereka untuk menyalakan lampu. Mereka menginvestasikan sebagian besar upaya mereka dalam memastikan waktu aktif dengan mengawasi sumber daya seperti memori, penyimpanan, dan throughput jaringan. Itu adalah bagian besar dari manajemen database, tetapi karena semakin banyak perusahaan memindahkan database mereka ke sumber daya cloud yang hampir tak terbatas seperti AWS dan Azure, aspek lain menjadi lebih penting.
Penyetelan kinerja SQL adalah salah satu aspek tersebut. Setelah lampu menyala dengan aman dan Anda meningkatkan hierarki kebutuhan dalam manajemen basis data, hal berikutnya yang Anda inginkan adalah kinerja yang lebih baik, dan itu memerlukan penyetelan.
Pertanyaan pertama yang diajukan saat penyetelan performa di SQL
Cepat atau lambat, banyak profesional database menemukan diri mereka di depan SQL Server yang tidak mereka buat. Tidak banyak panduan cara untuk situasi itu. Penyesuaian kinerja SQL adalah latihan untuk menggali, mencari tahu apa yang salah dan kemudian memperbaikinya secara iteratif.
Dalam perbaikan pertama Anda, Anda bahkan mungkin tidak menyentuh pernyataan SQL sama sekali. Beberapa profesional database dimulai dari tingkat pengguna/sesi. Mereka pergi ke tempat pengguna tidak senang, mendengarkan keluhan mereka dan mengajukan pertanyaan.
- Layar atau halaman mana yang membutuhkan waktu terlalu lama untuk dirender?
- Apakah aplikasi lebih lambat saat membuat tiket baru atau membuka tiket yang sudah ada?
- Apakah perlu waktu lama untuk menyimpan catatan?
- Berapa lama "lama?"
Begitu mereka mendapatkan jawaban itu, mereka akan melihat apa yang menyebabkannya di database.
Itu lebih baik daripada duduk di hari pertama dan memutuskan untuk menangani sesuatu seperti fragmentasi, yang mungkin tidak memengaruhi pengguna sama sekali. Intinya adalah memulai dengan apa yang menjadi perhatian pengguna.
Pikirkan juga tentang tingkat instance/database. Di dunia Microsoft, misalnya, pekerjaan Agen Server SQL adalah tempat yang baik untuk memulai. Mereka adalah serangkaian tindakan yang biasanya menentukan tugas administratif yang dapat Anda pantau untuk keberhasilan atau kegagalan. Mereka dimaksudkan agar nyaman, tetapi seperti banyak hal dalam manajemen basis data, mereka cenderung terakumulasi karena orang lupa bagaimana mereka berasal dan apa yang mereka lakukan.
Anda mungkin menemukan beberapa pekerjaan melakukan hal yang sama, seperti menjalankan versi berbeda dari skrip indeks atau, lebih buruk lagi, bekerja melawan satu sama lain. Periksa pekerjaan yang sudah dikonfigurasi berdasarkan dua pertanyaan:"Apa yang dilakukan pekerjaan ini?" dan, yang lebih penting, “Jika saya menghentikan pekerjaan itu, apakah hal buruk akan terjadi?”
Faktor apa yang harus Anda cari?
Setelah Anda mencapai tingkat penyetelan kinerja SQL, dibutuhkan isyarat perilaku dari beberapa faktor. Seperti yang dijelaskan selama webcast Ask the Experts:Database Performance Roundtable kami, Anda dapat menghabiskan lebih sedikit waktu untuk menyesuaikan SQL itu sendiri jika Anda menemukan dan menafsirkan dengan benar faktor-faktor seperti ini:
- Memblokir — Jika server memblokir, itu seperti bom waktu. Misalkan skrip memulai transaksi dan tidak menutupnya; yang dapat menyebabkan file log yang hanya tumbuh dan berkembang sampai ruang habis. Pemblokiran adalah berita buruk untuk performa, jadi carilah segera.
- Agen — Sehubungan dengan pekerjaan Agen Server SQL, administrator telah diketahui secara tidak sengaja membungkus tugas yang mengganggu kinerja dalam pekerjaan. Mereka dapat menjalankan transaksi atau membangun kembali indeks dalam suatu pekerjaan, atau mengecilkan database dalam suatu transaksi. Dalam kasus seperti itu, pertimbangkan untuk menonaktifkan agen sementara untuk menutup semua pekerjaan terkait. Ini adalah teknik yang agresif, tetapi jika itu meningkatkan kinerja, Anda akan tahu alasannya.
- Statistik tunggu — Tanyakan pada diri sendiri, “Apa yang sedang menunggu server sekarang?” Metrik seperti harapan hidup halaman dan panjang antrian disk memiliki beberapa jawaban, tetapi hanya menawarkan tampilan yang sempit. Statistik tunggu menunjukkan segalanya kepada Anda melalui lensa tipe menunggu dan kategori menunggu, memungkinkan Anda fokus pada lima atau lebih peristiwa menunggu yang menghabiskan waktu paling banyak. Sp_BlitzFirst Brent Ozar adalah prosedur tersimpan yang tepercaya untuk menemukan apa yang sedang ditunggu kueri SQL Server Anda saat ini. Kemudian, saat Anda ingin mempelajari pola jangka panjang dalam statistik tunggu untuk server Anda, lihat alat pemantauan kinerja.
- Aktivitas administrator — Ini juga dikenal sebagai "kesalahan pilot", karena beberapa masalah kinerja muncul dari apa yang Anda lakukan sendiri. Misalkan Anda menjalankan SQL Server Activity Monitor dan SQL Server Profiler secara bersamaan, mencoba mempelajari Query Store. Anda tidak dapat berlari lebih cepat dari efek pengamat; saat Anda melacak semuanya seperti itu, Anda hanya meminta agar database melambat.
- Indeks — Untuk sesuatu yang seharusnya bermanfaat, indeks pasti bisa membuat Anda sakit leher. Faktanya, mereka pantas mendapatkan lebih dari satu peluru. Baca terus.
Penyetelan kinerja SQL berarti memperhatikan indeks dengan cermat
Sebagian besar, penyetelan kinerja SQL bermuara pada penyetelan indeks. Untungnya, jika Anda menguasainya untuk manajemen database lokal, keahlian Anda dapat dengan mudah ditransfer ke manajemen database di cloud.
Penyesuaian indeks menjadi semakin penting karena beragamnya indeks yang terus berkembang: berkelompok, tidak berkerumun, unik, difilter, penyimpanan kolom, hash, tidak mengelompokkan memori yang dioptimalkan, XML, spasial, dan teks lengkap, untuk beberapa nama. Namun satu hal yang tidak pernah berubah adalah kolom pertama indeks, yang mendorong keputusan indeks yang dibuat oleh mesin database.
Banyak vendor menjual dan menyebarkan aplikasi dengan banyak indeks yang dimaksudkan dengan baik yang akhirnya tidak pernah digunakan atau, lebih buruk lagi, benar-benar menghambat kinerja. Jika Anda memeriksa skrip indeks yang tidak digunakan atau skrip konsumsi indeks di beberapa produk perangkat lunak, Anda akan menemukan banyak indeks pada kunci asing. Jika produk menggunakan, katakanlah, 20 kunci asing, vendor dapat mengirimkan sebanyak 20 indeks, ditambah sepuluh indeks kolom tunggal, ditambah sepuluh indeks lainnya pada indeks berkerumun unik, dan seterusnya.
Kapan pun Anda memiliki opsi, cara yang lebih baik untuk mendekati arsitektur basis data adalah memulai dengan satu indeks berkerumun yang menurut Anda paling mewakili tabel. Kemudian, biarkan sistem berjalan sendiri untuk sementara waktu. Jika dan saat Anda membutuhkan lebih banyak indeks, buatlah. Menambahkan indeks adalah latihan dalam menukar kinerja yang lebih baik di sini dengan masalah seperti mengisi ruang disk dan mengunci di sana. Sulit untuk melihat bagaimana setiap indeks tambahan mempengaruhi sistem secara keseluruhan.
Dalam hal ini, pertimbangkan untuk menghilangkan indeks — cara seseorang dengan alergi menghilangkan kelompok makanan — untuk melihat bagaimana kinerjanya berubah. Coba hapus setiap indeks pada instance dev Anda dan lihat mana yang memengaruhi lima kueri teratas Anda.
Penyetelan kinerja di SQL Server — alat yang menyertainya
Perhatikan bahwa Anda tidak sendirian dalam upaya ini. SQL Server menyertakan fitur yang dirancang untuk meningkatkan kinerja.
Panduan paket memungkinkan Anda mengubah cara SQL Server menjalankan kueri tertentu, dan meskipun itu bukan penyetelan performa SQL murni, hal itu memengaruhi performa. Banyak aplikasi berisi kueri SQL yang ditulis oleh vendor luar, dan bahkan jika kueri tersebut menyebabkan kinerja yang buruk, beberapa profesional database dapat dimengerti enggan untuk mengubahnya. Dengan panduan rencana, Anda dapat melampirkan petunjuk kueri atau rencana tetap ke kueri dan memengaruhi cara menjalankannya.
Namun, kelemahan dari panduan rencana adalah bahwa meskipun mereka tidak berubah seiring waktu, lingkungan di sekitar mereka berubah. Seperti peta jalan yang dicetak, mereka mungkin bekerja dengan baik dalam jangka pendek dan menjadi usang dalam waktu dekat, jadi jika Anda akan mengandalkannya, sebaiknya Anda mengunjunginya kembali sesekali.
Terkait dengan panduan paket adalah Query Store, fitur SQL Server yang membantu Anda mengidentifikasi dan menyesuaikan kueri yang menghabiskan sebagian besar sumber daya di sistem Anda. Penyimpanan kueri tidak diaktifkan secara default untuk database SQL Server dan Azure Synapse Analytics (SQL DW) baru. Tapi ini diaktifkan secara default di Azure SQL Databases baru.
Secara umum, tidak sulit untuk mengaktifkan Query Store, tetapi tidak semua SQL Server membutuhkannya sejak awal. Beberapa admin tidak tahu tentang Query Store, dan beberapa mengetahuinya tetapi belum meluangkan waktu untuk menjelajahinya secara memadai; mereka lebih baik membiarkannya dinonaktifkan. Kemudian, ketika mereka memahami cara kerja Penyimpanan Kueri, mereka dapat menggunakannya untuk menemukan perbedaan kinerja yang disebabkan oleh perubahan rencana kueri.
Terakhir, Database Engine Tuning Advisor menganalisis beban kerja dan merekomendasikan indeks atau strategi partisi untuk meningkatkan performa kueri. Menjalankan Tuning Advisor di database Anda adalah ide yang bagus; hanya saja jangan terlalu cepat menjalankannya. Pastikan database Anda berisi data yang cukup sehingga rekomendasi indeks valid. Saat pertama kali membuat aplikasi, Anda mungkin hanya memiliki seribu baris di setiap tabel. Rekomendasi Tuning Advisor akan lebih berguna setelah database berkembang.
Tunjukkan uangnya
Seperti yang saya sebutkan di awal, penyetelan kinerja SQL penting untuk manajemen basis data karena dapat menghemat uang Anda. Bagaimana?
Terutama di cloud, di mana penskalaan dengan kartu kredit populer, tim IT mencari tahu betapa mahalnya penyimpanan bulanan. Terlebih lagi, mereka mulai memahami bahwa menjalankan kueri yang ditulis dengan buruk dan membiarkan AWS dan Azure mengelola indeks mereka meningkatkan biaya komputasi awan mereka. Kueri yang lambat dan indeks yang buruk merugikan Anda.
Penyetelan kinerja SQL adalah tentang mendapatkan semua hal itu dengan benar. Dengan begitu, baik Anda tetap berada di dunia OpEx lokal atau bermigrasi ke dunia cloud CapEx, Anda tetap dapat mengontrol pengeluaran Anda.
