Bagikan melalui


DBCC CHECKTABLE (Transact-SQL)

Berlaku untuk: SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Memeriksa integritas semua halaman dan struktur yang membentuk tabel atau tampilan terindeks.

Konvensi sintaks transact-SQL

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. 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 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 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 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);

Lihat juga