Lebih dari satu tahun kemudian saya ingin semua orang tahu pengalaman saya dan hasil akhir dari pertanyaan / topik ini.
Saya mulai membuat sesuatu sendiri. Awalnya saya mengikuti Artikel Kumpulkan dan simpan data historis kinerja SQL Server counter dengan CMV oleh Tim Ford untuk mendapatkan sesuatu dan memperpanjang ini dengan Data apa pun yang ingin saya kumpulkan. Jadi sekali sehari saya menjalankan beberapa prosedur tersimpan pada setiap Sql Server yang mengumpulkan beberapa informasi spesifik dari DMV dan menyimpan hasilnya di Server lokal di dalam database. Ini termasuk penggunaan indeks, indeks yang hilang, entri log tertentu seperti autogrow, pengaturan server, pengaturan database aplikasi, fragmentasi, eksekusi pekerjaan, info log transaksi, informasi file, statistik tunggu dan banyak lagi.
Selain itu saya menambahkan hasil eksekusi reguler sp_blitz Brent Ozar ke repositori ini untuk mengumpulkan indikasi tambahan yang berharga untuk bekerja, meningkatkan, dan melaporkan.
Semua data kemudian dikumpulkan dari sana ke server Sql pemantauan khusus dan dengan cara ini saya membuat toko bundel untuk informasi kinerja yang relevan tentang semua server saya dan menggunakan ini sebagai dasar untuk investigasi dan pelaporan.
Kemudian saya membuat lembar excel dan juga laporan menggunakan layanan pelaporan untuk menganalisis dan menafsirkan. Beberapa sampel:
Saya juga mengkonfigurasi beberapa pemantauan penghitung kinerja menggunakan TYPEPERF yang terinspirasi oleh artikel " Mengumpulkan Data Kinerja ke dalam Tabel SQL Server " oleh Fedor Georgiev.
Dari contoh SQL Monitoring saya, saya memicu typeperf untuk menjalankan dan mengumpulkan jumlah sampel yang dapat dikonfigurasi dengan sampel yang dapat dikonfigurasi dan menyimpan hasilnya dalam db pemantauan pusat saya.
Ini memungkinkan saya untuk mengamati nilai kinerja jangka panjang, contoh:
Setelah beberapa saat menggunakan ini untuk mengumpulkan informasi dasar, ternyata cukup banyak pekerjaan pemeliharaan yang harus dihabiskan untuk melihat pekerjaan yang gagal, prosedur de-buggin (misalnya dalam kasus DB diambil offline, beberapa skrip gagal), mempertahankan pengaturan setelah server diganti ...
Juga basis data yang mengumpulkan semua catatan itu sendiri membutuhkan pemeliharaan dan penyetelan kinerja, sehingga pekerjaan tambahan muncul untuk menjaga data bermanfaat ...
Yang akhirnya benar-benar hilang adalah kemampuan untuk melihat hal-hal yang terjadi secara langsung. Dalam Kasus Terbaik, saya akan dapat memberi tahu apa yang mungkin terjadi pada hari berikutnya setelah pengumpul data berlari. Semua detail juga hilang. Saya tidak memiliki akses ke grafik jalan buntu, saya tidak bisa melihat rencana permintaan kueri yang berjalan dalam jangka waktu yang mencurigakan ....
Semua itu membuat saya akan membebankan biaya kepada manajemen untuk mengeluarkan uang untuk solusi prefesional yang tidak dapat saya buat sendiri.
Pilihan terakhir adalah membeli SentryOne karena dibandingkan dengan yang lain, SentryOne meyakinkan dan memberikan banyak informasi yang diperlukan untuk mengidentifikasi poin rasa sakit kami.
Sebagai kesimpulan akhir, saya akan menyarankan siapa pun yang mencari jawaban untuk pertanyaan serupa untuk tidak mencoba membuat hal-hal sendiri selama Anda tidak memiliki lingkungan kecil dan pada dasarnya sehat di tempat. Jika Anda memiliki beberapa sistem dan banyak masalah, lebih baik segera mencari solusi profesional dan menggunakan bantuan vendor pada masalah Anda daripada menghabiskan banyak waktu dan uang untuk membuat sesuatu yang kurang bermanfaat. Namun, rute ini masih sangat menarik dan membuat saya belajar banyak hal yang tidak ingin saya lewatkan.
Saya harap Anda menemukan ini berguna setelah Anda lari ke utas pertanyaan ini.
EDIT 20 April 2017:
Brent Ozar baru-baru ini memposting artikel berikut di facebook yang semacam pendekatan serupa yang diambil oleh Tim SQL Tiger: https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining -laporan-unleashed-for-enterprise-monitoring /