Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk: SQL Server
Azure SQL Database
Azure SQL Managed Instance
Memeriksa integritas semua halaman dan struktur yang membentuk tabel atau tampilan terindeks.
Sintaks
DBCC CHECKTABLE
(
table_name | view_name
[ , { NOINDEX | index_id }
| , { 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 ]
}
]
Argumen
| view_name table_name
Tabel atau tampilan terindeks untuk menjalankan pemeriksaan integritas. Nama tabel atau tampilan harus mematuhi aturan untuk pengidentifikasi.
NOINDEX
Menentukan bahwa pemeriksaan intensif indeks non-kluster untuk tabel pengguna tidak boleh dilakukan. Ini mengurangi waktu eksekusi keseluruhan.
NOINDEX
tidak memengaruhi tabel sistem karena pemeriksaan integritas selalu dilakukan pada semua indeks tabel sistem.
index_id
Nomor identifikasi indeks (ID) untuk menjalankan pemeriksaan integritas. Jika index_id ditentukan, DBCC CHECKTABLE
menjalankan pemeriksaan integritas hanya pada indeks tersebut, bersama dengan tumpukan atau indeks berkluster.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Menentukan bahwa DBCC CHECKTABLE
memperbaiki kesalahan yang ditemukan. Untuk menggunakan opsi perbaikan, database harus dalam mode pengguna tunggal.
IZINKAN_PERBAIKAN_HILANGNYA_DATA
Mencoba memperbaiki semua kesalahan yang dilaporkan. Perbaikan ini dapat menyebabkan beberapa kehilangan data.
PERBAIKAN_CEPAT
Sintaks dipertahankan hanya untuk kompatibilitas mundur. Tidak ada tindakan perbaikan yang dilakukan.
Perbaikan_Pembangunan_Ulang
Melakukan perbaikan yang tidak memiliki kemungkinan kehilangan data. Ini dapat mencakup perbaikan cepat, seperti memperbaiki baris yang hilang dalam indeks non-klusster, dan perbaikan yang lebih memakan waktu, seperti membangun ulang indeks.
Argumen ini tidak memperbaiki kesalahan yang melibatkan data FILESTREAM.
Penting
Gunakan opsi REPAIR hanya sebagai upaya terakhir. 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 CHECKTABLE
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 CHECKTABLE
dengan opsi ini.
ALL_ERRORMSGS
Menampilkan sejumlah kesalahan yang tidak terbatas. Semua pesan kesalahan ditampilkan secara default. Menentukan atau menghilangkan opsi ini tidak berpengaruh.
EXTENDED_LOGICAL_CHECKS
Jika tingkat kompatibilitas adalah 100, diperkenalkan di SQL Server 2008 (10.0.x), 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
Menekan semua pesan informasi.
TABLOCK
DBCC CHECKTABLE
Penyebab untuk mendapatkan kunci tabel bersama alih-alih menggunakan rekam jepret database internal.
TABLOCK
akan menyebabkan DBCC CHECKTABLE
berjalan lebih cepat pada tabel di bawah beban berat, tetapi mengurangi konkurensi yang tersedia pada tabel saat DBCC CHECKTABLE
sedang berjalan.
ESTIMASI
Menampilkan perkiraan jumlah tempdb
ruang yang diperlukan untuk dijalankan DBCC CHECKTABLE
dengan semua opsi lain yang ditentukan.
PHYSICAL_ONLY
Membatasi pemeriksaan ke integritas struktur fisik halaman, header rekaman, dan struktur fisik pohon B. Dirancang untuk memberikan pemeriksaan overhead kecil dari konsistensi fisik tabel, pemeriksaan ini juga dapat mendeteksi halaman robek, dan kegagalan perangkat keras umum yang dapat membahayakan data. Eksekusi DBCC CHECKTABLE
penuh mungkin memakan waktu jauh lebih lama daripada pada versi sebelumnya. Perilaku ini terjadi karena alasan berikut:
- Pemeriksaan logis lebih komprehensif.
- Beberapa struktur yang mendasar untuk diperiksa lebih kompleks.
- Banyak pemeriksaan baru telah diperkenalkan untuk menyertakan fitur baru.
Catatan
Dokumentasi menggunakan istilah pohon B umumnya dalam referensi ke indeks. Dalam indeks rowstore, Mesin Database mengimplementasikan pohon B+. Ini tidak berlaku untuk indeks penyimpan kolom atau indeks pada tabel yang dioptimalkan memori. Untuk informasi selengkapnya, lihat panduan arsitektur dan desain indeks SQL Server dan Azure SQL.
Oleh karena itu, menggunakan PHYSICAL_ONLY
opsi dapat menyebabkan run-time yang jauh lebih pendek untuk DBCC CHECKTABLE
pada tabel besar dan oleh karena itu direkomendasikan untuk sering digunakan pada sistem produksi. Kami masih menyarankan agar eksekusi DBCC CHECKTABLE
penuh dilakukan secara berkala. Frekuensi eksekusi ini tergantung pada faktor-faktor khusus untuk bisnis individu dan lingkungan produksi.
PHYSICAL_ONLY
selalu menyiratkan NO_INFOMSGS dan tidak diizinkan dengan salah satu opsi perbaikan.
Catatan
Menentukan PHYSICAL_ONLY
penyebab DBCC CHECKTABLE
untuk melewati semua pemeriksaan data FILESTREAM.
DATA_PURITY
DBCC CHECKTABLE
Penyebab memeriksa tabel untuk nilai kolom yang tidak valid atau di luar rentang. Misalnya, DBCC CHECKTABLE
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 dimutakhirkan dari versi SQL Server sebelumnya, Anda dapat menggunakan DBCC CHECKTABLE WITH DATA_PURITY
untuk menemukan dan memperbaiki kesalahan pada tabel tertentu; namun, pemeriksaan nilai kolom pada tabel tidak diaktifkan secara default sampai DBCC CHECKDB WITH DATA_PURITY
telah dijalankan bebas kesalahan pada database. Setelah ini, DBCC CHECKDB
dan DBCC CHECKTABLE
periksa integritas nilai kolom secara default.
Kesalahan validasi yang dilaporkan oleh opsi ini tidak dapat diperbaiki dengan menggunakan opsi perbaikan DBCC. Untuk informasi tentang memperbaiki kesalahan ini secara manual, lihat Memecahkan masalah kesalahan konsistensi database yang dilaporkan oleh DBCC CHECKDB.
Jika PHYSICAL_ONLY
ditentukan, pemeriksaan integritas kolom tidak dilakukan.
MAXDOP
Berlaku untuk: SQL Server 2014 (12.x) Paket Layanan 2 dan versi yang lebih baru.
Mengambil alih untuk pernyataan tersebut. MAXDOP dapat melebihi nilai yang dikonfigurasi dengan sp_configure
. Jika MAXDOP melebihi nilai yang dikonfigurasi dengan Resource Governor, Mesin Database menggunakan nilai MAXDOP Resource Governor, yang dijelaskan dalam ALTER WORKLOAD GROUP (Transact-SQL). 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.
Catatan
Jika MAXDOP diatur ke nol, maka server memilih tingkat paralelisme maksimum.
Keterangan
Catatan
Untuk melakukan DBCC CHECKTABLE
pada setiap tabel dalam database, gunakan DBCC CHECKDB.
Untuk tabel yang ditentukan, DBCC CHECKTABLE
periksa hal berikut:
- Halaman data indeks, dalam baris, LOB, dan luapan baris ditautkan dengan benar.
- Indeks dalam urutan pengurutan yang benar.
- Pointer konsisten.
- Data di setiap halaman wajar, termasuk kolom komputasi.
- Offset halaman wajar.
- Setiap baris dalam tabel dasar memiliki baris yang cocok di setiap indeks nonclustered, dan sebaliknya.
- Setiap baris dalam tabel atau indeks yang dipartisi berada di partisi yang benar.
- Konsistensi tingkat tautan antara sistem file dan tabel saat menyimpan data varbinary(maks) dalam sistem file menggunakan FILESTREAM.
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 (10.0.x)) atau lebih tinggi:
Kecuali
NOINDEX
ditentukan,DBCC CHECKTABLE
lakukan 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. JikaNOINDEX
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 terpencil, 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 CHECKTABLE
lakukan pemeriksaan konsistensi untuk memverifikasi bahwa entri indeks memenuhi predikat filter.
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
CHECKTABLE
terhadap database yang berisi objek ini. Namun, pemeriksaan konsistensi fisik objek ini selalu selesai. Hanya ketikaEXTENDED_LOGICAL_CHECKS
opsi ditentukan adalah evaluasi ekspresi yang dilakukan, selain pemeriksaan logis yang sudah ada (tampilan terindeks, indeks XML, dan indeks spasial) sebagai bagianEXTENDED_LOGICAL_CHECKS
dari opsi.Jika tingkat kompatibilitas adalah 90 (SQL Server 2005 (9.x)) atau kurang, kecuali
NOINDEX
ditentukan,DBCC CHECKTABLE
melakukan pemeriksaan konsistensi fisik dan logis pada satu tabel atau tampilan terindeks dan pada semua indeks nonclustered dan XML-nya. Indeks spasial tidak didukung.
Untuk mempelajari tingkat kompatibilitas database
Rekam jepret database internal
DBCC CHECKTABLE
menggunakan rekam jepret database internal untuk memberikan konsistensi transaksi yang harus dilakukannya. 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 CHECKTABLE
memperoleh kunci tabel bersama untuk mendapatkan konsistensi yang diperlukan.
Catatan
Jika DBCC CHECKTABLE
dijalankan terhadap tempdb
, ia harus memperoleh kunci tabel bersama. Ini karena, karena alasan performa, rekam jepret database tidak tersedia di tempdb
. Ini berarti bahwa konsistensi transaksi yang diperlukan tidak dapat diperoleh.
Memeriksa dan memperbaiki data FILESTREAM
Ketika FILESTREAM diaktifkan untuk database dan tabel, Anda dapat menyimpan objek besar biner (BLOB) varbinary(maks) secara opsional dalam sistem file. Saat menggunakan DBCC CHECKTABLE
pada tabel 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 CHECKTABLE
akan memeriksa bahwa ada pemetaan satu-ke-satu antara direktori sistem file dan file dan baris tabel, kolom, dan nilai kolom.
DBCC CHECKTABLE
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 dan akan menghapus direktori dan file apa pun yang tidak dipetakan ke baris tabel, kolom, atau nilai kolom.
Periksa objek secara paralel
Secara default, DBCC CHECKTABLE
melakukan pemeriksaan paralel objek. Tingkat paralelisme secara otomatis ditentukan oleh prosesor kueri. Tingkat paralelisme maksimum dikonfigurasi dengan cara yang 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 Bendera Pelacakan (Transact-SQL).
Catatan
DBCC CHECKTABLE
Selama operasi, byte yang disimpan dalam kolom jenis yang ditentukan pengguna yang diurutkan byte harus sama dengan serialisasi komputasi nilai jenis yang ditentukan pengguna. Jika ini tidak benar, DBCC CHECKTABLE
rutinitas akan melaporkan kesalahan konsistensi.
Catatan
Fitur ini tidak tersedia di setiap edisi SQL Server. Untuk informasi selengkapnya, lihat pemeriksaan konsistensi paralel di bagian pengelolaanRDBMS Edisi dan fitur yang didukung SQL Server 2022.
Memahami pesan kesalahan DBCC
DBCC CHECKTABLE
Setelah perintah selesai, pesan ditulis ke log kesalahan SQL Server. Jika perintah DBCC berhasil dijalankan, pesan menunjukkan keberhasilan penyelesaian dan jumlah waktu yang dijalankan perintah. Jika perintah DBCC berhenti sebelum menyelesaikan pemeriksaan karena kesalahan, pesan menunjukkan perintah dihentikan, nilai status, dan jumlah waktu perintah dijalankan. Tabel berikut ini mencantumkan dan menjelaskan nilai status yang bisa disertakan dalam pesan.
Provinsi | Deskripsi |
---|---|
0 | Nomor kesalahan 8930 dimunculkan. Ini menunjukkan kerusakan metadata yang menyebabkan perintah DBCC dihentikan. |
1 | Nomor kesalahan 8967 dimunculkan. Terjadi kesalahan DBCC internal. |
2 | Kegagalan terjadi selama perbaikan database mode darurat. |
3 | Ini menunjukkan kerusakan metadata yang menyebabkan perintah DBCC dihentikan. |
4 | Pernyataan atau pelanggaran akses terdeteksi. |
5 | Terjadi kesalahan yang tidak diketahui yang menghentikan perintah DBCC. |
Pelaporan kesalahan
File cadangan mini (SQLDUMP<nnnn>.txt
) dibuat di direktori SQL Server LOG
setiap kali DBCC CHECKTABLE
mendeteksi kesalahan kerusakan.
Ketika 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 CHECKTABLE
perintah dan output diagnostik tambahan. File telah membatasi daftar kontrol akses diskresi (DACL). 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 DBCC CHECKTABLE
melaporkan kesalahan, kami sarankan memulihkan database dari cadangan database alih-alih menjalankan REPAIR dengan salah satu opsi REPAIR. Jika tidak ada cadangan, menjalankan REPAIR dapat memperbaiki kesalahan yang dilaporkan. Opsi REPAIR untuk digunakan ditentukan di akhir daftar kesalahan yang dilaporkan. Namun, bahwa memperbaiki kesalahan dengan menggunakan REPAIR_ALLOW_DATA_LOSS
opsi mungkin mengharuskan beberapa halaman, dan oleh karena itu data, dihapus.
Perbaikan dapat dilakukan di bawah transaksi pengguna untuk memungkinkan pengguna mengembalikan perubahan yang telah dibuat. Jika perbaikan digulung balik, database masih akan berisi kesalahan, dan harus dipulihkan dari cadangan. Setelah Anda menyelesaikan semua perbaikan, cadangkan database.
Tataan hasil
DBCC CHECKTABLE
mengembalikan tataan hasil berikut. Tataan hasil yang sama dikembalikan jika Anda hanya menentukan nama tabel atau salah satu opsi.
DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC CHECKTABLE
mengembalikan tataan hasil berikut jika opsi ESTIMATEONLY ditentukan:
Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Izin
Pengguna harus memiliki tabel, atau menjadi anggota peran server tetap sysadmin, peran database tetap db_owner, atau peran database tetap db_ddladmin.
Contoh
J. Memeriksa tabel tertentu
Contoh berikut memeriksa integritas HumanResources.Employee
halaman data tabel dalam database AdventureWorks2022.
DBCC CHECKTABLE ('HumanResources.Employee');
GO
B. Melakukan pemeriksaan overhead rendah pada tabel
Contoh berikut melakukan pemeriksaan overhead rendah tabel Employee
dalam database AdventureWorks2022.
DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO
C. Memeriksa indeks tertentu
Contoh berikut memeriksa indeks tertentu, yang diperoleh dengan mengakses sys.indexes
.
DECLARE @indid int;
SET @indid = (SELECT index_id
FROM sys.indexes
WHERE object_id = OBJECT_ID('Production.Product')
AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);