Bagaimana menjawab mengapa tiba-tiba kita perlu indeks atau permintaan perlu diubah

Saya junior DBA dengan pengalaman 3 tahun. Tugas kami adalah untuk menyempurnakan permintaan atau memberi tahu pengembang bahwa kode tertentu harus ditulis ulang atau indeks diperlukan.

Satu pertanyaan sederhana yang sering ditanyakan oleh tim dev adalah: "Kemarin berjalan baik, apa yang berubah tiba-tiba?" dan kami akan diminta untuk memeriksa sisi infrastruktur. Reaksi pertama pada masalah apa pun tampaknya selalu menyalahkan infrastruktur yang selalu menjadi hal pertama yang divalidasi.

Bagaimana seharusnya kita menjawab pertanyaan "apa yang berubah" oleh tim pengembang? Apakah kalian pernah menghadapi situasi yang sama? Jika demikian, silakan bagikan pengalaman Anda.

Bagaimana menjawab pertanyaan yang diubah oleh dev?

Ini adalah pertanyaan yang sangat umum tidak hanya dengan DEV, itu berlaku untuk setiap tim di bidang TI dan bisnis.

Apa yang berubah ? ==> dapat dijawab dengan fakta dan angka.

Lihat fakta misalnya

• menambah jumlah pengguna yang mengakses database?
• Adakah perubahan pada parameter konfigurasi server?
• Pemeliharaan Database - perbarui statistik, reorg / pembangunan kembali indeks yang tidak dilakukan? Karena ini, rencana dibuat secara tidak benar!
• Jumlah data telah meningkat?
• Perubahan dibuat di sisi jaringan, OS ditambal dan / atau paket layanan baru atau CU untuk server sql digunakan - tanpa melakukan pengujian regresi penuh siklus bisnis aplikasi Anda ?
• SAN yang mendasarinya tiba-tiba menjadi lambat?

Angka dapat diturunkan jika Anda memiliki data untuk ditampilkan. Sebagai contoh :

• Baselining server Anda sangat penting dalam situasi ini. Ini akan mengurangi permainan menyalahkan karena Anda dapat mendukung fakta dengan angka yang solid.
• Mulai mengumpulkan data menggunakan DMV atau sp_whoisactive ke tabel, sehingga data tetap ada setelah server sql reboot.

(Anda harus berolahraga berdasarkan lingkungan dan kebutuhan Anda, pada seberapa sering mengumpulkan data / data apa yang akan dikumpulkan dan berapa banyak akan menjadi periode penyimpanan) atau (Anda dapat berinvestasi dalam perangkat lunak pihak ketiga seperti sqlsentry atau manajer diagnostik idera yang akan melakukan pekerjaan di atas untuk Anda) .

Nah, Anda bisa mendapatkan rencana yang berbeda karena:

• paket tersebut dapat diusir dari cache, karena:
  • restart layanan
  • kliring cache rencana secara manual
  • layanan restart atau failover
  • perubahan yang tidak disengaja, misalnya sp_configureperubahan tertentu dapat menyiram cache
  • beberapa perubahan pada objek yang mendasarinya, indeks, statistik, atau dependensi lainnya memicu kompilasi ulang
• Anda bisa saja mendapatkan paket berbeda dari pengguna lain atau pemanggilan sebelumnya karena:
  • teks kueri mungkin tidak identik (ini termasuk sensitivitas huruf dan spasi putih, apalagi kolom yang berbeda, kriteria gabungan, filter, dll.)
  • kueri dapat dijalankan oleh pengguna yang berbeda dengan opsi set yang berbeda (atau skema default yang berbeda, jika ada objek dalam paket tidak memiliki nama yang sepenuhnya memenuhi syarat, termasuk skema )
• kueri dan paketnya bisa sama, tetapi Anda bisa mendapatkan kinerja yang berbeda karena:
  • rencana di-cache menggunakan parameter yang berbeda, dan rencana itu tidak optimal untuk set parameter saat ini (ini biasa disebut "parameter sniffing")
  • jumlah data berdasarkan parameter atau hanya karena perubahan data sementara itu sangat berbeda
  • data telah cukup berubah untuk mengubah cara yang paling efisien untuk mengakses data, tetapi tidak cukup untuk memicu pembaruan atau kompilasi statistik (mencari masalah kunci yang naik serta algoritma statistik otomatis)
  • data telah diusir dari buffer pool, dan sekarang harus dibaca dari disk
  • ada konkurensi yang lebih tinggi, pemblokiran, atau tekanan lain pada sumber daya yang diperlukan untuk memenuhi permintaan

Saya membahas banyak hal ini secara lebih rinci di sini:

• Beberapa Paket untuk Kueri "Identik"

Jika ini berjalan pada lingkungan yang berbeda, maka saya memiliki serangkaian hal untuk diperiksa di sini:

• Paket berbeda untuk Server "Identik"

Juga, penting untuk diingat bahwa membuat indeks atau mengubah kueri mungkin bukan alasan langsung mengapa kueri tiba-tiba berkinerja lebih baik - kadang-kadang itu hanya karena perubahan itu benar-benar menghasilkan rencana baru dan / atau membatalkan yang sudah ada .

Seperti biasa Aaron Bertrand dan Kin memberikan jawaban yang sangat baik. Namun kedua jawaban berisi utas yang sama. Jika Anda menganalisis jawaban mana pun Anda akan melihat bahwa alasan mengapa XYZ tidak berfungsi seperti yang bekerja kemarin bukan karena sesuatu yang Anda / mereka / orang X lakukan. Alasan mengapa hal-hal berubah adalah karena database memutuskan untuk melakukan sesuatu secara berbeda karena alasan XYZ.

Database adalah entitas yang hidup dan bernafas . Database akan membuat keputusan, dan berubah pikiran karena kombinasi asumsi, statistik, dan alat heuristik lainnya. Ini secara dramatis berbeda dari kebanyakan pemrograman lapisan aplikasi (pembelajaran mesin menjadi pengecualian).

_{Saya akan menggunakan beberapa referensi militer karena saya tidak dapat memikirkan sesuatu yang lebih baik saat ini. Metafora yang lebih umum akan dihargai (tidak ada kata pun yang dimaksudkan).}

Dalam sebagian besar aplikasi, programmer bertindak sebagai Instruktur Bor. Mereka memberitahu komputer persis apa yang harus dilakukan, dalam rangka apa, dan kadang-kadang untuk berapa lama. Memprogram basis data lebih seperti bertindak sebagai Komandan. Anda memberi tahu apa yang ingin Anda lakukan di level tinggi, dan menawarkan beberapa panduan jika diperlukan. Basis data melakukan pekerjaan mencari tahu cara terbaik untuk melaksanakan rencana berdasarkan intelijen saat ini seperti perwira junior dan petugas non-komisi.

Dengan membuat perbedaan ini jelas dalam benak programmer lain, mereka semoga akan mulai melihat bahwa Anda tidak memiliki kekuatan diktorial seperti yang mereka miliki terhadap lingkungan mereka. Anda membimbing database ke solusi dan kadang-kadang database keluar jalur karena alasan baik atau buruk. Ingatkan mereka bahwa pada akhirnya tidak masalah mengapa * database keluar jalur, tetapi apa yang bisa kita lakukan untuk mengembalikannya.

_{* Saya mengenali "mengapa" sangat berharga untuk pencegahan, pembelajaran, dll di masa depan, tetapi sepertinya OP menghadapi perlawanan dari orang-orang yang tidak berusaha mempelajari atau membantu masalah tersebut.}