DBCC CHECKTABLE (Transact-SQL)

Artikel
04/26/2023

Berlaku untuk:Database SQL Server Azure SQL 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 ]
        }
    ]

Catatan

Untuk melihat sintaks Transact-SQL untuk SQL Server 2014 dan yang lebih lama, lihat Dokumentasi versi sebelumnya.

Argumen

| table_name view_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 indeks tumpukan atau 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.

REPAIR_ALLOW_DATA_LOSS

Mencoba memperbaiki semua kesalahan yang dilaporkan. Perbaikan ini dapat menyebabkan beberapa kehilangan data.
REPAIR_FAST

Sintaks dipertahankan hanya untuk kompatibilitas mundur. Tidak ada tindakan perbaikan yang dilakukan.
REPAIR_REBUILD

Melakukan perbaikan yang tidak memiliki kemungkinan kehilangan data. Ini dapat 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

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, yang diperkenalkan dalam 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

Menyembunyikan 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 berjalan.

ESTIMASIONAL

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 yang robek, dan kegagalan perangkat keras umum yang dapat membahayakan data. Eksekusi DBCC CHECKTABLE penuh mungkin memakan waktu jauh lebih lama daripada di versi sebelumnya. Perilaku ini terjadi karena alasan berikut:

Pemeriksaan logis lebih komprehensif.
Beberapa struktur yang mendasar yang akan diperiksa lebih kompleks.
Banyak pemeriksaan baru telah diperkenalkan untuk menyertakan fitur baru.

Catatan

SQL Server dokumentasi menggunakan istilah pohon B umumnya dalam referensi ke indeks. Dalam indeks rowstore, SQL Server mengimplementasikan pohon B+. Ini tidak berlaku untuk indeks penyimpan kolom atau penyimpanan data dalam memori. Untuk informasi selengkapnya, lihat panduan arsitektur dan desain indeks SQL Server dan Azure SQL.

Oleh karena itu, menggunakan opsi dapat PHYSICAL_ONLY menyebabkan run-time yang jauh lebih singkat 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 DATA_PURITY opsi . Untuk database yang ditingkatkan dari versi SQL Server yang lebih lama, 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 menjalankan kesalahan gratis 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 artikel Pangkalan Pengetahuan 923247: Memecahkan masalah kesalahan DBCC 2570 di SQL Server 2005 dan versi yang lebih baru.

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 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 menggunakan nilai Resource Governor MAXDOP, 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 ini:

Halaman data indeks, dalam baris, LOB, dan luapan baris ditautkan dengan benar.
Indeks berada dalam urutan pengurutan yang benar.
Pointer konsisten.
Data di setiap halaman masuk akal, termasuk kolom komputasi.
Offset halaman wajar.
Setiap baris dalam tabel dasar memiliki baris yang cocok di setiap indeks nonkluster, 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(max) 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 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 dapat memiliki efek yang sangat tinggi 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 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 ketika EXTENDED_LOGICAL_CHECKS opsi ditentukan adalah evaluasi ekspresi yang dilakukan, selain pemeriksaan logis yang sudah ada (tampilan terindeks, indeks XML, dan indeks spasial) sebagai bagian EXTENDED_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 non-kluster dan XML-nya. Indeks spasial tidak didukung.

Untuk mempelajari tingkat kompatibilitas database

Menampilkan atau Mengubah Tingkat Kompatibilitas Database

Rekam jepret database internal

DBCC CHECKTABLE menggunakan rekam jepret database internal untuk memberikan konsistensi transaksi yang harus dilakukan. Untuk informasi selengkapnya, lihat Melihat Ukuran File Sparse dari 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, untuk 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 secara opsional menyimpan objek besar biner (BLOB) varbinary(maks ) 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.

Memeriksa 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 pengelolaan RDBMS 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 dinaikkan. Ini menunjukkan kerusakan metadata yang menyebabkan perintah DBCC dihentikan.
1	Nomor kesalahan 8967 dinaikkan. Terjadi kesalahan DBCC internal.
2	Kegagalan terjadi selama perbaikan database mode darurat.
3	Ini menunjukkan kerusakan metadata yang menyebabkan perintah DBCC dihentikan.
4	Penegasan 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. 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 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 PERBAIKAN dengan salah satu opsi PERBAIKAN. Jika tidak ada cadangan, menjalankan REPAIR dapat memperbaiki kesalahan yang dilaporkan. Opsi PERBAIKAN 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 dilakukan. 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

A. 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 pada Employee tabel 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);

DBCC CHECKTABLE (Transact-SQL)

Sintaks

Argumen

| table_name view_name

NOINDEX

index_id

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMASIONAL

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Keterangan

Melakukan pemeriksaan konsistensi logis pada indeks

Untuk mempelajari tingkat kompatibilitas database

Rekam jepret database internal

Memeriksa dan memperbaiki data FILESTREAM

Memeriksa objek secara paralel

Memahami pesan kesalahan DBCC

Pelaporan kesalahan

Mengatasi kesalahan

Tataan hasil

Izin

Contoh

A. Memeriksa tabel tertentu

B. Melakukan pemeriksaan overhead rendah pada tabel

C. Memeriksa indeks tertentu

Lihat juga

Saran dan Komentar

Saran dan Komentar

Sumber Daya Tambahan: