DBCC CHECKDB: Повний посібник з MS SQL Server Стан бази даних (2025)

Пошкодження бази даних є кожним SQL Server кошмар адміністратора. Коли критично важливі бізнес-дані стають недоступними або ненадійними, cost може бути руйнівним. Цей вичерпний посібник охоплює все, що вам потрібно знати про використання DBCC CHECKDB для підтримки справності бази даних та запобігання пошкодженню, а також пропонує розширені рішення для відновлення, коли стандартних інструментів недостатньо.

1. Важливість SQL Server Стан бази даних

1.1 Що таке пошкодження бази даних Costs Бізнеси

Сьогодні, м.ost Компанії зберігають свої критично важливі дані в базах даних. Пошкодження бази даних має катастрофічні наслідки:

• Фінансові втрати в середньому 2.3 мільйона доларів США щорічно через втрату даних, основними причинами якої є збій обладнання та пошкодження (EMC Corporation)
• Показники закриття бізнесу показують, що 50% малих підприємств, які зазнають втрати даних через збої обладнання, збанкрутують протягом двох років, тоді як 94% підприємств з катастрофічною втратою даних взагалі не виживають.
• Частота пошкодження даних щорічно впливає на 20% критично важливих програм, спричиняючи порушення безперервності бізнесу (дослідження Gartner)
• Пошкодження обладнання становить 67% усіх випадків втрати даних через збої жорстких дисків та системні збої, причому 40% втрати даних безпосередньо пов'язані з несправностями обладнання.
• Пошкодження програмного забезпечення costs коливаються від тисяч до мільйонів доларів залежно від серйозності та масштабу, причому 82% підприємств зазнали незапланованих перебоїв у роботі, головною причиною яких була корупція.

1.2 Чому регулярні медичні огляди є критично важливими

Людям потрібні регулярні медичні огляди для раннього виявлення потенційних захворювань. Аналогічно, бази даних також потребують регулярних медичних оглядів:

1. Виявляйте потенційну корупцію на ранній стадії та оперативно реагуйте на неї, запобігаючи серйозним та поширеним проблемам, які можуть призвести до катастрофічних наслідків для бізнесу.
2. Забезпечте оптимальну продуктивність бази даних.
3. Cost Проактивні перевірки справності бази даних набагато нижчі, ніж реактивне відновлення даних після аварії бази даних.

1.3 Вступ до команд цілісності бази даних

SQL Server надає кілька вбудованих команд для підтримки справності бази даних, з DBCC CHECKDB виступаючи в ролі мost доступний комплексний інструмент перевірки цілісності. Ці команди працюють разом для перевірки різних аспектів структури вашої бази даних, від окремих таблиць до цілісності всієї бази даних, утворюючи повну стратегію обслуговування, яка забезпечує безпеку та доступність ваших даних.

2. Що таке DBCC CHECKDB

DBCC CHECKDB is SQL Serverосновний інструмент для перевірки цілісності бази даних та виявлення проблем з пошкодженням.

• Це оператор T-SQL, а не інструмент із графічним інтерфейсом.
• Ви можете виконати це за допомогою поширених методів, таких як SQL Server Студія управління (SSMS), SQL Server Агент, SQLCMD тощо.

2.1 Що насправді перевіряє CHECKDB у вашій базі даних

Під час виконання команди DBCC CHECKDB команда виконує кілька рівнів перевірки по всій структурі бази даних:

• Перевірка контрольних сум сторінок для виявлення фізичних пошкоджень та проблем, пов'язаних з обладнанням
• Перевірка узгодженості індексу щоб забезпечити належне отримання даних та виконання запитів
• Перевірки структури розподілу для підтвердження точного використання простору та розподілу сторінок
• Перевірка референційної цілісності між пов'язаними таблицями та зв'язками зовнішнього ключа
• Перевірка узгодженості системної таблиці для забезпечення SQL ServerВнутрішні метадані залишаються надійними
• Перевірка зв'язку сторінок даних для підтвердження цілісності належного ланцюжка сторінок
• Узгодженість схеми бази даних для перевірки визначень та залежностей об'єктів

Ці комплексні перевірки охоплюють як дані користувачів, так і системні структури, забезпечуючи повну видимість стану вашої бази даних.

3. Запуск DBCC CHECKDB: крок за кроком

Передумови для 3.1

Нижче наведено контрольний список перед виконанням будь-якої операції DBCC CHECKDB:

• Повне резервне копіювання бази даних – Створіть повну резервну копію перед запуском перевірки цілісності, щоб забезпечити захисну сітку на випадок виявлення пошкоджень або необхідності ремонтних робіт.
• Належні дозволи – Для виконання команд DBCC CHECKDB потрібні права доступу системного адміністратора або власника бази даних.
• Достатньо системних ресурсів:
  • Пам'ять: 25% від розміру бази даних
  • Простір у тимчасовій базі даних: 10-15% від розміру бази даних
  • ЦП: доступність 50-70% під час технічного обслуговування
  • Введення/виведення: очікується інтенсивне читання
• Доступність бази даних – Перевірте, чи доступна ваша база даних і чи не перебуває в обмеженому стані, оскільки CHECKDB вимагає доступу на читання до всіх сторінок бази даних.

3.2 Основна команда

Мost Базова команда DBCC CHECKDB включає три поширені варіанти:

(1) Перевірте поточну базу даних (без параметрів):

DBCC CHECKDB

(2) Перевірте базу даних за назвою:

DBCC CHECKDB ('YourDatabaseName')

(3) Перевірити базу даних за ідентифікатором:

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)
Утиліта	ESTIMATEONLY	Оцінює необхідний простір у тимчасовій базі даних (фактична перевірка відсутня).	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.

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

Приклад журналу помилок:

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 надійне рішення. Такий підхід гарантує цілісність даних, усуваючи при цьому основні причини пошкодження. Перед відновленням перевірте цілісність резервної копії за допомогою ВІДНОВИТИ ЛИШЕ VERIFY команди та розгляньте варіанти відновлення в певний момент часу, щоб мінімізувати втрату даних. Задокументуйте деталі пошкодження для аналізу першопричини, оскільки проблеми з обладнанням або програмні помилки можуть вимагати додаткової уваги для запобігання повторенню.

5.2 Рішення для пошкодження на рівні сторінки

Для ізольованого пошкодження сторінки, що впливає на невеликі частини даних, SQL Server Enterprise Edition пропонує можливості відновлення сторінок, які відновлюють певні пошкоджені сторінки без повного відновлення бази даних. Цей розширений метод вимагає повної моделі відновлення та актуальних резервних копій журналів.

Покроковий процес відновлення сторінки:

1. Визначте пошкоджену сторінку з повідомлення про помилку CHECKDB (наприклад, сторінка 1:256)
2. Зробіть резервну копію поточного журналу щоб зафіксувати останні транзакції:

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

3. Відновити пошкоджену сторінку від мost нещодавня повна резервна копія:

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

4. Застосувати диференціальне резервне копіювання (якщо такі є):

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

5. Застосувати всі резервні копії журналів послідовно, включаючи щойно створений:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Зробіть остаточну резервну копію журналу та відновіть її щоб оновити сторінку:

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 data

5.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 Найкращі практики для цих варіантів:

• Завжди тестуйте операції з відновлення копій бази даних, коли це можливо
• Завжди створюйте резервні копії перед запуском цих опцій
• Документуйте всі зміни для цілей дотримання вимог та усунення несправностей
• Налаштувати однокористувацький режим роботи бази даних перед початком ремонтних робіт

Зазвичай, нам слід спробувати РЕМОНТ_ВІДНОВЛЕННЯ варіант спочатку. Якщо це не вдасться, спробуйте REPAIR_ALLOW_DATA_LOSS варіант.

6.4 Результати REPAIR_ALLOW_DATA_LOSS

6.4.1 Успішне відновлення з втратою даних

Іноді REPAIR_ALLOW_DATA_LOSS опція буде успішною, але деякі дані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_DANO_LOSS)	Помилка10_1_fixed.mdf (Немає запису lost)
SQL Server 2014	Помилка10_2.mdf (Повідомлення 8909, а потім повідомлення 8939) (6000 записів (50%) lost з REPAIR_ALLOW_DANO_LOSS)	Помилка10_2_fixed.mdf (Тільки 100 записівost)
SQL Server 2014	Error7.mdf (100 записівost з REPAIR_ALLOW_DANO_LOSS)	Помилка7_fixed.mdf (Тільки один запис lost)

6.4.2 Невдалий ремонт – розгляньте професійне рішення

If REPAIR_ALLOW_DATA_LOSS якщо не вдасться, буде виведено одне або кілька повідомлень про помилки.

Нижче наведено кілька прикладів:

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 (Постійні помилки Msg 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	Error8.mdf (Повідомлення 5125)	Error8_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 CHECKTABLEC: Легка альтернатива

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Запропонований підхід дозволяє детальну перевірку цілісності, зберігаючи при цьому продуктивність системи протягом робочого часу.

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 та CHECKTABLICE: 1.27% середня швидкість відновлення
• DataNumen: 92.6% швидкість відновлення

Нижче наведено повне конкурентне порівняння:

9.3 Відновлення після серйозної корупції

Розширені можливості для важких випадків:

• Відновлення з фізично пошкодженого сховища
• Відновлення після відформатованих дисків або систем, що вийшли з ладу
• Відновлення з образів дисків, файлів резервних копій, файлів дисків віртуальної машини, темпуrary файли тощо.

9.4 Коли варто звернутися до професійних рішень

• Немає нещодавніх резервних копій
• Помилка перевірки DBCC CHECKDB
• Серйозні корупційні сценарії
• Робота з критично важливими бізнес-даними
• Коли критичний час
• Коли потрібне максимальне відновлення

10. Поширені запитання

11. Висновок

11.1 Резюме ключових положень

11.1.1 Підсумок основних команд DBCC CHECKDB

Опануйте базовий синтаксис DBCC CHECKDB для комплексної перевірки бази даних, використовуйте параметри NOINDEX та PHYSICAL_ONLY для оптимізації продуктивності та розумійте CHECKTABLE для... tarперевірка таблиці get. Ці фундаментальні команди формують основу проактивного обслуговування бази даних, що дозволяє раннє виявлення пошкоджень та систематичний моніторинг цілісності.

11.1.2 Нагадування про критично важливі найкращі практики

Завжди створюйте актуальні резервні копії перед запуском перевірок цілісності, плануйте регулярні операції CHECKDB залежно від критичності бази даних та впроваджуйте автоматизований моніторинг для негайного сповіщення про пошкодження. Пам’ятайте, що профілактика за допомогою регулярного моніторингу перевершує реактивні підходи, а професійні рішення для відновлення надають цінні варіанти резервного копіювання, коли стандартних інструментів недостатньо.

11.2 Коли використовувати DBCC CHECKDB порівняно з розширеними рішеннями

Використовуйте DBCC CHECKDB для регулярного моніторингу цілісності та вирішення незначних пошкоджень, залишаючи професійні інструменти відновлення для сценаріїв серйозних пошкоджень, що перевищують вбудовані можливості відновлення. Структура прийняття рішень повинна враховувати доступність резервного копіювання, критичність даних, часові обмеження та серйозність пошкодження. Успішні адміністратори баз даних поєднують регулярний моніторинг CHECKDB з комплексними стратегіями резервного копіювання та усвідомленням розширених варіантів відновлення, коли стандартні підходи виявляються недостатніми.

12. Посилання

1. 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
2. Microsoft Learn. «Виправлення неполадок узгодженості бази даних, про які повідомляє DBCC CHECKDB». SQL Server документаціяКорпорація Майкрософт.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors