DBCC CHECKDB е SQL ServerОсновният инструмент за целостност на базата данни. Научете как да го използвате с примери, да отстранявате повреди и да оптимизирате производителността.
1. Значение на SQL Server Състояние на базата данни
1.1 Какво представлява корупцията в базата данни Costбизнеси
Днес, мost Фирмите съхраняват критичните си данни в бази данни. Когато възникне повреда в базата данни, последствията са катастрофални:
- Финансови загуби средно 2.3 милиона долара годишно поради загуба на данни, като основните причини са хардуерни повреди и корупция (EMC Corporation)
- Процент на затваряне на бизнеси показват, че 50% от малките предприятия, които претърпяват загуба на данни поради хардуерни повреди, фалират в рамките на две години, докато 94% от предприятията с катастрофална загуба на данни изобщо не оцеляват.
- Честота на корупция на данни засяга 20% от критично важните приложения годишно, причинявайки прекъсвания на непрекъснатостта на бизнеса (изследване на Gartner)
- Повреда, свързана с хардуера представлява 67% от всички инциденти със загуба на данни поради сривове на твърди дискове и системни повреди, като 40% от загубата на данни се дължи директно на хардуерни неизправности
- Корупция в софтуера costs варират от хиляди до милиони долари в зависимост от тежестта и обхвата, като 82% от предприятията са претърпели непланирани прекъсвания, при които корупцията е била водеща причина
1.2 Защо редовните здравни прегледи са критични
Хората се нуждаят от редовни здравни прегледи, за да открият потенциални заболявания рано. По подобен начин базите данни също се нуждаят от редовни здравни проверки:
- Откривайте потенциална корупция рано и се справяйте с нея своевременно, предотвратявайки проблемите да станат сериозни и широко разпространени, което би могло да доведе до катастрофални последици за бизнеса.
- Уверете се, че базата данни работи с оптимална производителност.
- В cost Проактивните проверки на състоянието на базата данни са много по-ниски от тези за реактивно възстановяване на данни след възникване на катастрофа в базата данни.
1.3 Въведение в командите за целостта на базата данни
SQL Server предоставя няколко вградени команди за поддържане на здравето на базата данни, с DBCC CHECKDB служещ като мost Наличен е цялостен инструмент за проверка на целостта. Тези команди работят заедно, за да проверят различни аспекти на структурата на вашата база данни, от отделни таблици до цялостна съгласуваност на базата данни, образувайки цялостна стратегия за поддръжка, която пази данните ви в безопасност и достъпни.
2. Какво е DBCC CHECKDB
DBCC CHECKDB is SQL Serverосновният инструмент за проверка на целостта на базата данни и идентифициране на проблеми с корупция.
- Това е T-SQL оператор, а не GUI инструмент.
- Можете да го изпълните чрез обичайни методи, като например SQL Server Студио за управление (SSMS), SQL Server Агент, SQLCMD и др.
2.1 Какво всъщност проверява CHECKDB във вашата база данни
Когато изпълнявате DBCC CHECKDB, командата извършва множество слоеве за валидиране в структурата на вашата база данни:
- Проверка на контролните суми на страницата за откриване на физически повреди и проблеми, свързани с хардуера
- Валидиране на съгласуваност на индекса за да се осигури правилно извличане на данни и изпълнение на заявките
- Проверки на структурата на разпределение за да се потвърди точното използване на пространството и разпределението на страниците
- Проверка за референтна цялост между свързани таблици и връзки с външен ключ
- Валидиране на съгласуваност на системната таблица за да се гарантира SQL ServerВътрешните метаданни на остават надеждни
- Проверка на свързването на страници с данни за да се потвърди правилната целостност на веригата на страниците
- Съгласуваност на схемата на базата данни да валидира дефинициите и зависимостите на обекти
Тези всеобхватни проверки обхващат както потребителските данни, така и системните структури, осигурявайки пълна видимост върху състоянието на вашата база данни.
3. Изпълнение на DBCC CHECKDB: стъпка по стъпка
3.1 Предпоставки
По-долу е даден контролният списък преди изпълнение на каквато и да е DBCC CHECKDB операция:
- Пълно архивиране на базата данни – Създайте пълно резервно копие, преди да извършите проверки за целостта, като ваша предпазна мрежа в случай на откриване на повреда или необходимост от поправка.
- Подходящи разрешения – Необходими са ви права на администратор на системата или собственик на базата данни, за да изпълнявате команди DBCC CHECKDB.
- Достатъчни системни ресурси:
- Памет: 25% от размера на базата данни
- Tempdb пространство: 10-15% от размера на базата данни
- CPU: 50-70% наличност по време на поддръжка
- Входно/изходно: Очаквайте тежки операции за четене
- Достъпност на базата данни – Проверете дали базата данни е достъпна и не е в ограничено състояние, тъй като CHECKDB изисква достъп за четене до всички страници на базата данни
3.2 Основна команда
Мost Основната команда DBCC CHECKDB включва три често срещани варианта:
(1) Проверете текущата база данни (без параметри):
DBCC CHECKDB(2) Проверете база данни по име:
DBCC CHECKDB ('YourDatabaseName')S Проверка на база данни по ID:
DBCC CHECKDB(5) -- Replace 5 with your database IDТази основна команда извършва пълна проверка на целостта на посочената база данни, като разглежда всички таблици, индекси и системни структури. За бази данни със стандартни имена, които не съдържат интервали, можете да пропуснете кавичките. Командата ще се изпълнява до завършване, показвайки съобщения за напредък и крайни резултати. Този основен синтаксис работи перфектно за по-малки бази данни или когато имате достатъчно време за поддръжка.
По-долу е показана екранна снимка на изпълнението на DBCC CHECKDB в SQL Server Студио за управление (SSMS):
3.3 Пълни опции
По-долу са пълните опции за DBCC CHECKDB:
| категория | Опция | Описание | Пример за DBCC CHECKDB |
|---|---|---|---|
| Опции за ремонт | REPAIR_REBUILD |
Поправки без загуба на данни (напр. възстановяване на индекси) | DBCC CHECKDB ('MyDB', REPAIR_REBUILD) |
REPAIR_FAST |
Без поправка. Само обратна съвместимост. | DBCC CHECKDB ('MyDB', REPAIR_FAST) |
|
REPAIR_ALLOW_DATA_LOSS |
Поправя всички грешки (може да причини загуба на данни) | DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS) |
|
| Контрол на обхвата | NOINDEX |
Пропуска проверките на неклъстерирани индекси | DBCC CHECKDB ('LargeDB', NOINDEX) |
PHYSICAL_ONLY |
Проверява само целостта на физическото хранилище (страници/записи) | DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY) |
|
DATA_PURITY |
Проверява за логически грешки в стойностите на колоните (напр. невалидни дати) | DBCC CHECKDB ('OldDB', DATA_PURITY) |
|
EXTENDED_LOGICAL_CHECKS |
Дълбоки логически проверки (индексирани изгледи, XML/пространствени индекси) | DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS) |
|
| Изходен контрол | ALL_ERRORMSGS |
Показва всички грешки (по подразбиране: 200 на обект) | DBCC CHECKDB ('MyDB', ALL_ERRORMSGS) |
NO_INFOMSGS |
Скрива информационни съобщения | DBCC CHECKDB ('MyDB', NO_INFOMSGS) |
|
| Производителност | TABLOCK |
Използва таблични заключвания (намалява използването на TempDB, но блокира записите) | DBCC CHECKDB ('BigDB', TABLOCK) |
MAXDOP = number |
Заменя настройките за паралелизъм | DBCC CHECKDB ('MyDB', MAXDOP = 2) |
|
| Utility | ESTIMATEONLY |
Оценява необходимото пространство във TempDB. (без реална проверка) | DBCC CHECKDB ('MyDB', ESTIMATEONLY) |
4. Разбиране на резултатите
DBCC CHECKDB ще даде различни резултати в зависимост от това дали изпълнението му е завършено успешно или не. Нека ги обясним подробно.
4.1 Изпълнението на CHECKDB завършва успешно
Ако изпълнението на DBCC CHECKDB завърши успешно, то ще докладва различни видове резултати в зависимост от състоянието на вашата база данни.
4.1.1 Не са открити проблеми
Ако DBCC CHECKDB не открие никакви проблеми, ще видите резултат, подобен на:
CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.Този резултат показва, че вашата база данни поддържа перфектна цялост във всички проверени структури.
4.1.2 Открити грешки, свързани с корупция
Всеки път, когато DBCC CHECKDB открие грешка за повреда, ще докладва съобщение за грешка със следната структура:
Ръководство за нива на тежест:
- Ниво 16-19: Грешки, които потребителят може да поправи, често незначителни повреди
- Ниво 20-24: Системни грешки, сериозна корупция, изискваща незабавно внимание
- Ниво 25: Фатални грешки, базата данни може да е недостъпна
Често срещаните грешки включват:
- Неуспехи при контролната сума на страницата (съобщение 824)
- Грешки при разпределение (съобщение 8928)
- Проблеми с консистентността на индекса (съобщение 8964)
Разбирането на структурата на съобщението помага за приоритизиране на действията за реагиране и определяне на подходящи стратегии за възстановяване.
4.1.3 Често срещани информационни и предупредителни съобщения
Не всички изходни данни на DBCC CHECKDB показват сериозни проблеми. Възможно е също така да се изведат някои информационни и предупредителни съобщения, включително:
- Ремонтни актове – Съобщения, които предлагат команди за поправка на дребни проблеми
- Предупреждения за разпределение – Предупреждения относно разпределението на пространството, които не засягат достъпа до данни
- Препоръки за ефективност – Предложения за поддръжка и оптимизация на индекса
- Информационни съобщения – Общи съобщения за състояние, които не изискват незабавни действия
Тези съобщения предоставят ценни насоки за поддръжка, като същевременно разграничават критични повреди, изискващи незабавни действия, от незначителни проблеми, които могат да бъдат отстранени по време на редовните прозорци за поддръжка.
Примерно предупредително съобщение:
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 Прекъсвания на изпълнението на CHECKDB
Ако CHECKDB прекъсне изпълнението си поради различни причини, ще се докладва съобщение за грешка и ще се добави лог за грешки със следния код на състоянието:
| Област | Описание |
|---|---|
0 |
Възникна грешка номер 8930. Това показва повреда в метаданните, която е прекратила командата DBCC. |
1 |
Възникна грешка номер 8967. Възникна вътрешна DBCC грешка. |
2 |
Възникна грешка по време на поправката на базата данни в авариен режим. |
3 |
Това показва повреда в метаданните, която е прекратила командата DBCC. |
4 |
Открито е нарушение на твърдение или достъп. |
5 |
Възникна неизвестна грешка, която прекрати командата DBCC. |
Примерно съобщение за грешка:
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'.Примерен лог за грешки:
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.В такъв случай можете да опитате алтернативни разширени опции, като например DataNumen SQL Recovery за да поправите повредата във вашата база данни.
5. Поправяне на грешки, свързани с корупция
5.1 Архивиране и възстановяване: Най-безопасното решение
Когато DBCC CHECKDB идентифицира грешки в корупцията, възстановяването от чист архив представлява най-безопасният и най-безопасен метод.ost надеждно решение. Този подход гарантира целостта на данните, като същевременно елиминира основните причини за повреда. Преди възстановяване, проверете целостта на резервното копие, използвайки ВЪЗСТАНОВЯВАНЕ САМО ПРОВЕРКА команди и обмислете опции за възстановяване към определен момент, за да сведете до минимум загубата на данни. Документирайте подробностите за повредата за анализ на първопричината, тъй като хардуерните проблеми или софтуерните грешки може да изискват допълнително внимание, за да се предотврати повторение.
5.2 Решения за корупция на ниво страница
За изолирана повреда на страница, засягаща малки части от данни, SQL Server Enterprise Edition предлага възможности за възстановяване на страници, които поправят конкретни повредени страници без пълно възстановяване на базата данни. Тази усъвършенствана техника изисква пълен модел за възстановяване и текущи резервни копия на лог файлове.
Процесът на възстановяване на страница стъпка по стъпка:
- Идентифицирайте повредената страница от съобщението за грешка CHECKDB (напр. страница 1:256)
- Направете резервно копие на текущия лог за да се заснемат последните транзакции:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'- Възстановете повредената страница от мost скорошно пълно архивиране:
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Full.bak'- Прилагане на диференциално архивиране (ако е налична):
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Diff.bak'- Прилагане на всички резервни копия на лог файлове последователно, включително току-що създадената:
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'- Направете окончателно архивиране на лог файлове и го възстановете за да актуализирате страницата:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'Алтернатива за некритични данни: Ако повредата засяга некритични данни, можете да експортирате незасегнати редове в нови таблици, преди да възстановите повредените структури:
-- 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 Бързи решения за повреда в индекса
Корупцията в индексите често се повлиява добре от операции за възстановяване, които пресъздават структурите на индексите, без да засягат данните в таблицата:
ALTER INDEX ALL ON YourTable REBUILDТози подход работи особено добре при корупция в неклъстерни индекси, тъй като възстановяването регенерира индексните страници от данните на изходната таблица, като ефективно елиминира корупцията, като същевременно запазва цялата оригинална информация.
6. Използвайте REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS
Ако всички предишни методи се провалят или не са приложими, можете да използвате опциите REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS, за да поправите базата данни.
6.1 РЕМОНТ_ВЪЗСТАНОВЯВАНЕ (По-безопасен вариант):
- Използвай за: Повреда на индекса и незначителни грешки в разпределението
- Безопасност на данните: Опити за отстраняване на повреди без изтриване на данни
- Ниво на риск: Ниско – не се очаква загуба на данни
- Типични сценарии: Повреда на неклъстерен индекс, незначителни проблеми с метаданните
- Пример за команда:
DBCC CHECKDB('YourDB', REPAIR_REBUILD)
6.2 REPAIR_ALLOW_DATA_LOSS (Крайна мярка):
- Използвай за: Сериозна повреда, когато резервните копия не са налични
- Безопасност на данните: Може да изтрие повредени данни, за да възстанови функционалността на базата данни
- Ниво на риск: Високо – възможна е трайна загуба на данни
- Типични сценарии: Повреда на страницата, повреда на системната таблица, грешки във веригата за разпределение
- Пример за команда:
DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)
6.3 Най-добри практики за тези опции:
- Винаги тествайте операции за поправка на копия на базата данни, когато е възможно
- Винаги правете резервни копия преди да изпълните тези опции
- Документирайте всички промени за целите на съответствието и отстраняването на неизправности
- Задаване на базата данни в режим за един потребител преди извършване на ремонтни дейности
Обикновено трябва да опитаме РЕМОНТ_ВЪЗСТАНОВЯВАНЕ опцията първо. Ако не успее, опитайте РЕМОНТ_НА_ЗАГУБА_НА_ДАННИ .
6.4 Резултати от REPAIR_ALLOW_DATA_LOSS
6.4.1 Поправката е успешна със загуба на данни
Понякога РЕМОНТ_НА_ЗАГУБА_НА_ДАННИ опцията ще успее, но някои данни саost след ремонта.
По-долу са дадени някои примерни съобщения:
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.Това е така, защото DBCC CHECKDB поправя базата данни, като изоставя някои повредени записи, но всъщност most от тях все още могат да бъдат възстановени чрез DataNumen SQL Recovery.
Примерни файлове:
| Версия на SQL Server | Повреден MDF файл | MDF файл, фиксиран от DataNumen SQL Recovery |
| SQL Server 2014 | Грешка10_1.mdf (Съобщение 8909, последвано от съобщение 8939) (600 записаost с REPAIR_ALLOW_DATA_LOSS) | Грешка10_1_fixed.mdf (Няма записost) |
| SQL Server 2014 | Грешка10_2.mdf (Съобщение 8909, последвано от съобщение 8939) (6000 записа (50%) lost с REPAIR_ALLOW_DATA_LOSS) | Грешка10_2_fixed.mdf (Само 100 записаost) |
| SQL Server 2014 | Грешка7.mdf (100 записаost с REPAIR_ALLOW_DATA_LOSS) | Грешка7_fixed.mdf (Само един записost) |
6.4.2 Неуспешен ремонт – помислете за професионално решение
If РЕМОНТ_НА_ЗАГУБА_НА_ДАННИ неуспешно, ще се изведат едно или няколко съобщения за грешки.
По-долу са дадени някои примери:
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.В тези сценарии е необходимо да използвате професионално решение, като например DataNumen SQL Recovery да поправите базата си данни.
Примерни файлове
| Версия на SQL Server | Повреден MDF файл | MDF файл, фиксиран от DataNumen SQL Recovery |
| SQL Server 2014 | Грешка1_3.mdf (Единично съобщение 824) | Грешка1_3_fixed.mdf |
| SQL Server 2014 | Грешка1_1.mdf (Непрекъснати грешки в съобщение 824) | Грешка1_1_fixed.mdf |
| SQL Server 2014 | Грешка1_2.mdf ((Съобщение 824, последвано от Съобщение 7909) | Грешка1_2_fixed.mdf |
| SQL Server 2014 | Грешка4_1.mdf (Съобщение 8992, последвано от Съобщение 3852) | Грешка4_1_fixed.mdf |
| SQL Server 2014 | Грешка4_2.mdf (Съобщение 8992, последвано от Съобщение 3852) | Грешка4_2_fixed.mdf |
| SQL Server 2014 | Грешка5.mdf (Съобщение 8945) | Грешка5_fixed.mdf |
| SQL Server 2014 | Грешка6.mdf (Съобщение 2510) | Грешка6_fixed.mdf |
| SQL Server 2014 | Грешка2.mdf (Съобщение 2575) | Грешка2_fixed.mdf |
| SQL Server 2014 | Грешка11.mdf (Съобщение 8905) | Грешка11_fixed.mdf |
| SQL Server 2014 | Грешка3.mdf (Съобщение 5028) | Грешка3_fixed.mdf |
| SQL Server 2014 | Грешка8.mdf (Съобщение 5125) | Грешка8_fixed.mdf |
| SQL Server 2014 | Грешка9.mdf (Съобщение 3313) | Грешка9_fixed.mdf |
7. Най-добри практики
7.1 Планиране на редовни CHECKDB операции
Внедрете седмично изпълнение на DBCC CHECKDB за критични производствени бази данни, с ежедневни проверки за системи с висок брой транзакции. Планирайте операциите по време на периоди с ниско използване, за да минимизирате влиянието върху производителността, и помислете за редуване между пълни проверки и опции PHYSICAL_ONLY въз основа на размера на базата данни и прозорците за поддръжка. Автоматизирано планиране чрез SQL Server Агентът осигурява последователно изпълнение, като същевременно предоставя централизирани възможности за наблюдение и предупреждение.
7.2 Управление на въздействието върху производителността
Операциите DBCC CHECKDB консумират значителни системни ресурси, което потенциално може да повлияе на едновременната потребителска активност. Следете използването на процесора, потреблението на памет и дисковия вход/изход по време на проверките, за да разберете моделите на въздействие върху производителността. Помислете за използване на опции NOINDEX за рутинни проверки, като запазите пълната валидация за месечни прозорци за поддръжка. Внедрете удължения за време за изчакване на заявките и стратегии за комуникация с потребителите, за да управлявате очакванията по време на периоди на проверка на целостта.
7.3 Планиране на времевия период за поддръжка
Координирайте планирането на DBCC CHECKDB с други дейности по поддръжката, като операции по архивиране, възстановяване на индекси и актуализации на статистика. Избягвайте припокриващи се ресурсоемки операции, които биха могли да причинят влошаване на производителността или проблеми с времето за изчакване. Планирайте прозорците за поддръжка въз основа на прогнозите за растеж на размера на базата данни, като осигурите достатъчно време за пълна проверка на целостта с увеличаване на обемите на данните.
7.4 Автоматизирано наблюдение и предупреждение
Определен SQL Server Агентите могат да уведомяват администраторите незабавно, когато DBCC CHECKDB идентифицира повреда. Внедрете решения за парсиране на лог файлове, които извличат и категоризират резултатите от проверката за целостта, което позволява анализ на тенденциите и проактивно идентифициране на проблеми. Създайте процедури за ескалация, които определят срокове за реакция и отговорен персонал за различните нива на тежест на повредата.
8. DBCC CHECKTABLE: Леката алтернатива
8.1 Кога да използвате CHECKTABLE вместо CHECKDB
DBCC CHECKTABLE осигурява фокусирана проверка на целостта на отделни таблици, което го прави идеален за tarотстраняване на неизправности и поддръжка на специфични обекти на базата данни. Използвайте CHECKTABLE, когато проучвате проблеми с производителността на конкретни таблици, валидирате критични бизнес таблици между пълни проверки на базата данни или когато времевите ограничения пречат на пълната валидация на базата данни. Този подход се оказва особено ценен в големи бази данни, където пълните CHECKDB операции надвишават наличните прозорци за поддръжка.
8.2 Синтаксис и примери за DBCC CHECKTABLE
Основната команда CHECKTABLE tarполучава специфични таблици:
DBCC CHECKTABLE('YourTable')Подобно на CHECKDB, CHECKTABLE поддържа различни опции, включително NOINDEX за оптимизация на производителността и параметри за поправка за разрешаване на проблеми с корупцията. Можете също така да укажете имена на схеми за прецизна идентификация на таблици:
DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)Това tarПодходът geted позволява подробна проверка на целостта, като същевременно се поддържа производителността на системата по време на работно време.
8.3 Предимства за производителността при големи бази данни
Операциите CHECKTABLE се изпълняват значително по-бързо от пълните проверки на базата данни, което позволява по-честа проверка на целостта на критични таблици. Този подход позволява ежедневно валидиране на важни бизнес таблици, като същевременно запазва подробните CHECKTABLE операции за седмични или месечни графици. Намаленото потребление на ресурси прави CHECKTABLE подходящ за изпълнение в производствена среда с минимално въздействие върху потребителя.
9. Когато CHECKDB се провали
DBCC CHECKDB ще се провали в различни сценарии, включително:
- Изпълнение на DBCC CHECKDB прекратява необичайно
- Изпълнението на DBCC CHECKDB завършва успешно, но опции за ремонт неуспешно поправяне на базата данни.
В тези сценарии се нуждаем от по-професионален инструмент, който да ни помогне да поправим повредите в базата данни.
9.1 Въведение в DataNumen SQL Recovery
DataNumen SQL Recovery предоставя по-разширени възможности:
- Най-добър процент на възстановяване в индустрията.
- Възстановяване на силно повредени файлове от базата данни.
- Възстановете всички обекти на базата данни, включително таблици, индекси, изгледи, тригери, правила и настройки по подразбиране.
- Възстановяване на съхранени процедури, скаларни функции, вградени функции с таблични стойности и функции с таблични стойности с множество изказвания.
- Възстановяване на трайно изтрити записи.
- Дешифриране на криптирани обекти в SQL Server бази данни.
- Поправка на MDF файлове на партида.
- Комплексни възможности за ремонт.
- Разширено регистриране и отчитане.
- Поддръжка за всички SQL Server версии.
- Наличие на техническа поддръжка
- Редовни актуализации и подобрения
9.2 Сравнение на процента на успех
Успехът на възстановяването се различава значително:
- DBCC CHECKDB и CHECKTABLEC: 1.27% среден процент на възстановяване
- DataNumen: 92.6% възстановителен статус
По-долу е пълно конкурентно сравнение:
9.3 Възстановяване след тежка корупция
Разширени възможности за тежки случаи:
- Възстановяване от физически повредено хранилище
- Възстановяване от форматирани дискове или повредени системи
- Възстановяване от дискови изображения, архивни файлове, дискови файлове на виртуална машина, темпrary файлове и др.
9.4 Кога да обмислите професионални решения
- Няма скорошни налични резервни копия
- DBCC CHECKDB е неуспешен
- Тежки корупционни сценарии
- Работа с критични бизнес данни
- Когато времето е критично
- Когато максималното възстановяване е от съществено значение
10. Често задавани въпроси
10.1 Основни въпроси за употреба
В: Колко често трябва да изпълнявам DBCC CHECKDB?
A: За критични производствени бази данни, изпълнявайте CHECKDB седмично. За системи с висок брой транзакции, помислете за ежедневни проверки, използвайки опцията PHYSICAL_ONLY, с пълни проверки седмично. Базите данни за разработка могат да се проверяват месечно.
В: Мога ли да изпълня DBCC CHECKDB на активна производствена база данни?
A: Да, DBCC CHECKDB може да се изпълнява в онлайн бази данни, без да блокира потребителите. Той обаче консумира значителни ресурси, така че го планирайте за периоди с ниска активност и наблюдавайте производителността на системата.
В: Каква е разликата между CHECKDB и CHECKTABLE?
A: CHECKTABLE проверява цялата база данни, докато CHECKTABLE се фокусира върху отделни таблици. Използвайте CHECKTABLE за tarотстраняване на неизправности или когато трябва да проверите конкретни таблици, без да сканирате цялата база данни.
10.2 Въпроси, свързани с производителността и ресурсите
В: Защо DBCC CHECKDB отнема толкова време на голямата ми база данни?
A: Продължителността на CHECKDB зависи от размера на базата данни, производителността на хардуера и използваните опции. Използвайте PHYSICAL_ONLY за по-бързи проверки или NOINDEX, за да пропуснете неклъстерираните индекси. Помислете за изпълнение по време на прозорци за поддръжка с специално предназначени ресурси.
В: Колко място във временната база данни е необходимо за CHECKDB?
A: Обикновено разпределете 10-15% от размера на базата данни за tempdb по време на CHECKDB операции. Използвайте опцията ESTIMATEONLY, за да получите точни оценки: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY
В: Мога ли да прекратя изпълняваща се CHECKDB операция?
A: Да, можете да отмените CHECKDB, като използвате командата KILL на идентификатора на сесията. Отмяната обаче не предоставя информация за целостта на базата данни и ще трябва да я изпълните отново по-късно.
10.3 Въпроси за обработка на грешки
В: CHECKDB откри грешки – трябва ли да се паникьосвам?
A: Не се паникьосвайте, а действайте бързо. Първо, определете дали CHECKDB е завършил успешно, но е открил повреда, или дали самият CHECKDB не е успял да се изпълни. Проверете дали грешките засягат само неклъстерирани индекси (по-малко критично) или таблични данни (по-сериозно).
В: Кога трябва да използвам REPAIR_ALLOW_DATA_LOSS?
A: Само като абсолютна последна мярка, когато нямате използваеми резервни копия и загубата на данни е приемлива в сравнение с пълната загуба на базата данни. Винаги опитвайте първо да възстановите от резервно копие, тъй като операциите по възстановяване могат да причинят трайна загуба на данни.
В: Какво означават „грешки в консистентността в базата данни“ спрямо „грешки в разпределението“?
A: Грешките при разпределение влияят на това как SQL Server проследява използването на дисково пространство, докато грешките в консистентността показват проблеми с данните или индексните структури. И двете изискват внимание, но грешките в консистентността обикновено влияят по-директно на достъпността на данните.
10.4 Въпроси за архивиране и възстановяване
В: Трябва ли да стартирам CHECKDB върху резервните си копия?
A: Абсолютно! Изпълнете CHECKDB след възстановяване на резервни копия на тестови сървъри. Това проверява целостта на резервните копия и гарантира, че действително можете да ги възстановите от повреда. Автоматизирайте този процес, ако е възможно.
В: Архивното ми копие също е повредено – какво сега?
A: Опитайте по-стари резервни копия, докато не намерите чисто. Ако няма чисти резервни копия, помислете за професионални решения за възстановяване, като например DataNumen SQL RecoveryДокументирайте хронологията на корупцията, за да предотвратите бъдещи случаи.
В: Може ли възстановяването на страницата да поправи повреда без пълно възстановяване на базата данни?
A: Да, но само в SQL Server Enterprise Edition с модел за пълно възстановяване и текущи архиви на лог файлове. Възстановяването на страници работи за изолирани повреди на страници, но изисква внимателно изпълнение, следвайки правилните процедури.
10.5 Въпроси за отстраняване на неизправности
В: CHECKDB се проваля с грешки „няма място“ – какво мога да направя?
A: Освободете място във временната база данни, преместете я в по-бързо хранилище или използвайте опцията TABLOCK, за да намалите използването ѝ. Помислете за изпълнение на CHECKDB с NOINDEX или PHYSICAL_ONLY, за да намалите изискванията за ресурси.
В: Как да разбера коя таблица е повредена от изхода на CHECKDB?
A: Потърсете номера на „идентификатор на обект“ в съобщенията за грешки, след което използвайте: SELECT OBJECT_NAME(object_id) за намиране на имена на таблици. Съобщенията за грешки включват също номера на страници и слотове за точно идентифициране на местоположението.
В: Могат ли хардуерни проблеми да доведат до отчитане на фалшиви положителни резултати от CHECKDB?
A: Да, отказът на хардуер (особено на устройството за съхранение) може да причини периодична повреда, която се появява и изчезва между изпълненията на CHECKDB. Ако грешките са непоследователни, проверете вашата I/O подсистема и изпълнете множество проверки, за да потвърдите закономерностите.
10.6 Въпроси за разширена конфигурация
В: Какви флагове за проследяване могат да подобрят производителността на CHECKDB?
A: Флагът за проследяване 2562 може да подобри производителността, като изпълни CHECKDB като една партида. Флагът за проследяване 2549 е полезен, когато файловете на базата данни са на отделни дискове. Използвайте ги внимателно и първо тествайте в непроизводствена среда.
В: Как да автоматизирам наблюдението и предупрежденията на CHECKDB?
A: Използвайте SQL Server Сигнали за агенти за грешки с номера 8930, 8939 и други. Приложете парсиране на лог файлове, за да извлечете резултатите от CHECKDB и създайте известия за всякакви открити повреди. Помислете за използване на рамки за решения за поддръжка, като например скриптовете на Ола Халенгрен.
В: Трябва ли да използвам опцията EXTENDED_LOGICAL_CHECKS?
A: Само ако подозирате сложна логическа повреда и имате адекватни разходи за производителност. Тази опция извършва допълнителни проверки на индексирани изгледи, XML индекси и пространствени индекси, но значително увеличава времето за изпълнение.
11. заключение
11.1 Обобщение на ключовите точки
11.1.1 Обобщение на основните DBCC CHECKDB команди
Овладейте основния синтаксис на DBCC CHECKDB за цялостна проверка на базата данни, използвайте опциите NOINDEX и PHYSICAL_ONLY за оптимизация на производителността и разберете CHECKTABLE за tarпроверка на получена таблица. Тези основни команди формират основата на проактивната поддръжка на базата данни, позволявайки ранно откриване на корупция и систематично наблюдение на целостта.
11.1.2 Напомняне за най-важни добри практики
Винаги поддържайте актуални резервни копия, преди да извършвате проверки за целостта, планирайте редовни CHECKDB операции въз основа на критичността на базата данни и внедрете автоматизирано наблюдение за незабавни предупреждения за повреда. Не забравяйте, че превенцията чрез редовно наблюдение надминава реактивните подходи, а професионалните решения за възстановяване предоставят ценни опции за архивиране, когато стандартните инструменти се окажат недостатъчни.
11.2 Кога да използвате DBCC CHECKDB спрямо Advanced Solutions
Използвайте DBCC CHECKDB за рутинно наблюдение на целостта и разрешаване на малки повреди, като същевременно запазите професионални инструменти за възстановяване за сериозни сценарии на повреди, извън вградените възможности за поправка. Рамката за вземане на решения трябва да вземе предвид наличността на резервни копия, критичността на данните, времевите ограничения и тежестта на повредата. Успешните администратори на бази данни комбинират редовно наблюдение на CHECKDB с всеобхватни стратегии за архивиране и познаване на разширените опции за възстановяване, когато стандартните подходи се окажат неадекватни.
11.3 Бърз ежедневен контролен списък за здравни специалисти
Освен изпълнението на DBCC CHECKDB, поддържайте оптимално състояние на базата данни с тези основни ежедневни практики:
1. Проверете целостта на резервното копие
- Потвърдете успешното завършване на планираните резервни копия
- Използвайте RESTORE VERIFYONLY, за да проверите четливостта на резервното копие
- Осигурете синхронизация и достъпност на външните копия
Можете също да получите повече информация от нашето изчерпателно ръководство за SQL Server резервно копие.
2. Преглед на състоянието на съгласуваност
- Проверете автоматизираните резултати от DBCC CHECKDB от изпълнения през нощта
- Монитор SQL Server регистрационни файлове за грешки за предупреждения за корупция
- Незабавно разследвайте всички нарушения на целостта
3. Наблюдавайте здравето на сървъра
- Проверете показателите за I/O на процесора, паметта и диска
- Проверете наличността на пространството в tempdb
- Идентифицирайте блокирани процеси и дълго изпълняващи се заявки
4. Проследяване на активността при блокиране
- Преглед на графиките на безизходици от събития за състоянието на системата
- Идентифицирайте проблемни заявки и ги оптимизирайте с екипите за разработка
- Следете броя на жертвите на безизходици и въздействието им върху бизнеса
Важни напомняния
- Избягвайте честото свиване на базата данни – увеличава фрагментацията и влошава производителността. Свивайте само след големи изтривания на данни, когато е наистина необходимо.
- Автоматизирайте задачите за наблюдение използвайки SQL Server Задачи на агенти или планове за поддръжка с предупреждения за критични проблеми.
- Тестване на процедури за възстановяване след бедствие седмично, за да се гарантира, че резервните копия могат да се възстановят и целите за възстановяване остават постижими.
Чрез комбиниране на този ежедневен контролен списък с редовни операции на DBCC CHECKDB, вие създавате цялостна защита за вашата база данни чрез проактивно наблюдение и бърза реакция при проблеми.
12. Препратки
- Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server документацияКорпорация „Майкрософт“.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17 - Microsoft Learn. „Отстраняване на грешки в съгласуваността на базата данни, докладвани от DBCC CHECKDB.“ SQL Server документацияКорпорация „Майкрософт“.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors