DBCC CHECKDB: Kumpletong Gabay sa MS SQL Server Kalusugan ng Database (2026)

Ang DBCC CHECKDB ay SQL ServerAng pangunahing tool sa integridad ng database. Matutunan kung paano ito gamitin kasama ng mga halimbawa, ayusin ang katiwalian, at i-optimize ang performance.

3. Pagpapatakbo ng DBCC CHECKDB: Step-by-Step

Mga Kinakailangan ng 3.1

Nasa ibaba ang checklist bago isagawa ang anumang operasyon ng DBCC CHECKDB:

• Kumpletuhin ang backup ng database – Gumawa ng isang buong backup bago magpatakbo ng mga pagsusuri sa integridad bilang iyong safety net kung may natuklasang katiwalian o kinakailangan ang mga operasyon sa pagkukumpuni.
• Mga wastong pahintulot – Kailangan mo ng mga pahintulot ng sysadmin o db_owner upang maisagawa ang mga utos ng DBCC CHECKDB
• Sapat na mapagkukunan ng system:
  • Memorya: 25% ng laki ng database
  • Tempdb space: 10-15% ng laki ng database
  • CPU: 50-70% availability sa panahon ng maintenance
  • I/O: Asahan ang mabibigat na operasyon sa pagbasa
• Accessibility sa database – I-verify na ang iyong database ay naa-access at wala sa isang pinaghihigpitang estado, dahil ang CHECKDB ay nangangailangan ng read access sa lahat ng mga pahina ng database

3.2 Pangunahing Utos

M Angost Kasama sa pangunahing DBCC CHECKDB command ang tatlong karaniwang variation:

(1) Suriin ang kasalukuyang database (walang mga parameter):

DBCC CHECKDB

(2) Suriin ang isang database ayon sa pangalan:

DBCC CHECKDB ('YourDatabaseName')

(3) Suriin ang isang database sa pamamagitan ng ID:

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

Ang pangunahing utos na ito ay nagsasagawa ng kumpletong pagsusuri sa integridad ng tinukoy na database, sinusuri ang lahat ng mga talahanayan, index, at istruktura ng system. Para sa mga database na may mga karaniwang pangalan na walang mga puwang, maaari mong alisin ang mga quote. Ang utos ay tatakbo hanggang sa makumpleto, na nagpapakita ng mga mensahe ng pag-unlad at mga huling resulta. Ang pangunahing syntax na ito ay gumagana nang perpekto para sa mas maliliit na database o kapag mayroon kang sapat na oras ng pagpapanatili na magagamit.

Nasa ibaba ang isang screenshot ng pagpapatakbo ng DBCC CHECKDB in SQL Server Management Studio (SSMS):

3.3 Kumpletuhin ang mga Opsyon

Nasa ibaba ang kumpletong mga opsyon para sa DBCC CHECKDB:

kategorya	Opsyon	paglalarawan	Halimbawa ng DBCC CHECKDB
Mga Pagpipilian sa Pag-ayos	REPAIR_REBUILD	Mga pag-aayos nang walang pagkawala ng data (hal., muling pagtatayo ng index)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Walang repair. Backward compatibility lang	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Inaayos ang lahat ng mga error (maaaring magdulot ng pagkawala ng data)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Pagkontrol sa Saklaw	NOINDEX	Nilalaktawan ang mga nonclustered index checks	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Sinusuri lamang ang integridad ng pisikal na storage (mga pahina/tala)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Sinusuri para sa mga lohikal na column-value error (hal., mga di-wastong petsa)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Mga malalim na lohikal na pagsusuri (mga na-index na view, XML/spatial na mga index)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kontrol sa Output	ALL_ERRORMSGS	Ipinapakita ang lahat ng mga error (default: 200 bawat bagay)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Itinatago ang mga mensaheng nagbibigay-kaalaman	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
pagganap	TABLOCK	Gumagamit ng mga lock ng talahanayan (binabawasan ang paggamit ng TempDB ngunit nagsusulat ng mga bloke)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Ino-override ang mga setting ng parallelism	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Gamit	ESTIMATEONLY	Tinatantya ang TempDB space na kailangan. (walang aktwal na tseke)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Pag-unawa sa Iyong Mga Resulta

Magbibigay ang DBCC CHECKDB ng iba't ibang resulta batay sa kung matagumpay na nakumpleto ang pagpapatupad nito o hindi. Ipaliwanag natin ang mga ito nang detalyado.

4.1 Matagumpay na Nakumpleto ang Pagpapatupad ng CHECKDB

Kung matagumpay na nakumpleto ang pagpapatupad ng DBCC CHECKDB, mag-uulat ito ng iba't ibang uri ng mga resulta depende sa status ng kalusugan ng iyong database.

4.1.1 Walang Nahanap na Isyu

Kung ang DBCC CHECKDB ay walang mahanap na anumang isyu, makikita mo ang output na katulad ng:

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

Ang resultang ito ay nagpapahiwatig na ang iyong database ay nagpapanatili ng perpektong integridad sa lahat ng mga naka-check na istruktura.

4.1.2 Nakakita ng mga Error sa Korapsyon

Sa tuwing may nakitang error sa katiwalian ang DBCC CHECKDB, mag-uulat ito ng mensahe ng error na may sumusunod na istraktura:
Gabay sa Antas ng Kalubhaan:

• Antas 16-19: Mga error na natatama ng user, kadalasang maliit na katiwalian
• Antas 20-24: Mga error sa system, malubhang katiwalian na nangangailangan ng agarang atensyon
• Antas 25: Mga nakamamatay na error, maaaring hindi ma-access ang database

Kasama sa mga karaniwang error ang:

• Mga pagkabigo sa checksum ng page (mensahe 824)
• Mga error sa alokasyon (mensahe 8928)
• Mga problema sa pagkakapare-pareho ng index (mensahe 8964)

Ang pag-unawa sa istraktura ng mensahe ay nakakatulong na bigyang-priyoridad ang mga aksyon sa pagtugon at matukoy ang mga naaangkop na diskarte sa pagbawi.

4.1.3 Mga Karaniwang Mensahe na Pang-impormasyon at Babala

Hindi lahat ng output ng DBCC CHECKDB ay nagpapahiwatig ng mga seryosong problema. Maaari rin itong maglabas ng ilang mensaheng nagbibigay-kaalaman at babala, kabilang ang:

• Mga pahayag sa pag-aayos – Mga mensahe na nagmumungkahi ng mga utos sa pag-aayos para sa pag-aayos ng mga maliliit na isyu
• Mga babala sa alokasyon – Mga babala tungkol sa paglalaan ng espasyo na hindi nakakaapekto sa pag-access ng data
• Mga rekomendasyon sa pagganap – Mga mungkahi para sa pagpapanatili at pag-optimize ng index
• Mga abiso sa impormasyon – Mga pangkalahatang mensahe ng katayuan na hindi nangangailangan ng agarang aksyon

Ang mga mensaheng ito ay nagbibigay ng mahalagang gabay sa pagpapanatili habang tinutukoy ang pagkakaiba sa pagitan ng kritikal na katiwalian na nangangailangan ng agarang aksyon at mga maliliit na isyu na maaaring matugunan sa panahon ng regular na mga window ng pagpapanatili.

Halimbawang mensahe ng babala:

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 Ipinaabort ang Pagpapatupad ng CHECKDB

Kung abort ang CHECKDB sa panahon ng pagpapatupad nito dahil sa iba't ibang dahilan, mag-uulat ito ng mensahe ng error at magdaragdag ng log ng error na may code ng estado sa ibaba:

estado	paglalarawan
0	Itinaas ang error number 8930. Ito ay nagpapahiwatig ng katiwalian sa metadata na nagwakas sa utos ng DBCC.
1	Itinaas ang error number 8967. Nagkaroon ng panloob na error sa DBCC.
2	Naganap ang isang pagkabigo sa panahon ng pag-aayos ng database ng emergency mode.
3	Ito ay nagpapahiwatig ng katiwalian sa metadata na nagwakas sa utos ng DBCC.
4	May nakitang paggiit o paglabag sa pag-access.
5	May naganap na hindi kilalang error na nagwakas sa utos ng DBCC.

Halimbawang mensahe ng error:

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'.

Halimbawang log ng error:

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.

Sa ganoong sitwasyon, maaari mong subukan ang mga alternatibong advanced na opsyon tulad ng DataNumen SQL Recovery upang ayusin ang katiwalian sa iyong database.

5. Pag-aayos ng mga Error sa Korapsyon

5.1 Pag-backup at Pagpapanumbalik: Ang Pinakaligtas na Pag-aayos

Kapag natukoy ng DBCC CHECKDB ang mga error sa katiwalian, ang pagpapanumbalik mula sa isang malinis na backup ay kumakatawan sa pinakaligtas at most maaasahang solusyon. Ginagarantiyahan ng diskarteng ito ang integridad ng data habang inaalis ang mga pinagbabatayan na sanhi ng katiwalian. Bago i-restore, i-verify ang backup na integridad gamit Ibalik ang VERIFYONLY command, at isaalang-alang ang mga opsyon sa pagbawi ng point-in-time upang mabawasan ang pagkawala ng data. Idokumento ang mga detalye ng katiwalian para sa pagsusuri sa ugat, dahil ang mga isyu sa hardware o software bug ay maaaring mangailangan ng karagdagang pansin upang maiwasan ang pag-ulit.

5.2 Mga Solusyon sa Korapsyon sa Antas ng Pahina

Para sa mga nakahiwalay na page corruption na nakakaapekto sa maliliit na bahagi ng data, SQL Server Nag-aalok ang Enterprise Edition ng mga kakayahan sa pagpapanumbalik ng pahina na nag-aayos ng mga partikular na nasirang pahina nang walang kumpletong pagpapanumbalik ng database. Ang advanced na pamamaraan na ito ay nangangailangan ng ganap na modelo ng pagbawi at kasalukuyang mga backup ng log.

Hakbang-hakbang na proseso ng pagpapanumbalik ng pahina:

1. Kilalanin ang sira na pahina mula sa mensahe ng error ng CHECKDB (hal., pahina 1:256)
2. Kumuha ng kasalukuyang backup ng log para makuha ang mga kamakailang transaksyon:

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

3. Ibalik ang sira na pahina mula sa most kamakailang buong backup:

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

4. Ilapat ang differential backup (kung bakante):

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

5. Ilapat ang lahat ng backup ng log sa pagkakasunud-sunod, kasama ang kakalikha lang:

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. Kumuha ng panghuling backup ng log at i-restore upang dalhin ang pahina sa kasalukuyan:

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

Alternatibo para sa hindi kritikal na data: Kung makakaapekto ang katiwalian sa hindi kritikal na data, maaari mong i-export ang mga hindi apektadong row sa mga bagong talahanayan bago muling buuin ang mga sira na istruktura:

-- 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 Mga Mabilisang Pag-aayos ng Index Corruption

Ang katiwalian sa index ay madalas na tumutugon nang maayos sa muling pagtatayo ng mga operasyon na muling likhain ang mga istruktura ng index nang hindi naaapektuhan ang pinagbabatayan ng data ng talahanayan:

ALTER INDEX ALL ON YourTable REBUILD

Ang diskarte na ito ay partikular na mahusay na gumagana para sa hindi clustered index corruption, dahil ang muling pagbuo ay muling bumubuo ng mga index page mula sa source table data, na epektibong nag-aalis ng katiwalian habang pinapanatili ang lahat ng orihinal na impormasyon.

6. Gamitin ang REPAIR_REBUILD at REPAIR_ALLOW_DATA_LOSS

Kung ang mga nakaraang pamamaraan ay nabigo o hindi magagawa, maaari mong gamitin ang mga opsyon na REPAIR_REBUILD at REPAIR_ALLOW_DATA_LOSS upang ayusin ang database.

6.1 REPAIR_REBUILD (Mas Ligtas na Opsyon):

• Gamitin para sa: I-index ang katiwalian at maliliit na pagkakamali sa alokasyon
• Kaligtasan ng data: Sinusubukang ayusin ang katiwalian nang walang pagtanggal ng data
• Antas ng panganib: Mababa – walang inaasahang pagkawala ng data
• Mga karaniwang senaryo: Non-clustered index corruption, menor de edad na isyu sa metadata
• Halimbawa ng utos: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Huling Resort):

• Gamitin para sa: Matinding katiwalian kapag hindi available ang mga backup
• Kaligtasan ng data: Maaaring tanggalin ang sirang data upang maibalik ang functionality ng database
• Antas ng panganib: Mataas - posible ang permanenteng pagkawala ng data
• Mga karaniwang senaryo: Korapsyon sa page, pagkasira ng system table, mga error sa chain ng alokasyon
• Halimbawa ng utos: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Pinakamahuhusay na Kasanayan para sa Mga Opsyon na Ito:

• Laging sumubok mga pagpapatakbo ng pagkumpuni sa mga kopya ng database kapag posible
• Laging naka-back up bago patakbuhin ang mga pagpipiliang ito
• Idokumento ang lahat ng pagbabago para sa mga layunin ng pagsunod at pag-troubleshoot
• Itakda ang database sa single-user mode bago patakbuhin ang mga operasyon sa pagkukumpuni

Karaniwan, dapat nating subukan REPAIR_REBUILD option muna. Kung nabigo ito, pagkatapos ay subukan REPAIR_ALLOW_DATA_LOSS pagpipilian.

6.4 REPAIR_ALLOW_DATA_LOSS Resulta

6.4.1 Nagtagumpay ang Pag-aayos sa Pagkawala ng Data

Minsan ang REPAIR_ALLOW_DATA_LOSS ang opsyon ay magtatagumpay, ngunit ang ilang data ay lost pagkatapos ng pagkumpuni.

Nasa ibaba ang ilang sample na mensahe:

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.

Ito ay dahil inaayos ng DBCC CHECKDB ang database sa pamamagitan ng pag-abandona sa ilang mga nasirang rekord, ngunit sa totoo lang, most sa kanila ay maaari pa ring mabawi sa pamamagitan ng DataNumen SQL Recovery.

Mga sample na file:

SQL Server bersyon	Masirang MDF file	Ang MDF file ay naayos ng DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Msg 8909 na sinusundan ng Msg 8939) (600 records lost may REPAIR_ALLOW_DATA_LOSS)	Error10_1_fixed.mdf (Walang record lost)
SQL Server 2014	Error10_2.mdf (Msg 8909 na sinusundan ng Msg 8939) (6000 records(50%) lost may REPAIR_ALLOW_DATA_LOSS)	Error10_2_fixed.mdf (100 records lang lost)
SQL Server 2014	Error7.mdf (100 tala lost may REPAIR_ALLOW_DATA_LOSS)	Error7_fixed.mdf (Isang record lang lost)

6.4.2 Nabigo ang Pag-aayos – Isaalang-alang ang Propesyonal na Solusyon

If REPAIR_ALLOW_DATA_LOSS nabigo, maglalabas ito ng isa o maraming mensahe ng error.

Nasa ibaba ang ilang mga halimbawa:

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.

Sa mga sitwasyong ito, kailangan mong gumamit ng propesyonal na solusyon tulad ng DataNumen SQL Recovery upang ayusin ang iyong database.

Mga Sample na File

SQL Server bersyon	Masirang MDF file	Ang MDF file ay naayos ng DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (Single Msg 824)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (Continuous Msg 824 errors)	Error1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((Msg 824 na sinundan ng Msg 7909)	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (Msg 8992 na sinundan ng Msg 3852)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (Msg 8992 na sinundan ng Msg 3852)	Error4_2_fixed.mdf
SQL Server 2014	Error5.mdf (Msg 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (Msg 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (Msg 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (Msg 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (Msg 5028)	Error3_fixed.mdf
SQL Server 2014	Error8.mdf (Msg 5125)	Error8_fixed.mdf
SQL Server 2014	Error9.mdf (Msg 3313)	Error9_fixed.mdf

7. Pinakamahuhusay na Kasanayan

7.1 Pag-iiskedyul ng Mga Regular na Operasyon ng CHECKDB

Ipatupad ang lingguhang DBCC CHECKDB execution para sa mga kritikal na database ng produksyon, na may araw-araw na pagsusuri para sa mga high-transaction system. Mag-iskedyul ng mga operasyon sa panahon ng mababang paggamit upang mabawasan ang epekto sa pagganap, at isaalang-alang ang pag-ikot sa pagitan ng mga buong pagsusuri at PHYSICAL_ONLY na mga opsyon batay sa laki ng database at mga window ng pagpapanatili. Sa pamamagitan ng awtomatikong pag-iiskedyul SQL Server Tinitiyak ng ahente ang pare-parehong pagpapatupad habang nagbibigay ng sentralisadong kakayahan sa pagsubaybay at pag-alerto.

7.2 Pamamahala ng Epekto sa Pagganap

Ang mga pagpapatakbo ng DBCC CHECKDB ay gumagamit ng makabuluhang mapagkukunan ng system, na posibleng makaapekto sa kasabay na aktibidad ng user. Subaybayan ang paggamit ng CPU, pagkonsumo ng memorya, at disk I/O sa panahon ng mga pagsusuri upang maunawaan ang mga pattern ng epekto sa pagganap. Isaalang-alang ang paggamit ng mga opsyon sa NOINDEX para sa mga nakagawiang pagsusuri, na inireserba ang buong pagpapatunay para sa buwanang mga window ng pagpapanatili. Magpatupad ng mga extension ng timeout ng query at mga diskarte sa komunikasyon ng user para pamahalaan ang mga inaasahan sa panahon ng pagsusuri ng integridad.

7.3 Pagpaplano ng Window Pagpapanatili

I-coordinate ang pag-iskedyul ng DBCC CHECKDB sa iba pang mga aktibidad sa pagpapanatili tulad ng mga backup na operasyon, muling pagbuo ng index, at mga update sa istatistika. Iwasan ang mga overlapping na operasyong masinsinang mapagkukunan na maaaring magdulot ng pagkasira ng performance o mga isyu sa timeout. Magplano ng mga window ng pagpapanatili batay sa mga projection ng paglaki ng laki ng database, na tinitiyak ang sapat na oras para sa kumpletong pag-verify ng integridad habang tumataas ang dami ng data.

7.4 Automated Monitoring at Alerto

I-configure ang SQL Server Mga alerto ng ahente upang abisuhan kaagad ang mga administrator kapag natukoy ng DBCC CHECKDB ang katiwalian. Magpatupad ng mga solusyon sa pag-parse ng log na kumukuha at nakakategorya ng mga resulta ng pagsusuri sa integridad, nagpapagana ng pagsusuri sa trend at maagap na pagkilala sa problema. Lumikha ng mga pamamaraan ng pagdami na tumutukoy sa mga timeframe ng pagtugon at responsableng tauhan para sa iba't ibang antas ng kalubhaan ng katiwalian.

8. DBCC CHECKTABLE: The Lightweight Alternative

8.1 Kailan Gamitin ang CHECKTABLE Sa halip na CHECKDB

Ang DBCC CHECKTABLE ay nagbibigay ng nakatutok na pagsusuri sa integridad para sa mga indibidwal na talahanayan, na ginagawa itong perpekto para sa tarnakakuha ng pag-troubleshoot at pagpapanatili ng mga partikular na object ng database. Gumamit ng CHECKTABLE kapag nagsisiyasat ng mga isyu sa pagganap sa mga partikular na talahanayan, nagpapatunay ng mga kritikal na talahanayan ng negosyo sa pagitan ng buong pagsusuri sa database, o kapag pinipigilan ng mga hadlang sa oras ang kumpletong pagpapatunay ng database. Ang diskarte na ito ay nagpapatunay na mahalaga lalo na sa malalaking database kung saan ang buong CHECKDB na operasyon ay lumalampas sa mga available na maintenance window.

8.2 DBCC CHECKTABLE Syntax at Mga Halimbawa

Ang pangunahing CHECKTABLE na utos tarnakakakuha ng mga partikular na talahanayan:

DBCC CHECKTABLE('YourTable')

Tulad ng CHECKDB, sinusuportahan ng CHECKTABLE ang iba't ibang opsyon kabilang ang NOINDEX para sa pag-optimize ng pagganap at mga parameter ng pagkumpuni para sa paglutas ng katiwalian. Maaari mo ring tukuyin ang mga pangalan ng schema para sa tumpak na pagkakakilanlan ng talahanayan:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

ito tarAng geted approach ay nagbibigay-daan sa granular integrity verification habang pinapanatili ang performance ng system sa mga oras ng negosyo.

8.3 Mga Benepisyo sa Pagganap para sa Malalaking Database

Ang mga operasyon ng CHECKTABLE ay nakumpleto nang mas mabilis kaysa sa buong pagsusuri sa database, na nagpapagana ng mas madalas na pag-verify ng integridad ng mga kritikal na talahanayan. Ang diskarte na ito ay nagbibigay-daan sa pang-araw-araw na pagpapatunay ng mahahalagang talahanayan ng negosyo habang inilalaan ang mga komprehensibong operasyon ng CHECKDB para sa lingguhan o buwanang mga iskedyul. Ang pinababang pagkonsumo ng mapagkukunan ay ginagawang angkop ang CHECKTABLE para sa pagpapatupad ng kapaligiran ng produksyon na may kaunting epekto sa user.

9. Kapag Nabigo ang CHECKDB

Mabibigo ang DBCC CHECKDB sa iba't ibang mga sitwasyon, kabilang ang:

• Pagpapatupad ng DBCC CHECKDB nagwawakas nang abnormal
• Matagumpay na nakumpleto ang pagpapatupad ng DBCC CHECKDB, ngunit ang mga opsyon sa pag-aayos mabigong ayusin ang database.

Sa mga sitwasyong ito, kailangan namin ng mas propesyonal na tool upang matulungan kaming ayusin ang mga katiwalian sa database.

9.1 Panimula sa DataNumen SQL Recovery

DataNumen SQL Recovery nagbibigay ng mas advanced na mga kakayahan:

• Pinakamahusay na rate ng pagbawi sa industriya.
• I-recover ang malubhang sirang mga file ng database.
• I-recover ang lahat ng object ng database, kabilang ang mga talahanayan, index, view, trigger, panuntunan, at default.
• I-recover ang mga nakaimbak na procedure, scalar function, inline table-valued function, at multistatement table-valued function.
• I-recover ang permanenteng tinanggal na mga tala.
• I-decrypt ang mga naka-encrypt na bagay sa SQL Server mga database.
• Ayusin ang mga MDF file sa batch.
• Mga komprehensibong opsyon sa pag-aayos.
• Advanced na pag-log at pag-uulat.
• Suporta para sa lahat SQL Server mga bersyon.
• availability ng teknikal na suporta
• Mga regular na pag-update at pagpapabuti

9.2 Paghahambing ng Rate ng Tagumpay

Malaki ang pagkakaiba ng mga rate ng tagumpay sa pagbawi:

• DBCC CHECKDB & CHECKTABLE: 1.27% average na rate ng pagbawi
• DataNumen: 92.6% rate ng pagbawi

Nasa ibaba ang isang kumpletong mapagkumpitensyang paghahambing:

9.3 Pagbawi mula sa Matinding Korapsyon

Mga advanced na kakayahan para sa malalang kaso:

• Pagbawi mula sa pisikal na napinsalang imbakan
• Pagbawi mula sa mga na-format na drive o nag-crash na system
• Mabawi mula sa mga imahe sa disk, backup na file, virtual machine disk file, temporary file, atbp.

9.4 Kailan Dapat Isaalang-alang ang Propesyonal na Solusyon

• Walang kamakailang magagamit na backup
• Nabigo ang DBCC CHECKDB
• Matinding senaryo ng korapsyon
• Pagharap sa kritikal na data ng negosyo
• Kapag kritikal ang oras
• Kapag ang maximum na pagbawi ay mahalaga

10. Mga FAQ

11. Konklusyon

11.1 Buod ng Mga Pangunahing Punto

11.1.1 Mahahalagang DBCC CHECKDB Commands Recap

Master ang basic DBCC CHECKDB syntax para sa komprehensibong database checking, gamitin ang NOINDEX at PHYSICAL_ONLY na mga opsyon para sa performance optimization, at unawain ang CHECKTABLE para sa tarnakakuha ng pag-verify ng talahanayan. Ang mga pangunahing utos na ito ay bumubuo ng pundasyon ng maagap na pagpapanatili ng database, na nagbibigay-daan sa maagang pagtuklas ng katiwalian at sistematikong pagsubaybay sa integridad.

11.1.2 Paalala sa Mga Kritikal na Pinakamahuhusay na Kasanayan

Palaging panatilihin ang mga kasalukuyang backup bago patakbuhin ang mga pagsusuri sa integridad, mag-iskedyul ng mga regular na operasyon ng CHECKDB batay sa kritikalidad ng database, at magpatupad ng awtomatikong pagsubaybay para sa agarang mga alerto sa katiwalian. Tandaan na ang pag-iwas sa pamamagitan ng regular na pagsubaybay ay lumalampas sa mga reaktibong diskarte, at ang mga propesyonal na solusyon sa pagbawi ay nagbibigay ng mahalagang backup na opsyon kapag hindi sapat ang mga karaniwang tool.

11.2 Kailan Gamitin ang DBCC CHECKDB kumpara sa Mga Advanced na Solusyon

Gamitin ang DBCC CHECKDB para sa regular na pagsubaybay sa integridad at paglutas ng maliit na katiwalian, habang inilalaan ang mga propesyonal na tool sa pagbawi para sa mga sitwasyon ng matinding katiwalian na lampas sa built-in na mga kakayahan sa pagkumpuni. Dapat isaalang-alang ng balangkas ng desisyon ang pagkakaroon ng backup, pagiging kritikal ng data, mga hadlang sa oras, at kalubhaan ng katiwalian. Pinagsasama ng matagumpay na database administrator ang regular na pagsubaybay ng CHECKDB sa mga komprehensibong backup na estratehiya at kaalaman sa mga advanced na opsyon sa pagbawi kapag hindi sapat ang mga karaniwang diskarte.

11.3 Mabilis na Pang-araw-araw na Checklist ng Kalusugan para sa mga DBA

Higit pa sa pagpapatakbo ng DBCC CHECKDB, panatilihin ang pinakamainam na kalusugan ng database gamit ang mahahalagang pang-araw-araw na kasanayang ito:

1. I-verify ang Backup Integrity

• Kumpirmahin na matagumpay na nakumpleto ang mga naka-iskedyul na backup
• Gamitin ang RESTORE VERIFYONLY upang i-verify ang pagiging madaling mabasa ng backup
• Tiyaking naka-synchronize at naa-access ang mga offsite na kopya

Maaari ka ring makakuha ng karagdagang impormasyon mula sa ang aming komprehensibong gabay sa SQL Server backup.

2. Suriin ang Katayuan ng Consistency

• Suriin ang mga awtomatikong resulta ng DBCC CHECKDB mula sa mga overnight run
• Monitor SQL Server mga error log para sa mga babala sa katiwalian
• Siyasatin kaagad ang anumang mga pagkabigo sa integridad

3. Subaybayan ang Kalusugan ng Server

• Suriin ang mga sukatan ng CPU, memory, at disk I/O
• I-verify ang availability ng tempdb space
• Tukuyin ang mga naka-block na proseso at matagal nang mga query

4. Subaybayan ang Deadlock na Aktibidad

• Suriin ang mga deadlock graph mula sa mga kaganapan sa kalusugan ng system
• Tukuyin ang mga may problemang query at mag-optimize sa mga development team
• Subaybayan ang mga bilang ng biktima ng deadlock at epekto sa negosyo

Mahalagang Paalala

• Iwasan ang madalas na pag-urong ng database – pinapataas nito ang pagkapira-piraso at pinapababa ang pagganap. Paliitin lamang pagkatapos ng mga pangunahing pagtanggal ng data kapag talagang kinakailangan.
• I-automate ang mga gawain sa pagsubaybay paggamit SQL Server Mga trabaho sa ahente o mga plano sa pagpapanatili na may mga alerto para sa mga kritikal na isyu.
• Subukan ang mga pamamaraan sa pagbawi ng kalamidad lingguhan upang matiyak na maibabalik ang mga backup at mananatiling makakamit ang mga layunin sa pagbawi.

Sa pamamagitan ng pagsasama-sama ng pang-araw-araw na checklist na ito sa mga regular na operasyon ng DBCC CHECKDB, lumikha ka ng komprehensibong proteksyon para sa kapaligiran ng iyong database sa pamamagitan ng maagap na pagsubaybay at maagap na pagtugon sa isyu.

12. Mga sanggunian

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server dokumentasyon. 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. "I-troubleshoot ang mga error sa pagkakapare-pareho ng database na iniulat ng DBCC CHECKDB." SQL Server dokumentasyon. Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors