DBCC CHECKDB: Panduan Lengkap untuk MS SQL Server Basis Data Kesehatan (2025)

Korupsi database adalah setiap SQL Server mimpi buruk administrator. Ketika data bisnis penting menjadi tidak dapat diakses atau tidak dapat diandalkan,ost dapat menjadi bencana. Panduan komprehensif ini mencakup semua yang perlu Anda ketahui tentang penggunaan DBCC CHECKDB untuk menjaga kesehatan basis data dan mencegah kerusakan, ditambah solusi pemulihan tingkat lanjut saat alat standar tidak lagi memadai.

1. Kepentingan dari SQL Server Kesehatan Basis Data

1.1 Apa itu Database Corruption?ostBisnis

Hari ini, most Bisnis menyimpan data penting mereka dalam basis data. Ketika terjadi kerusakan basis data, konsekuensinya sangat buruk:

• Kerugian finansial rata-rata $2.3 juta per tahun akibat kehilangan data, dengan kegagalan dan kerusakan perangkat keras menjadi penyebab utamanya (EMC Corporation)
• Tingkat penutupan bisnis menunjukkan bahwa 50% dari bisnis kecil yang mengalami kehilangan data karena kegagalan perangkat keras bangkrut dalam waktu dua tahun, sementara 94% bisnis dengan kehilangan data yang sangat besar tidak bertahan sama sekali
• Frekuensi kerusakan data mempengaruhi 20% aplikasi penting setiap tahunnya, menyebabkan gangguan pada kelangsungan bisnis (penelitian Gartner)
• Kerusakan yang berhubungan dengan perangkat keras menyumbang 67% dari semua insiden kehilangan data akibat kerusakan hard drive dan kegagalan sistem, dengan 40% kehilangan data secara langsung disebabkan oleh kegagalan fungsi perangkat keras
• Korupsi perangkat lunak costs Kerugian berkisar dari ribuan hingga jutaan dolar tergantung pada tingkat keparahan dan cakupannya, dengan 82% bisnis mengalami pemadaman tak terencana yang mana korupsi merupakan penyebab utamanya

1.2 Mengapa Pemeriksaan Kesehatan Rutin Sangat Penting

Masyarakat perlu melakukan pemeriksaan kesehatan rutin untuk mendeteksi potensi penyakit sejak dini. Demikian pula, basis data juga memerlukan pemeriksaan kesehatan rutin:

1. Deteksi potensi korupsi sejak dini dan tangani dengan segera, cegah masalah menjadi parah dan meluas, yang dapat mengakibatkan konsekuensi bencana bagi bisnis.
2. Pastikan basis data beroperasi pada kinerja optimal.
3. Cost Tingkat pemeriksaan kesehatan basis data proaktif jauh lebih rendah daripada tingkat pemulihan data reaktif setelah bencana basis data terjadi.

1.3 Pengenalan Perintah Integritas Basis Data

SQL Server menyediakan beberapa perintah bawaan untuk menjaga kesehatan database, dengan DBCC CHECKDB berfungsi sebagai most Tersedia alat pemeriksaan integritas yang komprehensif. Perintah-perintah ini bekerja sama untuk memverifikasi berbagai aspek struktur basis data Anda, dari tabel individual hingga konsistensi seluruh basis data, membentuk strategi pemeliharaan lengkap yang menjaga data Anda tetap aman dan dapat diakses.

2. Apa itu DBCC CHECKDB

DBCC CHECKDB is SQL ServerAlat utama untuk memverifikasi integritas basis data dan mengidentifikasi masalah kerusakan.

• Ini adalah pernyataan T-SQL, bukan alat GUI.
• Anda dapat menjalankannya melalui metode umum, seperti SQL Server Studio Manajemen (SSMS), SQL Server Agen, SQLCMD, dll.

2.1 Apa yang Sebenarnya Diperiksa CHECKDB di Basis Data Anda

Saat Anda menjalankan DBCC CHECKDB, perintah tersebut melakukan beberapa lapisan validasi di seluruh struktur basis data Anda:

• Verifikasi checksum halaman untuk mendeteksi kerusakan fisik dan masalah terkait perangkat keras
• Validasi konsistensi indeks untuk memastikan pengambilan data dan kinerja kueri yang tepat
• Pemeriksaan struktur alokasi untuk mengonfirmasi penggunaan ruang dan alokasi halaman yang akurat
• Pemeriksaan integritas referensial antara tabel terkait dan hubungan kunci asing
• Validasi konsistensi tabel sistem untuk memastikan SQL ServerMetadata internal tetap dapat diandalkan
• Verifikasi tautan halaman data untuk mengonfirmasi integritas rantai halaman yang tepat
• Konsistensi skema basis data untuk memvalidasi definisi dan dependensi objek

Pemeriksaan komprehensif ini mencakup data pengguna dan struktur sistem, memberikan visibilitas lengkap terhadap status kesehatan basis data Anda.

3. Menjalankan DBCC CHECKDB: Langkah demi Langkah

Prasyarat 3.1

Berikut adalah daftar periksa sebelum menjalankan operasi DBCC CHECKDB apa pun:

• Pencadangan basis data lengkap – Buat cadangan penuh sebelum menjalankan pemeriksaan integritas sebagai jaring pengaman jika kerusakan ditemukan atau operasi perbaikan diperlukan.
• Izin yang sesuai – Anda memerlukan izin sysadmin atau db_owner untuk menjalankan perintah DBCC CHECKDB
• Sumber daya sistem yang memadai:
  • Memori: 25% dari ukuran basis data
  • Ruang Tempdb: 10-15% dari ukuran basis data
  • CPU: ketersediaan 50-70% selama pemeliharaan
  • I/O: Harapkan operasi baca yang berat
• Aksesibilitas basis data – Verifikasi bahwa database Anda dapat diakses dan tidak dalam status terbatas, karena CHECKDB memerlukan akses baca ke semua halaman database

3.2 Perintah Dasar

Most Perintah DBCC CHECKDB dasar mencakup tiga variasi umum:

(1) Periksa database saat ini (tanpa parameter):

DBCC CHECKDB

(2) Periksa database berdasarkan nama:

DBCC CHECKDB ('YourDatabaseName')

(3) Periksa database berdasarkan ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Perintah dasar ini melakukan pemeriksaan integritas lengkap dari basis data yang ditentukan, memeriksa semua tabel, indeks, dan struktur sistem. Untuk basis data dengan nama standar yang tidak mengandung spasi, Anda dapat menghilangkan tanda kutip. Perintah akan berjalan hingga selesai, menampilkan pesan kemajuan dan hasil akhir. Sintaks dasar ini berfungsi sempurna untuk basis data yang lebih kecil atau saat Anda memiliki cukup waktu pemeliharaan.

Berikut adalah tangkapan layar menjalankan DBCC CHECKDB di SQL Server Studio Manajemen (SSMS):

3.3 Opsi Lengkap

Berikut ini adalah pilihan lengkap untuk DBCC CHECKDB:

Kategori	pilihan	Description	Contoh DBCC CHECKDB
Opsi Perbaikan	REPAIR_REBUILD	Perbaikan tanpa kehilangan data (misalnya, membangun kembali indeks)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Tidak perlu perbaikan. Hanya kompatibilitas mundur	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Memperbaiki semua kesalahan (dapat menyebabkan hilangnya data)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kontrol Lingkup	NOINDEX	Melewati pemeriksaan indeks non-cluster	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Hanya memeriksa integritas penyimpanan fisik (halaman/catatan)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Memeriksa kesalahan nilai kolom logis (misalnya, tanggal tidak valid)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Pemeriksaan logika mendalam (tampilan terindeks, indeks XML/spasial)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kontrol Keluaran	ALL_ERRORMSGS	Menampilkan semua kesalahan (default: 200 per objek)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Menyembunyikan pesan informasi	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performance	TABLOCK	Menggunakan kunci tabel (mengurangi penggunaan TempDB tetapi memblokir penulisan)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Mengganti pengaturan paralelisme	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Kegunaan	ESTIMATEONLY	Memperkirakan ruang TempDB yang dibutuhkan. (tanpa pemeriksaan aktual)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Memahami Hasil Anda

DBCC CHECKDB akan menghasilkan hasil yang berbeda berdasarkan apakah eksekusinya berhasil atau tidak. Mari kita jelaskan secara terperinci.

4.1 Eksekusi CHECKDB Berhasil Diselesaikan

Jika eksekusi DBCC CHECKDB berhasil diselesaikan, ia akan melaporkan berbagai jenis hasil, tergantung pada status kesehatan basis data Anda.

4.1.1 Tidak Ditemukan Masalah

Jika DBCC CHECKDB tidak menemukan masalah apa pun, Anda akan melihat keluaran yang mirip dengan:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Hasil ini menunjukkan basis data Anda mempertahankan integritas sempurna di seluruh struktur yang diperiksa.

4.1.2 Ditemukannya Kesalahan Korupsi

Setiap kali DBCC CHECKDB mendeteksi kesalahan korupsi, ia akan melaporkan pesan kesalahan dengan struktur berikut:
Panduan Tingkat Keparahan:

• Tingkat 16-19: Kesalahan yang dapat diperbaiki pengguna, seringkali kerusakan kecil
• Tingkat 20-24: Kesalahan sistem, kerusakan serius yang memerlukan perhatian segera
• Tingkat 25: Kesalahan fatal, database mungkin tidak dapat diakses

Kesalahan umum meliputi:

• Kegagalan checksum halaman (pesan 824)
• Kesalahan alokasi (pesan 8928)
• Masalah konsistensi indeks (pesan 8964)

Memahami struktur pesan membantu memprioritaskan tindakan respons dan menentukan strategi pemulihan yang tepat.

4.1.3 Pesan Informasi dan Peringatan Umum

Tidak semua keluaran DBCC CHECKDB menunjukkan masalah serius. Output tersebut juga dapat menampilkan beberapa pesan informasi dan peringatan, termasuk:

• Pernyataan perbaikan – Pesan yang menyarankan perintah perbaikan untuk memperbaiki masalah kecil
• Peringatan alokasi – Peringatan tentang alokasi ruang yang tidak memengaruhi akses data
• Rekomendasi kinerja – Saran untuk pemeliharaan dan pengoptimalan indeks
• Pemberitahuan informasi – Pesan status umum yang tidak memerlukan tindakan segera

Pesan-pesan ini memberikan panduan pemeliharaan yang berharga sekaligus membedakan antara kerusakan kritis yang memerlukan tindakan segera dan masalah-masalah kecil yang dapat diatasi selama periode pemeliharaan rutin.

Contoh pesan peringatan:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 Eksekusi CHECKDB Dibatalkan

Jika CHECKDB gagal dieksekusi karena berbagai alasan, ia akan melaporkan pesan kesalahan dan menambahkan log kesalahan dengan kode status di bawah ini:

Negara	Description
0	Kesalahan nomor 8930 muncul. Ini menunjukkan adanya kerusakan pada metadata yang menghentikan perintah DBCC.
1	Kesalahan nomor 8967 muncul. Terjadi kesalahan DBCC internal.
2	Kegagalan terjadi selama perbaikan basis data mode darurat.
3	Ini menunjukkan adanya kerusakan pada metadata yang menghentikan perintah DBCC.
4	Pelanggaran pernyataan atau akses terdeteksi.
5	Terjadi kesalahan tak dikenal yang menghentikan perintah DBCC.

Contoh pesan kesalahan:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

or

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Contoh log kesalahan:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Dalam kasus seperti ini, Anda dapat mencoba opsi lanjutan alternatif seperti DataNumen SQL Recovery untuk memperbaiki kerusakan pada pangkalan data Anda.

5. Memperbaiki Kesalahan Korupsi

5.1 Backup dan Restore: Solusi Paling Aman

Ketika DBCC CHECKDB mengidentifikasi kesalahan korupsi, memulihkan dari cadangan yang bersih merupakan cara yang paling aman dan efektif untuk memulihkan dari cadangan yang bersih.ost solusi yang andal. Pendekatan ini menjamin integritas data sekaligus menghilangkan penyebab kerusakan yang mendasarinya. Sebelum memulihkan, verifikasi integritas cadangan menggunakan KEMBALIKAN HANYA VERIFIKASI perintah, dan pertimbangkan opsi pemulihan point-in-time untuk meminimalkan kehilangan data. Dokumentasikan detail kerusakan untuk analisis akar penyebab, karena masalah perangkat keras atau bug perangkat lunak mungkin memerlukan perhatian tambahan untuk mencegah terulangnya kembali.

5.2 Solusi Korupsi Tingkat Halaman

Untuk kerusakan halaman terisolasi yang memengaruhi sebagian data kecil, SQL Server Enterprise Edition menawarkan kemampuan pemulihan halaman yang memperbaiki halaman tertentu yang rusak tanpa pemulihan basis data secara menyeluruh. Teknik canggih ini memerlukan model pemulihan menyeluruh dan pencadangan log terkini.

Proses pemulihan halaman langkah demi langkah:

1. Identifikasi halaman yang rusak dari pesan kesalahan CHECKDB (misalnya, halaman 1:256)
2. Ambil cadangan log saat ini untuk menangkap transaksi terkini:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Pulihkan halaman yang rusak dari most cadangan lengkap terkini:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Terapkan cadangan diferensial (jika tersedia):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Terapkan semua cadangan log secara berurutan, termasuk yang baru saja dibuat:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Ambil cadangan log akhir dan pulihkan untuk memperbarui halaman:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternatif untuk data yang tidak penting: Jika kerusakan memengaruhi data yang tidak penting, Anda dapat mengekspor baris yang tidak terpengaruh ke tabel baru sebelum membangun kembali struktur yang rusak:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Perbaikan Cepat Korupsi Indeks

Kerusakan indeks sering kali merespons dengan baik operasi pembangunan kembali yang menciptakan kembali struktur indeks tanpa memengaruhi data tabel yang mendasarinya:

ALTER INDEX ALL ON YourTable REBUILD

Pendekatan ini bekerja dengan sangat baik untuk kerusakan indeks non-klaster, karena pembangunan kembali akan menghasilkan kembali halaman indeks dari data tabel sumber, yang secara efektif menghilangkan kerusakan sambil mempertahankan semua informasi asli.

6. Gunakan REPAIR_REBUILD dan REPAIR_ALLOW_DATA_LOSS

Jika semua metode sebelumnya gagal atau tidak dapat dilakukan, Anda dapat menggunakan opsi REPAIR_REBUILD dan REPAIR_ALLOW_DATA_LOSS untuk memperbaiki basis data.

6.1 REPAIR_REBUILD (Pilihan yang Lebih Aman):

• Digunakan untuk: Korupsi indeks dan kesalahan alokasi kecil
• Keamanan data: Mencoba perbaikan kerusakan tanpa menghapus data
• Tingkat risiko: Rendah – tidak ada kehilangan data yang diharapkan
• Skenario umum: Kerusakan indeks non-cluster, masalah metadata minor
• Contoh perintah: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Pilihan Terakhir):

• Digunakan untuk: Korupsi parah ketika cadangan tidak tersedia
• Keamanan data: Dapat menghapus data yang rusak untuk memulihkan fungsionalitas basis data
• Tingkat risiko: Tinggi – kemungkinan kehilangan data permanen
• Skenario umum: Kerusakan halaman, kerusakan tabel sistem, kesalahan rantai alokasi
• Contoh perintah: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Praktik Terbaik untuk Opsi Ini:

• Selalu uji operasi perbaikan pada salinan basis data bila memungkinkan
• Selalu melakukan backup sebelum menjalankan opsi ini
• Dokumentasikan semua perubahan untuk tujuan kepatuhan dan pemecahan masalah
• Atur database ke mode pengguna tunggal sebelum menjalankan operasi perbaikan

Biasanya, kita harus mencoba PERBAIKI_BANGUN KEMBALI pilihan pertama. Jika gagal, maka coba PERBAIKAN_ALLOW_DATA_LOSS .

6.4 Hasil REPAIR_ALLOW_DATA_LOSS

6.4.1 Perbaikan Berhasil dengan Kehilangan Data

Terkadang PERBAIKAN_ALLOW_DATA_LOSS opsi akan berhasil, tetapi beberapa data lost setelah perbaikan.

Berikut beberapa contoh pesan:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Hal ini karena DBCC CHECKDB memperbaiki database dengan meninggalkan beberapa catatan yang rusak, tetapi sebenarnya, most beberapa di antaranya masih bisa dipulihkan melalui DataNumen SQL Recovery.

Contoh file:

SQL Server versi	File MDF rusak	File MDF diperbaiki oleh DataNumen SQL Recovery
SQL Server 2014	Kesalahan10_1.mdf (Pesan 8909 diikuti oleh Pesan 8939) (600 catatan lost dengan REPAIR_ALLOW_DATA_LOSS)	Kesalahan10_1_fixed.mdf (Tidak ada catatan lost)
SQL Server 2014	Kesalahan10_2.mdf (Pesan 8909 diikuti oleh Pesan 8939) (6000 catatan (50%) lost dengan REPAIR_ALLOW_DATA_LOSS)	Kesalahan10_2_fixed.mdf (Hanya 100 catatan lost)
SQL Server 2014	Kesalahan 7.mdf (100 catatan lost dengan REPAIR_ALLOW_DATA_LOSS)	Kesalahan7_fixed.mdf (Hanya satu catatan lost)

6.4.2 Perbaikan Gagal – Pertimbangkan Solusi Profesional

If PERBAIKAN_ALLOW_DATA_LOSS gagal, maka akan muncul satu atau beberapa pesan kesalahan.

Di bawah ini beberapa contohnya:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Dalam skenario ini, Anda perlu menggunakan solusi profesional seperti DataNumen SQL Recovery untuk memperbaiki basis data Anda.

Contoh File

SQL Server versi	File MDF rusak	File MDF diperbaiki oleh DataNumen SQL Recovery
SQL Server 2014	Kesalahan1_3.mdf (Pesan Tunggal 824)	Kesalahan1_3_fixed.mdf
SQL Server 2014	Kesalahan1_1.mdf (Kesalahan Pesan Berkelanjutan 824)	Kesalahan1_1_fixed.mdf
SQL Server 2014	Kesalahan1_2.mdf ((Pesan 824 diikuti oleh Pesan 7909)	Kesalahan1_2_fixed.mdf
SQL Server 2014	Kesalahan4_1.mdf (Pesan 8992 diikuti oleh Pesan 3852)	Kesalahan4_1_fixed.mdf
SQL Server 2014	Kesalahan4_2.mdf (Pesan 8992 diikuti oleh Pesan 3852)	Kesalahan4_2_fixed.mdf
SQL Server 2014	Kesalahan5.mdf (Pesan 8945)	Kesalahan5_fixed.mdf
SQL Server 2014	Kesalahan6.mdf (Pesan 2510)	Kesalahan6_fixed.mdf
SQL Server 2014	Kesalahan2.mdf (Pesan 2575)	Kesalahan2_fixed.mdf
SQL Server 2014	Kesalahan11.mdf (Pesan 8905)	Kesalahan11_fixed.mdf
SQL Server 2014	Kesalahan3.mdf (Pesan 5028)	Kesalahan3_fixed.mdf
SQL Server 2014	Kesalahan 8.mdf (Pesan 5125)	Kesalahan 8_fixed.mdf
SQL Server 2014	Kesalahan9.mdf (Pesan 3313)	Kesalahan9_fixed.mdf

7. Praktik Terbaik

7.1 Penjadwalan Operasi CHECKDB Reguler

Terapkan eksekusi DBCC CHECKDB mingguan untuk basis data produksi penting, dengan pemeriksaan harian untuk sistem dengan transaksi tinggi. Jadwalkan operasi selama periode penggunaan rendah untuk meminimalkan dampak kinerja, dan pertimbangkan untuk melakukan rotasi antara pemeriksaan penuh dan opsi PHYSICAL_ONLY berdasarkan ukuran basis data dan jendela pemeliharaan. Penjadwalan otomatis melalui SQL Server Agen memastikan eksekusi yang konsisten sekaligus menyediakan kemampuan pemantauan dan peringatan yang terpusat.

7.2 Manajemen Dampak Kinerja

Operasi DBCC CHECKDB menghabiskan sumber daya sistem yang signifikan, yang berpotensi memengaruhi aktivitas pengguna secara bersamaan. Pantau penggunaan CPU, konsumsi memori, dan I/O disk selama pemeriksaan untuk memahami pola dampak kinerja. Pertimbangkan untuk menggunakan opsi NOINDEX untuk pemeriksaan rutin, dengan menyediakan validasi penuh untuk jendela pemeliharaan bulanan. Terapkan perpanjangan batas waktu kueri dan strategi komunikasi pengguna untuk mengelola ekspektasi selama periode pemeriksaan integritas.

7.3 Perencanaan Jendela Pemeliharaan

Koordinasikan penjadwalan DBCC CHECKDB dengan aktivitas pemeliharaan lainnya seperti operasi pencadangan, penyusunan ulang indeks, dan pembaruan statistik. Hindari operasi yang membutuhkan banyak sumber daya yang dapat menyebabkan penurunan kinerja atau masalah batas waktu. Rencanakan jendela pemeliharaan berdasarkan proyeksi pertumbuhan ukuran basis data, pastikan waktu yang cukup untuk verifikasi integritas lengkap seiring dengan peningkatan volume data.

7.4 Pemantauan dan Peringatan Otomatis

Konfigurasi SQL Server Agen memberikan peringatan untuk segera memberi tahu administrator saat DBCC CHECKDB mengidentifikasi kerusakan. Terapkan solusi penguraian log yang mengekstrak dan mengkategorikan hasil pemeriksaan integritas, yang memungkinkan analisis tren dan identifikasi masalah secara proaktif. Buat prosedur eskalasi yang menentukan kerangka waktu respons dan personel yang bertanggung jawab untuk berbagai tingkat keparahan kerusakan.

8. DBCC CHECKTABLE: Alternatif Ringan

8.1 Kapan Menggunakan CHECKTABLE Daripada CHECKDB

DBCC CHECKTABLE menyediakan pemeriksaan integritas terfokus untuk tabel individual, menjadikannya ideal untuk tarmendapatkan pemecahan masalah dan pemeliharaan objek basis data tertentu. Gunakan CHECKTABLE saat menyelidiki masalah kinerja dengan tabel tertentu, memvalidasi tabel bisnis penting di antara pemeriksaan basis data lengkap, atau saat kendala waktu mencegah validasi basis data lengkap. Pendekatan ini terbukti sangat berharga dalam basis data besar di mana operasi CHECKDB lengkap melebihi jendela pemeliharaan yang tersedia.

8.2 Sintaks dan Contoh DBCC CHECKTABLE

Perintah dasar CHECKTABLE tarmendapatkan tabel tertentu:

DBCC CHECKTABLE('YourTable')

Seperti CHECKDB, CHECKTABLE mendukung berbagai opsi termasuk NOINDEX untuk pengoptimalan kinerja dan parameter perbaikan untuk penyelesaian kerusakan. Anda juga dapat menentukan nama skema untuk identifikasi tabel yang tepat:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Kredensial mikro tarPendekatan yang didapat memungkinkan verifikasi integritas terperinci sambil tetap menjaga kinerja sistem selama jam kerja.

8.3 Manfaat Kinerja untuk Basis Data Besar

Operasi CHECKTABLE selesai jauh lebih cepat daripada pemeriksaan basis data penuh, yang memungkinkan verifikasi integritas tabel-tabel penting lebih sering. Pendekatan ini memungkinkan validasi harian tabel-tabel bisnis penting sambil menyediakan operasi CHECKDB yang komprehensif untuk jadwal mingguan atau bulanan. Konsumsi sumber daya yang berkurang membuat CHECKTABLE cocok untuk eksekusi lingkungan produksi dengan dampak pengguna yang minimal.

9. Ketika CHECKDB Gagal

DBCC CHECKDB akan gagal dalam berbagai skenario, termasuk:

• Eksekusi DBCC CHECKDB berakhir secara tidak normal
• Eksekusi DBCC CHECKDB berhasil diselesaikan, tetapi opsi perbaikan gagal memperbaiki basis data.

Dalam skenario ini, kita memerlukan alat yang lebih profesional untuk membantu kita memperbaiki kerusakan dalam basis data.

9.1 Pengantar DataNumen SQL Recovery

DataNumen SQL Recovery menyediakan kemampuan yang lebih canggih:

• Tingkat pemulihan terbaik di industri.
• Memulihkan berkas basis data yang rusak parah.
• Pulihkan semua objek basis data, termasuk tabel, indeks, tampilan, pemicu, aturan, dan default.
• Pulihkan prosedur tersimpan, fungsi skalar, fungsi bernilai tabel inline, dan fungsi bernilai tabel multipernyataan.
• Memulihkan rekaman yang dihapus secara permanen.
• Dekripsi objek terenkripsi di SQL Server database.
• Memperbaiki berkas MDF secara batch.
• Opsi perbaikan yang komprehensif.
• Pencatatan dan pelaporan tingkat lanjut.
• Dukungan untuk semua SQL Server versi.
• Ketersediaan dukungan teknis
• Pembaruan dan peningkatan rutin

9.2 Perbandingan Tingkat Keberhasilan

Tingkat keberhasilan pemulihan berbeda secara signifikan:

• DBCC CHECKDB & TABEL PERIKSA: 1.27% tingkat pemulihan rata-rata
• DataNumen: 92.6% tingkat pemulihan

Berikut ini adalah perbandingan kompetitif yang lengkap:

9.3 Pemulihan dari Korupsi Berat

Kemampuan tingkat lanjut untuk kasus parah:

• Pemulihan dari penyimpanan yang rusak secara fisik
• Pemulihan dari drive yang diformat atau sistem yang rusak
• Pulihkan dari gambar disk, file cadangan, file disk mesin virtual, temporarfile y, dll.

9.4 Kapan Harus Mempertimbangkan Solusi Profesional

• Tidak ada ketersediaan cadangan terbaru
• DBCC CHECKDB gagal
• Skenario korupsi yang parah
• Berurusan dengan data bisnis penting
• Ketika waktu sangat penting
• Ketika pemulihan maksimal sangat penting

10. Tanya Jawab

11. Kesimpulan

11.1 Ringkasan Poin-Poin Utama

11.1.1 Ringkasan Perintah DBCC CHECKDB yang Penting

Kuasai sintaks DBCC CHECKDB dasar untuk pemeriksaan database yang komprehensif, manfaatkan opsi NOINDEX dan PHYSICAL_ONLY untuk pengoptimalan kinerja, dan pahami CHECKTABLE untuk tarverifikasi tabel geted. Perintah-perintah dasar ini membentuk dasar pemeliharaan basis data proaktif, yang memungkinkan deteksi kerusakan dini dan pemantauan integritas sistematis.

11.1.2 Pengingat Praktik Terbaik yang Penting

Selalu pertahankan cadangan terkini sebelum menjalankan pemeriksaan integritas, jadwalkan operasi CHECKDB rutin berdasarkan kekritisan basis data, dan terapkan pemantauan otomatis untuk peringatan kerusakan segera. Ingat bahwa pencegahan melalui pemantauan rutin melampaui pendekatan reaktif, dan solusi pemulihan profesional menyediakan opsi cadangan yang berharga saat alat standar terbukti tidak memadai.

11.2 Kapan Menggunakan DBCC CHECKDB vs. Solusi Lanjutan

Gunakan DBCC CHECKDB untuk pemantauan integritas rutin dan penyelesaian kerusakan kecil, sembari menyediakan alat pemulihan profesional untuk skenario kerusakan parah di luar kemampuan perbaikan bawaan. Kerangka kerja pengambilan keputusan harus mempertimbangkan ketersediaan cadangan, kekritisan data, batasan waktu, dan tingkat keparahan kerusakan. Administrator basis data yang sukses menggabungkan pemantauan CHECKDB rutin dengan strategi cadangan komprehensif dan kesadaran akan opsi pemulihan lanjutan saat pendekatan standar terbukti tidak memadai.

12. Referensi

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server Dokumentasi. Microsoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Memecahkan masalah kesalahan konsistensi basis data yang dilaporkan oleh DBCC CHECKDB.” SQL Server Dokumentasi. Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors