SQL Server 2016 Enterprise kinerja buruk

Maaf lama, tapi saya ingin memberi Anda informasi sebanyak mungkin sehingga mungkin berguna untuk analisis.

Saya tahu ada beberapa posting dengan masalah serupa, namun saya sudah mengikuti berbagai posting dan informasi lain yang tersedia di web, tetapi masalahnya tetap ada.

Saya memiliki masalah kinerja serius dalam SQL Server yang membuat pengguna gila. Masalah ini berlanjut selama beberapa tahun, dan sampai akhir 2016 dikelola oleh entitas lain dan mulai 2017 dikelola oleh saya.

Di pertengahan tahun 2017, saya dapat menyelesaikan masalah dengan mengikuti petunjuk pengindeksan yang ditunjukkan oleh Laporan Dashboard Kinerja Microsoft SQL Server 2012. Efeknya langsung, itu terdengar seperti sihir. Prosesor yang ada di hari-hari terakhir hampir selalu di 100%, menjadi super tenang dan umpan balik dari pengguna bergema. Bahkan teknisi ERP kami senang, karena biasanya butuh 20 menit untuk mendapatkan daftar tertentu dan akhirnya dia bisa melakukannya dalam hitungan detik.

Namun seiring waktu, perlahan-lahan mulai memburuk. Saya menghindari membuat lebih banyak indeks, karena khawatir terlalu banyak indeks akan memperburuk kinerja. Tetapi pada titik tertentu saya harus menghapus yang tidak digunakan dan membuat yang baru yang disarankan Dashboard Kinerja kepada saya. Namun tidak berdampak.

Kelambanan yang dirasakan pada dasarnya adalah saat menabung dan berkonsultasi, dalam ERP.

Saya memiliki Windows Server 2012 R2 yang didedikasikan untuk SQL Server 2016 Enterprise (64-bit) dengan konfigurasi berikut:

• CPU: Intel Xeon CPU E5-2650 v3 @ 2.30GHz
• Memori: 84 GB
• Dalam hal penyimpanan, server memiliki volume yang didedikasikan untuk sistem operasi, yang lain didedikasikan untuk data dan yang lain didedikasikan untuk log.
• 17 basis data
• Pengguna:
  • Dalam DB terbesar terhubung kurang lebih 113 pengguna secara bersamaan
  • Di lain ada sekitar 9 pengguna
  • Dalam dua dari mereka adalah 3 + 3
  • Sisanya masing-masing hanya memiliki 1 pengguna
  • Kami memiliki web yang juga menulis untuk database yang lebih besar, tetapi di mana penggunaannya jauh lebih jarang, dan yang seharusnya memiliki sekitar 20 pengguna.
• Ukuran DB:
  • Basis data terbesar memiliki 290 GB
  • Terbesar kedua memiliki 100GB
  • Terbesar ketiga memiliki 20 GB
  • Keempat, 14 GB
  • Sisanya masing-masing lebih dari 3 GB

Ini adalah contoh produksi, tetapi kami juga memiliki contoh pengembangan yang saya percaya dapat diabaikan untuk tujuan ini, karena sebagian besar waktu saya satu-satunya penghubung di sana, tetapi masalah ini terjadi terus-menerus, bahkan ketika saya tidak terhubung .

Prosesornya hampir selalu seperti ini:

Kami memiliki rutinitas yang berjalan pada malam hari (tidak bermasalah) dan beberapa yang berjalan pada siang hari.

Pengguna terhubung melalui Remote Desktop ke mesin lain yang dikonfigurasi oleh ODBC 32 untuk mengakses SQL Server.

Datacenter tempat server berada memiliki 100/100 Mbps, serta keberadaan saya. Sebagian besar situs ditautkan oleh MPLS dan lainnya oleh IPSec (dari FO ke 4G). Penyedia membuat banyak analisis dan rangkaian ok.

Rasio Hit Cache adalah 99% (Permintaan Pengguna dan Sesi Pengguna)

Menunggu terlihat seperti ini:

Saya sudah mengumpulkan data dengan Perfmon dan saya mendapatkan hasilnya jika itu membantu analisis Anda - secara pribadi, saya tidak mendapatkan kesimpulan dari analisis tersebut.

Saya mengandalkan dukungan Anda dalam menyelesaikan masalah ini, tersedia untuk memberikan informasi yang Anda anggap perlu untuk resolusi tersebut.

Terima kasih banyak.

Inilah markdown sp_blitz (Saya mengganti nama perusahaan dengan nama samaran):

Prioritas 1: Keandalan :

• CHECKDB DBCC baik terakhir lebih dari 2 minggu

  • menguasai

  • model - Terakhir berhasil CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - Terakhir berhasil CHECKDB: 2018-02-07 15: 04: 27.740

Prioritas 10: Kinerja :

• CPU dengan jumlah core yang ganjil

  • Node 0 memiliki 5 core yang ditetapkan untuknya. Ini adalah konfigurasi NUMA yang sangat buruk.

  • Node 1 memiliki 5 core yang ditugaskan untuk itu. Ini adalah konfigurasi NUMA yang sangat buruk.

Prioritas 20: Konfigurasi File :

• TempDB on C Drive tempdb - Database tempdb memiliki file di drive C. TempDB sering tumbuh tak terduga, menempatkan server Anda dalam risiko kehabisan ruang drive C dan menabrak keras. C juga sering jauh lebih lambat daripada drive lain, sehingga kinerjanya mungkin menurun.

Prioritas 50: Keandalan :

• Kesalahan yang Dicatat Baru-Baru Ini di Jejak Default
  • master - 2018-03-07 08: 43: 11.72 Logon Error: 17892, Severity: 20, State: 1. 2018-03-07 08: 43: 11.72 Logon Logon gagal login 'example_user' karena memicu eksekusi. [KLIEN: IPADDR]

(catatan: banyak kesalahan seperti ini karena pemicu aktif yang membatasi sesi pengguna - untuk kontrol penggunaan lisensi ERP)

• Verifikasi Halaman Tidak Optimal

  • DATABASE_A - Database [DATABASE_A] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_B - Database [DATABASE_B] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_C - Database [DATABASE_C] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_D - Database [DATABASE_D] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_E - Database [DATABASE_E] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_F - Database [DATABASE_F] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_G - Database [DATABASE_G] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_H - Database [DATABASE_H] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_I - Database [DATABASE_I] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_Z - Database [DATABASE_Z] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_K - Database [DATABASE_K] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_J - Database [DATABASE_J] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_L - Database [DATABASE_L] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_M - Database [DATABASE_M] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_O - Database [DATABASE_O] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_P - Database [DATABASE_P] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_Q - Database [DATABASE_Q] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_R - Database [DATABASE_R] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_S - Database [DATABASE_S] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_T - Database [DATABASE_T] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_U - Database [DATABASE_U] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_V - Database [DATABASE_V] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

  • DATABASE_X - Database [DATABASE_X] tidak memiliki NONE untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

• Remote DAC Disabled - Akses jarak jauh ke Dedicated Admin Connection (DAC) tidak diaktifkan. DAC dapat membuat pemecahan masalah jarak jauh lebih mudah ketika SQL Server tidak responsif.

Prioritas 50: Info Server :

• Inisialisasi File Instan Tidak Diaktifkan - Pertimbangkan untuk mengaktifkan IFI untuk mengembalikan lebih cepat dan pertumbuhan file data.

Prioritas 100: Kinerja :

• Isi Faktor yang Diubah

  • DATABASE_A - Database [DATABASE_A] memiliki 417 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_B - Database [DATABASE_B] memiliki 318 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_C - Database [DATABASE_C] memiliki 346 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_D - Database [DATABASE_D] memiliki 663 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_E - Database [DATABASE_E] memiliki 335 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_F - Database [DATABASE_F] memiliki 1705 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_G - Database [DATABASE_G] memiliki 671 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_H - Database [DATABASE_H] memiliki 2364 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_I - Database [DATABASE_I] memiliki 1658 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_Z - Database [DATABASE_Z] memiliki 673 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_K - Database [DATABASE_K] memiliki 312 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_J - Database [DATABASE_J] memiliki 864 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_L - Database [DATABASE_L] memiliki 1170 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_M - Database [DATABASE_M] memiliki 382 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_O - Database [DATABASE_O] memiliki 356 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • msdb - Database [msdb] memiliki 8 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_P - Database [DATABASE_P] memiliki 291 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_Q - Database [DATABASE_Q] memiliki 343 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_R - Database [DATABASE_R] memiliki 2048 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_S - Database [DATABASE_S] memiliki 325 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_T - Database [DATABASE_T] memiliki 322 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_U - Database [DATABASE_U] memiliki 351 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_V - Database [DATABASE_V] memiliki 312 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • DATABASE_X - Database [DATABASE_X] memiliki 352 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

  • tempdb - Database [tempdb] memiliki 2 objek dengan fill factor = 70%. Ini dapat menyebabkan masalah kinerja memori dan penyimpanan, tetapi juga dapat mencegah pemisahan halaman.

• Banyak Paket untuk Satu Permintaan - 20763 paket tersedia untuk satu permintaan dalam cache paket - artinya kita mungkin memiliki masalah parameterisasi.

• Pemicu Server Diaktifkan - Pemicu Server [connection_limit_trigger] diaktifkan. Pastikan Anda memahami apa yang dilakukan pemicu itu - semakin sedikit kerjanya, semakin baik.

• Prosedur Tersimpan DENGAN RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] telah DENGAN RECOMPILE dalam kode prosedur yang tersimpan, yang dapat menyebabkan peningkatan penggunaan CPU karena rekompilasi kode yang konstan.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] telah DENGAN RECOMPILE dalam kode prosedur yang tersimpan, yang dapat menyebabkan peningkatan penggunaan CPU karena terus-menerus mengkompilasi ulang kode.

Prioritas 110: Kinerja :

• Tabel Aktif Tanpa Indeks Clustered

  • DATABASE_A - Basis data [DATABASE_A] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

  • DATABASE_B - Basis data [DATABASE_B] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_C - Basis data [DATABASE_C] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_E - Basis data [DATABASE_E] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_F - Basis data [DATABASE_F] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_H - Database [DATABASE_H] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_I - Database [DATABASE_I] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_K - Basis data [DATABASE_K] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_O - Database [DATABASE_O] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_Q - Database [DATABASE_Q] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_S - Basis data [DATABASE_S] memiliki banyak - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

  • DATABASE_T - Database [DATABASE_T] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_U - Basis data [DATABASE_U] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_V - Basis data [DATABASE_V] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

  • DATABASE_X - Basis data [DATABASE_X] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

Prioritas 150: Kinerja :

(Catatan: Nasihat Nany di sini, tetapi saya tidak dapat memasukkannya karena keterbatasan karakter. Jika ada cara lain untuk berbagi, harap sebutkan.)

Anda memberi kami pertanyaan yang panjang (dan sangat rinci). Sekarang Anda harus berurusan dengan jawaban yang panjang. ;)

Ada beberapa hal yang saya sarankan untuk diubah di server Anda. Tapi mari kita mulai dengan masalah yang paling mendesak.

Tindakan darurat satu kali:

Fakta bahwa kinerjanya memuaskan setelah menyebarkan indeks pada sistem Anda dan kinerja yang perlahan merosot adalah petunjuk yang sangat kuat bahwa Anda perlu mulai mempertahankan statistik Anda dan (pada tingkat yang lebih rendah) menjaga framenasi indeks.

Sebagai tindakan darurat saya menyarankan pembaruan statistik manual satu kali pada semua basis data Anda. Anda bisa mendapatkan nessecary TSQL dengan menjalankan skrip ini:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Ini disediakan oleh Tim Ford di blogpost- nya di mssqltips.com dan dia juga menjelaskan mengapa memperbarui statistik itu penting.

Harap dicatat bahwa ini adalah tugas intensif CPU dan IO yang tidak boleh dilakukan selama jam kerja.

Jika ini menyelesaikan masalah Anda, jangan berhenti di situ!

Perawatan Reguler:

Lihatlah Ola Hallengren Maintenance Solution dan kemudian atur setidaknya dua pekerjaan ini:

• Pekerjaan pembaruan statistik (jika memungkinkan setiap malam). Anda dapat menggunakan kode CMD ini dalam pekerjaan agen Anda. Pekerjaan ini harus dibuat dari awal.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Pekerjaan pemeliharaan indeks. Saya menyarankan memulai dengan eksekusi yang dijadwalkan sebulan sekali. Anda dapat mulai dengan default yang disediakan Ola untuk Pekerjaan IndexOptimize.

Ada beberapa alasan mengapa saya menyarankan pekerjaan pertama untuk memperbarui statistik secara terpisah:

• Pembuatan kembali indeks hanya akan memperbarui statistik kolom yang dicakup oleh indeks itu sementara reorganisasi indeks tidak memperbarui statistik sama sekali. Ola memisahkan fragmentasi dalam tiga kategori. Secara default, hanya indeks tinggi kategori yang akan dibangun kembali.
• Statistik untuk kolom yang tidak tercakup oleh indeks hanya akan diperbarui oleh pekerjaan IndexOptimize.
• Untuk mengurangi Masalah Kunci Menaik .

SQL Server akan memperbarui statistik secara otomatis jika default dibiarkan diaktifkan. Masalah dengan itu adalah ambang (kurang dari masalah dengan SQL Server 2016 Anda). Statistik diperbarui ketika sejumlah baris berubah (20% dalam Versi SQL Server yang lebih lama). Jika Anda memiliki tabel besar, ini bisa menjadi banyak perubahan sebelum statistik diperbarui. Lihat info lebih lanjut tentang ambang batas di sini .

Karena Anda melakukan CHECKDB sejauh yang saya tahu Anda bisa terus melakukannya seperti sebelumnya atau Anda menggunakan solusi pemeliharaan untuk itu juga.

Untuk informasi lebih lanjut tentang fragmentasi dan pemeliharaan indeks, lihat:

Ikhtisar Fragmentasi Indeks SQL Server

Berhenti Khawatir Tentang Fragmentasi SQL Server

Mempertimbangkan subsistem penyimpanan Anda, saya sarankan untuk tidak memfokuskan banyak pada "fragmentasi eksternal" karena data tidak disimpan dalam urutan pada SAN Anda.

Optimalkan pengaturan Anda

Skrip sp_Blitz memberi Anda daftar yang bagus untuk memulai.

Prioritas 20: Konfigurasi File - TempDB di Drive C: Bicaralah dengan admin penyimpanan Anda. Tanyakan kepada mereka apakah drive C Anda adalah disk tercepat yang tersedia untuk SQL Server Anda. Jika tidak, letakkan tempdb Anda di sana ... titik. Kemudian periksa berapa banyak file temdb yang Anda miliki. Jika jawabannya adalah salah satu memperbaikinya . Jika ukurannya tidak sama, perbaiki keduanya.

Prioritas 50: Info Server - Inisialisasi File Instan Tidak Diaktifkan: Ikuti tautan yang diberikan skrip sp_Blitz kepada Anda dan aktifkan IFI.

Prioritas 50: Keandalan - Verifikasi Halaman Tidak Optimal: Anda harus mengatur ini kembali ke default (CHECKSUM). Ikuti tautan yang diberikan skrip sp_Blitz kepada Anda dan ikuti instruksi.

Prioritas 100: Kinerja - Faktor Isi Diubah: Tanyakan pada diri sendiri mengapa ada begitu banyak objek dengan faktor pengisian diatur ke 70. Jika Anda tidak memiliki jawaban dan tidak ada vendor aplikasi yang secara ketat menuntutnya. Kembalikan ke 100%.

Ini pada dasarnya berarti SQL Server akan meninggalkan 30% ruang kosong di halaman ini. Jadi untuk mendapatkan jumlah data yang sama (dibandingkan dengan 100% halaman penuh) server Anda harus membaca 30% lebih banyak halaman dan mereka akan mengambil 30% lebih banyak ruang dalam memori. Alasan yang sering dilakukan adalah mencegah fragmentasi indeks.

Tetapi sekali lagi, penyimpanan Anda menyimpan halaman-halaman itu dalam potongan yang berbeda pula. Jadi saya akan mengaturnya kembali ke 100% dan mengambilnya dari sana.

Apa yang harus dilakukan jika semua orang senang:

• Lihat sisa output sp_Blitz dan putuskan apakah Anda mengubahnya seperti yang disarankan.
• Jalankan sp_BlitzIndex dan lihat indeks yang Anda buat, jika digunakan atau di mana ada peluang untuk menambah / mengubahnya.
• Lihatlah data Query Store Anda (seperti yang disarankan oleh Peter). Anda dapat menemukan pengantar di sini .
• Nikmati live bintang rock yang layak diterima DBA. ;)

Tidak mengabaikan semua jawaban Anda yang sangat berguna dan yang saya terapkan atau akan terapkan, masalah terbesar adalah tidak mudah ditemukan.

Masalahnya memburuk pada hari-hari setelah pesan terakhir kami.

Karena kami berbasis cloud, baik saya maupun perusahaan yang mengelola infrastruktur dan memberi kami dukungan memiliki akses ke host fisik.

Sesuatu membuat saya bertanya-tanya ketika saya perhatikan bahwa beberapa hari prosesor rata-rata 20% dan hari-hari lainnya jauh lebih tinggi, lebih dari 60%, ketika beban kerjanya, meskipun tidak pernah persis sama, serupa. Ada jumlah orang yang sama yang melakukan kurang lebih jenis operasi yang sama.

Awal pekan ini, pengguna mulai macet selama beberapa menit dan hanya prosesor yang dicekik. Saya meminta beberapa pengguna untuk logout (mereka yang menghabiskan lebih banyak sumber daya tetapi masih tidak biasa), saya mematikan berbagai layanan yang terhubung ke database, dan pada akhirnya tidak ada yang berubah. Saya bertanya kepada sysadmin yang mendukung kami dan yang dapat berkomunikasi dengan orang-orang dari cloud kami untuk remote ke mesin saya untuk melihat apa yang saya lihat dan membantu saya menemukan sesuatu, karena saya tidak bisa berbuat lebih baik untuk menemukan masalahnya.

Teknisi juga tidak menemukan apa pun. Dia akhirnya mulai memberi saya beberapa alasan bahwa sesuatu yang lain harus menyebabkan masalah ini dan ketika ia menghubungi cloud. Di cloud, mereka tidak menyadari apa-apa, hanya saja karena ada konfigurasi load balancing antara host fisik, VM yang mendukung SQL Server kami telah dipindahkan beberapa kali hari itu antara host fisik. Untungnya, saya memberi tahu teknisi kami kapan tepatnya masalah mulai terjadi hari itu, yang bertepatan dengan waktu VM dipindahkan terakhir kali ke salah satu host fisik yang tidak meninggalkan sisa hari itu.

Jika teknisi tidak mengikuti dengan seksama masalah ini, ini akan menjadi lebih dari satu kali ketika ia bahkan dapat berbicara dengan cloud guys, tetapi ketika mereka melihat sampel kinerja, mereka tidak akan mendapatkan apa-apa, karena sekali lagi awan hanya melihat sampel dengan CPU pada urutan 40/50%, padahal sebenarnya itu rata-rata di atas 80% dan sering terjebak pada 100%.

Sekarang mesin tersebut berdiri di atas host fisik (tidak bergerak di antara host) dan meskipun kami belum mencapai kinerja yang sempurna, semua orang bekerja dan memberikan umpan balik yang jauh lebih positif, karena rata-rata CPU sekitar 20% dengan semua pengguna kami dan jasa.

Sementara itu, kami juga meletakkan tempdb pada disk lain (pada disk Sistem Pengoperasian) dan kami menambah file, agar lebih sesuai dengan jumlah core CPU.

Jumlah core juga disesuaikan berdasarkan rekomendasi sp_Blitz.

Ada juga rutin otomatis yang berjalan sepanjang hari berdasarkan tanggal yang lama ... dan karena itu tidak berakhir di pagi hari ketika kami tiba, dan kami tidak memiliki cara untuk memeriksa apakah itu berjalan atau tidak, saya masih mulai berjalan secara manual. Tapi mungkin yang lain masih berjalan dan berlari dua kali selama waktu itu. Kami telah mengubah tanggal untuk mengurangi waktu yang diperlukan, dan sekarang sudah larut malam. Tapi ini bukan solusinya, karena diselesaikan sebelum banyak masalah yang kita miliki seperti yang dijelaskan di sini.

Kami juga berhasil membuat asisten ERP untuk menjadwalkan pertemuan dengan pabrikan, jadi kami akan menunjukkan sistem kami dan mencari saran, serta mengklarifikasi beberapa keraguan, karena ada rekomendasi dalam video pelatihan yang bertentangan dengan sebagian besar rekomendasi, termasuk Microsoft sendiri, seperti Peningkatan Prioritas dan Isi Faktor 70%.

Karena aplikasi ini juga memiliki layar pemeliharaan, saya akan mencari periodisitas yang diperlukan dari pemeliharaan ini, dan apa yang tersisa untuk dilakukan di luar aplikasi. Ide saya adalah menggunakan rencana Ola Hallengren.

Saya percaya bahwa jawaban Thomas Kronawitter benar dan saya menerapkannya, namun, saya pikir uraian ini bisa penting bagi orang lain bahwa setelah mengikuti semua praktik yang baik masih tidak dapat memperbaiki masalah karena bisa di host fisik . Terima kasih Thomas.