Sebagai DBA, menangani masalah kinerja sering kali merupakan peristiwa reaktif; masalah terjadi, Anda harus merespons. Kadang-kadang Anda melihat contoh SQL Server yang Anda kenal dengan baik, di lain waktu itu mungkin pertemuan pertama Anda dengan suatu lingkungan. Hal ini juga terjadi di dunia konsultan. Saat membantu pelanggan jangka panjang, saya sudah memiliki detail tentang lingkungan yang disimpan. Namun, ketika kami menerima email dari seseorang yang belum pernah bekerja dengan kami sebelumnya, dan ini adalah situasi darurat di mana mereka membutuhkan bantuan segera, kami tidak memiliki latar belakang tentang lingkungan dan tidak tahu apa yang sedang kami hadapi. Kami memberikan bantuan tanpa melalui proses pengumpulan dan analisis data ekstensif yang dimulai setiap keterlibatan pelanggan baru.
Untuk alasan ini, saya memiliki satu set lima item yang saya periksa segera ketika saya menghadapi lingkungan baru. Informasi yang saya kumpulkan menetapkan tahapan untuk bagaimana saya mendekati pemecahan masalah ke depan, dan meskipun jarang menunjukkan THE masalah tertentu, ini membantu saya mengesampingkan apa yang BUKAN masalahnya, yang terkadang sama pentingnya.
Metode Pengumpulan Data
Saya menyadari bahwa setiap orang memiliki pendekatan yang berbeda ketika menghadapi lingkungan baru. Ada beberapa skrip gratis yang tersedia secara luas yang dapat Anda unduh dan jalankan untuk memberi Anda "lay of the land" untuk contoh SQL Server (skrip DMV Glenn Berry muncul di benak Anda). Fokus di sini bukanlah bagaimana Anda mengumpulkan data, itu apa data yang Anda kumpulkan, dan apa yang Anda analisis pertama .
Properti Server
Hal pertama yang ingin saya ketahui ketika saya melihat sebuah instance adalah versi dan edisi SQL Server. Cara tercepat untuk mendapatkan informasi ini adalah dengan menjalankan:
SELECT @@VERSION;
Dengan output ini, saya dapat memeriksa build untuk menentukan paket layanan, pembaruan kumulatif, dan hotfix yang diterapkan, dan saya tahu edisi apa yang digunakan. Saya juga ingin tahu apakah instance di-cluster, jadi saya juga menjalankan:
SELECT SERVERPROPERTY('IsClustered'); Terkadang saya mendapatkan informasi ini dari pelanggan, tetapi tidak ada salahnya untuk memverifikasi, karena versi dan edisi dapat memengaruhi langkah pemecahan masalah dan rekomendasi berikutnya. Misalnya, klien baru-baru ini menghubungi kami tentang masalah kinerja terputus-putus yang mereka lihat dengan SQL Server 2008. Pemeriksaan cepat versi mengungkapkan bahwa mereka menjalankan SQL Server 2008 SP3, dan ada beberapa Pembaruan Kumulatif yang dirilis setelah SP3 yang membahas berbagai masalah kinerja. Sementara saya mengumpulkan lebih banyak informasi sebelum membuat rekomendasi bahwa mereka menerapkan CU terbaru, ini adalah tanda bahaya langsung tentang apa yang mungkin menyebabkan masalah.
sys.configurations
Tampilan katalog ini membantu membangun fondasi yang dimulai dengan properti server, dan membantu kami memahami cara instans dikonfigurasi. Dengan tampilan ini, saya mencari pengaturan yang telah diubah dari default, tetapi seharusnya tidak, dan yang tidak telah dimodifikasi, tetapi seharusnya.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Pertimbangkan pengaturan memori server (MB) maks, yang membatasi jumlah memori yang tersedia untuk kumpulan buffer. Nilai default adalah 2147483647, tetapi harus diubah ke nilai yang lebih kecil dari total memori di server untuk memastikan ada banyak memori untuk OS, aplikasi lain, dan tugas SQL Server lainnya yang memerlukan memori yang tidak diambil dari kumpulan buffer . Untuk panduan tentang pengaturan nilai yang sesuai untuk memori server maks (MB), saya merekomendasikan posting Jonathan, Berapa banyak memori yang sebenarnya dibutuhkan SQL Server saya?
Sebaliknya, pengaturan peningkatan prioritas memiliki default nol, dan harus selalu dibiarkan seperti itu. Faktanya, Microsoft menyarankan untuk tidak mengubahnya, dan opsi tersebut akan dihapus pada rilis SQL Server mendatang.
sys.databases
Setelah saya memahami bagaimana instance dikonfigurasi, selanjutnya saya melihat untuk melihat apa yang ada di tingkat database.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Ketika saya memeriksa output dari tampilan katalog ini, saya mencari anti-pola – apa pun yang muncul sebagai tidak terduga atau tidak biasa – dalam data. Outputnya kondusif untuk analisis cepat – banyak pengaturan mencantumkan 0 atau 1 untuk nilai (mati atau aktif) dan saya membuat catatan mental tentang apa yang berbeda. Saya berharap statistik pembuatan otomatis dan statistik pembaruan otomatis diaktifkan (diatur ke 1). Saya berharap tutup otomatis dan menyusut otomatis dinonaktifkan (diatur ke 0). Saya melihat untuk melihat apa susunan untuk basis data pengguna, khususnya apakah mereka semua memiliki susunan yang sama, dan apakah susunan itu sama dengan tempdb. Saya juga mencatat opsi keamanan seperti rantai lintas basis data dan opsi is_trustworthy, keduanya dinonaktifkan (0) secara default. Jika saya menemukan bahwa salah satu dari pengaturan ini menyimpang dari apa yang saya harapkan, saya mencatatnya, dan melanjutkan. Saya tidak pernah menghentikan pengumpulan atau analisis saya untuk membuat perubahan, karena saya hanya mengumpulkan informasi secepat mungkin untuk mendapatkan pemahaman yang baik tentang lingkungan.
Selain memeriksa pengaturan database, saya juga mencatat jumlah database pengguna. Tidak ada "jumlah yang tepat" dari database pengguna untuk sebuah instans – sebuah instans dapat berkinerja buruk dengan satu database, dan dapat bekerja dengan sangat baik dengan 100. Ada banyak sekali faktor yang berperan, dan jumlah database hanyalah sebuah titik data perlu diperhatikan.
Log Kesalahan
Saya akui, saya dulu mengabaikan SQL Server ERRORLOG; itu seperti renungan ketika saya menyelidiki masalah SQL Server. Kemudian saya menyadari kesalahan cara saya, dan saya tidak menerima begitu saja sejak itu. Saya cenderung menavigasi melalui Management Studio untuk mengakses log (dalam Management | SQL Server Logs), meskipun Anda dapat menggunakan prosedur tersimpan sp_readerrorlog atau menelusuri file dan membukanya editor teks favorit Anda.
Dalam ERRORLOG saya mencari kesalahan terbaru – misalnya apa pun yang terkait dengan memori – dan saya juga melihat untuk melihat tanda jejak apa, jika ada, yang digunakan. Saya juga memeriksa untuk melihat apakah Lock Pages in Memory diaktifkan, apakah cache sedang dihapus (sengaja atau tidak), dan jika ada aktivitas tidak biasa lainnya yang terjadi secara teratur. Bergantung pada seberapa mendesak masalahnya, saya juga melihat log Windows (Event, Application, and Security), sekali lagi tidak hanya mencari kesalahan, tetapi juga pola pesan yang tidak terduga.
Statistik Tunggu
Area terakhir dari SQL Server yang saya tinjau ketika melihat masalah kinerja pada instance yang tidak diketahui adalah statistik tunggu. Setiap instance SQL Server akan menunggu – tidak peduli seberapa baik kodenya disetel, tidak peduli berapa banyak perangkat keras di belakangnya. Sebagai DBA, Anda ingin tahu seperti apa penantian tipikal Anda, dan ketika saya melihat lingkungan baru, saya tidak langsung tahu apakah penantian yang saya lihat adalah tipikal, atau karena masalah kinerja. Saya bertanya kepada pelanggan apakah mereka menunggu statistik dasar, dan jika tidak, saya bertanya apakah saya dapat menghapusnya dan membiarkannya mulai menumpuk saat masalah kinerja terjadi. Untuk memeriksa statistik menunggu, Anda dapat menggunakan skrip di postingan yang sering dirujuk oleh Paul Randal, atau versi di kueri DMV Glenn.
Setelah Anda meninjau akumulasi statistik menunggu, Anda akan memiliki bagian terakhir yang memberikan "gambaran besar" dari contoh SQL Server, dan informasi yang Anda butuhkan untuk memulai pemecahan masalah. Bukan hal yang aneh untuk memeriksa statistik tunggu terlebih dahulu saat memecahkan masalah, tetapi menunggu saja tidak cukup informasi untuk menentukan apa yang perlu Anda selidiki selanjutnya kecuali Anda juga memahami konfigurasi dasar SQL Server.
Langkah Selanjutnya
Seperti yang saya singgung sebelumnya, biasanya tidak ada satu pun data yang memberi tahu Anda di mana letak masalah kinerja, ini adalah beberapa titik data yang diperoleh yang mengarahkan Anda ke arah yang benar. Bagaimana Anda menangkap informasi itu terserah Anda, tetapi setelah Anda meninjau hasilnya, Anda harus memiliki pemahaman yang baik tentang bagaimana lingkungan SQL Server dikonfigurasi, dan pengetahuan itu, dikombinasikan dengan statistik tunggu, dapat membantu Anda memutuskan apa yang akan diselidiki selanjutnya. Pemecahan masalah bekerja paling baik dengan pendekatan metodis, jadi mulailah dengan dasar-dasar dan kerjakan, dan ketika Anda merasa telah menentukan akar masalahnya, gali sedikit lebih banyak dan temukan satu atau dua bukti tambahan yang mendukung temuan Anda. Setelah memiliki data tersebut, Anda dapat membuat rekomendasi untuk membantu meningkatkan atau menyelesaikan masalah.
