DBCC CHECKDB: Udhëzues i plotë për MS SQL Server Shëndeti i Bazës së të Dhënave (2026)

DBCC CHECKDB është SQL ServerMjeti kryesor i integritetit të bazës së të dhënave. Mësoni si ta përdorni atë me shembuj, si të rregulloni korruptimin dhe si të optimizoni performancën.

3. Ekzekutimi i DBCC CHECKDB: Hap pas hapi

3.1 Parakushtet

Më poshtë është lista e kontrollit përpara se të ekzekutoni ndonjë operacion DBCC CHECKDB:

• Kopje rezervë e plotë e bazës së të dhënave – Krijoni një kopje rezervë të plotë përpara se të kryeni kontrolle integriteti si rrjetë sigurie nëse zbulohet ndonjë dëmtim ose bëhen të nevojshme operacionet e riparimit.
• Lejet e duhura – Ju nevojiten lejet e administratorit të sistemit ose db_owner për të ekzekutuar komandat DBCC CHECKDB
• Burime të mjaftueshme të sistemit:
  • Memoria: 25% e madhësisë së bazës së të dhënave
  • Hapësira Tempdb: 10-15% e madhësisë së bazës së të dhënave
  • CPU: 50-70% disponueshmëri gjatë mirëmbajtjes
  • I/O: Prisni operacione të rënda leximi
• Qasshmëria në bazën e të dhënave – Verifikoni që baza juaj e të dhënave është e arritshme dhe jo në gjendje të kufizuar, pasi CHECKDB kërkon akses leximi në të gjitha faqet e bazës së të dhënave

3.2 Komanda bazë

Most Komanda bazë DBCC CHECKDB përfshin tre variacione të zakonshme:

(1) Kontrolloni bazën e të dhënave aktuale (pa parametra):

DBCC CHECKDB

(2) Kontrolloni një bazë të dhënash me emër:

DBCC CHECKDB ('YourDatabaseName')

(3) Kontrolloni një bazë të dhënash sipas ID-së:

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

Kjo komandë themelore kryen një kontroll të plotë të integritetit të bazës së të dhënave të specifikuar, duke shqyrtuar të gjitha tabelat, indekset dhe strukturat e sistemit. Për bazat e të dhënave me emra standardë që nuk përmbajnë hapësira, mund të hiqni thonjëzat. Komanda do të funksionojë deri në përfundim, duke shfaqur mesazhe progresi dhe rezultate përfundimtare. Kjo sintaksë bazë funksionon në mënyrë perfekte për bazat e të dhënave më të vogla ose kur keni kohë të mjaftueshme mirëmbajtjeje në dispozicion.

Më poshtë është një pamje e ekranit e ekzekutimit të DBCC CHECKDB në SQL Server Studio Menaxhimi (SSMS):

3.3 Opsione të plota

Më poshtë janë opsionet e plota për DBCC CHECKDB:

Kategoria	Alternativë	Përshkrim	Shembull i DBCC CHECKDB
Opsionet e Riparimit	REPAIR_REBUILD	Riparime pa humbje të të dhënave (p.sh., rindërtime të indeksit)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Pa riparim. Vetëm pajtueshmëri me versionet e mëparshme	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Riparon të gjitha gabimet (mund të shkaktojë humbje të të dhënave)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kontrolli i fushëveprimit	NOINDEX	Anashkalon kontrollet e indeksit jo të grumbulluara	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Kontrollon vetëm integritetin e ruajtjes fizike (faqet/regjistrimet)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Kontrollon për gabime logjike të vlerës së kolonës (p.sh., data të pavlefshme)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Kontrolle të thella logjike (pamje të indeksuara, indekse XML/hapësinore)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kontrolli i daljes	ALL_ERRORMSGS	Shfaq të gjitha gabimet (parazgjedhja: 200 për objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Fsheh mesazhet informative	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performance	TABLOCK	Përdor bllokimet e tabelave (zvogëlon përdorimin e TempDB, por bllokon shkrimet)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Mbivendos cilësimet e paralelizmit	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Dobi	ESTIMATEONLY	Vlerëson hapësirën e nevojshme të TempDB. (pa kontroll real)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Kuptimi i rezultateve tuaja

DBCC CHECKDB do të prodhojë rezultate të ndryshme në varësi të faktit nëse ekzekutimi i tij përfundon me sukses apo jo. Le t'i shpjegojmë ato në detaje.

4.1 Ekzekutimi i CHECKDB përfundon me sukses

Nëse ekzekutimi i DBCC CHECKDB përfundon me sukses, ai do të raportojë lloje të ndryshme rezultatesh në varësi të gjendjes shëndetësore të bazës së të dhënave tuaja.

4.1.1 Nuk u gjetën probleme

Nëse DBCC CHECKDB nuk gjen ndonjë problem, do të shihni një rezultat të ngjashëm me këtë:

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

Ky rezultat tregon se baza juaj e të dhënave ruan integritet të përsosur në të gjitha strukturat e kontrolluara.

4.1.2 Gabime të gjetura të korrupsionit

Sa herë që DBCC CHECKDB zbulon një gabim korruptimi, ai do të raportojë një mesazh gabimi me strukturën e mëposhtme:
Udhëzues për Nivelin e Ashpërsisë:

• Niveli 16-19: Gabime të korrigjueshme nga përdoruesi, shpesh korruptime të vogla
• Niveli 20-24: Gabime të sistemit, korrupsion serioz që kërkon vëmendje të menjëhershme
• Niveli 25: Gabime fatale, baza e të dhënave mund të jetë e paarritshme

Gabimet e zakonshme përfshijnë:

• Dështime në kontrollin e faqes (mesazhi 824)
• Gabime në ndarje (mesazhi 8928)
• Probleme me konsistencën e indeksit (mesazhi 8964)

Të kuptuarit e strukturës së mesazhit ndihmon në përcaktimin e përparësive të veprimeve të reagimit dhe në përcaktimin e strategjive të përshtatshme të rimëkëmbjes.

4.1.3 Mesazhe të zakonshme informuese dhe paralajmëruese

Jo të gjitha rezultatet e DBCC CHECKDB tregojnë probleme serioze. Mund të prodhojë gjithashtu disa mesazhe informuese dhe paralajmëruese, duke përfshirë:

• Deklaratat e riparimit – Mesazhe që sugjerojnë komanda riparimi për të rregulluar probleme të vogla
• Paralajmërime për ndarjen – Paralajmërime rreth ndarjes së hapësirës që nuk ndikojnë në aksesin në të dhëna
• Rekomandime për performancën – Sugjerime për mirëmbajtjen dhe optimizimin e indeksit
• Njoftime informuese – Mesazhe të përgjithshme të statusit që nuk kërkojnë veprim të menjëhershëm

Këto mesazhe ofrojnë udhëzime të vlefshme për mirëmbajtjen, ndërkohë që bëjnë dallimin midis korruptimit kritik që kërkon veprim të menjëhershëm dhe problemeve të vogla që mund të adresohen gjatë dritareve të rregullta të mirëmbajtjes.

Shembull mesazhi paralajmërues:

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 Ndërprerjet e Ekzekutimit të CHECKDB

Nëse CHECKDB ndërpritet gjatë ekzekutimit të tij për arsye të ndryshme, ai do të raportojë një mesazh gabimi dhe do të shtojë një regjistër gabimesh me kodin e gjendjes më poshtë:

shtet	Përshkrim
0	U shfaq gabimi numër 8930. Kjo tregon një korruptim në meta të dhëna që e ka mbyllur komandën DBCC.
1	U shfaq gabimi numër 8967. Kishte një gabim të brendshëm DBCC.
2	Ndodhi një dështim gjatë riparimit të bazës së të dhënave në modalitetin e emergjencës.
3	Kjo tregon një korruptim në metadata që përfundoi komandën DBCC.
4	U zbulua një shkelje e pohimit ose qasjes.
5	Ndodhi një gabim i panjohur që ndërpreu komandën DBCC.

Shembull mesazhi gabimi:

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

Shembull i regjistrit të gabimeve:

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.

Në një rast të tillë, mund të provoni opsione të avancuara alternative, të tilla si DataNumen SQL Recovery për të rregulluar korrupsionin në bazën tuaj të të dhënave.

5. Rregullimi i Gabimeve të Korrupsionit

5.1 Rezervimi dhe Rivendosja: Zgjidhja më e Sigurt

Kur DBCC CHECKDB identifikon gabime korruptimi, rivendosja nga një kopje rezervë e pastër përfaqëson mënyrën më të sigurt dhe më të mirë.ost zgjidhje e besueshme. Kjo qasje garanton integritetin e të dhënave duke eliminuar shkaqet themelore të korrupsionit. Para se të rivendosni, verifikoni integritetin e kopjes rezervë duke përdorur RIVENDOS VERIFIKIM VETËM komandat dhe merrni në konsideratë opsionet e rikuperimit në moment të caktuar për të minimizuar humbjen e të dhënave. Dokumentoni detajet e korruptimit për analizën e shkakut rrënjësor, pasi problemet e harduerit ose gabimet e softuerit mund të kërkojnë vëmendje shtesë për të parandaluar përsëritjen.

5.2 Zgjidhje për Korrupsionin në Nivel Faqeje

Për korruptimin e izoluar të faqes që prek pjesë të vogla të të dhënave, SQL Server Enterprise Edition ofron aftësi për rikthimin e faqeve që riparojnë faqe specifike të dëmtuara pa restaurim të plotë të bazës së të dhënave. Kjo teknikë e përparuar kërkon model të plotë rikuperimi dhe kopje rezervë të regjistrave aktualë.

Procesi hap pas hapi i rikuperimit të faqes:

1. Identifikoni faqen e dëmtuar nga mesazhi i gabimit CHECKDB (p.sh., faqja 1:256)
2. Merrni një kopje rezervë të regjistrit aktual për të kapur transaksionet e fundit:

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

3. Rivendos faqen e dëmtuar nga most kopje rezervë e plotë e kohëve të fundit:

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

4. Aplikoni kopje rezervë diferenciale (nëse në dispozicion):

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

5. Zbato të gjitha kopjet rezervë të regjistrave në sekuencë, përfshirë atë që sapo është krijuar:

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. Bëni një kopje rezervë përfundimtare të regjistrit dhe rivendoseni atë. për ta sjellë faqen në gjendje të azhurnuar:

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

Alternativë për të dhëna jo-kritike: Nëse korruptimi ndikon në të dhënat jo kritike, mund të eksportoni rreshtat e paprekur në tabela të reja përpara se të rindërtoni strukturat e korruptuara:

-- 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 Zgjidhje të Shpejta për Korrupsionin e Indeksit

Korruptimi i indeksit shpesh i përgjigjet mirë operacioneve të rindërtimit që rikrijojnë strukturat e indeksit pa ndikuar në të dhënat themelore të tabelës:

ALTER INDEX ALL ON YourTable REBUILD

Kjo qasje funksionon veçanërisht mirë për korruptimin e indeksit jo të grumbulluar, pasi rindërtimi rigjeneron faqet e indeksit nga të dhënat e tabelës burimore, duke eliminuar në mënyrë efektive korruptimin duke ruajtur të gjithë informacionin origjinal.

6. Përdorni REPAIR_REBUILD dhe REPAIR_ALLOW_DATA_LOSS

Nëse të gjitha metodat e mëparshme dështojnë ose nuk janë të realizueshme, mund të përdorni opsionet REPAIR_REBUILD dhe REPAIR_ALLOW_DATA_LOSS për të riparuar bazën e të dhënave.

6.1 RIPARIME_RINDËRTIM (Opsion më i Sigurt):

• Përdorimi për: Korrupsioni i indeksit dhe gabimet e vogla të alokimit
• Siguria e të dhënave: Përpjekje për të rregulluar korrupsionin pa fshirë të dhënat
• Niveli i rrezikut: E ulët - nuk pritet humbje e të dhënave
• Skenarë tipikë: Korruptim i indeksit jo të grumbulluar, probleme të vogla me meta të dhënat
• Shembull komande: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Mjeti i Fundit):

• Përdorimi për: Korrupsion i rëndë kur kopjet rezervë nuk janë të disponueshme
• Siguria e të dhënave: Mund të fshijë të dhënat e korruptuara për të rivendosur funksionalitetin e bazës së të dhënave
• Niveli i rrezikut: E lartë - humbje e përhershme e të dhënave e mundshme
• Skenarë tipikë: Dëmtimi i faqes, dëmtimi i tabelës së sistemit, gabimet e zinxhirit të alokimit
• Shembull komande: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Praktikat më të Mira për Këto Opsione:

• Provoni gjithmonë operacione riparimi në kopjet e bazës së të dhënave kur është e mundur
• Gjithmonë bëj kopje rezervë para se të ekzekutoni këto opsione
• Dokumentoni të gjitha ndryshimet për qëllime pajtueshmërie dhe zgjidhjeje të problemeve
• Vendosni bazën e të dhënave në modalitetin me një përdorues të vetëm para se të kryeni operacione riparimi

Normalisht, duhet të përpiqemi RIPARIM_RINDËRTIM opsioni i parë. Nëse dështon, atëherë provo REPAIR_ALLOW_DATA_LOSS opsion.

6.4 Rezultatet e REPAIR_ALLOW_DATA_LOSS

6.4.1 Riparimi Sukses me Humbjen e të Dhënave

Ndonjëherë REPAIR_ALLOW_DATA_LOSS opsioni do të ketë sukses, por disa të dhëna janë lost pas riparimit.

Më poshtë janë disa mesazhe shembullore:

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.

Kjo ndodh sepse DBCC CHECKDB e rregullon bazën e të dhënave duke braktisur disa të dhëna të dëmtuara, por në fakt, most prej tyre ende mund të rikuperohen nëpërmjet DataNumen SQL Recovery.

Skedarë shembullorë:

SQL Server version	Skedar MDF i korruptuar	Skedari MDF i rregulluar nga DataNumen SQL Recovery
SQL Server 2014	Gabim 10_1.mdf (Mesazhi 8909 i ndjekur nga Mesazhi 8939) (600 të dhëna lost me REPAIR_ALLOW_DATA_LOSS)	Gabimi10_1_rregulluar.mdf (Pa regjistrim lost)
SQL Server 2014	Gabim 10_2.mdf (Mesazhi 8909 i ndjekur nga Mesazhi 8939) (6000 regjistrime (50%) lost me REPAIR_ALLOW_DATA_LOSS)	Gabimi10_2_rregulluar.mdf (Vetëm 100 regjistrime lost)
SQL Server 2014	Gabim7MDF (100 regjistrime lost me REPAIR_ALLOW_DATA_LOSS)	Gabim 7_rregulluar.mdf (Vetëm një rekord lost)

6.4.2 Dështimet në riparim – Konsideroni zgjidhje profesionale

If REPAIR_ALLOW_DATA_LOSS Nëse dështon, do të nxjerrë një ose më shumë mesazhe gabimi.

Më poshtë janë disa shembuj:

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.

Në këto raste, duhet të përdorni një zgjidhje profesionale, siç është p.sh. DataNumen SQL Recovery për të rregulluar bazën tuaj të të dhënave.

Skedarë shembullorë

SQL Server version	Skedar MDF i korruptuar	Skedari MDF i rregulluar nga DataNumen SQL Recovery
SQL Server 2014	Gabim 1_3.mdf (Mesazh i vetëm 824)	Gabimi1_3_rregulluar.mdf
SQL Server 2014	Gabim 1_1.mdf (Gabime të vazhdueshme të Msg 824)	Gabim 1_1_rregulluar.mdf
SQL Server 2014	Gabim 1_2.mdf ((Mesazhi 824 i ndjekur nga Mesazhi 7909)	Gabimi1_2_rregulluar.mdf
SQL Server 2014	Gabim 4_1.mdf (Mesazhi 8992 i ndjekur nga Mesazhi 3852)	Gabimi4_1_rregulluar.mdf
SQL Server 2014	Gabim 4_2.mdf (Mesazhi 8992 i ndjekur nga Mesazhi 3852)	Gabimi4_2_rregulluar.mdf
SQL Server 2014	Gabim 5.mdf (Msg 8945)	Gabim 5_rregulluar.mdf
SQL Server 2014	Gabim 6.mdf (Msg 2510)	Gabim 6_rregulluar.mdf
SQL Server 2014	Gabim 2.mdf (Msg 2575)	Gabim 2_rregulluar.mdf
SQL Server 2014	Gabim 11.mdf (Msg 8905)	Gabim 11_rregulluar.mdf
SQL Server 2014	Gabim 3.mdf (Msg 5028)	Gabim 3_rregulluar.mdf
SQL Server 2014	Gabim8MDF (Msg 5125)	Gabim8_rregulluar.mdf
SQL Server 2014	Gabim 9.mdf (Msg 3313)	Gabim 9_rregulluar.mdf

7. Praktikat më të mira

7.1 Planifikimi i Operacioneve të Rregullta të CHECKDB

Zbatoni ekzekutimin javor të DBCC CHECKDB për bazat e të dhënave kritike të prodhimit, me kontrolle ditore për sistemet me transaksione të larta. Planifikoni operacionet gjatë periudhave me përdorim të ulët për të minimizuar ndikimin në performancë dhe merrni në konsideratë alternimin midis kontrolleve të plota dhe opsioneve PHYSICAL_ONLY bazuar në madhësinë e bazës së të dhënave dhe dritaret e mirëmbajtjes. Planifikim i automatizuar përmes SQL Server Agjenti siguron ekzekutim të qëndrueshëm, ndërkohë që ofron aftësi të centralizuara monitorimi dhe alarmi.

7.2 Menaxhimi i Ndikimit në Performancë

Operacionet DBCC CHECKDB konsumojnë burime të konsiderueshme të sistemit, duke ndikuar potencialisht në aktivitetin e njëkohshëm të përdoruesit. Monitoroni përdorimin e CPU-së, konsumin e memories dhe hyrjet/daljet e diskut gjatë kontrolleve për të kuptuar modelet e ndikimit në performancë. Konsideroni përdorimin e opsioneve NOINDEX për kontrolle rutinë, duke rezervuar validimin e plotë për dritaret mujore të mirëmbajtjes. Implementoni zgjatjet e kohës së skadimit të pyetjeve dhe strategjitë e komunikimit të përdoruesit për të menaxhuar pritjet gjatë periudhave të kontrollit të integritetit.

7.3 Planifikimi i Dritares së Mirëmbajtjes

Koordinoni planifikimin e DBCC CHECKDB me aktivitete të tjera të mirëmbajtjes, si operacionet e kopjimit rezervë, rindërtimi i indeksit dhe përditësimet e statistikave. Shmangni mbivendosjen e operacioneve që kërkojnë shumë burime, të cilat mund të shkaktojnë degradim të performancës ose probleme me skadimin e kohës. Planifikoni dritaret e mirëmbajtjes bazuar në parashikimet e rritjes së madhësisë së bazës së të dhënave, duke siguruar kohë të mjaftueshme për verifikimin e plotë të integritetit ndërsa vëllimet e të dhënave rriten.

7.4 Monitorim dhe Alarmim i Automatizuar

Konfiguroni SQL Server Agjenti sinjalizon administratorët menjëherë kur DBCC CHECKDB identifikon korrupsion. Implementon zgjidhje për analizimin e regjistrave që nxjerrin dhe kategorizojnë rezultatet e kontrollit të integritetit, duke mundësuar analizën e trendeve dhe identifikimin proaktiv të problemeve. Krijoni procedura përshkallëzimi që përcaktojnë afatet kohore të reagimit dhe personelin përgjegjës për nivele të ndryshme të ashpërsisë së korrupsionit.

8. DBCC CHECKTABLE: Alternativa e Lehtë

8.1 Kur duhet përdorur CHECKTABLE në vend të CHECKDB

DBCC CHECKTABLE ofron kontroll të fokusuar të integritetit për tabela individuale, duke e bërë atë ideal për tarzgjidhja e problemeve dhe mirëmbajtja e objekteve specifike të bazës së të dhënave. Përdorni CHECKTABLE kur hetoni problemet e performancës me tabela të veçanta, validoni tabelat kritike të biznesit midis kontrolleve të plota të bazës së të dhënave ose kur kufizimet kohore parandalojnë validimin e plotë të bazës së të dhënave. Kjo qasje rezulton veçanërisht e vlefshme në bazat e të dhënave të mëdha ku operacionet e plota të CHECKDB tejkalojnë dritaret e disponueshme të mirëmbajtjes.

8.2 Sintaksa dhe Shembuj të DBCC CHECKTABLE

Komanda bazë CHECKTABLE tarmerr tabela specifike:

DBCC CHECKTABLE('YourTable')

Ashtu si CHECKDB, CHECKTABLE mbështet opsione të ndryshme duke përfshirë NOINDEX për optimizimin e performancës dhe parametrat e riparimit për zgjidhjen e korrupsionit. Gjithashtu mund të specifikoni emrat e skemave për identifikimin e saktë të tabelave:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

kjo tarQasja e integruar lejon verifikimin e hollësishëm të integritetit duke ruajtur performancën e sistemit gjatë orarit të punës.

8.3 Përfitimet e Performancës për Bazat e të Dhënave të Mëdha

Operacionet e CHECKTABLE përfundojnë dukshëm më shpejt sesa kontrollet e plota të bazës së të dhënave, duke mundësuar verifikim më të shpeshtë të integritetit të tabelave kritike. Kjo qasje lejon validimin ditor të tabelave thelbësore të biznesit, duke rezervuar operacione gjithëpërfshirëse të CHECKDB për orare javore ose mujore. Konsumi i reduktuar i burimeve e bën CHECKTABLE të përshtatshëm për ekzekutimin e mjedisit të prodhimit me ndikim minimal te përdoruesi.

9. Kur CHECKDB dështon

DBCC CHECKDB do të dështojë në skenarë të ndryshëm, duke përfshirë:

• Ekzekutimi i DBCC CHECKDB përfundon në mënyrë anormale
• Ekzekutimi i DBCC CHECKDB përfundon me sukses, por opsionet e riparimit dështon në riparimin e bazës së të dhënave.

Në këto skenarë, na duhet një mjet më profesional për të na ndihmuar të rregullojmë korruptimet në bazën e të dhënave.

9.1 Hyrje në DataNumen SQL Recovery

DataNumen SQL Recovery ofron aftësi më të përparuara:

• Shkalla më e mirë e rikuperimit në industri.
• Rikuperoni skedarët e bazës së të dhënave të dëmtuara rëndë.
• Rikuperoni të gjitha objektet e bazës së të dhënave, duke përfshirë tabelat, indekset, pamjet, shkaktuesit, rregullat dhe parazgjedhjet.
• Rikuperoni procedurat e ruajtura, funksionet skalare, funksionet inline me vlerë të tabelës dhe funksionet me vlerë të tabelës me shumë deklarata.
• Rikuperoni të dhënat e fshira përgjithmonë.
• Dekripto objektet e enkriptuara në SQL Server Bazat e të dhënave.
• Riparoni skedarët MDF në grup.
• Opsione gjithëpërfshirëse të riparimit.
• Regjistrim dhe raportim i avancuar.
• Mbështetje për të gjithë SQL Server Versione të.
• Disponueshmëria e mbështetjes teknike
• Përditësime dhe përmirësime të rregullta

9.2 Krahasimi i Shkallës së Suksesit

Normat e suksesit të rikuperimit ndryshojnë ndjeshëm:

• DBCC CHECKDB & CHECKTABLE: 1.27% norma mesatare e rikuperimit
• DataNumen: 92.6% shkalla e rikuperimit

Më poshtë është një krahasim i plotë konkurrues:

9.3 Rimëkëmbja nga korrupsioni i rëndë

Aftësi të avancuara për raste të rënda:

• Rimëkëmbja nga magazinimi i dëmtuar fizikisht
• Rimëkëmbja nga disqet e formatuar ose sistemet e rrëzuara
• Rikuperoni nga imazhet e diskut, skedarët rezervë, skedarët e diskut të makinës virtuale, ritminrary skedarë, etj.

9.4 Kur duhet të merren në konsideratë zgjidhjet profesionale

• Nuk ka rezervë të disponueshme së fundmi
• DBCC CHECKDB dështon
• Skenarë të rëndë korrupsioni
• Trajtimi i të dhënave kritike të biznesit
• Kur koha është kritike
• Kur rikuperimi maksimal është thelbësor

10. Pyetjet e shpeshta

11. Përfundim

11.1 Përmbledhje e pikave kyçe

11.1.1 Përmbledhje e Komandave Thelbësore të DBCC CHECKDB

Zotëroni sintaksën bazë të DBCC CHECKDB për kontroll gjithëpërfshirës të bazës së të dhënave, përdorni opsionet NOINDEX dhe PHYSICAL_ONLY për optimizimin e performancës dhe kuptoni CHECKTABLE për tarVerifikimi i tabelës së marrë. Këto komanda themelore formojnë themelin e mirëmbajtjes proaktive të bazës së të dhënave, duke mundësuar zbulimin e hershëm të korrupsionit dhe monitorimin sistematik të integritetit.

11.1.2 Kujtesë për Praktikat më të Mira Kritike

Mbani gjithmonë kopje rezervë të azhurnuara përpara se të kryeni kontrolle integriteti, caktoni operacione të rregullta CHECKDB bazuar në kritikalitetin e bazës së të dhënave dhe zbatoni monitorim të automatizuar për alarme të menjëhershme korruptimi. Mos harroni se parandalimi përmes monitorimit të rregullt tejkalon qasjet reaktive dhe zgjidhjet profesionale të rimëkëmbjes ofrojnë mundësi të vlefshme për kopje rezervë kur mjetet standarde rezultojnë të pamjaftueshme.

11.2 Kur duhet të përdoret DBCC CHECKDB kundrejt zgjidhjeve të avancuara

Përdorni DBCC CHECKDB për monitorimin rutinë të integritetit dhe zgjidhjen e korrupsionit të vogël, duke rezervuar mjete profesionale të rikuperimit për skenarë të rëndë korrupsioni përtej aftësive të integruara të riparimit. Korniza e vendimmarrjes duhet të marrë në konsideratë disponueshmërinë e kopjes rezervë, kritikalitetin e të dhënave, kufizimet kohore dhe ashpërsinë e korrupsionit. Administratorët e suksesshëm të bazës së të dhënave kombinojnë monitorimin e rregullt të CHECKDB me strategji gjithëpërfshirëse të kopjes rezervë dhe ndërgjegjësimin për opsionet e avancuara të rikuperimit kur qasjet standarde rezultojnë të papërshtatshme.

11.3 Listë e shpejtë e kontrollit ditor të shëndetit për DBA-të

Përtej ekzekutimit të DBCC CHECKDB, mirëmbani gjendjen optimale të bazës së të dhënave me këto praktika thelbësore të përditshme:

1. Verifikoni Integritetin e Rezervës Kopjuese

• Konfirmo që kopjet rezervë të planifikuara përfunduan me sukses
• Përdorni RESTORE VERIFYONLY për të verifikuar lexueshmërinë e kopjes rezervë
• Sigurohuni që kopjet jashtë faqes të jenë të sinkronizuara dhe të arritshme

Ju gjithashtu mund të merrni më shumë informacion nga udhëzuesi ynë gjithëpërfshirës mbi SQL Server backup.

2. Rishikimi i Statusit të Përputhshmërisë

• Kontrolloni rezultatet e automatizuara të DBCC CHECKDB nga vrapimet gjatë natës
• Monitor SQL Server regjistrat e gabimeve për paralajmërimet e korrupsionit
• Hetoni menjëherë çdo dështim të integritetit

3. Monitoroni shëndetin e serverit

• Kontrolloni metrikat e CPU-së, memories dhe hyrje-daljeve në disk
• Verifikoni disponueshmërinë e hapësirës tempdb
• Identifikoni proceset e bllokuara dhe pyetjet që ekzekutohen për një kohë të gjatë

4. Ndjekja e aktivitetit të bllokimit

• Rishikoni grafikët e bllokimit nga ngjarjet e shëndetit të sistemit
• Identifikoni pyetjet problematike dhe optimizoni me ekipet e zhvillimit
• Monitoroni numrin e viktimave të bllokimit dhe ndikimin në biznes

Kujtesa të Rëndësishme

• Shmangni zvogëlimin e shpeshtë të bazës së të dhënave – rrit fragmentimin dhe degradon performancën. Zvogëlojeni vetëm pas fshirjeve të mëdha të të dhënave kur është vërtet e nevojshme.
• Automatizoni detyrat e monitorimit përdorim SQL Server Punë agjentësh ose plane mirëmbajtjeje me alarme për probleme kritike.
• Testimi i procedurave të rimëkëmbjes nga fatkeqësitë çdo javë për të siguruar që kopjet rezervë janë të rikuperueshme dhe objektivat e rikuperimit mbeten të arritshme.

Duke kombinuar këtë listë kontrolli ditore me operacionet e rregullta të DBCC CHECKDB, ju krijoni mbrojtje gjithëpërfshirëse për mjedisin tuaj të bazës së të dhënave përmes monitorimit proaktiv dhe reagimit të shpejtë ndaj problemeve.

12. Referencat

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server dokumentimKorporata Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Zgjidhja e gabimeve të konsistencës së bazës së të dhënave të raportuara nga DBCC CHECKDB.” SQL Server dokumentimKorporata Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors