DBCC CHECKDB je SQL ServerGlavni alat za integritet baze podataka. Naučite kako ga koristiti s primjerima, ispravite oštećenje i optimizirajte performanse.
1. Važnost SQL Server Zdravlje baze podataka
1.1 Šta je oštećenje baze podataka Costs Preduzeća
Danas, most Preduzeća pohranjuju svoje kritične podatke u baze podataka. Kada dođe do oštećenja baze podataka, posljedice su katastrofalne:
- Finansijski gubici Prosječno 2.3 miliona dolara godišnje zbog gubitka podataka, pri čemu su glavni uzroci kvar hardvera i oštećenje (EMC Corporation)
- Stope zatvaranja preduzeća pokazuju da 50% malih preduzeća koja dožive gubitak podataka zbog kvarova hardvera propadnu u roku od dvije godine, dok 94% preduzeća sa katastrofalnim gubitkom podataka uopšte ne preživi.
- Učestalost oštećenja podataka godišnje utič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 kvarova tvrdog diska i sistemskih kvarova, pri čemu se 40% gubitka podataka direktno pripisuje kvarovima hardvera
- Korupcija softvera costs kreću se od hiljada do miliona dolara, ovisno o ozbiljnosti i obimu, pri čemu je 82% preduzeća doživjelo neplanirane prekide u radu gdje je korupcija bila vodeći uzrok
1.2 Zašto su redovni zdravstveni pregledi ključni
Ljudima su potrebni redovni zdravstveni pregledi kako bi se potencijalne bolesti otkrile u ranoj fazi. Slično tome, i baze podataka trebaju redovne 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 stanja baze podataka su mnogo 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 komandi za održavanje zdravlja baze podataka, sa DBCC CHECKDB služi kao most Dostupan je sveobuhvatni alat za provjeru integriteta. Ove naredbe rade zajedno kako bi provjerile različite aspekte strukture vaše baze podataka, od pojedinačnih tabela do konzistentnosti cijele baze podataka, formirajući kompletnu strategiju održavanja koja čuva vaše podatke sigurnima i dostupnima.
2. Šta je DBCC CHECKDB
DBCC CHECKDB is SQL Serverje primarni alat za provjeru integriteta baze podataka i identifikaciju problema s korupcijom.
- 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 Šta CHECKDB zapravo provjerava u vašoj bazi podataka
Kada pokrenete DBCC CHECKDB, naredba vrši više slojeva validacije u strukturi vaše baze podataka:
- Verifikacija kontrolnih suma stranica za otkrivanje fizičke korupcije i problema povezanih s hardverom
- Validacija konzistentnosti indeksa kako bi se osiguralo pravilno preuzimanje podataka i izvođenje upita
- Provjere strukture alokacije kako bi se potvrdila tačna upotreba prostora i alokacija stranica
- Ispitivanje referencijalnog integriteta između povezanih tabela i odnosa sa stranim ključem
- Validacija konzistentnosti sistemske tabele osigurati SQL ServerInterni metapodaci ostaju pouzdani
- Verifikacija povezivanja stranica s podacima da potvrdi integritet ispravnog lanca stranica
- Konzistentnost sheme baze podataka za validaciju definicija i zavisnosti objekata
Ove sveobuhvatne provjere obuhvataju i korisničke podatke i sistemske strukture, pružajući potpuni uvid u stanje vaše baze podataka.
3. Pokretanje DBCC CHECKDB: Korak po korak
3.1 Preduvjeti
Ispod je kontrolna lista prije izvršavanja bilo koje DBCC CHECKDB operacije:
- Potpuna sigurnosna kopija baze podataka – Napravite potpunu sigurnosnu kopiju prije pokretanja provjera integriteta kao svoju sigurnosnu mrežu u slučaju da se otkrije oštećenje ili da su potrebne popravke.
- Odgovarajuće dozvole – Potrebne su vam dozvole sysadmin ili db_owner za izvršavanje DBCC CHECKDB naredbi
- Dovoljni sistemski resursi:
- Memorija: 25% veličine baze podataka
- Tempdb prostor: 10-15% veličine baze podataka
- CPU: 50-70% dostupnost tokom održavanja
- U/I: Očekujte velike operacije čitanja
- Pristupačnost baze podataka – Provjerite da li je vaša baza podataka dostupna i da nije u ograničenom stanju, jer CHECKDB zahtijeva pristup za čitanje svih stranica baze podataka
3.2 Osnovna komanda
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 po ID-u:
DBCC CHECKDB(5) -- Replace 5 with your database IDOva osnovna naredba vrši potpunu provjeru integriteta navedene baze podataka, ispitujući sve tabele, indekse i sistemske strukture. Za baze podataka sa standardnim imenima koja 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 funkcioniše za manje baze podataka ili kada imate dovoljno vremena za održavanje.
Ispod je snimak ekrana pokretanja DBCC CHECKDB u SQL Server Management Studio (SSMS):
3.3 Kompletne opcije
U nastavku su navedene kompletne opcije za DBCC CHECKDB:
| kategorija | opcija | Opis | Primjer DBCC CHECKDB-a |
|---|---|---|---|
| Opcije popravka | REPAIR_REBUILD |
Popravke bez gubitka podataka (npr. ponovna izgradnja indeksa) | DBCC CHECKDB ('MyDB', REPAIR_REBUILD) |
REPAIR_FAST |
Bez popravke. 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 memorije (stranice/zapisi) | DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY) |
|
DATA_PURITY |
Provjerava logičke greške u vrijednostima kolone (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 greške (zadano: 200 po objektu) | DBCC CHECKDB ('MyDB', ALL_ERRORMSGS) |
NO_INFOMSGS |
Skriva informativne poruke | DBCC CHECKDB ('MyDB', NO_INFOMSGS) |
|
| performanse | TABLOCK |
Koristi zaključavanje tabela (smanjuje korištenje TempDB-a, ali blokira pisanje) | DBCC CHECKDB ('BigDB', TABLOCK) |
MAXDOP = number |
Zaobilazi 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 na osnovu toga da li je njegovo izvršavanje uspješno završeno ili ne. Hajde da ih detaljno objasnimo.
4.1 Izvršavanje CHECKDB naredbe uspješno 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 ovom:
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 greške u vezi s oštećenjem
Kad god DBCC CHECKDB otkrije grešku usljed oštećenja, prijavit će poruku o grešci sa sljedećom strukturom:
Vodič za nivo ozbiljnosti:
- Nivo 16-19: Greške koje korisnik može ispraviti, često manja oštećenja
- Nivo 20-24: Sistemske greške, ozbiljna korupcija koja zahtijeva hitnu pažnju
- Nivo 25: Fatalne greške, baza podataka možda nije dostupna
Uobičajene greške uključuju:
- Greške kontrolne sume stranice (poruka 824)
- Greške pri alokaciji (poruka 8928)
- Problemi s konzistentnošću indeksa (poruka 8964)
Razumijevanje strukture poruke pomaže u određivanju prioriteta akcija odgovora i određivanju odgovarajućih strategija oporavka.
4.1.3 Uobičajene informativne i upozoravajuće poruke
Nisu svi izlazi DBCC CHECKDB znak za ozbiljne probleme. Također mogu prikazati neke informativne i upozoravajuće poruke, uključujući:
- Izjave o popravci – Poruke koje predlažu naredbe za popravku manjih problema
- Upozorenja o alokaciji – Upozorenja o alokaciji prostora koja ne utiču na pristup podacima
- Preporuke za performanse – Prijedlozi za održavanje i optimizaciju indeksa
- Informativna obavještenja – Opšte poruke o statusu koje ne zahtijevaju hitnu akciju
Ove poruke pružaju vrijedne smjernice za održavanje, istovremeno razlikujući kritične probleme koji zahtijevaju hitnu akciju od manjih problema koji se mogu riješiti tokom 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 naredbe
Ako CHECKDB prekine tokom izvršavanja iz različitih razloga, prijavit će poruku o grešci i dodati zapisnik o grešci sa sljedećim kodom stanja:
| stanje | Opis |
|---|---|
0 |
Pojavila se greška broj 8930. Ovo 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 greške tokom popravke baze podataka u hitnom režimu. |
3 |
Ovo ukazuje na oštećenje metapodataka koji je prekinuo 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 greš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.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'.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 da biste ispravili oštećenje u vašoj bazi podataka.
5. Ispravljanje grešaka uzrokovanih korupcijom
5.1 Sigurnosna kopija i vraćanje: Najsigurnije rješenje
Kada DBCC CHECKDB identificira greške u oštećenju, vraćanje iz čiste sigurnosne kopije predstavlja najsigurniji i najučinkovitiji način.ost pouzdano rješenje. Ovaj pristup garantuje integritet podataka, a istovremeno eliminiše osnovne uzroke oštećenja. Prije vraćanja, provjerite integritet sigurnosne kopije koristeći VRATI SAMO POTVRDI naredbe i razmotrite opcije oporavka u određenom trenutku kako biste smanjili gubitak podataka. Dokumentujte detalje o oštećenju radi analize 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 nivou stranice
Za izolovano oštećenje stranice koje utič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 restauracije baze podataka. Ova napredna tehnika zahtijeva model potpunog oporavka i trenutne sigurnosne kopije dnevnika.
Postupak vraćanja stranice korak po korak:
- Identifikujte oštećenu stranicu iz poruke o grešci CHECKDB (npr. stranica 1:256)
- Napravite trenutnu sigurnosnu kopiju dnevnika za prikupljanje nedavnih transakcija:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'- Vratite 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 dnevnika redom, uključujući i upravo kreiranu:
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 konačnu sigurnosnu kopiju dnevnika i vratite je da ažurirate stranicu:
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 utiče na nekritične podatke, možete izvesti nepromijenjene redove u nove tabele prije ponovnog kreiranja 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 data5.3 Brza rješenja za oštećenje indeksa
Oštećenje indeksa često dobro reaguje na operacije ponovnog kreiranja koje rekreiraju strukture indeksa bez uticaja na podatke osnovne tabele:
ALTER INDEX ALL ON YourTable REBUILDOvaj pristup posebno dobro funkcionira za oštećenje neklasteriranih indeksa, jer ponovna izgradnja regenerira stranice indeksa iz podataka izvorne tabele, efektivno eliminirajući oštećenje uz očuvanje svih originalnih informacija.
6. Koristite REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS
Ako sve prethodne metode ne uspiju ili nisu izvodljive, možete koristiti opcije REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS za popravak baze podataka.
6.1 POPRAVAK_OBNOVA (Sigurnija opcija):
- Upotreba za: Oštećenje indeksa i manje greške u alokaciji
- Sigurnost podataka: Pokušava ispraviti oštećenje bez brisanja podataka
- Nivo rizika: Nisko – ne očekuje se gubitak podataka
- Tipični scenariji: Oštećenje neklasterovanog indeksa, manji problemi s metapodacima
- Primjer naredbe:
DBCC CHECKDB('YourDB', REPAIR_REBUILD)
6.2 POPRAVAK_DOZVOLJENOG_GUBITKA_PODATAKA (Posljednja opcija):
- Upotreba za: Ozbiljna korupcija kada sigurnosne kopije nisu dostupne
- Sigurnost podataka: Može izbrisati oštećene podatke kako bi se vratila funkcionalnost baze podataka
- Nivo rizika: Visoko – moguć je trajni gubitak podataka
- Tipični scenariji: Oštećenje stranice, oštećenje sistemske tabele, greške u lancu alokacije
- Primjer naredbe:
DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)
6.3 Najbolje prakse za ove opcije:
- Uvijek testirajte operacije popravke na kopijama baze podataka kada je to moguće
- Uvijek pravi sigurnosnu kopiju prije pokretanja ovih opcija
- Dokumentujte sve promjene u svrhu usklađenosti i rješavanja problema
- Postavljanje baze podataka na jednokorisnički način rada prije izvođenja popravki
Normalno, trebali bismo pokušati POPRAVAK_OBNOVA prvo opciju. Ako ne uspije, pokušajte REPAIR_ALLOW_DATA_LOSS opcija.
6.4 Rezultati POPRAVKA_DOZVOLJENOG_GUBITKA_PODATAKA
6.4.1 Popravak uspijeva uz gubitak podataka
Ponekad REPAIR_ALLOW_DATA_LOSS opcija će uspjeti, ali neki podaci su izgubljeniost nakon popravke.
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 i dalje može oporaviti putem DataNumen SQL Recovery.
Primjeri datoteka:
| SQL Server verzija | Oštećena MDF datoteka | MDF fajl popravljen od strane DataNumen SQL Recovery |
| SQL Server 2014 | Greška10_1.mdf (Poruka 8909 nakon koje slijedi poruka 8939) (600 zapisa lost sa POPRAVAK_DOZVOLJENOG_GUBIKA_PODATAKA) | Greška10_1_fixed.mdf (Nema zapisa lost) |
| SQL Server 2014 | Greška10_2.mdf (Poruka 8909 nakon koje slijedi poruka 8939) (6000 zapisa (50%) lost sa POPRAVAK_DOZVOLJENOG_GUBIKA_PODATAKA) | Greška10_2_fixed.mdf (Samo 100 zapisaost) |
| SQL Server 2014 | Greška 7.mdf (100 zapisa lost sa POPRAVAK_DOZVOLJENOG_GUBIKA_PODATAKA) | Error7_fixed.mdf (Samo jedan zapis lost) |
6.4.2 Popravka ne uspije – Razmotrite profesionalno rješenje
If REPAIR_ALLOW_DATA_LOSS ne uspije, prikazaće jednu ili više poruka o grešci.
U nastavku su 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 ovim scenarijima, potrebno je koristiti profesionalno rješenje, kao što je DataNumen SQL Recovery da popravite svoju bazu podataka.
Primjeri datoteka
| SQL Server verzija | Oštećena MDF datoteka | MDF fajl popravljen od strane DataNumen SQL Recovery |
| SQL Server 2014 | Greška1_3.mdf (Jedna poruka 824) | Greška1_3_fixed.mdf |
| SQL Server 2014 | Greška1_1.mdf (Kontinuirana poruka greške 824) | Greška1_1_fixed.mdf |
| SQL Server 2014 | Greška1_2.mdf ((Poruka 824 nakon koje slijedi poruka 7909) | Greška1_2_fixed.mdf |
| SQL Server 2014 | Greška4_1.mdf (Poruka 8992 nakon koje slijedi poruka 3852) | Greška4_1_fixed.mdf |
| SQL Server 2014 | Greška4_2.mdf (Poruka 8992 nakon koje slijedi poruka 3852) | Greška4_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 | Greška 8.mdf (Poruka 5125) | Greška 8_fixed.mdf |
| SQL Server 2014 | Greška9.mdf (Poruka 3313) | Error9_fixed.mdf |
7. Najbolje prakse
7.1 Planiranje redovnih CHECKDB operacija
Implementirajte sedmično izvršavanje DBCC CHECKDB naredbe za kritične produkcijske baze podataka, s dnevnim provjerama za sisteme s visokim brojem transakcija. Planirajte operacije tokom perioda niske upotrebe kako biste smanjili utjecaj na performanse i razmotrite rotiranje između punih provjera i opcija PHYSICAL_ONLY na osnovu veličine baze podataka i prozora održavanja. Automatsko zakazivanje putem SQL Server Agent osigurava konzistentno izvršavanje, a istovremeno pruža centralizovane mogućnosti praćenja i upozoravanja.
7.2 Upravljanje utjecajem na učinak
DBCC CHECKDB operacije troše značajne sistemske resurse, što potencijalno utiče na istovremenu aktivnost korisnika. Pratite iskorištenost CPU-a, potrošnju memorije i I/O operacija na disku tokom 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 produženja vremenskog ograničenja upita i strategije komunikacije s korisnicima kako biste upravljali očekivanjima tokom perioda provjere integriteta.
7.3 Planiranje vremenskog okvira održavanja
Koordinirajte DBCC CHECKDB raspoređivanje s drugim aktivnostima održavanja kao što su operacije sigurnosnog kopiranja, ponovna izgradnja indeksa i ažuriranja statistike. Izbjegavajte preklapanje operacija koje zahtijevaju mnogo resursa, a koje bi mogle uzrokovati smanjenje performansi ili probleme s istekom vremena. Planirajte prozore za održavanje na osnovu 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 upozoravanje
konfigurisati SQL Server Agent šalje upozorenja kako bi odmah obavijestio administratore kada DBCC CHECKDB identificira oštećenje. Implementirajte rješenja za parsiranje logova koja izdvajaju i kategoriziraju rezultate provjere integriteta, omogućavajući analizu trendova i proaktivnu identifikaciju problema. Kreirajte procedure eskalacije koje definiraju vremenske okvire odgovora i odgovorno osoblje za različite nivoe ozbiljnosti oštećenja.
8. DBCC CHECKTABLE: Lagana alternativa
8.1 Kada koristiti CHECKTABLE umjesto CHECKDB
DBCC CHECKTABLE pruža fokusiranu provjeru integriteta za pojedinačne tabele, š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 tabela, validacije kritičnih poslovnih tabela između potpunih provjera baze podataka ili kada vremenska ograničenja sprječavaju potpunu validaciju baze podataka. Ovaj pristup se pokazao posebno vrijednim 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 tardobija određene tabele:
DBCC CHECKTABLE('YourTable')Kao i CHECKDB, CHECKTABLE podržava različite opcije, uključujući NOINDEX za optimizaciju performansi i parametre za popravak radi rješavanja problema s oštećenjima. Također možete odrediti nazive shema za preciznu identifikaciju tabela:
DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)ovo tarGeted pristup omogućava detaljnu provjeru integriteta uz održavanje performansi sistema tokom radnog vremena.
8.3 Prednosti performansi za velike baze podataka
CHECKTABLE operacije se izvršavaju znatno brže od potpunih provjera baze podataka, što omogućava češću provjeru integriteta kritičnih tabela. Ovaj pristup omogućava dnevnu validaciju bitnih poslovnih tabela, dok se sveobuhvatne CHECKTABLE operacije rezervišu za sedmične ili mjesečne rasporede. Smanjena potrošnja resursa čini CHECKTABLE pogodnim za izvršavanje u produkcijskom okruženju uz minimalan uticaj na korisnika.
9. Kada CHECKDB ne uspije
DBCC CHECKDB neće uspjeti u različitim scenarijima, uključujući:
- Izvršenje DBCC CHECKDB-a završava se abnormalno
- Izvršavanje DBCC CHECKDB naredbe se uspješno završava, ali opcije popravke ne uspijevaju popraviti bazu podataka.
U ovim scenarijima, potreban nam je profesionalniji alat koji će nam pomoći da ispravimo greške 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 tabele, indekse, prikaze, okidače, pravila i podrazumevane vrednosti.
- Oporavi pohranjene procedure, skalarne funkcije, inline 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 baze podataka.
- Popravak MDF datoteka u serijama.
- Opsežne opcije popravke.
- Napredno evidentiranje i izvještavanje.
- Podrška za sve SQL Server verzije.
- Dostupnost tehničke podrške
- Redovna ažuriranja i poboljšanja
9.2 Poređenje stope uspjeha
Stope uspješnosti oporavka značajno se razlikuju:
- DBCC CHECKDB i CHECKTABLEC: 1.27% prosječna stopa oporavka
- DataNumen: 92.6% stopa oporavka
Ispod je kompletno poređenje konkurencije:
9.3 Oporavak od teške korupcije
Napredne mogućnosti za teške slučajeve:
- Oporavak od fizički oštećenog skladišta
- Oporavak sa formatiranih diskova ili srušenih sistema
- Oporavak sa slika diska, datoteka rezervnih kopija, datoteka diska virtuelne mašine, temparary fajlove itd.
9.4 Kada razmotriti profesionalna rješenja
- Nema nedavnih sigurnosnih kopija
- DBCC CHECKDB ne uspijeva
- Teški scenariji korupcije
- Rad s kritičnim poslovnim podacima
- Kada je vreme kritično
- Kada je neophodan maksimalan 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 treba pokretati sedmično. Za sisteme s velikim brojem transakcija, razmotrite dnevne provjere koristeći opciju PHYSICAL_ONLY, s potpunim provjerama sedmično. 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 raditi na online bazama podataka bez blokiranja korisnika. Međutim, troši značajne resurse, stoga ga zakažite tokom perioda niske aktivnosti i pratite performanse sistema.
P: Koja je razlika između CHECKDB i CHECKTABLE?
A: CHECKTABLE pregleda cijelu bazu podataka, dok se CHECKTABLE fokusira na pojedinačne tabele. Koristite CHECKTABLE za tarrješavanje problema ili kada trebate provjeriti određene tabele bez skeniranja cijele baze podataka.
10.2 Pitanja o performansama i resursima
P: Zašto DBCC CHECKDB traje toliko dugo na mojoj velikoj bazi podataka?
A: Trajanje CHECKDB naredbe zavisi od veličine baze podataka, performansi hardvera i korištenih opcija. Koristite PHYSICAL_ONLY za brže provjere ili NOINDEX za preskakanje neklasteriranih indeksa. Razmislite o pokretanju naredbe tokom perioda održavanja sa namjenskim resursima.
P: Koliko tempdb prostora je potrebno za CHECKDB?
A: Generalno, dodijelite 10-15% veličine vaše baze podataka za tempdb tokom CHECKDB operacija. Koristite opciju ESTIMATEONLY da biste dobili precizne procjene: 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 ponovo pokrenuti kasnije.
10.3 Pitanja o rukovanju greškama
P: CHECKDB je pronašao greške – trebam li paničariti?
A: Ne paničite, već djelujte brzo. Prvo utvrdite da li je CHECKDB uspješno završen, ali je pronašao oštećenje, ili se sam CHECKDB nije uspio pokrenuti. Provjerite da li greške utiču samo na neklasterovane indekse (manje kritično) ili na podatke u tabeli (ozbiljnije).
P: Kada trebam koristiti REPAIR_ALLOW_DATA_LOSS?
A: Samo kao apsolutno posljednje rješenje kada nemate upotrebljive sigurnosne kopije i gubitak podataka je prihvatljiv u poređenju sa potpunim gubitkom baze podataka. Uvijek prvo pokušajte vratiti podatke iz sigurnosne kopije, jer operacije popravke mogu uzrokovati trajni gubitak podataka.
P: Šta znači „greške konzistentnosti u bazi podataka“ u odnosu na „greške alokacije“?
A: Greške u alokaciji utiču na to kako SQL Server prati korištenje prostora na disku, dok greške konzistentnosti ukazuju na probleme sa podacima ili strukturama indeksa. Obje zahtijevaju pažnju, ali greške konzistentnosti obično direktnije utiču na dostupnost podataka.
10.4 Pitanja o sigurnosnoj kopiji i oporavku
P: Da li trebam pokrenuti CHECKDB na svojim sigurnosnim kopijama?
A: Apsolutno! Pokrenite CHECKDB nakon vraćanja sigurnosnih kopija na testne servere. Ovo provjerava integritet sigurnosne kopije i osigurava da se zaista možete oporaviti od oštećenja. Automatizirajte ovaj proces ako je moguće.
P: Moja sigurnosna kopija je također oštećena – šta sad?
A: Isprobajte starije sigurnosne kopije dok ne pronađete čistu. Ako ne postoje čiste sigurnosne kopije, razmislite o profesionalnim rješenjima za oporavak kao što je DataNumen SQL RecoveryDokumentujte vremenski tok 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 praćenje odgovarajućih procedura.
10.5 Pitanja o rješavanju problema
P: CHECKDB ne uspijeva sa greškom „nema dovoljno prostora“ – šta mogu učiniti?
A: Oslobodite prostor u tempdb bazi podataka, premjestite tempdb na bržu pohranu ili koristite opciju TABLOCK da biste smanjili korištenje tempdb baze podataka. Razmislite o pokretanju CHECKDB s NOINDEX ili PHYSICAL_ONLY da biste smanjili zahtjeve za resursima.
P: Kako da utvrdim koja tabela ima greške na osnovu CHECKDB izlaza?
A: Potražite brojeve "objekta ID" u porukama o grešci, a zatim koristite: SELECT OBJECT_NAME(object_id) da pronađete nazive tabela. Poruke o grešci također uključuju brojeve stranica i slotova za preciznu identifikaciju lokacije.
P: Mogu li problemi s hardverom uzrokovati da CHECKDB prijavljuje lažno pozitivne rezultate?
A: Da, kvar hardvera (posebno memorije) može uzrokovati povremenu korupciju koja se pojavljuje i nestaje između izvršavanja CHECKDB-a. Ako su greške nekonzistentne, istražite svoj I/O podsistem 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 se datoteke baze podataka nalaze na odvojenim diskovima. Koristite ih pažljivo i prvo testirajte u neprodukcijskom okruženju.
P: Kako da automatizujem praćenje i upozoravanje CHECKDB-a?
A: upotreba SQL Server Obavještenja agenta za greške brojeva 8930, 8939 i druge. Implementirajte parsiranje logova kako biste izdvojili rezultate CHECKDB-a i kreirali obavještenja za sva otkrića korupcije. Razmislite o korištenju okvira za rješenja za održavanje poput skripti Ole Hallengren.
P: Da li trebam koristiti opciju EXTENDED_LOGICAL_CHECKS?
A: Samo ako sumnjate na složenu logičku korupciju i imate odgovarajuće opterećenje performansi. Ova opcija vrši 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 tačaka
11.1.1 Sažetak osnovnih DBCC CHECKDB naredbi
Savladajte osnovnu DBCC CHECKDB sintaksu za sveobuhvatnu provjeru baze podataka, koristite opcije NOINDEX i PHYSICAL_ONLY za optimizaciju performansi i razumite CHECKTABLE za tarVerifikacija dobijene tabele. Ove osnovne komande čine osnovu proaktivnog održavanja baze podataka, omogućavajući rano otkrivanje korupcije i sistematsko 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 redovne CHECKDB operacije na osnovu kritičnosti baze podataka i implementirajte automatizirano praćenje za neposredna upozorenja o oštećenju. Zapamtite da prevencija putem redovnog praćenja nadmašuje reaktivne pristupe, a profesionalna rješenja za oporavak pružaju vrijedne opcije sigurnosnog kopiranja kada se standardni alati pokažu nedovoljnim.
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 koristite za ozbiljne scenarije oštećenja izvan ugrađenih mogućnosti popravka. Okvir za odlučivanje treba uzeti u obzir dostupnost sigurnosnih kopija, kritičnost podataka, vremenska ograničenja i ozbiljnost oštećenja. Uspješni administratori baza podataka kombiniraju redovno praćenje CHECKDB-a sa sveobuhvatnim strategijama sigurnosnog kopiranja i svjesnošću naprednih opcija oporavka kada se standardni pristupi pokažu neadekvatnim.
11.3 Kratka dnevna lista provjere zdravlja za administratore baza podataka
Pored pokretanja DBCC CHECKDB, održavajte optimalno stanje baze podataka pomoću ovih osnovnih dnevnih praksi:
1. Provjerite integritet sigurnosne kopije
- Potvrdite da su planirane sigurnosne kopije uspješno završene
- Koristite RESTORE VERIFYONLY za provjeru čitljivosti sigurnosne kopije
- Osigurajte sinhronizaciju i dostupnost vanjskih kopija
Također možete dobiti više informacija od naš sveobuhvatni vodič o SQL Server rezerva.
2. Pregledajte status konzistentnosti
- Provjerite automatizirane rezultate DBCC CHECKDB iz noćnih izvršavanja
- monitor SQL Server zapisnici grešaka za upozorenja o oštećenju
- Odmah istražite sve propuste u integritetu
3. Pratite zdravlje servera
- Provjerite metrike CPU-a, memorije i diska I/O
- Provjerite dostupnost tempdb prostora
- Identifikujte blokirane procese i dugotrajne upite
4. Praćenje aktivnosti zastoja
- Pregledajte grafikone zastoja iz događaja ispravnosti sistema
- Identifikujte problematične upite i optimizujte ih sa razvojnim timovima
- Pratite broj žrtava zastoja i njihov utjecaj na poslovanje
Važni podsjetnici
- Izbjegavajte često smanjivanje baze podataka – povećava fragmentaciju i smanjuje performanse. Smanjujte podatke samo nakon brisanja većih podataka kada je to zaista neophodno.
- Automatizirajte zadatke praćenja korišćenje SQL Server Poslovi agenta ili planovi održavanja s upozorenjima za kritične probleme.
- Testiranje procedura za oporavak od katastrofe sedmično kako bi se osiguralo da se sigurnosne kopije mogu oporaviti i da ciljevi oporavka ostanu ostvarivi.
Kombinacijom ove dnevne kontrolne liste s redovnim DBCC CHECKDB operacijama, kreirate sveobuhvatnu zaštitu za okruženje vaše baze podataka putem proaktivnog praćenja i brzog odgovora na probleme.
12. Literatura
- Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server DokumentacijaMicrosoft 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 greškama u konzistentnosti baze podataka koje prijavljuje DBCC CHECKDB.“ SQL Server DokumentacijaMicrosoft korporacija.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors