DBCC CHECKDB: MS SQL Server Vodič za zdravlje baze podataka

DBCC CHECKDB je SQL ServerGlavni alat za integritet baze podataka. Naučite kako ga koristiti s primjerima, ispraviti oštećenje i optimizirati performanse.

1. Važnost od SQL Server Zdravlje baze podataka

1.1 Što je oštećenje baze podataka Costs Poslovanja

Danas, most tvrtke pohranjuju svoje kritične podatke u baze podataka. Kada dođe do oštećenja baze podataka, posljedice su katastrofalne:

Financijski gubici prosječno 2.3 milijuna dolara godišnje zbog gubitka podataka, pri čemu su glavni uzroci kvar hardvera i oštećenje (EMC Corporation)
Stope zatvaranja poduzeća pokazuju da 50% malih poduzeća koja gube podatke zbog kvarova hardvera propadaju unutar dvije godine, dok 94% poduzeća s katastrofalnim gubitkom podataka uopće ne preživi
Učestalost oštećenja podataka godišnje utječe na 20% kritičnih aplikacija, uzrokujući poremećaje u kontinuitetu poslovanja (Gartnerovo istraživanje)
Oštećenje hardvera čini 67% svih incidenata gubitka podataka zbog padova tvrdog diska i kvarova sustava, pri čemu se 40% gubitka podataka izravno pripisuje kvarovima hardvera
Korupcija softvera costs kreću se od tisuća do milijuna dolara, ovisno o ozbiljnosti i opsegu, pri čemu je 82% tvrtki doživjelo neplanirane prekide u radu gdje je korupcija bila glavni uzrok

1.2 Zašto su redoviti zdravstveni pregledi ključni

Ljudima su potrebni redoviti zdravstveni pregledi kako bi se potencijalne bolesti otkrile u ranoj fazi. Slično tome, i baze podataka trebaju redovite zdravstvene provjere:

Rano otkrijte potencijalnu korupciju i odmah je riješite, sprječavajući da problemi postanu ozbiljni i rašireni, što bi moglo dovesti do katastrofalnih posljedica za poslovanje.
Osigurajte da baza podataka radi s optimalnim performansama.
Cost Proaktivne provjere zdravlja baze podataka mnogo su niže od reaktivnog oporavka podataka nakon što dođe do katastrofe baze podataka.

1.3 Uvod u naredbe za integritet baze podataka

SQL Server pruža nekoliko ugrađenih naredbi za održavanje zdravlja baze podataka, s DBCC CHECKDB služi kao most Dostupan je sveobuhvatan alat za provjeru integriteta. Ove naredbe rade zajedno kako bi provjerile različite aspekte strukture vaše baze podataka, od pojedinačnih tablica do konzistentnosti cijele baze podataka, tvoreći cjelovitu strategiju održavanja koja čuva vaše podatke sigurnima i dostupnima.

2. Što je DBCC CHECKDB

DBCC CHECKDB is SQL Serverprimarni alat za provjeru integriteta baze podataka i identificiranje problema s oštećenjem.

To je T-SQL naredba, a ne GUI alat.
Možete ga izvršiti uobičajenim metodama, kao što su SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD itd.

2.1 Što CHECKDB zapravo provjerava u vašoj bazi podataka

Kada pokrenete DBCC CHECKDB, naredba provodi više slojeva validacije u strukturi vaše baze podataka:

Provjera kontrolnih zbrojeva stranica za otkrivanje fizičke štete i problema povezanih s hardverom
Validacija konzistentnosti indeksa kako bi se osiguralo pravilno dohvaćanje podataka i izvođenje upita
Provjere strukture alokacije kako bi se potvrdila točna upotreba prostora i dodjela stranica
Ispitivanje referencijalnog integriteta između povezanih tablica i odnosa vanjskog ključa
Validacija konzistentnosti sistemske tablice kako bi se osiguralo SQL ServerInterni metapodaci ostaju pouzdani
Provjera povezivanja stranica s podacima kako bi se potvrdio integritet ispravnog lanca stranica
Konzistentnost sheme baze podataka za validaciju definicija i ovisnosti objekata

Ove sveobuhvatne provjere obuhvaćaju i korisničke podatke i sistemske strukture, pružajući potpuni uvid u zdravstveno stanje vaše baze podataka.

3. Pokretanje DBCC CHECKDB-a: Korak po korak

Preduvjeti za 3.1

U nastavku slijedi kontrolni popis prije izvršavanja bilo koje DBCC CHECKDB operacije:

Potpuna sigurnosna kopija baze podataka – Izradite potpunu sigurnosnu kopiju prije pokretanja provjera integriteta kao svoju sigurnosnu mrežu u slučaju otkrivanja oštećenja ili potrebe za popravcima.
Ispravna dopuštenja – Za izvršavanje DBCC CHECKDB naredbi potrebne su vam dozvole sysadmin ili db_owner
Dovoljno sistemskih resursa:
- Memorija: 25% veličine baze podataka
- Tempdb prostor: 10-15% veličine baze podataka
- CPU: 50-70% dostupnost tijekom održavanja
- U/I: Očekujte velike operacije čitanja
Pristupačnost baze podataka – Provjerite je li vaša baza podataka dostupna i nije u ograničenom stanju, jer CHECKDB zahtijeva pristup za čitanje svih stranica baze podataka

3.2 Osnovna naredba

Most Osnovna DBCC CHECKDB naredba uključuje tri uobičajene varijacije:

(1) Provjerite trenutnu bazu podataka (bez parametara):

DBCC CHECKDB

(2) Provjerite bazu podataka po imenu:

DBCC CHECKDB ('YourDatabaseName')

(3) Provjerite bazu podataka prema ID-u:

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

Ova osnovna naredba provodi potpunu provjeru integriteta navedene baze podataka, ispitujući sve tablice, indekse i sistemske strukture. Za baze podataka sa standardnim nazivima koji ne sadrže razmake, možete izostaviti navodnike. Naredba će se izvršavati do završetka, prikazujući poruke o napretku i konačne rezultate. Ova osnovna sintaksa savršeno funkcionira za manje baze podataka ili kada imate dovoljno vremena za održavanje.

Ispod je snimka zaslona pokretanja DBCC CHECKDB u SQL Server Management Studio (SSMS):

3.3 Potpune opcije

U nastavku su navedene sve opcije za DBCC CHECKDB:

Kategorija	opcija	Opis	Primjer DBCC CHECKDB-a
Mogućnosti popravka	`REPAIR_REBUILD`	Popravci bez gubitka podataka (npr. ponovna izgradnja indeksa)	`DBCC CHECKDB ('MyDB', REPAIR_REBUILD)`
	`REPAIR_FAST`	Bez popravka. Samo unatrag kompatibilna.	`DBCC CHECKDB ('MyDB', REPAIR_FAST)`
	`REPAIR_ALLOW_DATA_LOSS`	Popravlja sve greške (može uzrokovati gubitak podataka)	`DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)`
Kontrola opsega	`NOINDEX`	Preskače provjere neklasteriranih indeksa	`DBCC CHECKDB ('LargeDB', NOINDEX)`
	`PHYSICAL_ONLY`	Provjerava samo integritet fizičke pohrane (stranice/zapisi)	`DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)`
	`DATA_PURITY`	Provjerava logičke pogreške u vrijednostima stupaca (npr. nevažeće datume)	`DBCC CHECKDB ('OldDB', DATA_PURITY)`
	`EXTENDED_LOGICAL_CHECKS`	Dubinske logičke provjere (indeksirani prikazi, XML/prostorni indeksi)	`DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)`
Izlazna kontrola	`ALL_ERRORMSGS`	Prikazuje sve pogreške (zadano: 200 po objektu)	`DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)`
Izlazna kontrola	`NO_INFOMSGS`	Skriva informativne poruke	`DBCC CHECKDB ('MyDB', NO_INFOMSGS)`
Izvođenje	`TABLOCK`	Koristi zaključavanje tablica (smanjuje korištenje TempDB-a, ali blokira pisanje)	`DBCC CHECKDB ('BigDB', TABLOCK)`
Izvođenje	`MAXDOP = number`	Nadjačava postavke paralelizma	`DBCC CHECKDB ('MyDB', MAXDOP = 2)`
Korisnost	`ESTIMATEONLY`	Procjenjuje potreban prostor u TempDB-u. (bez stvarne provjere)	`DBCC CHECKDB ('MyDB', ESTIMATEONLY)`

4. Razumijevanje vaših rezultata

DBCC CHECKDB će dati različite rezultate ovisno o tome je li njegovo izvršavanje uspješno završeno ili ne. Objasnimo ih detaljnije.

4.1 Izvršavanje CHECKDB-a uspješno je završeno

Ako se izvršavanje DBCC CHECKDB uspješno završi, prijavit će različite vrste rezultata ovisno o stanju baze podataka.

4.1.1 Nisu pronađeni problemi

Ako DBCC CHECKDB ne pronađe nikakve probleme, vidjet ćete izlaz sličan ovome:

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

Ovaj rezultat ukazuje na to da vaša baza podataka održava savršen integritet u svim provjerenim strukturama.

4.1.2 Pronađene pogreške korupcije

Kad god DBCC CHECKDB otkrije grešku korupcije, prijavit će poruku o pogrešci sljedeće strukture:
Vodič za razinu ozbiljnosti:

Razina 16-19: Korisnik može ispraviti pogreške, često manja oštećenja
Razina 20-24: Sistemske pogreške, ozbiljna korupcija koja zahtijeva hitnu pozornost
Razina 25: Fatalne pogreške, baza podataka možda nije dostupna

Uobičajene pogreške uključuju:

Pogreške kontrolnog zbroja stranice (poruka 824)
Pogreške u alokaciji (poruka 8928)
Problemi s konzistentnošću indeksa (poruka 8964)

Razumijevanje strukture poruke pomaže u određivanju prioriteta odgovora i određivanju odgovarajućih strategija oporavka.

4.1.3 Uobičajene informativne i upozoravajuće poruke

Nisu svi izlazi DBCC CHECKDB-a ozbiljni problemi. Također mogu izbaciti neke informativne i upozoravajuće poruke, uključujući:

Izjave o popravku – Poruke koje predlažu naredbe za popravak manjih problema
Upozorenja o dodjeli – Upozorenja o dodjeli prostora koja ne utječu na pristup podacima
Preporuke za performanse – Prijedlozi za održavanje i optimizaciju indeksa
Informativne obavijesti – Općenite poruke o statusu koje ne zahtijevaju hitnu akciju

Ove poruke pružaju vrijedne smjernice za održavanje, a istovremeno razlikuju kritične probleme koji zahtijevaju hitnu akciju od manjih problema koji se mogu riješiti tijekom redovnog održavanja.

Primjer poruke upozorenja:

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 Prekidi izvršavanja CHECKDB-a

Ako se CHECKDB prekine tijekom izvršavanja iz različitih razloga, prijavit će poruku o pogrešci i dodati zapisnik o pogrešci sa sljedećim kodom stanja:

Država	Opis
`0`	Pojavila se pogreška broj 8930. To ukazuje na oštećenje metapodataka koji je prekinuo DBCC naredbu.
`1`	Pojavila se greška broj 8967. Došlo je do interne DBCC greške.
`2`	Došlo je do kvara tijekom popravka baze podataka u hitnom načinu rada.
`3`	To ukazuje na oštećenje metapodataka koje je prekinulo DBCC naredbu.
`4`	Otkriveno je kršenje tvrdnje ili pristupa.
`5`	Došlo je do nepoznate greške koja je prekinula DBCC naredbu.

Primjer poruke o pogrešci:

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.

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

Primjer zapisnika o greškama:

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.

U takvom slučaju možete isprobati alternativne napredne opcije kao što su DataNumen SQL Recovery kako biste ispravili oštećenje u svojoj bazi podataka.

5. Ispravljanje pogrešaka uzrokovanih korupcijom

5.1 Sigurnosna kopija i vraćanje: Najsigurnije rješenje

Kada DBCC CHECKDB identificira pogreške u oštećenju, vraćanje iz čiste sigurnosne kopije predstavlja najsigurniji i najučinkovitiji način.ost pouzdano rješenje. Ovaj pristup jamči integritet podataka, a istovremeno uklanja temeljne uzroke oštećenja. Prije vraćanja provjerite integritet sigurnosne kopije pomoću VRATI SAMO POTVRDI naredbe i razmotrite opcije oporavka u određenom trenutku kako biste smanjili gubitak podataka. Dokumentirajte detalje o oštećenju za analizu uzroka, jer hardverski problemi ili softverske greške mogu zahtijevati dodatnu pažnju kako bi se spriječilo ponavljanje.

5.2 Rješenja za korupciju na razini stranice

Za izolirano oštećenje stranice koje utječe na male dijelove podataka, SQL Server Enterprise Edition nudi mogućnosti vraćanja stranica koje popravljaju određene oštećene stranice bez potpune obnove baze podataka. Ova napredna tehnika zahtijeva model potpunog oporavka i trenutne sigurnosne kopije dnevnika.

Postupak vraćanja stranice korak po korak:

Identificirajte oštećenu stranicu iz poruke o pogrešci CHECKDB (npr. stranica 1:256)
Napravite trenutnu sigurnosnu kopiju dnevnika za bilježenje nedavnih transakcija:

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

Vrati oštećenu stranicu od most nedavna potpuna sigurnosna kopija:

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

Primijeni diferencijalnu sigurnosnu kopiju (ako je dostupno):

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

Primijeni sve sigurnosne kopije zapisnika redom, uključujući i upravo stvoreni:

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'

Napravite završnu sigurnosnu kopiju dnevnika i vratite je za ažuriranje stranice:

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

Alternativa za nekritične podatke: Ako oštećenje utječe na nekritične podatke, možete izvesti nepromijenjene retke u nove tablice prije obnove oštećenih struktura:

-- 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 Brza rješenja za oštećenje indeksa

Oštećenje indeksa često dobro reagira na operacije ponovne izgradnje koje ponovno izgrađuju strukture indeksa bez utjecaja na temeljne podatke tablice:

ALTER INDEX ALL ON YourTable REBUILD

Ovaj pristup posebno dobro funkcionira za oštećenje neklasteriranog indeksa, jer ponovna izgradnja regenerira stranice indeksa iz podataka izvorne tablice, učinkovito uklanjajući oštećenje uz očuvanje svih izvornih informacija.

6. Koristite REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS

Ako sve prethodne metode ne uspiju ili nisu izvedive, možete upotrijebiti opcije REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS za popravak baze podataka.

6.1 POPRAVAK_OBNOVA (Sigurnija opcija):

Koristi za: Oštećenje indeksa i manje pogreške u alokaciji
Sigurnost podataka: Pokušava ispraviti oštećenje bez brisanja podataka
Razina rizika: Nisko – ne očekuje se gubitak podataka
Tipični scenariji: Oštećenje neklasteriranog indeksa, manji problemi s metapodacima
Primjer naredbe: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 POPRAVAK_DOPUŠTANJE_GUBITKA_PODATAKA (Posljednja mjera):

Koristi za: Ozbiljna korupcija kada sigurnosne kopije nisu dostupne
Sigurnost podataka: Može izbrisati oštećene podatke radi vraćanja funkcionalnosti baze podataka
Razina rizika: Visoka – moguć je trajni gubitak podataka
Tipični scenariji: Oštećenje stranice, oštećenje sistemske tablice, pogreške u lancu alokacije
Primjer naredbe: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Najbolje prakse za ove opcije:

Uvijek testiraj operacije popravka na kopijama baze podataka kada je to moguće
Uvijek napravi sigurnosnu kopiju prije pokretanja ovih opcija
Dokumentirajte sve promjene radi usklađenosti i rješavanja problema
Postavljanje baze podataka na način rada za jednog korisnika prije izvođenja popravnih radova

Normalno, trebali bismo pokušati POPRAVAK_OBNOVA prvo opciju. Ako ne uspije, pokušajte REPAIR_ALLOW_DATA_LOSS opcija.

6.4 Rezultati POPRAVKA_DOPUŠTANJA_GUBITKA_PODATAKA

6.4.1 Popravak uspijeva s gubitkom podataka

Ponekad REPAIR_ALLOW_DATA_LOSS opcija će uspjeti, ali neki podaci su izgubljeniost nakon popravka.

U nastavku su neki primjeri poruka:

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.

To je zato što DBCC CHECKDB popravlja bazu podataka napuštanjem nekih oštećenih zapisa, ali zapravo, most od njih se još uvijek može oporaviti putem DataNumen SQL Recovery.

Primjeri datoteka:

SQL Server verzija	Oštećena MDF datoteka	MDF datoteku popravio DataNumen SQL Recovery
SQL Server 2014	Greška10_1.mdf (Poruka 8909 nakon koje slijedi poruka 8939) (600 zapisa lost s POPRAVAK_DOPUŠTA_GUBITA_PODATAKA)	Error10_1_fixed.mdf (Nema zapisa lost)
SQL Server 2014	Greška10_2.mdf (Poruka 8909 nakon koje slijedi poruka 8939) (6000 zapisa (50%) lost s POPRAVAK_DOPUŠTA_GUBITA_PODATAKA)	Error10_2_fixed.mdf (Samo 100 zapisaost)
SQL Server 2014	Error7 MDF (100 zapisa lost s POPRAVAK_DOPUŠTA_GUBITA_PODATAKA)	Error7_fixed.mdf (Samo jedan zapis lost)

6.4.2 Popravak ne uspije – Razmotrite profesionalno rješenje

If REPAIR_ALLOW_DATA_LOSS ne uspije, ispisat će jednu ili više poruka o pogrešci.

U nastavku su navedeni neki primjeri:

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.

U tim slučajevima trebate koristiti profesionalno rješenje kao što je DataNumen SQL Recovery popraviti vašu bazu podataka.

Primjeri datoteka

SQL Server verzija	Oštećena MDF datoteka	MDF datoteku popravio DataNumen SQL Recovery
SQL Server 2014	Greška1_3.mdf (Jedna poruka 824)	Error1_3_fixed.mdf
SQL Server 2014	Greška1_1.mdf (Kontinuirana poruka 824 greške)	Greška1_1 _fiksno.mdf
SQL Server 2014	Greška1_2.mdf ((Poruka 824 nakon koje slijedi poruka 7909)	Error1_2_fixed.mdf
SQL Server 2014	Greška4_1.mdf (Poruka 8992 nakon koje slijedi poruka 3852)	Error4_1_fixed.mdf
SQL Server 2014	Greška4_2.mdf (Poruka 8992 nakon koje slijedi poruka 3852)	Error4_2_fixed.mdf
SQL Server 2014	Greška5.mdf (Poruka 8945)	Error5_fixed.mdf
SQL Server 2014	Greška6.mdf (Poruka 2510)	Error6_fixed.mdf
SQL Server 2014	Greška2.mdf (Poruka 2575)	Error2_fixed.mdf
SQL Server 2014	Greška11.mdf (Poruka 8905)	Error11_fixed.mdf
SQL Server 2014	Greška3.mdf (Poruka 5028)	Error3_fixed.mdf
SQL Server 2014	Error8 MDF (Poruka 5125)	Error8 _fiksno.mdf
SQL Server 2014	Greška9.mdf (Poruka 3313)	Error9_fixed.mdf

7. Najbolji primjeri iz prakse

7.1 Raspoređivanje redovnih CHECKDB operacija

Implementirajte tjedno izvršavanje DBCC CHECKDB naredbe za kritične produkcijske baze podataka, s dnevnim provjerama za sustave s visokim brojem transakcija. Planirajte operacije tijekom razdoblja s niskom korištenjem kako biste smanjili utjecaj na performanse i razmislite o rotiranju između punih provjera i opcija PHYSICAL_ONLY na temelju veličine baze podataka i prozora održavanja. Automatizirano zakazivanje putem SQL Server Agent osigurava dosljedno izvršavanje uz istovremeno pružanje centraliziranih mogućnosti praćenja i upozoravanja.

7.2 Upravljanje utjecajem na uspješnost

DBCC CHECKDB operacije troše značajne sistemske resurse, što potencijalno utječe na istovremenu aktivnost korisnika. Pratite iskorištenost CPU-a, potrošnju memorije i I/O operacija na disku tijekom provjera kako biste razumjeli obrasce utjecaja na performanse. Razmislite o korištenju NOINDEX opcija za rutinske provjere, a potpunu validaciju rezervirajte za mjesečne prozore održavanja. Implementirajte proširenja vremenskog ograničenja upita i strategije komunikacije s korisnicima kako biste upravljali očekivanjima tijekom razdoblja provjere integriteta.

7.3 Planiranje razdoblja održavanja

Koordinirajte DBCC CHECKDB raspored s drugim aktivnostima održavanja poput operacija sigurnosnog kopiranja, ponovne izgradnje indeksa i ažuriranja statistike. Izbjegavajte preklapanje operacija koje zahtijevaju puno resursa, a koje bi mogle uzrokovati smanjenje performansi ili probleme s vremenskim ograničenjem. Planirajte prozore održavanja na temelju projekcija rasta veličine baze podataka, osiguravajući dovoljno vremena za potpunu provjeru integriteta kako se količina podataka povećava.

7.4 Automatizirano praćenje i uzbunjivanje

konfigurirati SQL Server Agent šalje upozorenja kako bi odmah obavijestio administratore kada DBCC CHECKDB identificira oštećenje. Implementirajte rješenja za parsiranje zapisnika koja izdvajaju i kategoriziraju rezultate provjere integriteta, omogućujući analizu trendova i proaktivno prepoznavanje problema. Izradite postupke eskalacije koji definiraju vremenske okvire odgovora i odgovorno osoblje za različite razine ozbiljnosti oštećenja.

8. DBCC CHECKTABLICE: Lagana alternativa

8.1 Kada koristiti CHECKTABLE umjesto CHECKDB

DBCC CHECKTABLE omogućuje fokusiranu provjeru integriteta pojedinačnih tablica, što ga čini idealnim za tarrješavanje problema i održavanje određenih objekata baze podataka. Koristite CHECKTABLE prilikom istraživanja problema s performansama određenih tablica, validacije kritičnih poslovnih tablica između potpunih provjera baze podataka ili kada vremenska ograničenja sprječavaju potpunu validaciju baze podataka. Ovaj pristup posebno je vrijedan u velikim bazama podataka gdje potpune CHECKDB operacije premašuju dostupne prozore za održavanje.

8.2 Sintaksa i primjeri DBCC CHECKTABLE

Osnovna naredba CHECKTABLE tardobiva određene tablice:

DBCC CHECKTABLE('YourTable')

Kao i CHECKDB, CHECKTABLE podržava razne opcije, uključujući NOINDEX za optimizaciju performansi i parametre popravka za rješavanje problema s oštećenjima. Također možete odrediti nazive shema za preciznu identifikaciju tablica:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Ova tarGeted pristup omogućuje detaljnu provjeru integriteta uz održavanje performansi sustava tijekom radnog vremena.

8.3 Prednosti performansi za velike baze podataka

CHECKTABLE operacije se dovršavaju znatno brže od potpunih provjera baze podataka, što omogućuje češću provjeru integriteta kritičnih tablica. Ovaj pristup omogućuje dnevnu validaciju bitnih poslovnih tablica, a sveobuhvatne CHECKTABLE operacije rezervira za tjedne ili mjesečne rasporede. Smanjena potrošnja resursa čini CHECKTABLE prikladnim za izvršavanje u produkcijskom okruženju uz minimalan utjecaj na korisnika.

9. Kada CHECKDB ne uspije

DBCC CHECKDB neće uspjeti u raznim scenarijima, uključujući:

Izvršenje DBCC CHECKDB-a završava abnormalno
Izvršavanje DBCC CHECKDB naredbe uspješno se završava, ali mogućnosti popravka ne uspije popraviti bazu podataka.

U tim scenarijima potreban nam je profesionalniji alat koji će nam pomoći u ispravljanju oštećenja u bazi podataka.

9.1 Uvod u DataNumen SQL Recovery

DataNumen SQL Recovery pruža naprednije mogućnosti:

Najbolja stopa oporavka u industriji.
Oporavak ozbiljno oštećenih datoteka baze podataka.
Oporavite sve objekte baze podataka, uključujući tablice, indekse, prikaze, okidače, pravila i zadane vrijednosti.
Oporavite pohranjene procedure, skalarne funkcije, ugrađene funkcije s tabličnim vrijednostima i funkcije s tabličnim vrijednostima s više iskaza.
Oporavite trajno izbrisane zapise.
Dešifriraj šifrirane objekte u SQL Server baza podataka.
Popravak MDF datoteka u serijama.
Sveobuhvatne mogućnosti popravka.
Napredno bilježenje i izvješćivanje.
Podrška za sve SQL Server verzije.
Dostupnost tehničke podrške
Redovita ažuriranja i poboljšanja

9.2 Usporedba stope uspjeha

Stope uspješnosti oporavka značajno se razlikuju:

DBCC CHECKDB i CHECKTABLICE: 1.27% prosječna stopa oporavka
DataNumen: 92.6% stopa oporavka

Ispod je kompletna kompetitivna usporedba:

9.3 Oporavak od teške korupcije

Napredne mogućnosti za teške slučajeve:

Oporavak od fizički oštećene pohrane
Oporavak od formatiranih pogona ili srušenih sustava
Oporavak od slika diska, datoteka sigurnosne kopije, datoteka diska virtualnog stroja, temporary datoteke, itd.

9.4 Kada razmotriti profesionalna rješenja

Nema nedavne dostupnosti sigurnosnih kopija
DBCC CHECKDB ne uspijeva
Teški scenariji korupcije
Rad s kritičnim poslovnim podacima
Kad je vrijeme kritično
Kada je neophodan maksimalni oporavak

10. Česta pitanja

10.1 Osnovna pitanja o korištenju

P: Koliko često trebam pokretati DBCC CHECKDB?

A: Za kritične produkcijske baze podataka, CHECKDB pokrećete tjedno. Za sustave s velikim brojem transakcija, razmislite o dnevnim provjerama koristeći opciju PHYSICAL_ONLY, s potpunim provjerama tjedno. Razvojne baze podataka mogu se provjeravati mjesečno.

P: Mogu li pokrenuti DBCC CHECKDB na aktivnoj produkcijskoj bazi podataka?

A: Da, DBCC CHECKDB može se izvoditi na online bazama podataka bez blokiranja korisnika. Međutim, troši značajne resurse, stoga ga zakažite tijekom razdoblja niske aktivnosti i pratite performanse sustava.

P: Koja je razlika između CHECKDB i CHECKTABLE?

A: CHECKTABLE pregledava cijelu bazu podataka, dok se CHECKTABLE fokusira na pojedinačne tablice. Koristite CHECKTABLE za tarrješavanje problema ili kada trebate provjeriti određene tablice bez skeniranja cijele baze podataka.

10.2 Pitanja o performansama i resursima

P: Zašto DBCC CHECKDB toliko dugo traje na mojoj velikoj bazi podataka?

A: Trajanje CHECKDB-a ovisi o veličini baze podataka, performansama hardvera i korištenim opcijama. Koristite PHYSICAL_ONLY za brže provjere ili NOINDEX za preskakanje neklasteriranih indeksa. Razmislite o pokretanju tijekom razdoblja održavanja s namjenskim resursima.

P: Koliko tempdb prostora treba CHECKDB-u?

A: Općenito, dodijelite 10-15% veličine baze podataka za tempdb tijekom CHECKDB operacija. Koristite opciju ESTIMATEONLY za dobivanje preciznih procjena: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

P: Mogu li otkazati pokrenutu CHECKDB operaciju?

A: Da, možete otkazati CHECKDB pomoću naredbe KILL na ID-u sesije. Međutim, otkazivanje ne pruža nikakve informacije o integritetu baze podataka i morat ćete ga ponovno pokrenuti kasnije.

10.3 Pitanja o rješavanju pogrešaka

P: CHECKDB je pronašao greške – trebam li paničariti?

A: Ne paničarite, već brzo reagirajte. Prvo utvrdite je li CHECKDB uspješno završen, ali je pronašao oštećenje, ili se sam CHECKDB nije uspio pokrenuti. Provjerite utječu li pogreške samo na neklasterirane indekse (manje kritično) ili na podatke u tablici (ozbiljnije).

P: Kada trebam koristiti REPAIR_ALLOW_DATA_LOSS?

A: Samo kao apsolutno krajnje rješenje kada nemate upotrebljivih sigurnosnih kopija i gubitak podataka je prihvatljiv u usporedbi s potpunim gubitkom baze podataka. Uvijek prvo pokušajte vratiti podatke iz sigurnosne kopije jer operacije popravka mogu uzrokovati trajni gubitak podataka.

P: Što znači „greške konzistentnosti u bazi podataka“ u odnosu na „greške alokacije“?

A: Pogreške u alokaciji utječu na to kako SQL Server prati korištenje prostora na disku, dok pogreške konzistentnosti ukazuju na probleme s podacima ili strukturama indeksa. Obje zahtijevaju pažnju, ali pogreške konzistentnosti obično izravnije utječu na dostupnost podataka.

10.4 Pitanja o sigurnosnoj kopiji i oporavku

P: Trebam li pokrenuti CHECKDB na svojim sigurnosnim kopijama?

A: Apsolutno! Pokrenite CHECKDB nakon vraćanja sigurnosnih kopija na testne poslužitelje. To provjerava integritet sigurnosne kopije i osigurava da se zapravo možete oporaviti od oštećenja. Automatizirajte ovaj proces ako je moguće.

P: Moja sigurnosna kopija je također oštećena – što sad?

A: Isprobajte starije sigurnosne kopije dok ne pronađete čistu. Ako ne postoje čiste sigurnosne kopije, razmislite o profesionalnim rješenjima za oporavak poput DataNumen SQL RecoveryDokumentirajte vremenski slijed korupcije kako biste spriječili buduće pojave.

P: Može li vraćanje stranice popraviti oštećenje bez potpunog oporavka baze podataka?

A: Da, ali samo u SQL Server Enterprise izdanje s modelom potpunog oporavka i trenutnim sigurnosnim kopijama dnevnika. Vraćanje stranice funkcionira za izolirane slučajeve oštećenja stranice, ali zahtijeva pažljivo izvršavanje uz odgovarajuće postupke.

10.5 Pitanja o rješavanju problema

P: CHECKDB ne uspijeva s greškama "nema prostora" - što mogu učiniti?

A: Oslobodite prostor u privremenim bazama podataka, premjestite ih na bržu pohranu ili upotrijebite opciju TABLOCK za smanjenje korištenja privremenih baza podataka. Razmislite o pokretanju naredbe CHECKDB s NOINDEX ili PHYSICAL_ONLY za smanjenje zahtjeva za resursima.

P: Kako mogu utvrditi koja je tablica oštećena iz izlaza CHECKDB-a?

A: Potražite brojeve "objekta ID" u porukama o pogrešci, a zatim upotrijebite: SELECT OBJECT_NAME(object_id) za pronalaženje naziva tablica. Poruke o pogreškama također uključuju brojeve stranica i mjesta za preciznu identifikaciju lokacije.

P: Mogu li problemi s hardverom uzrokovati da CHECKDB prijavljuje lažno pozitivne rezultate?

A: Da, kvar hardvera (posebno pohrane) može uzrokovati povremenu korupciju koja se pojavljuje i nestaje između izvršavanja CHECKDB-a. Ako su pogreške nedosljedne, istražite svoj I/O podsustav i pokrenite više provjera kako biste potvrdili obrasce.

10.6 Napredna pitanja o konfiguraciji

P: Koje zastavice praćenja mogu poboljšati performanse CHECKDB-a?

A: Zastavica praćenja 2562 može poboljšati performanse pokretanjem CHECKDB-a kao jedne serije. Zastavica praćenja 2549 pomaže kada su datoteke baze podataka na odvojenim diskovima. Koristite ih pažljivo i prvo testirajte u neprodukcijskom okruženju.

P: Kako automatizirati nadzor i upozoravanje CHECKDB-a?

A: Koristiti SQL Server Upozorenja agenta za brojeve pogrešaka 8930, 8939 i druge. Implementirajte parsiranje zapisnika za izdvajanje rezultata CHECKDB-a i stvorite obavijesti za sva otkrića korupcije. Razmislite o korištenju okvira za rješenja za održavanje poput skripti Ole Hallengren.

P: Trebam li koristiti opciju EXTENDED_LOGICAL_CHECKS?

A: Samo ako sumnjate na složenu logičku korupciju i imate odgovarajuće opterećenje performansi. Ova opcija izvodi dodatne provjere indeksiranih prikaza, XML indeksa i prostornih indeksa, ali značajno povećava vrijeme izvršavanja.

11. Zaključak

11.1 Sažetak ključnih točaka

11.1.1 Sažetak bitnih DBCC CHECKDB naredbi

Savladajte osnovnu DBCC CHECKDB sintaksu za sveobuhvatnu provjeru baze podataka, koristite opcije NOINDEX i PHYSICAL_ONLY za optimizaciju performansi i shvatite CHECKTABLE za tarprovjera dobivene tablice. Ove temeljne naredbe čine temelj proaktivnog održavanja baze podataka, omogućujući rano otkrivanje korupcije i sustavno praćenje integriteta.

11.1.2 Podsjetnik na ključne najbolje prakse

Uvijek održavajte ažurne sigurnosne kopije prije pokretanja provjera integriteta, zakažite redovite CHECKDB operacije na temelju kritičnosti baze podataka i implementirajte automatizirano praćenje za neposredna upozorenja o oštećenju. Imajte na umu da prevencija redovitim praćenjem nadilazi reaktivne pristupe, a profesionalna rješenja za oporavak pružaju vrijedne opcije sigurnosnog kopiranja kada se standardni alati pokažu nedostatnima.

11.2 Kada koristiti DBCC CHECKDB u odnosu na napredna rješenja

Koristite DBCC CHECKDB za rutinsko praćenje integriteta i rješavanje manjih oštećenja, dok profesionalne alate za oporavak rezervirate za ozbiljne scenarije oštećenja izvan ugrađenih mogućnosti popravka. Okvir za odlučivanje trebao bi uzeti u obzir dostupnost sigurnosnih kopija, kritičnost podataka, vremenska ograničenja i ozbiljnost oštećenja. Uspješni administratori baza podataka kombiniraju redovito praćenje CHECKDB-a sa sveobuhvatnim strategijama sigurnosnog kopiranja i svjesnošću naprednih opcija oporavka kada se standardni pristupi pokažu neadekvatnima.

11.3 Kratka dnevna kontrolna lista za administratore baza podataka

Osim pokretanja DBCC CHECKDB, održavajte optimalno stanje baze podataka pomoću ovih bitnih dnevnih praksi:

1. Provjerite integritet sigurnosne kopije

Potvrdite da su planirane sigurnosne kopije uspješno dovršene
Koristite RESTORE VERIFYONLY za provjeru čitljivosti sigurnosne kopije
Osigurajte sinkronizaciju i dostupnost vanjskih kopija

Također možete dobiti više informacija od naš sveobuhvatni vodič o SQL Server rezerva.

2. Pregledajte status dosljednosti

Provjerite automatizirane rezultate DBCC CHECKDB iz noćnih izvršavanja
Praćenje SQL Server zapisnici pogrešaka za upozorenja o oštećenju
Odmah istražite sve propuste u integritetu

3. Pratite stanje poslužitelja

Provjerite metrike CPU-a, memorije i diskovnog I/O
Provjerite dostupnost tempdb prostora
Identificirajte blokirane procese i dugotrajne upite

4. Praćenje aktivnosti zastoja

Pregled grafova zastoja iz događaja ispravnosti sustava
Identificirajte problematične upite i optimizirajte ih s razvojnim timovima
Praćenje broja žrtava zastoja i utjecaja na poslovanje

Važni podsjetnici

Izbjegavajte često smanjivanje baze podataka – povećava fragmentaciju i smanjuje performanse. Smanjujte samo nakon brisanja većih podataka kada je to zaista potrebno.
Automatizirajte zadatke praćenja koristeći SQL Server Poslovi agenata ili planovi održavanja s upozorenjima za kritične probleme.
Testiranje postupaka oporavka od katastrofe tjedno kako bi se osiguralo da se sigurnosne kopije mogu oporaviti i da ciljevi oporavka ostanu ostvarivi.

Kombiniranjem ove dnevne kontrolne liste s redovitim DBCC CHECKDB operacijama, stvarate sveobuhvatnu zaštitu za okruženje vaše baze podataka putem proaktivnog praćenja i brzog odgovora na probleme.

12. Reference

Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server DokumentacijaMicrosoftova korporacija.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
Microsoft Learn. „Rješavanje problema s pogreškama konzistentnosti baze podataka koje prijavljuje DBCC CHECKDB.“ SQL Server DokumentacijaMicrosoftova korporacija.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors

DBCC CHECKDB: Potpuni vodič za MS SQL Server Zdravlje baze podataka (2026.)