DBCC CHECKDB (Transact-SQL)

Berlaku untuk: SQL Server (semua versi yang didukung) Azure SQL Managed Instance Database Azure SQL

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 perintah DBCC CHECKALLOC, 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.

Catatan

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.

tautan topikIkon Konvensi Sintaks Transact-SQL

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
Adalah 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_LOSS adalah fitur yang didukung tetapi mungkin tidak selalu menjadi opsi terbaik untuk membawa database ke keadaan yang konsisten secara fisik. Jika berhasil, opsi REPAIR_ALLOW_DATA_LOSS 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 memulihkan dari kesalahan yang dilaporkan oleh DBCC CHECKDB. Opsi REPAIR_ALLOW_DATA_LOSS bukanlah alternatif untuk memulihkan dari cadangan yang diketahui baik. Ini adalah opsi darurat "upaya terakhir" yang direkomendasikan untuk digunakan hanya jika memulihkan dari cadangan tidak dimungkinkan.

Kesalahan tertentu, yang hanya dapat diperbaiki menggunakan opsi REPAIR_ALLOW_DATA_LOSS, mungkin melibatkan 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 (menggunakan DBCC CHECKCONSTRAINTS) setelah menggunakan opsi REPAIR_ALLOW_DATA_LOSS.

Sebelum melakukan perbaikan, buat 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, dll.

Sebelum melakukan perbaikan, pertimbangkan untuk mengubah status database ke mode DARURAT 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 pengguna menggunakan CHECKDB 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, pengguna 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 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 ( SQL Server 2008) atau lebih tinggi, melakukan pemeriksaan konsistensi logis pada tampilan terindeks, indeks XML, dan indeks spasial, jika ada.
Untuk informasi selengkapnya, lihat Melakukan Pemeriksaan Konsistensi Logis pada Indeks, di bagian Keterangan nanti di artikel ini.

NO_INFOMSGS
Menyembunyikan semua pesan informasi.

TABLOCK
Menyebabkan DBCC CHECKDB 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 berjalan.

Penting

TABLOCK membatasi pemeriksaan yang dilakukan; DBCC CHECKCATALOG tidak dijalankan pada database, dan data Service Broker tidak divalidasi.

ESTIMASIONAL
Menampilkan perkiraan jumlah ruang tempdb yang diperlukan untuk menjalankan 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 penuh DBCC CHECKDB 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 PHYSICAL_ONLY dapat menyebabkan run-time yang jauh lebih singkat untuk DBCC CHECKDB pada database besar dan direkomendasikan untuk sering digunakan pada sistem produksi. Kami masih menyarankan agar eksekusi penuh DBCC CHECKDB 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 menyebabkan DBCC CHECKDB melewati semua pemeriksaan data FILESTREAM.

DATA_PURITY
Menyebabkan DBCC CHECKDB 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 opsi DATA_PURITY. Untuk database yang ditingkatkan dari versi SQL Server sebelumnya, pemeriksaan nilai kolom tidak diaktifkan secara default hingga DBCC CHECKDB WITH DATA_PURITY telah menjalankan kesalahan secara 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 dalam topik 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 ( SQL Server 2014 (12.x) SP2 dan yang lebih baru).

Mengambil alih opsi konfigurasi paralelisme tingkat maksimumsp_configure 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 MAXDOP Resource Governor, yang dijelaskan dalam ALTER WORKLOAD GROUP. Semua aturan semantik yang digunakan dengan tingkat maksimum opsi konfigurasi paralelisme berlaku saat Anda menggunakan petunjuk kueri MAXDOP. Untuk informasi selengkapnya, lihat Mengonfigurasi tingkat maksimum Opsi Konfigurasi Server paralelisme.

Peringatan

Jika MAXDOP diatur ke nol, 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 ketika DBCC CHECKDB dijalankan. Untuk informasi selengkapnya, lihat Persyaratan Jenis yang Ditentukan Pengguna.

Karena database Sumber Daya hanya dapat dimodifikasi dalam mode pengguna tunggal, perintah DBCC CHECKDB tidak dapat dijalankan di atasnya secara langsung. Namun, ketika DBCC CHECKDB dijalankan terhadap database master, CHECKDB kedua 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) SP2, menjalankan DBCC CHECKDB tidak lagi menghapus cache paket untuk instans SQL Server. Sebelum SQL Server 2005 (9.x) SP2, menjalankan DBCC CHECKDB akan menghapus cache rencana. 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 adalah 100 (SQL Server 2008) atau lebih tinggi:
  • Kecuali NOINDEX ditentukan, DBCC CHECKDB melakukan 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_CHECKS ditentukan, pemeriksaan logis dilakukan pada tampilan terindeks, indeks XML, dan indeks spasial, jika ada. Secara default, pemeriksaan konsistensi fisik dilakukan sebelum pemeriksaan konsistensi logis. Jika NOINDEX juga 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 bisa memiliki efek yang sangat tinggi pada performa, dan kemajuannya tidak dapat dilacak. Oleh karena itu, kami sarankan Anda menentukan hanya jika Anda mencurigai WITH EXTENDED_LOGICAL_CHECKS 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 CHECKDB melakukan pemeriksaan konsistensi untuk memverifikasi bahwa entri indeks memenuhi predikat filter.
  • Jika tingkat kompatibilitas adalah 90 atau kurang, kecuali NOINDEX ditentukan, DBCC CHECKDB melakukan 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, 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 CHECKDB terhadap database yang berisi objek ini. Namun, pemeriksaan konsistensi fisik objek ini selalu selesai. Hanya ketika EXTENDED_LOGICAL_CHECKS opsi ditentukan, apakah evaluasi ekspresi akan dilakukan selain pemeriksaan logis yang sudah ada sebagai bagian EXTENDED_LOGICAL_CHECKS dari 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 jika rekam jepret database internal tidak dapat dibuat. Menjalankan DBCC CHECKDB terhadap tempdb tidak melakukan alokasi atau pemeriksaan 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

  1. DBCC CHECKDB membuat database rekam jepret internal.

  2. Database rekam jepret internal dibuat dengan menggunakan file fisik. Misalnya, untuk database dengan database_ID = 10 yang memiliki tiga file E:\Data\my_DB.mdf, , E:\Data\my_DB.ndfdan E:\Data\my_DB.ldf, database rekam jepret internal akan dibuat menggunakan E:\Data\my_DB.mdf_MSSQL_DBCC11 file dan E:\Data\my_DB.ndf_MSSQL_DBCC11 . Perhatikan bahwa database_id rekam jepret database_id + 1. Perhatikan juga bahwa file baru dibuat di folder yang sama menggunakan konvensi <penamaan filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Tidak ada file jarang yang dibuat untuk log transaksi.

  3. 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 perintah DBCC CHECKDB. Ukuran file baru akan menjadi file yang sama dengan file .mdf atau .ndf.

  4. File baru dihapus di akhir pemrosesan DBCC CHECKDB. File jarang yang dibuat oleh DBCC CHECKDB ini memiliki atribut "Hapus saat Ditutup".

Peringatan

Jika sistem operasi mengalami pematian tak terduga saat perintah DBCC CHECKDB sedang berlangsung, maka file-file ini tidak akan dibersihkan. Mereka akan memakan ruang, dan berpotensi menyebabkan kegagalan pada eksekusi DBCC CHECKDB di masa mendatang. Dalam hal ini, Anda dapat menghapus file baru ini setelah mengonfirmasi bahwa tidak ada perintah DBCC CHECKDB yang saat ini sedang dijalankan.

File baru terlihat dengan menggunakan utilitas file biasa seperti Windows Explorer.

Catatan

Dalam versi SQL Server 2012 dan yang lebih lama, aliran file bernama digunakan sebagai gantinya untuk membuat file rekam jepret internal. Aliran file bernama tidak terlihat dengan menggunakan utilitas file biasa seperti Windows Explorer. Oleh karena itu, pada SQL Server 2012 atau versi yang lebih lama, Anda mungkin mengalami pesan kesalahan 7926 dan 5030 saat Anda menjalankan perintah DBCC CHECKDB untuk file database yang terletak pada volume berformat ReFS. Ini karena aliran file tidak dapat dibuat pada Sistem File Tangguh (RefS). Untuk informasi selengkapnya, lihat artikel Pangkalan Pengetahuan 2974455: Perilaku DBCC CHECKDB saat database SQL Server terletak pada volume ReFS..

Memeriksa dan Memperbaiki Data FILESTREAM

Ketika FILESTREAM diaktifkan untuk database dan tabel, Anda dapat secara opsional menyimpan objek besar biner varbinary(maks) (BLOB) 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 opsi REPAIR_ALLOW_DATA_LOSS. 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 secara berkala menjalankan DBCC CHECKDB 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 RDBMS dari Fitur yang Didukung oleh Edisi SQL Server 2016.

Memahami Pesan Kesalahan DBCC

Setelah perintah DBCC CHECKDB 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 ERRORLOG dalam format berikut:

CHECKDB for database '<database>' finished without errors on 2019-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 log SQL Server 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 perintah DBCC CHECKDB 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 opsi REPAIR_ALLOW_DATA_LOSS 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 opsi DATA_PURITY 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 opsi REPAIR_ALLOW_DATA_LOSS 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 perintah DBCC CHECKDB dalam mode darurat di dalam transaksi pengguna dan mengembalikan transaksi setelah eksekusi.

Ketika database dalam mode darurat dan DBCC CHECKDB dengan klausa REPAIR_ALLOW_DATA_LOSS dijalankan, tindakan berikut diambil:

  • DBCC CHECKDB menggunakan 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 CHECKDB mencoba memulihkan database menggunakan teknik pemulihan berbasis log reguler.
  • Jika, karena kerusakan log transaksi, pemulihan database tidak berhasil, log transaksi dibangun kembali. Membangun kembali log transaksi dapat mengakibatkan hilangnya konsistensi transaksi.

Peringatan

Opsi REPAIR_ALLOW_DATA_LOSS adalah fitur SQL Server yang didukung. Namun, mungkin tidak selalu menjadi opsi terbaik untuk membawa database ke keadaan yang konsisten secara fisik. Jika berhasil, opsi REPAIR_ALLOW_DATA_LOSS 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 memulihkan dari kesalahan yang dilaporkan oleh DBCC CHECKDB. Opsi REPAIR_ALLOW_DATA_LOSS bukanlah alternatif untuk memulihkan dari cadangan yang diketahui baik. Ini adalah opsi darurat "upaya terakhir" 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.

Jika perintah DBCC CHECKDB berhasil, database dalam keadaan 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. Jika perintah DBCC CHECKDB gagal, database tidak dapat diperbaiki.

Menjalankan DBCC CHECKDB dengan REPAIR_ALLOW_DATA_LOSS di Database yang Direplikasi

Menjalankan perintah DBCC CHECKDB dengan opsi REPAIR_ALLOW_DATA_LOSS 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 CHECKDB untuk memperbaiki data pengguna yang rusak mungkin tidak direplikasi:
  • Replikasi penggabungan menggunakan pemicu untuk melacak perubahan pada tabel yang diterbitkan. Jika baris disisipkan, diperbarui, atau dihapus oleh proses CHECKDB, 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 proses CHECKDB, Agen Pembaca Log tidak menerjemahkannya ke pernyataan DELETE; oleh karena itu, perubahan tidak direplikasi.
  • Tabel metadata replikasi. Tindakan yang dilakukan oleh proses CHECKDB untuk memperbaiki tabel metadata replikasi yang rusak memerlukan penghapusan dan konfigurasi ulang replikasi.

Jika Anda harus menjalankan perintah DBCC CHECKDB dengan opsi REPAIR_ALLOW_DATA_LOSS pada database pengguna atau database distribusi:

  1. Hentikan sistem: Hentikan aktivitas pada database dan di semua database lain dalam topologi replikasi, lalu coba sinkronkan semua simpul. Untuk informasi selengkapnya, lihat Menghentikan Topologi Replikasi (Pemrograman Transact-SQL Replikasi).
  2. Jalankan DBCC CHECKDB.
  3. Jika laporan DBCC CHECKDB 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.
  4. Jika laporan DBCC CHECKDB 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 opsi ESTIMATEONLY, PHYSICAL_ONLY, atau 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 saat NO_INFOMSGS ditentukan:

 The command(s) completed successfully.

DBCC CHECKDB mengembalikan tataan hasil berikut saat 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 hasil berikut yang ditetapkan saat 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. Memeriksa database saat ini dan database lain

Contoh berikut dijalankan DBCC CHECKDB untuk database saat ini dan untuk AdventureWorks2019 database.

-- Check the current database.    
DBCC CHECKDB;    
GO    
-- Check the AdventureWorks2012 database without nonclustered indexes.    
DBCC CHECKDB (AdventureWorks2012, NOINDEX);    
GO    

B. Memeriksa database saat ini, menyembunyikan pesan informasi

Contoh berikut memeriksa database saat ini dan menekan semua pesan informasi.

DBCC CHECKDB WITH NO_INFOMSGS;    
GO    

Lihat juga

DBCC (Transact-SQL)
Menampilkan Ukuran File Jarang dari Rekam Jepret Database (Transact-SQL)
sp_helpdb (T-SQL)
Tabel Sistem (Transact-SQL)