Saya telah mengajar dan menulis tentang kesalahan umum SQL Server selama bertahun-tahun. Saya juga menulis blog tentang itu bertahun-tahun yang lalu, namun seiring berjalannya waktu, panduannya sedikit berubah. Artikel ini akan memperluas artikel saya sebelumnya dan menunjukkan bagaimana ini berlaku untuk SQL Server, Azure SQL Database, dan Azure SQL Managed Instance.
Selama bertahun-tahun saya telah menemukan pengguna membuat kesalahan yang sama. Saya menyebutnya kesalahan Namun, dalam banyak kasus, ini lebih merupakan hal-hal yang tidak dilakukan dengan benar karena orang-orang yang mengelola lingkungan tidak tahu lebih baik. Berikut adalah beberapa item penting yang harus diketahui oleh siapa pun yang menginstal dan mendukung SQL Server:
- Cadangan
- DBCC CHECKDB
- Pengaturan memori
- Statistik
- Pemeliharaan indeks
- MAXDOP dan ambang biaya untuk paralelisme
- Peringatan Agen Server SQL
Cadangan
Saya selalu memeriksa cadangan terlebih dahulu ketika melihat sistem baru. Memiliki cadangan yang tepat untuk memenuhi tujuan pemulihan sangat penting. Kehilangan data dapat merugikan organisasi. Saat melihat cadangan, saya memeriksa model pemulihan dan riwayat pencadangan saat ini untuk setiap basis data. Saya biasanya menemukan kombinasi berikut:
- Tidak ada cadangan sama sekali – tidak ada catatan cadangan apa pun untuk database
- Cadangan tidak ada – tidak ada cadangan log untuk database menggunakan model pemulihan penuh
- Tidak ada pencadangan terbaru – pencadangan terakhir berumur beberapa minggu/bulan/tahun
Cadangan yang salah dikonfigurasi merugikan organisasi ketika situasi pemulihan muncul. Bekerja dengan dan harus memberi tahu pelanggan bahwa mereka kehilangan data tidak pernah menyenangkan atau mudah. Memiliki cadangan yang tepat untuk memenuhi SLA harus menjadi prioritas utama organisasi selain memastikan ada salinan cadangan ini yang disimpan di lokasi sekunder di luar lokasi.
Situasi ini berlaku untuk SQL Server dan IaaS lokal. Azure SQL Database dan Azure Managed Instance memiliki cadangan terkelola.
DBCC CHECKDB
Kerusakan database terjadi sayangnya. Tanpa secara teratur memeriksa korupsi, pelanggan dapat menemukan diri mereka di tempat yang buruk dengan tidak memiliki cadangan untuk memulihkan ketika korupsi itu mempengaruhi data fisik. Untuk memeriksa korupsi, DBCC CHECKDB harus dijalankan terhadap setiap database secara teratur. Apa yang saya temukan sangat mirip dengan backup:
- Tidak ada DBCC CHECKDB yang dilakukan sama sekali
- DBCC CHECKDB hanya dilakukan pada database tertentu
- DBCC CHECKDB terakhir dilakukan beberapa bulan atau tahun lalu
Kasus terburuk adalah pelaporan pekerjaan terjadwal gagal DBCC CHECKDBs
Tidak pernah menyenangkan menemukan korupsi atau meminta pelanggan menjangkau masalah korupsi ketika korupsi adalah tumpukan atau indeks berkerumun dan tidak ada cadangan sebelum korupsi terjadi. Dalam kasus ini, korupsi adalah data aktual dan memulai pemulihan dari sebelum korupsi dalam banyak kasus, satu-satunya pilihan. Dalam kasus di mana korupsi adalah indeks non-cluster, membangun kembali indeks adalah solusinya.
Dalam beberapa situasi, saya harus bekerja dengan pelanggan yang memiliki korupsi buruk tanpa cadangan yang tepat di mana saya dapat membuat skrip database dan secara manual menyalin semua data yang dapat digunakan ke database yang baru dibuat. Situasi yang mahal ini dapat dengan mudah dihindari dengan menjalankan DBCC CHECKDB dan memiliki penyimpanan cadangan yang tepat.
Saya menyarankan pelanggan untuk menjalankan DBCC CHECKDB di tempat, IaaS, Azure SQL Database, dan Azure SQL Managed Instance. Azure melakukan pekerjaan yang baik untuk memeriksa kerusakan fisik; namun, saya merasa bahwa konsumen perlu memeriksa korupsi logis.
Setelan Memori
Penginstalan default Microsoft SQL Server memiliki nilai memori minimum yang ditetapkan ke 0 dan nilai memori server maksimum yang ditetapkan ke 2147483647 MB, yaitu 2 Petabyte. Sebelum SQL Server 2012, nilai memori server maksimum hanya diterapkan ke bufferpool, sehingga pelanggan perlu membatasi jumlah memori yang dapat digunakan bufferpool untuk menghemat memori untuk sistem operasi dan proses lainnya. SQL Server 2012 memperkenalkan penulisan ulang manajer memori sehingga nilai memori server maksimum berlaku untuk semua alokasi memori SQL Server.
Sangat disarankan untuk menetapkan nilai maksimum untuk instance SQL Server Anda. Jonathan Kehayias telah menulis posting blog Berapa banyak memori yang sebenarnya dibutuhkan SQL Server saya, dengan formula yang membantu menetapkan dasar untuk nilai memori maksimum. Dalam kasus SQL Server bersama, saya menyarankan klien saya untuk menetapkan nilai minimum hingga 30% dari memori di server.
Dalam situasi dengan beberapa contoh atau di mana server digunakan untuk SQL Server, SSIS, SSAS, atau SSRS, Anda perlu mengevaluasi berapa banyak memori yang dibutuhkan sistem lain dan mengurangi nilai memori server maksimum untuk memungkinkan memori yang memadai untuk OS dan lainnya layanan.
Masalah ini berlaku untuk lokal, IaaS, dan sebagian untuk Instans Terkelola Azure SQL. Instans Terkelola menetapkan nilai memori server maksimum berdasarkan tingkat yang diterapkan, namun ketika saya menguji pengubahan ukuran lingkungan, nilai memori maksimum tidak berubah secara dinamis. Dalam situasi itu, Anda perlu memperbarui nilainya secara manual. Masalah ini tidak berlaku untuk Azure SQL Database.
Statistik
Pengoptimal kueri menggunakan statistik untuk membuat rencana eksekusi. Ini berarti SQL Server membutuhkan statistik yang terbaru sehingga pengoptimal kueri memiliki peluang lebih baik untuk membuat rencana eksekusi yang baik. Secara default, statistik diperbarui setelah 20% +500 baris data diubah. Itu bisa memakan waktu lama di meja yang lebih besar. Dimulai dengan tingkat kompatibilitas 130, ambang batas pembaruan statistik untuk tabel besar telah diturunkan. Untuk SQL Server 2008R – 2014, Anda dapat menurunkan ambang batas ini menggunakan trace flag 2371.
Saya secara teratur menemukan bahwa pelanggan tidak memperbarui statistik secara manual dan bahkan dengan ambang yang lebih rendah, saya menemukan bahwa memperbarui secara manual membuat lingkungan lebih stabil.
Saya menyarankan agar pelanggan menggunakan skrip pihak ketiga untuk memperbarui statistik. Ola Hallengren telah menerbitkan Solusi Pemeliharaan yang banyak digunakan untuk SQL Server. Bagian dari proses itu adalah prosedur Pengoptimalan Indeksnya, yang dapat mengambil parameter tambahan untuk memperbarui statistik.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Saya telah menemukan bahwa pelanggan yang menggunakan produk atau skrip pihak ketiga untuk melakukan pemeliharaan indeks berdasarkan tingkat fragmentasi indeks tidak mempertimbangkan bahwa reorganisasi tidak memperbarui statistik seperti yang dilakukan oleh pembangunan kembali. Banyak dari aplikasi pihak ketiga ini memiliki opsi untuk memperbarui statistik seperti prosedur Pengoptimalan Indeks Ola, Anda hanya perlu mengaktifkannya.
Statistik pembaruan berlaku untuk lokal, IaaS, Azure SQL Database, dan Azure SQL Managed Instance.
Pemeliharaan Indeks
Melakukan pemeliharaan indeks dengan menghapus fragmentasi dari indeks Anda masih penting. Beberapa dokumentasi pensiunan dari Microsoft menyatakan bahwa fragmentasi indeks dapat memiliki dampak negatif dari 13-460% tergantung pada ukuran lingkungan dan tingkat fragmentasi. Sementara perangkat keras seperti SAN cerdas, Solid State Disk, dan kemajuan lainnya telah membantu mempercepat, ruang yang terbuang dalam indeks dapat diterjemahkan menjadi ruang yang terbuang di kumpulan buffer serta membuang lebih banyak I/O.
Fragmentasi terjadi melalui operasi reguler seperti penyisipan, pembaruan, dan penghapusan. Untuk memulihkan ini, pemeliharaan indeks yang tepat untuk membangun kembali atau mengatur ulang indeks Anda diperlukan. Saya kembali beralih ke Ola Hallengren, untuk skrip Index Optimize-nya. Skrip Ola menyediakan kemampuan untuk menentukan untuk membangun kembali atau mengatur ulang berdasarkan tingkat fragmentasi dan halaman minimum. Banyak alat pihak ketiga menawarkan logika yang sama. Paket Pemeliharaan Database SQL Server sebelum SQL Server 2016 hanya diizinkan untuk membangun kembali atau mengatur ulang semua indeks. Dimulai dengan SQL Server 2016, Anda sekarang dapat menentukan logika serupa berdasarkan tingkat fragmentasi. Jangan lupakan statistik tersebut jika Anda menggunakan logika cerdas berdasarkan tingkat fragmentasi.
Saya suka skrip Ola dan alat pihak ketiga yang masuk ke tabel. Saya kemudian dapat menanyakan tabel untuk melihat apakah saya memiliki hot spot indeks di mana fragmentasi terus-menerus terjadi pada tingkat tinggi dan memecahkan masalah mengapa fragmentasi begitu lazim dan apa pun dapat dilakukan.
Ada pengecualian untuk setiap aturan atau praktik terbaik. Beberapa pola akses data menyebabkan fragmentasi konstan. Biaya untuk membangun kembali/mengatur ulang tabel-tabel tersebut secara terus-menerus mungkin tidak sepadan dan dapat dikeluarkan dari pemeliharaan. Situasi tersebut harus dievaluasi berdasarkan kasus per kasus.
Ini berlaku untuk lokal, IaaS, Azure SQL Database, dan Azure SQL Managed Instance.
MAXDOP
Saya menemukan bahwa tingkat maksimum paralelisme dan ambang biaya untuk paralelisme biasanya dibiarkan pada nilai default di server klien. Untuk MAXDOP nilai defaultnya adalah nol yang berarti jumlah CPU yang 'tidak terbatas' dapat digunakan untuk mengeksekusi wilayah paralel kueri. Secara teknis hingga 64 prosesor kecuali Anda mengaktifkan tanda pelacakan untuk menggunakan lebih banyak.
Satu dekade yang lalu, ketika prosesor memiliki jumlah inti yang lebih rendah, nilai ini dapat diterima. Saat ini, dengan kepadatan inti yang tinggi dan server multi-socket, jumlah CPU yang tidak terbatas untuk paralelisme tidak begitu baik. Microsoft telah memberikan panduan tentang nilai apa yang digunakan untuk MAXDOP.
Jika Anda menggunakan SQL Server 2008 – SQL Server 2014, untuk satu node NUMA dengan kurang dari 8 prosesor logis, pertahankan MAXDOP pada atau di bawah jumlah prosesor logis. Jika Anda memiliki lebih dari 8 pemroses logis, pertahankan MAXDOP di 8. Jika Anda memiliki beberapa NUMA node dengan kurang dari 8 prosesor logis per NUMA node, pertahankan MAXDOP pada atau di bawah jumlah prosesor logis per NUMA node. Lebih dari 8, pertahankan MAXDOP di 8.
SQL Server 2016 memperkenalkan node soft-NUMA. Selama startup layanan, jika Mesin Basis Data mendeteksi lebih dari 8 inti fisik per NUMA node atau soket, node NUMA lunak dibuat secara otomatis. Mesin menangani penempatan prosesor logis dari inti fisik yang sama ke dalam node NUMA lunak yang berbeda. Oleh karena itu, kami memiliki panduan yang sedikit berbeda untuk MAXDOP untuk SQL Server 2016 dan seterusnya.
Jika Anda menggunakan SQL Server 2016 dan yang lebih baru, untuk satu node NUMA dengan kurang dari 16 prosesor logis, pertahankan MAXDOP pada atau di bawah jumlah prosesor logis. Jika Anda memiliki lebih dari 16 pemroses logis, pertahankan MAXDOP pada 16. Jika Anda memiliki beberapa NUMA node dengan kurang dari 16 prosesor logis per NUMA node, pertahankan MAXDOP pada atau di bawah jumlah prosesor logis per NUMA node. Lebih besar dari 16, pertahankan MAXDOP pada setengah jumlah prosesor logis per NUMA node dengan nilai MAX 16.
Jika Anda sebagian besar tervirtualisasi pada mesin dengan 8 atau lebih sedikit prosesor logis dengan MAXDOP default, Anda mungkin baik-baik saja. Jika Anda memiliki perangkat keras fisik besar dengan default, maka Anda harus melihat mengoptimalkan MAXDOP.
Semua angka di atas adalah pedoman, bukan kebenaran yang sulit. Beban kerja Anda bervariasi dan pertimbangan harus diambil saat Anda menentukan nilai yang paling optimal untuk beban kerja Anda.
Mengonfigurasi MAXDOP berlaku untuk Instans Terkelola di tempat, IaaS, dan Azure SQL. Namun, ada konfigurasi cakupan database yang dapat diterapkan per database yang dimulai dengan SQL Server 2016, dan ini berlaku untuk Azure SQL Database.
Ambang Biaya untuk Paralelisme
Ambang biaya untuk paralelisme memiliki nilai default 5. Riwayat nomor ini kembali ke hari-hari awal SQL Server dan workstation tempat pengujian beban kerja dilakukan. Dengan perangkat keras modern, perkiraan biaya 5 sudah ketinggalan zaman. Pengujian telah menunjukkan bahwa meningkatkan angka dari 5 ke nilai yang lebih tinggi akan membuat kueri yang berjalan lebih pendek tidak memiliki paket paralel. Saya cenderung merekomendasikan untuk meningkatkan nilai ini ke angka yang lebih tinggi setelah memeriksa Cache Rencana. Dalam banyak kasus saya akhirnya memulai dengan nilai 25 dan kemudian memantau lebih lanjut dan menyesuaikan dari sana, jika diperlukan. Untuk informasi lebih lanjut tentang menyetel ambang biaya untuk paralelisme, Jonathan Kehayias menulis:Menyetel 'ambang biaya untuk paralelisme' dari Cache Rencana.
Ini berlaku untuk Instans Terkelola di tempat, IaaS, dan Azure SQL.
Peringatan Agen SQL Server
Setiap orang harus memanfaatkan peringatan Agen SQL kecuali mereka memiliki aplikasi pihak ketiga yang memantau kondisi kesalahan yang sama. Mengonfigurasi lansiran itu mudah dan gratis, dan mengonfigurasinya akan memberi Anda informasi penting saat server Anda mengalami masalah.
Saya menulis sebuah artikel berjudul SQL Server Agent Alerts, memberikan petunjuk langkah demi langkah tentang cara membuat peringatan untuk kesalahan 19-25 yang parah dan kesalahan 825. Mengaktifkan peringatan ini mudah:aktifkan email database, buat operator email, lalu buat peringatan. Ini dapat dicapai dengan menggunakan GUI atau dengan T-SQL. Saya mendorong semua orang untuk membuat skrip proses ini menggunakan T-SQL dan menjadikannya bagian dari pembuatan server standar Anda.
Ini berlaku untuk Instans Terkelola di tempat, IaaS, dan Azure SQL.
Ringkasan
Seperti yang Anda lihat, ada banyak pengaturan yang harus diubah dari default setelah menginstal SQL Server. Ini bukan daftar yang lengkap; namun, ini mencakup banyak masalah yang lebih kritis dan memengaruhi kinerja yang saya temukan, dan saya telah dikelompokkan dalam kategori "kecelakaan SQL Server".
