DBCC CHECKDB sangat penting untuk database SQL Server agar 100% yakin bahwa tidak ada korupsi. Namun, karena basis data bertambah besar, sangat sulit untuk menemukan jendela pemeliharaan saat Anda mengklaim 24x7 ke atas. Selama bertahun-tahun, tim SQL Server telah menerapkan berbagai mekanisme yang akan mendeteksi bentuk paling umum dari korupsi terutama terkait dengan korupsi fisik yang disebabkan oleh perangkat keras.
SQL Server 2005 dan yang lebih baru memiliki PAGE_VERIFY = CHECKSUM yang dapat membantu Anda secara proaktif mendeteksi korupsi fisik di halaman database sehingga menambahkan checksum ke setiap halaman seperti yang ditulis ke sistem I / O dan memvalidasi checksum saat itu dibaca dari disk.
Juga, pencadangan (penuh atau diferensial) dengan CHECKSUM akan menjamin untuk mendeteksi korupsi I / O yang disebabkan oleh perangkat keras.
Oleh karena itu, dari sisi perangkat keras korupsi, SQL Server melakukan pekerjaan yang baik untuk mendeteksi dan melaporkannya. (Pastikan juga untuk mengatur Peringatan terkait korupsi yang penting ).
Bahwa sedang dikatakan, masih logis korupsi , kesalahan yang disebabkan scribbler - di mana halaman dalam memori rusak baik oleh kode pihak ketiga yang berjalan di dalam proses SQL Server atau oleh driver atau perangkat lunak lain dengan hak istimewa yang cukup mengeksekusi dalam mode kernel Windows dan / atau SQL Server Bug , dll tidak terdeteksi menggunakan metode di atas dan karenanya CHECKDB muncul.
DBCC CHECKDB melakukan pemeriksaan yang lebih menyeluruh yang mencakup memeriksa header halaman untuk kemungkinan korupsi yang tidak dapat dideteksi dengan cara lain.
Adakah skrip yang ada di luar sana?
Alih-alih menciptakan kembali roda, saya akan sangat menyarankan Anda untuk melihat solusi SQL Server Integrity Check
Menjalankan DBCC CHECKDB secara efisien:
Anda hanya perlu kreatif ketika Anda berada dalam jendela pemeliharaan yang ketat yang memiliki basis data sangat besar atau jumlah basis data yang tinggi untuk menjalankan CHECKDB.
Setelah mengikuti pelatihan SQLSkills, apa yang telah saya terapkan di lingkungan saya adalah:
- memprioritaskan tabel apa yang penting untuk diperiksa.
- pisahkan tabel menjadi kelompok dengan prioritas yang berbeda dan kemudian jalankan
DBCC CHECKTABLE
bersama dengan menjalankan DBCC CHECKALLOC
danDBCC CHECKCATALOG
- Buat tabel pekerja yang akan menyimpan nama tabel dengan prioritas. Pastikan saja semua tabel prioritas tinggi (yang sangat besar) tidak berada dalam satu grup lagi, CHECKDB Anda tidak akan selesai sama sekali.
- Anda bahkan dapat memiliki kolom batas waktu di tabel pekerja Anda yang akan mengatur kapan CHECKDB Anda akan terbunuh begitu telah melewati jendela pemeliharaan
- Tambahkan berapa lama per tabel untuk dijalankan
DBCC CHECKTABLE
, DBCC CHECKALLOC
dan DBCC CHECKCATALOG
. Sehingga Anda bisa merasakan berapa lama biasanya untuk menjalankan cek Anda.
- Anda bahkan dapat menjalankan dengan
NOINDEX
opsi karena akan mempercepat operasi karena tidak memeriksa Indeks Non-Clustered pada tabel pengguna. Ini memiliki beberapa keuntungan karena tidak sepenting korupsi data karena tidak ada data yang hilang dan Anda dapat menjatuhkan dan membuat ulang Indeks jika perlu.
Jelas, edisi Enterprise dapat mengambil keuntungan dari eksekusi Paralel pernyataan DBCC, tetapi perhatikan pengaturan MAXDOP karena mungkin akan berakhir dengan mengambil semua CPU Anda. Ini bisa sulit dibatasi oleh Gubernur Sumber Daya.
Catatan: Jika Anda memiliki kolom SPARSE, maka CHECKDB Anda akan mati lambat seperti dijelaskan di sini .
Akhirnya, ini adalah cara mencegah korupsi basis data dengan memanfaatkan semua set alat yang tersedia + keyakinan Anda pada sistem perangkat keras server basis data Anda dan yang paling penting nilai data Anda.
Beberapa referensi bagus: