Мәліметтер қорының бұзылуы әрбір 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 Неліктен денсаулықты тұрақты тексеру өте маңызды?
Адамдарға ықтимал ауруларды ерте анықтау үшін жүйелі түрде медициналық тексеру қажет. Сол сияқты, дерекқорлар да тұрақты денсаулықты тексеруді қажет етеді:
- Ықтимал сыбайлас жемқорлықты ерте анықтап, бизнес үшін апатты салдарға әкеп соғуы мүмкін мәселелердің ауыр және кең таралуына жол бермей, оны дереу шешіңіз.
- Дерекқордың оңтайлы өнімділікпен жұмыс істеуін қамтамасыз етіңіз.
- Cost дерекқор апатынан кейін реактивті деректерді қалпына келтіруге қарағанда проактивті дерекқор денсаулығын тексеру әлдеқайда төмен.
1.3 Мәліметтер қорының тұтастығы командаларына кіріспе
SQL Server көмегімен дерекқордың денсаулығын сақтауға арналған бірнеше кірістірілген пәрмендерді қамтамасыз етеді DBCC CHECKDB м ретінде қызмет етедіost тұтастығын тексеру құралы бар. Бұл пәрмендер деректеріңізді қауіпсіз және қолжетімді сақтайтын толық техникалық қызмет көрсету стратегиясын құра отырып, жеке кестелерден бастап бүкіл дерекқордың сәйкестігіне дейін дерекқор құрылымының әртүрлі аспектілерін тексеру үшін бірге жұмыс істейді.
2. DBCC CHECKDB дегеніміз не
DBCC CHECKDB is SQL Serverдерекқордың тұтастығын тексеруге және сыбайлас жемқорлық мәселелерін анықтауға арналған негізгі құрал.
- Бұл GUI құралы емес, T-SQL мәлімдемесі.
- Оны жалпы әдістер арқылы орындауға болады, мысалы SQL Server Басқару студиясы (SSMS), SQL Server Агент, SQLCMD және т.б.
2.1 CHECKDB дерекқорыңызда нақты нені тексереді
DBCC CHECKDB іске қосқан кезде, пәрмен дерекқор құрылымында бірнеше тексеру қабаттарын орындайды:
- Бет бақылау сомасын тексеру физикалық бүлінуді және аппараттық құралдарға қатысты мәселелерді анықтау
- Индекс сәйкестігін тексеру деректерді алу және сұраудың дұрыс орындалуын қамтамасыз ету
- Бөлу құрылымын тексеру дәл орынды пайдалануды және бетті бөлуді растау үшін
- Анықтамалық тұтастықты тексеру байланысты кестелер мен сыртқы кілт қатынастары арасында
- Жүйелік кестенің сәйкестігін тексеру қамтамасыз ету SQL Serverішкі метадеректер сенімді болып қалады
- Деректер парағының байланысын тексеру бет тізбегінің дұрыс тұтастығын растау үшін
- Мәліметтер базасының схемасының сәйкестігі нысан анықтамалары мен тәуелділіктерін тексеру
Бұл жан-жақты тексерулер пайдаланушы деректерін де, жүйе құрылымдарын да қамтып, дерекқордың денсаулық күйін толық көруді қамтамасыз етеді.
3. DBCC CHECKDB іске қосу: қадамдық
3.1 пререквизиттері
Төменде кез келген DBCC CHECKDB операциясын орындау алдында тексеру тізімі берілген:
- Дерекқордың сақтық көшірмесін жасаңыз – Сыбайлас жемқорлық анықталса немесе жөндеу операциялары қажет болса, қауіпсіздік желісі ретінде тұтастықты тексеруді іске қоспас бұрын толық сақтық көшірме жасаңыз.
- Тиісті рұқсаттар – DBCC CHECKDB пәрмендерін орындау үшін sysadmin немесе db_owner рұқсаттары қажет
- Жүйе ресурстары жеткілікті:
- Жад: дерекқор көлемінің 25%
- Tempdb кеңістігі: дерекқор көлемінің 10-15%
- CPU: техникалық қызмет көрсету кезінде 50-70% қолжетімділік
- Енгізу/шығару: ауыр оқу операцияларын күтіңіз
- Мәліметтер қорының қолжетімділігі – Дерекқорыңыздың қол жетімді екенін және шектелген күйде емес екенін тексеріңіз, себебі CHECKDB барлық дерекқор беттеріне оқу рұқсатын талап етеді
3.2 Негізгі пәрмен
Most негізгі 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) |
|
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.
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 сенімді шешім. Бұл тәсіл сыбайлас жемқорлықтың негізгі себептерін жоя отырып, деректер тұтастығына кепілдік береді. Қалпына келтіру алдында сақтық көшірменің тұтастығын пайдаланып тексеріңіз ТЕК ҚАЛПЫНА КЕЛТІРУ пәрмендерін таңдап, деректердің жоғалуын азайту үшін уақытында қалпына келтіру опцияларын қарастырыңыз. Түбірлік себептерді талдау үшін бүліну туралы мәліметтерді құжаттаңыз, себебі аппараттық мәселелер немесе бағдарламалық құрал қателері қайталануды болдырмау үшін қосымша назар аударуды қажет етуі мүмкін.
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 data
5.3 Индекстегі сыбайлас жемқорлықты жылдам түзетулер
Индекстің бүлінуі көбінесе негізгі кесте деректеріне әсер етпей, индекс құрылымдарын қайта жасайтын қайта құру операцияларына жақсы жауап береді:
ALTER INDEX ALL ON YourTable REBUILD
Бұл тәсіл әсіресе кластерленбеген индекстің бүлінуі үшін жақсы жұмыс істейді, өйткені қайта құру бастапқы кесте деректерінен индекс беттерін қалпына келтіреді, барлық бастапқы ақпаратты сақтай отырып, сыбайлас жемқорлықты тиімді жояды.
6. REPAIR_REBUILD және REPAIR_ALLOW_DATA_LOSS пайдаланыңыз
Алдыңғы әдістердің барлығы сәтсіз болса немесе мүмкін болмаса, дерекқорды жөндеу үшін REPAIR_REBUILD және REPAIR_ALLOW_DATA_LOSS опцияларын пайдалануға болады.
6.1 REPAIR_REBUILD (Қауіпсіз опция):
- үшін пайдаланыңыз: Индекстің бұзылуы және шағын бөлу қателері
- Деректер қауіпсіздігі: Деректерді жоюсыз сыбайлас жемқорлықты түзету әрекеттері
- Тәуекел деңгейі: Төмен – деректердің жоғалуы күтілмейді
- Типтік сценарийлер: Кластерлік емес индекстердің бүлінуі, кішігірім метадеректер мәселелері
- Пәрмен мысалы:
DBCC CHECKDB('YourDB', REPAIR_REBUILD)
6.2 REPAIR_ALLOW_DATA_LOSS (соңғы шара):
- үшін пайдаланыңыз: Сақтық көшірмелер қолжетімсіз болған кезде қатты сыбайлас жемқорлық
- Деректер қауіпсіздігі: Дерекқор функциясын қалпына келтіру үшін бүлінген деректерді жоюы мүмкін
- Тәуекел деңгейі: Жоғары – деректердің тұрақты жоғалуы мүмкін
- Типтік сценарийлер: Беттің бүлінуі, жүйелік кестенің зақымдалуы, бөлу тізбегі қателері
- Пәрмен мысалы:
DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)
6.3 Осы опциялар үшін ең жақсы тәжірибелер:
- Әрқашан сынау мүмкіндігінше дерекқор көшірмелерін жөндеу операциялары
- Әрқашан сақтық көшірме жасаңыз осы опцияларды іске қоспас бұрын
- Барлық өзгерістерді құжаттаңыз сәйкестік және ақаулықтарды жою мақсатында
- Дерекқорды бір пайдаланушы режиміне орнатыңыз жөндеу жұмыстарын орындау алдында
Әдетте, біз тырысуымыз керек REPAIR_REBUILD бірінші опция. Егер ол сәтсіз болса, көріңіз ЖӨНДЕУ_АЛУ_ДЕРЕКТЕРДІ_ЖОГЫТҚУ опция.
6.4 REPAIR_ALLOW_DATA_LOSS Нәтижелері
6.4.1 Жөндеу деректердің жоғалуымен сәтті болады
Кейде ЖӨНДЕУ_АЛУ_ДЕРЕКТЕРДІ_ЖОГЫТҚУ опция сәтті болады, бірақ кейбір деректер lost жөндеуден кейін.
Төменде кейбір хабарламалар үлгісі берілген:
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 жазба lost REPAIR_ALLOW_DATA_LOSS бар) | Қате10_1_fixed.mdf (Жазба жоқ lost) |
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_түзілген.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_түзілген.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 CHECKDB орнына CHECKTABLE қашан пайдалану керек
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 операциялары толық дерекқор тексерулеріне қарағанда айтарлықтай жылдам аяқталады, бұл маңызды кестелердің тұтастығын жиірек тексеруге мүмкіндік береді. Бұл тәсіл апталық немесе айлық кестелер үшін жан-жақты CHECKDB операцияларын сақтау кезінде маңызды бизнес кестелерін күнделікті тексеруге мүмкіндік береді. Ресурстарды тұтынудың азаюы 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 & CHECKTABLE: 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: CHECKDB бүкіл дерекқорды зерттейді, ал CHECKTABLE жеке кестелерге назар аударады. үшін CHECKTABLE пайдаланыңыз tarақаулықтарды жою немесе бүкіл дерекқорды сканерлеусіз нақты кестелерді тексеру қажет болғанда.
10.2 Өнімділік және ресурстар сұрақтары
С: Неліктен DBCC CHECKDB менің үлкен дерекқорымда ұзақ уақыт алады?
A: CHECKDB ұзақтығы дерекқор өлшеміне, аппараттық құрал өнімділігіне және пайдаланылатын опцияларға байланысты. Жылдамырақ тексеру үшін PHYSICAL_ONLY пайдаланыңыз немесе кластерленбеген индекстерді өткізіп жіберу үшін NOINDEX пайдаланыңыз. Арнайы ресурстары бар техникалық қызмет көрсету терезелері кезінде іске қосуды қарастырыңыз.
С: CHECKDB үшін қанша tempdb кеңістігі қажет?
A: Әдетте, CHECKDB әрекеттері кезінде tempdb үшін дерекқор өлшемінің 10-15% бөліңіз. Нақты бағалауларды алу үшін ESTIMATEONLY опциясын пайдаланыңыз: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY
С: Мен іске қосылған CHECKDB әрекетін тоқтата аламын ба?
A: Иә, сеанс идентификаторындағы KILL пәрменін пайдаланып CHECKDB әрекетінен бас тартуға болады. Дегенмен, бас тарту дерекқордың тұтастығы туралы ақпарат бермейді және оны кейінірек қайта іске қосу қажет болады.
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: tempdb кеңістігін босатыңыз, tempdb файлын жылдамырақ сақтауға жылжытыңыз немесе tempdb пайдалануын азайту үшін TABLOCK опциясын пайдаланыңыз. Ресурс талаптарын азайту үшін CHECKDB бағдарламасын NOINDEX немесе PHYSICAL_ONLY көмегімен іске қосуды қарастырыңыз.
С: CHECKDB шығысынан қай кестеде бүліну бар екенін қалай анықтауға болады?
A: Қате туралы хабарлардан «нысан идентификаторы» нөмірлерін іздеңіз, содан кейін мынаны пайдаланыңыз: SELECT OBJECT_NAME(object_id)
кесте атауларын табу. Қате туралы хабарлар сонымен қатар орынды дәл анықтау үшін бет пен ұяшық нөмірлерін қамтиды.
С: Аппараттық ақаулар CHECKDB қате позитивтер туралы хабарлауға әкелуі мүмкін бе?
A: Иә, істен шыққан аппараттық құрал (әсіресе жад) CHECKDB іске қосулары арасында пайда болатын және жоғалатын үзіліссіз бүлінуді тудыруы мүмкін. Қателер сәйкес келмесе, енгізу/шығару ішкі жүйеңізді зерттеңіз және үлгілерді растау үшін бірнеше тексеруді орындаңыз.
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 және Кеңейтілген шешімдерді қашан пайдалану керек
Кірістірілген жөндеу мүмкіндіктерінен тыс ауыр сыбайлас жемқорлық сценарийлері үшін кәсіби қалпына келтіру құралдарын сақтай отырып, жүйелі тұтастық мониторингі және кішігірім сыбайлас жемқорлықты шешу үшін DBCC CHECKDB пайдаланыңыз. Шешім жүйесі сақтық көшірменің қолжетімділігін, деректердің маңыздылығын, уақыт шектеулерін және сыбайлас жемқорлықтың ауырлығын ескеруі керек. Табысты дерекқор әкімшілері тұрақты CHECKDB мониторингін кешенді сақтық көшірме стратегияларымен және стандартты тәсілдер жеткіліксіз болған кезде кеңейтілген қалпына келтіру опциялары туралы хабардар болуымен біріктіреді.
12. Әдебиеттер
- Microsoft Learn. «DBCC CHECKDB (Transact-SQL).» SQL Server Құжаттама. Microsoft корпорациясы.
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 Құжаттама. Microsoft корпорациясы.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors