Apa 3 masalah kinerja teratas yang Anda temui dengan SQL Server Anda?

Saya seorang mahasiswa dari Fontys University di Eindhoven, dan saat ini saya sedang melakukan serangkaian wawancara untuk membantu pengembangan alat SQL Server dan saya ingin mendapatkan umpan balik dari para ahli di lapangan.

Salah satu pertanyaan saya adalah:

Apa masalah kinerja 3 teratas yang Anda temui dengan SQL Server Instances Anda dan bagaimana Anda mengidentifikasi masalah-masalah itu?

Khususnya saya tertarik pada skrip dan alat yang digunakan untuk mengukur ini.

Dari atas kepala saya - 3 masalah permintaan teratas:

• Konversi tersirat
• Strategi pengindeksan yang buruk (terlalu banyak atau tidak cukup atau jenisnya salah)
• Menggunakan SELECT * alih-alih memberi nama hanya bidang yang Anda butuhkan

Ada banyak hal lain di sekitar masalah konfigurasi tingkat server, masalah skema basis data, masalah perangkat keras, dll. Saya menulis skrip untuk menganalisis server dengan cepat mencari masalah seperti ini:

http://www.brentozar.com/blitz/

• Desain / kueri / pengindeksan buruk
• Tidak diperbolehkan membeli perangkat keras yang benar
• Braindead ORMs (alias "SQL is dead")

Bukan 3 teratas, tetapi saya pikir saya akan menyebutkan hal-hal yang belum disebutkan:

1. SQL memakai mesin virtual tanpa rincian / transparansi yang disediakan untuk DBA. Server host akan secara dinamis mengubah pengaturan mesin tamu yang menyebabkan penurunan kinerja, dan meninggalkan DBA tanpa petunjuk. Fitur-fitur seperti hypertreading, team network, dan memory ballooning membuat penghitung kinerja target bergerak untuk dipantau.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Demikian pula, tidak ada transparansi / verifikasi pada pengaturan SAN yang disediakan untuk DBA. Saya telah memiliki LUN dengan preferensi cache baca / tulis yang berbeda tetapi mengatakan bahwa semuanya sama.Tools: IO DMVs, SQLIO.
3. Arsitektur DB buruk: seperti ukuran dan penempatan data dan file log, dan tempdb. Penggunaan paralelisme yang tidak tepat. Membuat beberapa grup file pada disk fisik yang sama.Tools: experience.

Alat lain yang saya periksa sekarang adalah Project Lucy . Tampak rapi.

• tidak memiliki indeks yang tepat
• penggunaan dengan nolock dalam kode produksi oleh seseorang untuk mencoba menyelesaikan masalah kinerja. Terutama buruk jika kode memodifikasi data dalam tabel
• aplikasi memilih lebih banyak data daripada yang dibutuhkan pada waktu yang lebih banyak daripada yang diperlukan. Mantan memiliki biner kembali setiap kali bahkan jika Anda hanya ingin data teks dari tabel yang sama.

Kueri yang skalanya sangat buruk (dapatkan semua pesanan selama X tahun untuk semua pelanggan, dll. Termasuk semua pesanan termasuk data yang dijumlahkan dan data rata-rata lainnya dihitung dengan buruk)

Hanya menanyakan semuanya sekaligus.

Tabel yang berisi 'deskripsikan' varchar / bidang teks yang harus dicari melalui setiap permintaan.

• Perawatan yang tidak benar, yaitu tidak ada indeks reorg, statistik, tidak ada cadangan log
• Indeks tidak ada
• Pertanyaan yang ditulis dengan buruk

• Basis data dan desain aplikasi buruk
• buruknya penggunaan keunggulan platform (pengembang ingin memiliki kode akses database yang tidak bergantung platform. tidak ada SP, tidak ada fungsi, dll.)
• pengindeksan yang buruk, tentu saja.

• pertanyaan ad-hoc pada data prod - ya, pengembang percaya itu perlu dan beberapa bahkan mungkin memiliki akses :-)
• desain aplikasi yang buruk yang menggunakan database - misalnya: terlalu banyak data yang ditambahkan dan tidak pernah dihapus bahkan jika itu tidak diperlukan lagi (yang mengarah ke masalah kinerja karena cadangan tumbuh besar, tugas pemeliharaan memakan waktu lebih lama .. dll)
• semua file database pada serangan yang sama atau lebih buruk, pada drive yang sama (mis: sistem dbs, tempdb, pengguna dbs semuanya bersama-sama di drive / serangan yang sama)

• Desain basis data buruk
• Strategi Pengindeksan yang Buruk (termasuk terlalu banyak indeks, indeks yang hilang, dan kurangnya pemeliharaan indeks)
• Keputusan arsitektur perangkat keras yang buruk

Pengindeksan sangat penting untuk kinerja, tetapi saya telah menemukan sebagian besar DBA tahu itu, dan itu cenderung menjadi salah satu hal pertama yang diperbaiki melalui optimasi kueri. Area yang sering tidak ditangani dengan baik:

1. Terlalu banyak pulang pergi DB. Chattiness adalah salah satu masalah kinerja utama yang saya lihat.
2. Mendapatkan batasan transaksi yang tepat. Bertransaksi setiap INSERT / UPDATE / DELETE dapat menjadi pembunuh kinerja besar.
3. Gagal mengoptimalkan sisi perangkat keras; khususnya, menempatkan log DB pada volume yang berbeda dari data DB.

Jika saya bisa menambahkan item keempat ke daftar, itu akan menjadi penggunaan yang berlebihan dan tidak tepat dari pemicu dan / atau kursor. Tampaknya tidak terjadi terlalu banyak hari ini, tetapi ketika itu terjadi, itu menyakitkan dari perspektif kinerja.