DBCC CHECKDB (Transact-SQL)
Berlaku untuk:
Database SQL Server Azure SQL Azure SQL Managed Instance
Memeriksa integritas logis dan fisik semua objek dalam database yang ditentukan dengan melakukan operasi berikut:
- Menjalankan DBCC CHECKALLOC pada database.
- Menjalankan DBCC CHECKTABLE pada setiap tabel dan menampilkan dalam database.
- Menjalankan DBCC CHECKCATALOG pada database.
- Memvalidasi konten setiap tampilan terindeks dalam database.
- Memvalidasi konsistensi tingkat tautan antara metadata tabel dan direktori sistem file dan file saat menyimpan data varbinary(max) dalam sistem file menggunakan FILESTREAM.
- Memvalidasi data Service Broker dalam database.
Ini berarti bahwa DBCC CHECKALLOCperintah , DBCC CHECKTABLE, atau DBCC CHECKCATALOG tidak harus dijalankan secara terpisah dari DBCC CHECKDB. Untuk informasi lebih rinci tentang pemeriksaan yang dilakukan perintah ini, lihat deskripsi perintah ini.
DBCC CHECKDB didukung pada database yang berisi tabel yang dioptimalkan memori tetapi validasi hanya terjadi pada tabel berbasis disk. Namun, sebagai bagian dari pencadangan dan pemulihan database, validasi CHECKSUM dilakukan untuk file dalam grup file yang dioptimalkan memori.
Karena opsi perbaikan DBCC tidak tersedia untuk tabel yang dioptimalkan memori, Anda harus mencadangkan database Anda secara teratur dan menguji cadangan. Jika masalah integritas data terjadi dalam tabel yang dioptimalkan memori, Anda harus memulihkan dari cadangan baik terakhir yang diketahui.
Sintaks
DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]
Catatan
Untuk melihat sintaks Transact-SQL untuk SQL Server 2014 dan yang lebih lama, lihat Dokumentasi versi sebelumnya.
Argumen
| database_name database_id | 0
Nama atau ID database untuk menjalankan pemeriksaan integritas. Jika tidak ditentukan, atau jika 0 ditentukan, database saat ini digunakan. Nama database harus mematuhi aturan untuk pengidentifikasi.
NOINDEX
Menentukan bahwa pemeriksaan intensif indeks non-kluster untuk tabel pengguna tidak akan dilakukan. Pilihan ini mengurangi waktu eksekusi keseluruhan. NOINDEX tidak memengaruhi tabel sistem karena pemeriksaan integritas selalu dilakukan pada indeks tabel sistem.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Menentukan bahwa DBCC CHECKDB memperbaiki kesalahan yang ditemukan. Gunakan opsi REPAIR hanya sebagai upaya terakhir. Database yang ditentukan harus dalam mode pengguna tunggal untuk menggunakan salah satu opsi perbaikan berikut.
REPAIR_ALLOW_DATA_LOSS
Mencoba memperbaiki semua kesalahan yang dilaporkan. Perbaikan ini dapat menyebabkan beberapa kehilangan data.
Peringatan
Opsi
REPAIR_ALLOW_DATA_LOSSini adalah fitur yang didukung tetapi mungkin tidak selalu menjadi opsi terbaik untuk membawa database ke keadaan yang konsisten secara fisik. Jika berhasil,REPAIR_ALLOW_DATA_LOSSopsi dapat mengakibatkan beberapa kehilangan data. Bahkan, hal ini dapat mengakibatkan lebih banyak data hilang daripada jika pengguna memulihkan database dari cadangan baik terakhir yang diketahui.Microsoft selalu merekomendasikan pemulihan pengguna dari cadangan baik terakhir yang diketahui sebagai metode utama untuk pulih dari kesalahan yang dilaporkan oleh
DBCC CHECKDB. OpsiREPAIR_ALLOW_DATA_LOSSini bukan alternatif untuk memulihkan dari cadangan yang diketahui baik. Ini adalah opsi upaya terakhir darurat yang direkomendasikan untuk digunakan hanya jika memulihkan dari cadangan tidak dimungkinkan.Kesalahan tertentu, yang hanya dapat diperbaiki menggunakan
REPAIR_ALLOW_DATA_LOSSopsi , mungkin melibatkan pembukaan alokasi baris, halaman, atau rangkaian halaman untuk menghapus kesalahan. Setiap data yang dibatalkan alokasinya tidak lagi dapat diakses atau dipulihkan untuk pengguna, dan konten pasti dari data yang tidak dialokasikan tidak dapat ditentukan. Oleh karena itu, integritas referensial mungkin tidak akurat setelah baris atau halaman apa pun dibatalkan alokasinya karena batasan kunci asing tidak diperiksa atau dipertahankan sebagai bagian dari operasi perbaikan ini. Pengguna harus memeriksa integritas referensial database mereka (menggunakanDBCC CHECKCONSTRAINTS) setelah menggunakanREPAIR_ALLOW_DATA_LOSSopsi .Sebelum melakukan perbaikan, Anda harus membuat salinan fisik file milik database ini. Ini termasuk file data utama (
.mdf), file data sekunder apa pun (.ndf), semua file log transaksi (.ldf), dan kontainer lain yang membentuk database termasuk katalog teks lengkap, folder aliran file, data memori yang dioptimalkan, dan sebagainya.Sebelum melakukan perbaikan, pertimbangkan untuk mengubah status database ke
EMERGENCYmode dan mencoba mengekstrak informasi sebanyak mungkin dari tabel penting dan menyimpan data tersebut.REPAIR_FAST
Mempertahankan sintaks untuk kompatibilitas mundur saja. Tidak ada tindakan perbaikan yang dilakukan.
REPAIR_REBUILD
Melakukan perbaikan yang tidak memiliki kemungkinan kehilangan data. Opsi ini mungkin mencakup perbaikan cepat, seperti memperbaiki baris yang hilang dalam indeks nonkluster, dan perbaikan yang lebih memakan waktu, seperti membangun kembali indeks.
Argumen ini tidak memperbaiki kesalahan yang melibatkan data FILESTREAM.
Penting
Karena DBCC CHECKDB dengan salah satu opsi REPAIR sepenuhnya dicatat dan dipulihkan, Microsoft selalu merekomendasikan penggunaan DBCC CHECKDB pengguna dengan opsi REPAIR apa pun dalam transaksi (jalankan BEGIN TRANSACTION sebelum menjalankan perintah) sehingga pengguna dapat mengonfirmasi bahwa mereka ingin menerima hasil operasi. Kemudian pengguna dapat menjalankan COMMIT TRANSACTION untuk melakukan semua pekerjaan yang dilakukan oleh operasi perbaikan. Jika pengguna tidak ingin menerima hasil operasi, mereka dapat menjalankan ROLLBACK TRANSACTION untuk membatalkan efek operasi perbaikan.
Untuk memperbaiki kesalahan, kami sarankan memulihkan dari cadangan. Operasi perbaikan tidak mempertimbangkan batasan apa pun yang mungkin ada di atau di antara tabel. Jika tabel yang ditentukan terlibat dalam satu atau beberapa batasan, sebaiknya jalankan DBCC CHECKCONSTRAINTS setelah operasi perbaikan. Jika Anda harus menggunakan REPAIR, jalankan DBCC CHECKDB tanpa opsi perbaikan untuk menemukan tingkat perbaikan yang akan digunakan. Jika Anda menggunakan tingkat tersebut REPAIR_ALLOW_DATA_LOSS , kami sarankan Anda mencadangkan database sebelum menjalankan DBCC CHECKDB dengan opsi ini.
ALL_ERRORMSGS
Menampilkan semua kesalahan yang dilaporkan per objek. Semua pesan kesalahan ditampilkan secara default. Menentukan atau menghilangkan opsi ini tidak berpengaruh. Pesan kesalahan diurutkan menurut ID objek, kecuali untuk pesan yang dihasilkan dari database tempdb.
EXTENDED_LOGICAL_CHECKS
Jika tingkat kompatibilitas adalah 100, yang diperkenalkan dalam SQL Server 2008 (10.0.x), opsi ini melakukan pemeriksaan konsistensi logis pada tampilan terindeks, indeks XML, dan indeks spasial, jika ada.
Untuk informasi selengkapnya, lihat Melakukan pemeriksaan konsistensi logis pada indeks nanti di artikel ini.
NO_INFOMSGS
Menyembunyikan semua pesan informasi.
TABLOCK
DBCC CHECKDB Penyebab untuk mendapatkan kunci alih-alih menggunakan rekam jepret database internal. Ini termasuk kunci eksklusif jangka pendek (X) pada database. TABLOCK akan menyebabkan DBCC CHECKDB berjalan lebih cepat pada database di bawah beban berat, tetapi akan mengurangi konkurensi yang tersedia pada database saat DBCC CHECKDB sedang berjalan.
Penting
TABLOCK membatasi pemeriksaan yang dilakukan; DBCC CHECKCATALOG tidak dijalankan pada database, dan data Service Broker tidak divalidasi.
ESTIMASIONAL
Menampilkan perkiraan jumlah tempdb ruang yang diperlukan untuk dijalankan DBCC CHECKDB dengan semua opsi lain yang ditentukan. Pemeriksaan database aktual tidak dilakukan.
PHYSICAL_ONLY
Membatasi pemeriksaan ke integritas struktur fisik halaman dan header rekaman dan konsistensi alokasi database. Pemeriksaan ini dirancang untuk memberikan pemeriksaan overhead kecil dari konsistensi fisik database, tetapi juga dapat mendeteksi halaman yang robek, kegagalan checksum, dan kegagalan perangkat keras umum yang dapat membahayakan data pengguna.
Eksekusi DBCC CHECKDB penuh mungkin membutuhkan waktu jauh lebih lama untuk diselesaikan daripada versi sebelumnya. Perilaku ini terjadi karena:
- Pemeriksaan logis lebih komprehensif.
- Beberapa struktur yang mendasar yang akan diperiksa lebih kompleks.
- Banyak pemeriksaan baru telah diperkenalkan untuk menyertakan fitur baru.
Oleh karena itu, menggunakan opsi ini PHYSICAL_ONLY dapat menyebabkan run-time yang jauh lebih singkat untuk DBCC CHECKDB database besar dan direkomendasikan untuk sering digunakan pada sistem produksi. Kami masih menyarankan agar eksekusi DBCC CHECKDB penuh dilakukan secara berkala. Frekuensi eksekusi ini tergantung pada faktor-faktor khusus untuk bisnis individu dan lingkungan produksi.
Argumen ini selalu menyiratkan NO_INFOMSGS dan tidak diizinkan dengan salah satu opsi perbaikan.
Peringatan
Menentukan PHYSICAL_ONLY penyebab DBCC CHECKDB untuk melewati semua pemeriksaan data FILESTREAM.
DATA_PURITY
DBCC CHECKDB Penyebab memeriksa database untuk nilai kolom yang tidak valid atau di luar rentang. Misalnya, DBCC CHECKDB mendeteksi kolom dengan nilai tanggal dan waktu yang lebih besar dari atau kurang dari rentang yang dapat diterima untuk jenis data tanggalwaktu ; atau kolom tipe data desimal atau perkiraan numerik dengan nilai skala atau presisi yang tidak valid.
Pemeriksaan integritas nilai kolom diaktifkan secara default dan tidak memerlukan DATA_PURITY opsi . Untuk database yang ditingkatkan dari versi SQL Server sebelumnya, pemeriksaan nilai kolom tidak diaktifkan secara default sampai DBCC CHECKDB WITH DATA_PURITY telah menjalankan kesalahan gratis pada database. Setelah ini, DBCC CHECKDB memeriksa integritas nilai kolom secara default. Untuk informasi selengkapnya tentang bagaimana CHECKDB mungkin terpengaruh dengan memutakhirkan database dari versi SQL Server yang lebih lama, lihat bagian Keterangan nanti di artikel ini.
Peringatan
Jika PHYSICAL_ONLY ditentukan, pemeriksaan integritas kolom tidak dilakukan.
Kesalahan validasi yang dilaporkan oleh opsi ini tidak dapat diperbaiki dengan menggunakan opsi perbaikan DBCC. Untuk informasi tentang memperbaiki kesalahan ini secara manual, lihat artikel Pangkalan Pengetahuan 923247: Memecahkan masalah kesalahan DBCC 2570 di SQL Server 2005 dan versi yang lebih baru.
MAXDOP
Berlaku untuk: SQL Server 2014 (12.x) Paket Layanan 2 dan versi yang lebih baru
Mengambil alih tingkat maksimum opsi sp_configure konfigurasi paralelisme untuk pernyataan tersebut. MAXDOP dapat melebihi nilai yang dikonfigurasi dengan sp_configure. Jika MAXDOP melebihi nilai yang dikonfigurasi dengan Resource Governor, mesin database SQL Server menggunakan nilai Resource GovernorMAXDOP, yang dijelaskan dalam UBAH GRUP BEBAN KERJA. Semua aturan semantik yang digunakan dengan opsi konfigurasi paralelisme tingkat maksimum berlaku saat Anda menggunakan MAXDOP petunjuk kueri. Untuk informasi selengkapnya, lihat Mengonfigurasi tingkat maksimum Opsi Konfigurasi Server paralelisme.
Peringatan
Jika MAXDOP diatur ke nol maka SQL Server memilih tingkat paralelisme maksimum untuk digunakan.
Keterangan
DBCC CHECKDB tidak memeriksa indeks yang dinonaktifkan. Untuk informasi selengkapnya tentang indeks yang dinonaktifkan, lihat Menonaktifkan Indeks dan Batasan.
Jika jenis yang ditentukan pengguna ditandai sebagai byte yang diurutkan, hanya boleh ada satu serialisasi jenis yang ditentukan pengguna. Tidak memiliki serialisasi yang konsisten dari jenis yang ditentukan pengguna yang diurutkan byte menyebabkan kesalahan 2537 saat DBCC CHECKDB dijalankan. Untuk informasi selengkapnya, lihat Persyaratan Jenis yang Ditentukan Pengguna.
Karena database Sumber Daya hanya dapat dimodifikasi dalam mode pengguna tunggal, DBCC CHECKDB perintah tidak dapat dijalankan di atasnya secara langsung. Namun, ketika DBCC CHECKDB dijalankan terhadap database master, satu detik CHECKDB juga dijalankan secara internal pada database Sumber Daya. Ini berarti bahwa DBCC CHECKDB dapat mengembalikan hasil tambahan. Perintah mengembalikan tataan hasil tambahan saat tidak ada opsi yang diatur, atau saat PHYSICAL_ONLY opsi atau ESTIMATEONLY diatur.
Dimulai dengan SQL Server 2005 (9.x) Paket Layanan 2, menjalankan DBCC CHECKDB tidak lagi menghapus cache paket untuk instans SQL Server. Sebelum SQL Server 2005 (9.x) Paket Layanan 2, menjalankan DBCC CHECKDB menghapus cache paket. Menghapus cache rencana menyebabkan kompilasi ulang semua rencana eksekusi nanti dan dapat menyebabkan penurunan performa kueri secara tiba-tiba dan sementara.
Melakukan pemeriksaan konsistensi logis pada indeks
Pemeriksaan konsistensi logis pada indeks bervariasi sesuai dengan tingkat kompatibilitas database, sebagai berikut:
- Jika tingkat kompatibilitas setidaknya 100 (diperkenalkan pada SQL Server 2008 (10.0.x)):
- Kecuali
NOINDEXditentukan,DBCC CHECKDBmelakukan pemeriksaan konsistensi fisik dan logis pada satu tabel dan pada semua indeks non-klusternya. Namun, pada indeks XML, indeks spasial, dan tampilan terindeks hanya pemeriksaan konsistensi fisik yang dilakukan secara default. - Jika
WITH EXTENDED_LOGICAL_CHECKSditentukan, pemeriksaan logis dilakukan pada tampilan terindeks, indeks XML, dan indeks spasial, jika ada. Secara default, pemeriksaan konsistensi fisik dilakukan sebelum pemeriksaan konsistensi logis. JikaNOINDEXjuga ditentukan, hanya pemeriksaan logis yang dilakukan.
Konsistensi logis ini memeriksa silang tabel indeks internal objek indeks dengan tabel pengguna yang dirujuknya. Untuk mengetahui baris yang terpenting, kueri internal dibuat untuk melakukan persimpangan penuh tabel internal dan pengguna. Menjalankan kueri ini dapat memiliki efek signifikan pada performa, dan kemajuannya tidak dapat dilacak. Oleh karena itu, kami sarankan Anda menentukan WITH EXTENDED_LOGICAL_CHECKS hanya jika Anda mencurigai masalah indeks yang tidak terkait dengan kerusakan fisik, atau jika checksum tingkat halaman telah dinonaktifkan dan Anda mencurigai kerusakan perangkat keras tingkat kolom.
- Jika indeks adalah indeks yang difilter,
DBCC CHECKDBlakukan pemeriksaan konsistensi untuk memverifikasi bahwa entri indeks memenuhi predikat filter. - Jika tingkat kompatibilitas adalah 90 atau kurang, kecuali
NOINDEXditentukan,DBCC CHECKDBmelakukan pemeriksaan konsistensi fisik dan logis pada satu tabel atau tampilan terindeks dan pada semua indeks non-kluster dan XML-nya. Indeks spasial tidak didukung. - Dimulai dengan SQL Server 2016 (13.x), pemeriksaan tambahan pada kolom komputasi yang dipertahankan, kolom UDT, dan indeks yang difilter tidak akan berjalan secara default untuk menghindari evaluasi ekspresi yang mahal. Perubahan ini sangat mengurangi durasi
CHECKDBterhadap database yang berisi objek ini. Namun, pemeriksaan konsistensi fisik objek ini selalu selesai. Hanya ketikaEXTENDED_LOGICAL_CHECKSopsi ditentukan, adalah evaluasi ekspresi yang dilakukan, selain pemeriksaan logis yang sudah ada sebagai bagianEXTENDED_LOGICAL_CHECKSdari opsi (tampilan terindeks, indeks XML, dan indeks spasial).
Untuk mempelajari tingkat kompatibilitas database
Rekam jepret database internal
DBCC CHECKDB menggunakan rekam jepret database internal untuk konsistensi transaksi yang diperlukan untuk melakukan pemeriksaan ini. Ini mencegah masalah pemblokiran dan konkurensi ketika perintah ini dijalankan. Untuk informasi selengkapnya, lihat Melihat Ukuran File Sparse rekam jepret Database (Transact-SQL) dan bagian Penggunaan Rekam Jepret Database Internal DBCC di DBCC (Transact-SQL). Jika rekam jepret tidak dapat dibuat, atau TABLOCK ditentukan, DBCC CHECKDB memperoleh kunci untuk mendapatkan konsistensi yang diperlukan. Dalam hal ini, kunci database eksklusif diperlukan untuk melakukan pemeriksaan alokasi, dan kunci tabel bersama diperlukan untuk melakukan pemeriksaan tabel.
DBCC CHECKDB gagal saat dijalankan terhadap master database jika rekam jepret database internal tidak dapat dibuat.
tempdb Menjalankan DBCC CHECKDB terhadap tidak melakukan pemeriksaan alokasi atau katalog apa pun dan harus memperoleh kunci tabel bersama untuk melakukan pemeriksaan tabel. Ini karena, karena alasan performa, rekam jepret database tidak tersedia di tempdb. Ini berarti bahwa konsistensi transaksi yang diperlukan tidak dapat diperoleh.
Bagaimana DBCC CHECKDB membuat database rekam jepret internal yang dimulai dengan SQL Server 2014
DBCC CHECKDBmembuat database rekam jepret internal.Database rekam jepret internal dibuat dengan menggunakan file fisik. Misalnya, untuk database dengan
database_id = 10yang memiliki tiga fileE:\Data\my_DB.mdf, ,E:\Data\my_DB.ndfdanE:\Data\my_DB.ldf, database rekam jepret internal akan dibuat menggunakanE:\Data\my_DB.mdf_MSSQL_DBCC11file danE:\Data\my_DB.ndf_MSSQL_DBCC11.database_idDari rekam jepret adalahdatabase_id + 1. Perhatikan juga bahwa file baru dibuat di folder yang sama menggunakan konvensi<filename.extension>_MSSQL_DBCC<database_id_of_snapshot>penamaan . Tidak ada file jarang yang dibuat untuk log transaksi.File baru ditandai sebagai file jarang pada tingkat sistem file. Ukuran pada Disk yang digunakan oleh file baru akan meningkat berdasarkan berapa banyak data yang diperbarui dalam database sumber selama
DBCC CHECKDBperintah. Ukuran file baru akan menjadi file yang sama dengan.mdffile atau.ndf.File baru dihapus di akhir
DBCC CHECKDBpemrosesan. File jarang yang dibuat denganDBCC CHECKDBmengatur atribut "Hapus saat Tutup".
Peringatan
Jika sistem operasi mengalami pematian tak terduga saat DBCC CHECKDB perintah sedang berlangsung, maka file-file ini tidak akan dibersihkan. Mereka akan mengambil ruang, dan berpotensi menyebabkan kegagalan pada eksekusi di masa depan DBCC CHECKDB . Dalam hal ini, Anda dapat menghapus file baru ini setelah mengonfirmasi bahwa saat ini tidak DBCC CHECKDB ada perintah yang dijalankan.
File baru terlihat dengan menggunakan utilitas file biasa seperti Windows Explorer.
Catatan
Sebelum SQL Server 2014 (12.x), aliran file bernama digunakan sebagai gantinya untuk membuat file rekam jepret internal. Aliran file bernama menggunakan format <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Aliran file bernama tidak terlihat dengan menggunakan utilitas file biasa seperti Windows Explorer. Oleh karena itu, pada SQL Server 2012 (11.x) dan versi yang lebih lama, Anda mungkin mengalami pesan kesalahan 7926 dan 5030 saat Menjalankan DBCC CHECKDB perintah untuk file database yang terletak pada volume berformat ReFS. Ini karena aliran file tidak dapat dibuat pada Sistem File Tangguh (RefS).
Memeriksa dan memperbaiki data FILESTREAM
Ketika FILESTREAM diaktifkan untuk database dan tabel, Anda dapat secara opsional menyimpan objek besar biner (BLOB) varbinary(maks ) dalam sistem file. Saat menggunakan DBCC CHECKDB pada database yang menyimpan BLOB dalam sistem file, DBCC memeriksa konsistensi tingkat tautan antara sistem file dan database.
Misalnya, jika tabel berisi kolom varbinary(max) yang menggunakan atribut FILESTREAM, DBCC CHECKDB akan memeriksa bahwa ada pemetaan satu-ke-satu antara direktori sistem file dan file dan baris tabel, kolom, dan nilai kolom. DBCC CHECKDB dapat memperbaiki kerusakan jika Anda menentukan REPAIR_ALLOW_DATA_LOSS opsi . Untuk memperbaiki kerusakan FILESTREAM, DBCC akan menghapus baris tabel apa pun yang kehilangan data sistem file.
Praktik terbaik
Kami menyarankan agar Anda menggunakan PHYSICAL_ONLY opsi untuk sering digunakan pada sistem produksi. Menggunakan PHYSICAL_ONLY dapat sangat mempersingkat run-time untuk DBCC CHECKDB pada database besar. Kami juga menyarankan agar Anda menjalankan DBCC CHECKDB secara berkala tanpa opsi. Seberapa sering Anda harus melakukan eksekusi ini tergantung pada bisnis individual dan lingkungan produksinya.
Memeriksa objek secara paralel
Secara default, DBCC CHECKDB melakukan pemeriksaan paralel objek. Tingkat paralelisme secara otomatis ditentukan oleh prosesor kueri. Tingkat paralelisme maksimum dikonfigurasi sama seperti kueri paralel. Untuk membatasi jumlah maksimum prosesor yang tersedia untuk pemeriksaan DBCC, gunakan sp_configure. Untuk informasi selengkapnya, lihat Mengonfigurasi tingkat maksimum Opsi Konfigurasi Server paralelisme. Pemeriksaan paralel dapat dinonaktifkan dengan menggunakan Bendera Pelacakan 2528. Untuk informasi selengkapnya, lihat Lacak Bendera (Transact-SQL).
Catatan
Fitur ini tidak tersedia di setiap edisi SQL Server. Untuk informasi selengkapnya, lihat pemeriksaan konsistensi paralel di bagian pengelolaan RDBMSEdisi dan fitur yang didukung SQL Server 2022.
Memahami pesan kesalahan DBCC
DBCC CHECKDB Setelah perintah selesai, pesan ditulis ke log kesalahan SQL Server. Jika perintah DBCC berhasil dijalankan, pesan menunjukkan keberhasilan dan jumlah waktu yang dijalankan perintah. Jika perintah DBCC berhenti sebelum menyelesaikan pemeriksaan karena kesalahan, pesan menunjukkan bahwa perintah dihentikan, nilai status, dan jumlah waktu perintah berjalan. Tabel berikut ini mencantumkan dan menjelaskan nilai status yang bisa disertakan dalam pesan.
| Provinsi | Deskripsi |
|---|---|
| 0 | Nomor kesalahan 8930 dimunculkan. Ini menunjukkan kerusakan dalam metadata yang menghentikan perintah DBCC. |
| 1 | Nomor kesalahan 8967 dimunculkan. Terjadi kesalahan DBCC internal. |
| 2 | Kegagalan terjadi selama perbaikan database mode darurat. |
| 3 | Ini menunjukkan kerusakan dalam metadata yang menghentikan perintah DBCC. |
| 4 | Penegasan atau pelanggaran akses terdeteksi. |
| 5 | Terjadi kesalahan yang tidak diketahui yang menghentikan perintah DBCC. |
Catatan
SQL Server merekam tanggal dan waktu saat pemeriksaan konsistensi dijalankan untuk database tanpa kesalahan (atau pemeriksaan konsistensi "bersih"). Ini dikenal sebagai last known clean check. Saat database pertama kali dimulai, tanggal ini ditulis ke EventLog (EventID-17573) dan log kesalahan dalam format berikut:
CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.
Pelaporan kesalahan
File cadangan (SQLDUMP<nnnn>.txt) dibuat di direktori SQL Server LOG setiap kali DBCC CHECKDB mendeteksi kesalahan kerusakan. Saat fitur pengumpulan data Penggunaan Fitur dan Pelaporan Kesalahan diaktifkan untuk instans SQL Server, file secara otomatis diteruskan ke Microsoft. Data yang dikumpulkan digunakan untuk meningkatkan fungsionalitas SQL Server.
File cadangan berisi hasil DBCC CHECKDB perintah dan output diagnostik tambahan. Akses terbatas pada akun layanan SQL Server dan anggota peran sysadmin. Secara default, peran sysadmin berisi semua anggota grup Windows BUILTIN\Administrators dan grup administrator lokal. Perintah DBCC tidak gagal jika proses pengumpulan data gagal.
Mengatasi kesalahan
Jika ada kesalahan yang dilaporkan oleh DBCC CHECKDB, kami sarankan memulihkan database dari cadangan database alih-alih menjalankan REPAIR dengan salah satu opsi REPAIR. Jika tidak ada pencadangan, perbaikan yang berjalan akan memperbaiki kesalahan yang dilaporkan. Opsi perbaikan yang akan digunakan ditentukan di akhir daftar kesalahan yang dilaporkan. Namun, memperbaiki kesalahan dengan menggunakan REPAIR_ALLOW_DATA_LOSS opsi mungkin memerlukan penghapusan beberapa halaman, dan oleh karena itu beberapa data.
Dalam beberapa keadaan, nilai mungkin dimasukkan ke dalam database yang tidak valid atau di luar rentang berdasarkan jenis data kolom. DBCC CHECKDB dapat mendeteksi nilai kolom yang tidak valid untuk semua jenis data kolom. Oleh karena itu, menjalankan DBCC CHECKDB dengan DATA_PURITY opsi pada database yang telah ditingkatkan dari versi SQL Server sebelumnya mungkin mengungkapkan kesalahan nilai kolom yang sudah ada sebelumnya. Karena SQL Server tidak dapat memperbaiki kesalahan ini secara otomatis, nilai kolom harus diperbarui secara manual. Jika CHECKDB mendeteksi kesalahan seperti itu, CHECKDB mengembalikan peringatan, nomor kesalahan 2570, dan informasi untuk mengidentifikasi baris yang terpengaruh dan memperbaiki kesalahan secara manual.
Perbaikan dapat dilakukan di bawah transaksi pengguna untuk memungkinkan pengguna mengembalikan perubahan yang dibuat. Jika perbaikan digulung balik, database masih akan berisi kesalahan dan harus dipulihkan dari cadangan. Setelah perbaikan selesai, cadangkan database.
Mengatasi kesalahan dalam mode darurat database
Ketika database telah diatur ke mode darurat dengan menggunakan pernyataan ALTER DATABASE , DBCC CHECKDB dapat melakukan beberapa perbaikan khusus pada database jika REPAIR_ALLOW_DATA_LOSS opsi ditentukan. Perbaikan ini dapat memungkinkan database yang biasanya tidak dapat dipulihkan untuk dibawa kembali online dalam keadaan konsisten secara fisik. Perbaikan ini harus digunakan sebagai upaya terakhir dan hanya ketika Anda tidak dapat memulihkan database dari cadangan. Ketika database diatur ke mode darurat, database ditandai READ_ONLY, pengelogan dinonaktifkan, dan akses terbatas pada anggota peran server tetap sysadmin.
Catatan
Anda tidak dapat menjalankan DBCC CHECKDB perintah dalam mode darurat di dalam transaksi pengguna dan mengembalikan transaksi setelah eksekusi.
Saat database dalam mode darurat dan DBCC CHECKDB dengan REPAIR_ALLOW_DATA_LOSS klausul dijalankan, tindakan berikut diambil:
DBCC CHECKDBmenggunakan halaman yang telah ditandai tidak dapat diakses karena kesalahan I/O atau checksum, seolah-olah kesalahan belum terjadi. Melakukan ini meningkatkan kemungkinan pemulihan data dari database.DBCC CHECKDBmencoba memulihkan database menggunakan teknik pemulihan berbasis log reguler.- Jika pemulihan database tidak berhasil karena kerusakan log transaksi, log transaksi dibangun kembali. Membangun kembali log transaksi dapat mengakibatkan hilangnya konsistensi transaksi.
Peringatan
Opsi REPAIR_ALLOW_DATA_LOSS ini adalah fitur SQL Server yang didukung. Namun, mungkin tidak selalu menjadi opsi terbaik untuk membawa database ke keadaan yang konsisten secara fisik. Jika berhasil, REPAIR_ALLOW_DATA_LOSS opsi dapat mengakibatkan beberapa kehilangan data.
Bahkan, hal ini dapat mengakibatkan lebih banyak data hilang daripada jika pengguna memulihkan database dari cadangan baik terakhir yang diketahui. Microsoft selalu merekomendasikan pemulihan pengguna dari cadangan baik terakhir yang diketahui sebagai metode utama untuk pulih dari kesalahan yang dilaporkan oleh DBCC CHECKDB.
Opsi REPAIR_ALLOW_DATA_LOSS ini bukan alternatif untuk memulihkan dari cadangan yang diketahui baik. Ini adalah opsi upaya terakhir darurat yang direkomendasikan untuk digunakan hanya jika memulihkan dari cadangan tidak dimungkinkan.
Setelah membangun kembali log, tidak ada jaminan ACID penuh.
Setelah membangun kembali log, DBCC CHECKDB akan dilakukan secara otomatis dan akan melaporkan dan memperbaiki masalah konsistensi fisik.
Konsistensi data logis dan batasan yang diberlakukan logika bisnis harus divalidasi secara manual.
Ukuran log transaksi akan dibiarkan ke ukuran defaultnya dan harus disesuaikan secara manual kembali ke ukuran terbarunya.
DBCC CHECKDB Jika perintah berhasil, database berada dalam status konsisten secara fisik, dan status database diatur ke ONLINE. Namun, database mungkin berisi satu atau beberapa inkonsistensi transaksi. Kami menyarankan agar Anda menjalankan DBCC CHECKCONSTRAINTS untuk mengidentifikasi kelemahan logika bisnis apa pun dan segera mencadangkan database.
DBCC CHECKDB Jika perintah gagal, database tidak dapat diperbaiki.
Jalankan DBCC CHECKDB dengan REPAIR_ALLOW_DATA_LOSS dalam database yang direplikasi
DBCC CHECKDB Menjalankan perintah dengan REPAIR_ALLOW_DATA_LOSS opsi dapat memengaruhi database pengguna (database publikasi dan langganan) dan database distribusi yang digunakan oleh replikasi. Database publikasi dan langganan mencakup tabel yang diterbitkan dan tabel metadata replikasi. Ketahui potensi masalah berikut dalam database ini:
- Tabel yang diterbitkan. Tindakan yang dilakukan oleh proses untuk memperbaiki data pengguna yang
CHECKDBrusak mungkin tidak direplikasi: - Replikasi penggabungan menggunakan pemicu untuk melacak perubahan pada tabel yang diterbitkan. Jika baris disisipkan, diperbarui, atau dihapus oleh
CHECKDBproses, pemicu tidak diaktifkan; oleh karena itu, perubahan tidak direplikasi. - Replikasi transaksional menggunakan log transaksi untuk melacak perubahan pada tabel yang diterbitkan. Agen Pembaca Log kemudian memindahkan perubahan ini ke database distribusi. Beberapa perbaikan DBCC, meskipun dicatat, tidak dapat direplikasi oleh Agen Pembaca Log. Misalnya, jika halaman data dibatalkan alokasinya oleh
CHECKDBproses, Agen Pembaca Log tidak menerjemahkan dealokasi ini ke pernyataan DELETE; oleh karena itu, perubahan tidak direplikasi. - Tabel metadata replikasi. Tindakan yang dilakukan oleh
CHECKDBproses untuk memperbaiki tabel metadata replikasi yang rusak memerlukan penghapusan dan konfigurasi ulang replikasi.
Jika Anda harus menjalankan DBCC CHECKDB perintah dengan REPAIR_ALLOW_DATA_LOSS opsi pada database pengguna atau database distribusi:
- Hentikan sistem: Hentikan aktivitas pada database dan di semua database lain dalam topologi replikasi, lalu coba sinkronkan semua simpul. Untuk informasi selengkapnya, lihat Mendiamkan Topologi Replikasi (Pemrograman Transact-SQL Replikasi).
- Jalankan
DBCC CHECKDB. DBCC CHECKDBJika laporan menyertakan perbaikan untuk tabel apa pun dalam database distribusi atau tabel metadata replikasi apa pun dalam database pengguna, hapus dan konfigurasi ulang replikasi. Untuk informasi selengkapnya, lihat Menonaktifkan Penerbitan dan Distribusi.DBCC CHECKDBJika laporan menyertakan perbaikan untuk tabel yang direplikasi, lakukan validasi data untuk menentukan apakah ada perbedaan antara data dalam database publikasi dan langganan.
Tataan hasil
DBCC CHECKDB mengembalikan tataan hasil berikut. Nilai mungkin bervariasi kecuali ketika ESTIMATEONLYopsi , , PHYSICAL_ONLYatau NO_INFOMSGS ditentukan:
DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.
DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".
DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".
DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC CHECKDB mengembalikan tataan hasil (pesan) berikut ketika NO_INFOMSGS ditentukan:
The command(s) completed successfully.
DBCC CHECKDB mengembalikan tataan hasil berikut ketika PHYSICAL_ONLY ditentukan:
DBCC results for 'model'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC CHECKDB mengembalikan tataan hasil berikut ketika ESTIMATEONLY ditentukan.
Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13
(1 row(s) affected)
Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Izin
Memerlukan keanggotaan dalam peran server tetap sysadmin atau peran database tetap db_owner.
Contoh
A. Periksa database saat ini dan database lainnya
Contoh berikut dijalankan DBCC CHECKDB untuk database saat ini dan untuk AdventureWorks2022 database.
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO
B. Periksa database saat ini, menyembunyikan pesan informasi
Contoh berikut memeriksa database saat ini dan menyembunyikan semua pesan informasi.
DBCC CHECKDB WITH NO_INFOMSGS;
GO
Lihat juga
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk