DBCC CHECKDB- MS အတွက် လမ်းညွှန်ချက်အပြည့်အစုံ SQL Server ဒေတာဘေ့စ်ကျန်းမာရေး (2026)

DBCC CHECKDB ဖြစ်ပါ သည်။ SQL Server၏ အဓိက ဒေတာဘေ့စ် ခိုင်မာမှု ကိရိယာ။ ၎င်းကို အသုံးပြုနည်းကို ဥပမာများဖြင့် လေ့လာပါ၊ အကျင့်ပျက်ခြစားမှုကို ဖြေရှင်းရန်နှင့် စွမ်းဆောင်ရည်ကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပါ။

3. DBCC CHECKDB ကို လုပ်ဆောင်နေသည်- အဆင့်ဆင့်

၂.၁ လိုအပ်ချက်များ

DBCC CHECKDB လုပ်ဆောင်ချက်ကို မလုပ်ဆောင်မီ အောက်တွင် စစ်ဆေးရန်စာရင်း ဖြစ်ပါသည်။

• ဒေတာဘေ့စ်အရန်ကို အပြီးသတ်ပါ။ - အကျင့်ပျက်ခြစားမှုကို ရှာဖွေတွေ့ရှိပါက သို့မဟုတ် ပြုပြင်ခြင်းလုပ်ငန်းများ လိုအပ်လာပါက သင်၏လုံခြုံရေးပိုက်ကွန်အဖြစ် သမာဓိစစ်ဆေးမှုများမလုပ်ဆောင်မီ အရန်အရန်အပြည့်အစုံကို ဖန်တီးပါ။
• သင့်လျော်သောခွင့်ပြုချက် - DBCC CHECKDB ညွှန်ကြားချက်များကိုလုပ်ဆောင်ရန် sysadmin သို့မဟုတ် db_owner ခွင့်ပြုချက်များ လိုအပ်သည်
• လုံလောက်သော စနစ်အရင်းအမြစ်များ
  • သိုလှောင်မှု- ဒေတာဘေ့စ်အရွယ်အစား၏ 25%
  • Tempdb နေရာ- ဒေတာဘေ့စ်အရွယ်အစား၏ 10-15%
  • CPU- ပြုပြင်ထိန်းသိမ်းနေစဉ်အတွင်း 50-70% ရရှိနိုင်သည်။
  • I/O- ပြင်းပြင်းထန်ထန် ဖတ်ရှုခြင်း လုပ်ဆောင်ချက်များကို မျှော်လင့်ပါ။
• ဒေတာဘေ့စ်သုံးစွဲနိုင်မှု - CHECKDB ဒေတာဘေ့စ်စာမျက်နှာများအားလုံးသို့ ဝင်ရောက်ဖတ်ရှုခွင့် လိုအပ်သောကြောင့် သင်၏ဒေတာဘေ့စ်ကို ကန့်သတ်ထားသည့်အခြေအနေတွင် မထားရှိကြောင်း စစ်ဆေးအတည်ပြုပါ။

3.2 အခြေခံ Command

အဆိုပါမီတာost အခြေခံ DBCC CHECKDB command တွင် ဘုံကွဲလွဲမှု သုံးခု ပါဝင်သည်-

(၁) လက်ရှိဒေတာဘေ့စ်ကို စစ်ဆေးပါ (ကန့်သတ်ချက်များမရှိပါ)။

DBCC CHECKDB

(၂) အမည်ဖြင့် ဒေတာဘေ့စ်ကို စစ်ဆေးပါ။

DBCC CHECKDB ('YourDatabaseName')

(3) ID ဖြင့် ဒေတာဘေ့စ်ကို စစ်ဆေးပါ-

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

ဤအခြေခံ command သည် သတ်မှတ်ထားသော ဒေတာဘေ့စ်၏ ပြီးပြည့်စုံသော သမာဓိစစ်ဆေးမှုကို လုပ်ဆောင်ပြီး ဇယားများ၊ အညွှန်းကိန်းများနှင့် စနစ်တည်ဆောက်ပုံအားလုံးကို စစ်ဆေးသည်။ နေရာလွတ်များမပါဝင်သော စံအမည်များဖြင့် ဒေတာဘေ့စ်များအတွက်၊ သင်ကိုးကားချက်များကို ချန်လှပ်နိုင်ပါသည်။ ညွှန်ကြားချက်သည် ပြီးဆုံးသည်အထိ လုပ်ဆောင်မည်ဖြစ်ပြီး တိုးတက်မှုမက်ဆေ့ချ်များနှင့် နောက်ဆုံးရလဒ်များကို ပြသမည်ဖြစ်သည်။ ဤအခြေခံ syntax သည် သေးငယ်သောဒေတာဘေ့စ်များအတွက် သို့မဟုတ် သင့်တွင် ပြုပြင်ထိန်းသိမ်းမှုအချိန်များစွာရနိုင်သည့်အခါတွင် ကောင်းမွန်စွာအလုပ်လုပ်ပါသည်။

အောက်တွင် DBCC CHECKDB တွင် လုပ်ဆောင်နေသည့် စခရင်ရှော့တစ်ခုဖြစ်သည်။ SQL Server စီမံခန့်ခွဲမှုစတူဒီယို (SSMS)-

3.3 အပြီးသတ်ရွေးချယ်မှုများ

DBCC CHECKDB အတွက် ပြီးပြည့်စုံသော ရွေးချယ်စရာများ အောက်တွင် ရှိပါသည်။

အမျိုးအစား	option ကို	ဖေါ်ပြချက်	DBCC CHECKDB ဥပမာ
ပြုပြင်ရေး Options များ	REPAIR_REBUILD	ဒေတာဆုံးရှုံးမှုမရှိဘဲ ပြုပြင်မှုများ (ဥပမာ၊ အညွှန်းကိန်း ပြန်လည်တည်ဆောက်ခြင်း)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	ပြုပြင်ခြင်းမရှိ။ နောက်ပြန်လိုက်ဖက်မှုသာ	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	error အားလုံးကို ပြုပြင်ပေးသည် (ဒေတာ ဆုံးရှုံးမှု ဖြစ်စေနိုင်သည်)	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/spatial အညွှန်းများ)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Output ထိန်းချုပ်ခြင်း	ALL_ERRORMSGS	အမှားအယွင်းအားလုံးကို ပြသည် (မူလ- အရာတစ်ခုလျှင် ၂၀၀)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	အချက်အလက်ဆိုင်ရာ မက်ဆေ့ဂျ်များကို ဝှက်ထားသည်။	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
performance	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 သည် အကျင့်ပျက်ခြစားမှု အမှားကို တွေ့ရှိသည့်အခါတိုင်း၊ ၎င်းသည် အောက်ပါဖွဲ့စည်းပုံပါရှိသော အမှားသတင်းကို အစီရင်ခံလိမ့်မည်-
ပြင်းထန်မှုအဆင့်လမ်းညွှန်-

• level 16-19: အသုံးပြုသူ-ပြုပြင်နိုင်သော အမှားများ မကြာခဏဆိုသလို အသေးစား အကျင့်ပျက်ခြစားမှုများ
• level 20-24: စနစ်အမှားအယွင်းများ၊ ကြီးလေးသောအကျင့်ပျက်ခြစားမှုကိုချက်ချင်းအာရုံစိုက်ရန်လိုအပ်သည်။
• အဆင့် ၅: ဆိုးရွားသော အမှားများ၊ ဒေတာဘေ့စ်ကို လက်လှမ်းမမီနိုင်ပါ။

အဖြစ်များသောအမှားများ ပါဝင်သည်-

• စာမျက်နှာ checksum ကျရှုံးမှုများ (မက်ဆေ့ခ်ျ 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 သည် အကျင့်ပျက်ခြစားမှု အမှားများကို ဖော်ထုတ်သောအခါ၊ သန့်ရှင်းသော အရန်သိမ်းဆည်းမှုမှ ပြန်လည်ရယူခြင်းသည် အလုံခြုံဆုံးဖြစ်ပြီး most ယုံကြည်စိတ်ချရသောဖြေရှင်းချက်။ ဤချဉ်းကပ်မှုသည် အရင်းခံအကျင့်ပျက်ခြစားမှုကို ဖယ်ရှားရာတွင် ဒေတာခိုင်မာမှုကို အာမခံပါသည်။ ပြန်လည်ရယူခြင်းမပြုမီ၊ အသုံးပြု၍ အရန်ထားရှိမှုကို စစ်ဆေးပါ။ မှန်ကန်စွာ ပြန်လည်ရယူပါ။ ညွှန်ကြားချက်များ နှင့် ဒေတာဆုံးရှုံးမှုကို အနည်းဆုံးဖြစ်စေရန် အချက်-အချိန်ကိုက် ပြန်လည်ရယူရေး ရွေးချယ်မှုများကို ထည့်သွင်းစဉ်းစားပါ။ ဟာ့ဒ်ဝဲပြဿနာများ သို့မဟုတ် ဆော့ဖ်ဝဲလ်ချွတ်ယွင်းမှုများ ထပ်တလဲလဲဖြစ်ပွားခြင်းမှ ကာကွယ်ရန် ထပ်လောင်းသတိပြုရနိုင်သောကြောင့် အကျင့်ပျက်ခြစားမှုအသေးစိတ်အချက်အလက်များကို အရင်းအနှီးခွဲခြမ်းစိတ်ဖြာရန်အတွက် မှတ်တမ်းတင်ထားပါ။

5.2 စာမျက်နှာအဆင့် အကျင့်ပျက်ခြစားမှုဖြေရှင်းချက်

သီးခြားစာမျက်နှာ အကျင့်ပျက်ခြစားမှုအတွက် သေးငယ်သော အချက်အလက်အပိုင်းများကို ထိခိုက်စေခြင်း၊ SQL Server Enterprise Edition သည် ဒေတာဘေ့စ်ကို အပြည့်အ၀ ပြန်လည်မွမ်းမံခြင်းမရှိဘဲ ပျက်စီးသွားသော စာမျက်နှာများကို ပြန်လည်ပြုပြင်နိုင်သည့် စာမျက်နှာပြန်လည်ရယူသည့် စွမ်းရည်များကို ပေးပါသည်။ ဤအဆင့်မြင့်နည်းပညာသည် အပြည့်အဝ ပြန်လည်ရယူရေးပုံစံနှင့် လက်ရှိမှတ်တမ်းအရန်များ လိုအပ်သည်။

အဆင့်ဆင့် စာမျက်နှာ ပြန်လည်ရယူခြင်း လုပ်ငန်းစဉ်-

1. ပျက်စီးနေသောစာမျက်နှာကိုဖော်ထုတ်ပါ။ CHECKDB မှ အမှားသတင်းတို (ဥပမာ၊ စာမျက်နှာ 1:256)
2. လက်ရှိမှတ်တမ်း အရန်ကူးယူပါ။ လတ်တလော အရောင်းအဝယ်များကို ဖမ်းယူရန်-

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

3. ပျက်စီးနေသော စာမျက်နှာကို ပြန်ယူပါ။ m မှ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 အညွှန်းကိန်း အကျင့်ပျက်ခြစားမှု အမြန်ပြင်ဆင်မှုများ

Index အကျင့်ပျက်ခြစားမှုသည် အောက်ခြေဇယားဒေတာကို မထိခိုက်စေဘဲ အညွှန်းဖွဲ့စည်းပုံများကို ပြန်လည်ဖန်တီးသည့် ပြန်လည်တည်ဆောက်ခြင်းဆိုင်ရာ လုပ်ငန်းများကို ကောင်းစွာတုံ့ပြန်လေ့ရှိသည်-

ALTER INDEX ALL ON YourTable REBUILD

မူလအချက်အလက်အားလုံးကို ထိန်းသိမ်းထားစဉ်တွင် အဂတိလိုက်စားမှုကို ထိရောက်စွာ ဖယ်ရှားပေးသည့် အရင်းအမြစ်ဇယားဒေတာမှ အညွှန်းစာမျက်နှာများကို ပြန်လည်တည်ဆောက်ခြင်းဖြင့် ဤနည်းလမ်းသည် အစုအစည်းမရှိသော အညွှန်းကိန်းအကျင့်ပျက်ခြစားမှုအတွက် အထူးကောင်းမွန်ပါသည်။

6. REPAIR_REBUILD နှင့် REPAIR_ALLOW_DATA_LOSS ကိုသုံးပါ။

ယခင်နည်းလမ်းများ အားလုံးပျက်ကွက် သို့မဟုတ် မဖြစ်နိုင်ပါက၊ ဒေတာဘေ့စ်ကို ပြုပြင်ရန် REPAIR_REBUILD နှင့် REPAIR_ALLOW_DATA_LOSS ရွေးချယ်မှုများကို သင်အသုံးပြုနိုင်ပါသည်။

6.1 REPAIR_REBUILD (ဘေးကင်းသော ရွေးချယ်မှု)-

• အသုံးပြု: အကျင့်ပျက်ခြစားမှုညွှန်းကိန်းနှင့် အသေးစားခွဲဝေမှုအမှားများ
• ဒေတာဘေးကင်းရေး- ဒေတာဖျက်ခြင်းမရှိဘဲ အကျင့်ပျက်ခြစားမှုကို ပြင်ဆင်ရန် ကြိုးပမ်းသည်။
• အန္တရာယ်အဆင့်- နိမ့်သည် - ဒေတာဆုံးရှုံးမှုကို မျှော်လင့်မထားပါ။
• ပုံမှန်အခြေအနေများ- အစုအဝေးမဟုတ်သော အညွှန်းကိန်း အကျင့်ပျက်ခြစားမှု၊ အသေးစား မက်တာဒေတာ ပြဿနာများ
• Command ဥပမာ- DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (နောက်ဆုံးအပန်းဖြေစခန်း)-

• အသုံးပြု: အရန်သိမ်းဆည်းမှုများ မရရှိနိုင်သောအခါ ဆိုးရွားစွာ အကျင့်ပျက်ခြစားမှု
• ဒေတာဘေးကင်းရေး- ဒေတာဘေ့စ်လုပ်ဆောင်နိုင်စွမ်းကို ပြန်လည်ရယူရန် ပျက်စီးနေသောဒေတာကို ဖျက်ပစ်နိုင်သည်။
• အန္တရာယ်အဆင့်- မြင့်မားသော - အမြဲတမ်းဒေတာဆုံးရှုံးမှုဖြစ်နိုင်သည်။
• ပုံမှန်အခြေအနေများ- စာမျက်နှာအကျင့်ပျက်ခြစားမှု၊ စနစ်ဇယားပျက်စီးမှု၊ ခွဲဝေမှုကွင်းဆက်အမှားများ
• Command ဥပမာ- DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 ဤရွေးချယ်စရာများအတွက် အကောင်းဆုံးအလေ့အကျင့်များ-

• အမြဲတမ်းစစ်ဆေးပါ ဖြစ်နိုင်လျှင် ဒေတာဘေ့စ်မိတ္တူများကို ပြုပြင်ပါ။
• အမြဲတမ်း back up လုပ်ပါ။ ဤရွေးချယ်မှုများကို မလုပ်ဆောင်မီ
• ပြောင်းလဲမှုအားလုံးကို မှတ်တမ်းတင်ပါ။ လိုက်နာမှုနှင့် ပြဿနာဖြေရှင်းခြင်း ရည်ရွယ်ချက်များအတွက်
• ဒေတာဘေ့စ်ကို အသုံးပြုသူတစ်ခုတည်းမုဒ်သို့ သတ်မှတ်ပါ။ ပြုပြင်ခြင်းလုပ်ငန်းများ မလုပ်ဆောင်မီ

သာမာန်အားဖြင့် ကျွန်တော်တို့ ကြိုးစားသင့်တယ်။ REPAIR_REBUILD ရွေးချယ်မှု ပထမ။ အဆင်မပြေရင် ကြိုးစားပါ။ REPAIR_ALLOW_DATA_LOSS option ကို။

6.4 REPAIR_ALLOW_DATA_LOSS ရလဒ်များ

6.4.1 ဒေတာဆုံးရှုံးမှုဖြင့် ပြုပြင်ခြင်း အောင်မြင်သည်။

တခါတရံ REPAIR_ALLOW_DATA_LOSS ရွေးချယ်မှုအောင်မြင်မည်ဖြစ်သော်လည်း အချို့သောဒေတာသည် l ဖြစ်သည်။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 သည် ပျက်စီးနေသော မှတ်တမ်းအချို့ကို စွန့်လွှတ်ခြင်းဖြင့် ဒေတာဘေ့စ်ကို ပြုပြင်ပေးသောကြောင့်၊ost ၎င်းတို့ကို တစ်ဆင့်ပြန်လည်ရယူနိုင်သည်။ DataNumen SQL Recovery.

နမူနာဖိုင်များ-

SQL Server ဗားရှင်း	ပျက်စီးနေသည့် MDF ဖိုင်	MDF ဖိုင်ကိုပြုပြင်သည်။ DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Msg 8909 နောက်တွင် Msg 8939) (600 မှတ်တမ်းများ lost REPAIR_ALLOW_DATA_LOSS ဖြင့်)	Error10_1_fixed.mdf (မှတ်တမ်းမရှိ lost)
SQL Server 2014	Error10_2.mdf (Msg 8909 ၏နောက်တွင် Msg 8939) (6000 မှတ်တမ်းများ(50%) lost REPAIR_ALLOW_DATA_LOSS ဖြင့်)	Error10_2_fixed.mdf (မှတ်တမ်း 100 သာ lost)
SQL Server 2014	အမှား7.mdf (မှတ်တမ်း 100 lost REPAIR_ALLOW_DATA_LOSS ဖြင့်)	Error7_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	Error1_3.mdf (Single Msg 824)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (အဆက်မပြတ် Msg 824 အမှားများ)	အမှား၁_၁_fixed.mdf
SQL Server 2014	Error1_2.mdf ((msg 824 နောက်တွင် Msg 7909)	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (Msg 8992 ၏နောက်တွင် Msg 3852)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (Msg 8992 ၏နောက်တွင် Msg 3852)	Error4_2_fixed.mdf
SQL Server 2014	Error5.mdf (Msg 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (Msg 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (Msg 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (Msg 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (Msg 5028)	Error3_fixed.mdf
SQL Server 2014	အမှား8.mdf (Msg 5125)	အမှား8_fixed.mdf
SQL Server 2014	Error9.mdf (Msg 3313)	Error9_fixed.mdf

7. အကောင်းဆုံးအလေ့အကျင့်များ

7.1 ပုံမှန် CHECKDB လည်ပတ်မှုများကို အချိန်ဇယားဆွဲခြင်း။

အရေးကြီးသော ထုတ်လုပ်မှုဒေတာဘေ့စ်များအတွက် အပတ်စဉ် DBCC CHECKDB လုပ်ဆောင်ချက်ကို အကောင်အထည်ဖော်ပါ၊ မြင့်မားသော ငွေပေးငွေယူစနစ်များအတွက် နေ့စဉ် စစ်ဆေးမှုများ ပြုလုပ်ပါ။ စွမ်းဆောင်ရည်သက်ရောက်မှုကို လျှော့ချရန်အတွက် အသုံးပြုမှုနည်းပါးသောကာလများအတွင်း လည်ပတ်မှုများကို အချိန်ဇယားဆွဲပြီး ဒေတာဘေ့စ်အရွယ်အစားနှင့် ပြုပြင်ထိန်းသိမ်းမှုဝင်းဒိုးများအပေါ်အခြေခံ၍ စစ်ဆေးမှုအပြည့်အစုံနှင့် PHYSICAL_ONLY ရွေးချယ်မှုများကြားတွင် လှည့်ပတ်စဉ်းစားပါ။ အလိုအလျောက်အချိန်ဇယားဆွဲခြင်းများ SQL Server Agent သည် ဗဟိုမှ စောင့်ကြည့်ခြင်းနှင့် သတိပေးခြင်းစွမ်းရည်များကို ပံ့ပိုးပေးနေစဉ် တသမတ်တည်း လုပ်ဆောင်မှုကို သေချာစေသည်။

7.2 စွမ်းဆောင်ရည် သက်ရောက်မှု စီမံခန့်ခွဲမှု

DBCC CHECKDB လုပ်ဆောင်ချက်များသည် သိသာထင်ရှားသော စနစ်ရင်းမြစ်များကို စားသုံးကြပြီး၊ တစ်ပြိုင်နက် အသုံးပြုသူများ၏ လုပ်ဆောင်ချက်များကို ထိခိုက်စေနိုင်သည်။ စွမ်းဆောင်ရည်သက်ရောက်မှုပုံစံများကို နားလည်ရန် စစ်ဆေးမှုများအတွင်း CPU အသုံးပြုမှု၊ မမ်မိုရီသုံးစွဲမှုနှင့် ဒစ်ခ် I/O ကို စောင့်ကြည့်ပါ။ ပုံမှန်စစ်ဆေးမှုများအတွက် NOINDEX ရွေးစရာများကို အသုံးပြု၍ လစဉ်ထိန်းသိမ်းမှု windows အတွက် အပြည့်အဝ တရားဝင်မှုကို သိမ်းဆည်းထားသည်။ ခိုင်မာမှုစစ်ဆေးသည့်ကာလများအတွင်း မျှော်လင့်ချက်များကို စီမံခန့်ခွဲရန် query timeout extensions နှင့် user communication strategies များကို အကောင်အထည်ဖော်ပါ။

7.3 ပြုပြင်ထိန်းသိမ်းမှု Window Planning

အရန်လုပ်ဆောင်မှုများ၊ အညွှန်းပြန်လည်တည်ဆောက်ခြင်းနှင့် စာရင်းအင်းမွမ်းမံမှုများကဲ့သို့သော အခြားပြုပြင်ထိန်းသိမ်းမှုလုပ်ငန်းများနှင့် DBCC CHECKDB အချိန်ဇယားဆွဲခြင်းကို ညှိနှိုင်းပါ။ စွမ်းဆောင်ရည် ကျဆင်းခြင်း သို့မဟုတ် အချိန်ကုန်ခြင်းဆိုင်ရာ ပြဿနာများကို ဖြစ်စေနိုင်သည့် ထပ်နေသော အရင်းအမြစ်များ အထူးပြု လုပ်ဆောင်မှုများကို ရှောင်ကြဉ်ပါ။ ဒေတာပမာဏ တိုးလာသည်နှင့်အမျှ ဒေတာပမာဏများ များပြားလာသည်နှင့်အမျှ ပြီးပြည့်စုံသော ခိုင်မာမှုရှိရှိ အတည်ပြုခြင်းအတွက် လုံလောက်သောအချိန်ကို သေချာစေမည့် ဒေတာဘေ့စ် အရွယ်အစား ကြီးထွားမှုဆိုင်ရာ ခန့်မှန်းချက်များကို အခြေခံ၍ ပြုပြင်ထိန်းသိမ်းမှု windows ကို စီစဉ်ပါ။

7.4 အလိုအလျောက် စောင့်ကြည့်ခြင်းနှင့် သတိပေးခြင်း။

configure SQL Server DBCC CHECKDB သည် အဂတိလိုက်စားမှုကို ဖော်ထုတ်သည့်အခါ စီမံခန့်ခွဲသူများကို ချက်ချင်းအကြောင်းကြားရန် Agent မှ သတိပေးသည်။ ခိုင်မာမှုစစ်ဆေးခြင်းရလဒ်များကို ထုတ်ယူပြီး အမျိုးအစားခွဲသည့် မှတ်တမ်းခွဲခြမ်းစိတ်ဖြာသည့် ဖြေရှင်းချက်များအား အကောင်အထည်ဖော်ပါ၊ လမ်းကြောင်းခွဲခြမ်းစိတ်ဖြာမှုနှင့် ပြဿနာကို ကြိုတင်ဖော်ထုတ်ခြင်းတို့ကို လုပ်ဆောင်ပါ။ မတူညီသော အကျင့်ပျက်ခြစားမှုပြင်းထန်မှုအဆင့်များအတွက် တုံ့ပြန်မှုအချိန်ဘောင်များနှင့် တာဝန်ရှိဝန်ထမ်းများကို သတ်မှတ်သည့် တိုးမြင့်သည့်လုပ်ငန်းစဉ်များကို ဖန်တီးပါ။

8. DBCC စစ်ဆေးခြင်း- ပေါ့ပါးသောရွေးချယ်မှု

8.1 မည်သည့်အချိန်တွင် CHECKTABLE ကို CHECKDB အစား အသုံးပြုရမည်နည်း။

DBCC CHECKTABLE သည် ဇယားတစ်ခုချင်းစီအတွက် အလေးပေးထားသော သမာဓိစစ်ဆေးခြင်းကို ပံ့ပိုးပေးသည်၊ ၎င်းသည် စံပြဖြစ်စေသည်၊ tarသီးခြားဒေတာဘေ့စ်အရာဝတ္ထုများ၏ ပြဿနာဖြေရှင်းခြင်းနှင့် ပြုပြင်ထိန်းသိမ်းခြင်းတို့ကို ရရှိခဲ့သည်။ ဒေတာဘေ့စ်စစ်ဆေးမှုများ အပြည့်အစုံကြားရှိ အရေးကြီးသော လုပ်ငန်းဇယားများကို စစ်ဆေးသည့်အခါ သို့မဟုတ် အချိန်ကန့်သတ်ချက်များကြောင့် ဒေတာဘေ့စ်စစ်ဆေးခြင်းကို အပြီးအပြတ်တားဆီးသောအခါတွင် CHECKTABLE ကို အသုံးပြုပါ။ CHECKDB လုပ်ဆောင်ချက် အပြည့်အစုံသည် ရရှိနိုင်သော ပြုပြင်ထိန်းသိမ်းမှု ပြတင်းပေါက်များထက် ကျော်လွန်သည့် ကြီးမားသောဒေတာဘေ့စ်များတွင် ဤချဉ်းကပ်မှုသည် အထူးသဖြင့် အဖိုးတန်ကြောင်း သက်သေပြပါသည်။

8.2 DBCC စစ်ဆေးချက်ဇယား အထားအသိုနှင့် ဥပမာများ

အခြေခံ checkTABLE အမိန့် tarသီးခြားဇယားများရရှိသည်-

DBCC CHECKTABLE('YourTable')

CHECKDB ကဲ့သို့ပင်၊ CHECKTABLE သည် အကျင့်ပျက်ခြစားမှုဖြေရှင်းမှုအတွက် စွမ်းဆောင်ရည်ပိုကောင်းအောင်နှင့် ပြုပြင်ခြင်းဆိုင်ရာ ကန့်သတ်ဘောင်များအတွက် NOINDEX အပါအဝင် ရွေးချယ်စရာအမျိုးမျိုးကို ပံ့ပိုးပေးပါသည်။ တိကျသောဇယားသတ်မှတ်ခြင်းအတွက် schema အမည်များကိုလည်း သင်သတ်မှတ်နိုင်သည်-

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

ဤ targeted approach သည် ရုံးချိန်အတွင်း စနစ်စွမ်းဆောင်ရည်ကို ထိန်းသိမ်းထားစဉ် အသေးစိတ် ခိုင်မာမှုကို စစ်ဆေးခြင်းကို ခွင့်ပြုသည်။

8.3 ကြီးမားသော ဒေတာဘေ့စ်များအတွက် စွမ်းဆောင်ရည် အကျိုးကျေးဇူးများ

CHECKTABLE လုပ်ဆောင်ချက်များသည် ဒေတာဘေ့စ်စစ်ဆေးမှုများထက် သိသိသာသာ ပိုမိုမြန်ဆန်စွာ ပြီးမြောက်ပြီး အရေးကြီးသောဇယားများ၏ မကြာခဏ သမာဓိရှိမှုကို ပိုမိုအတည်ပြုနိုင်စေပါသည်။ ဤချဉ်းကပ်မှုသည် အပတ်စဉ် သို့မဟုတ် လစဉ်အချိန်ဇယားများအတွက် ကျယ်ကျယ်ပြန့်ပြန့် CHECKDB လည်ပတ်မှုများကို သိမ်းဆည်းထားစဉ် မရှိမဖြစ်လိုအပ်သော လုပ်ငန်းဇယားများကို နေ့စဉ်အတည်ပြုနိုင်စေပါသည်။ အရင်းအမြစ်သုံးစွဲမှု လျှော့ချခြင်းသည် အသုံးပြုသူအပေါ် သက်ရောက်မှုအနည်းဆုံးဖြင့် ထုတ်လုပ်မှုပတ်ဝန်းကျင်ကို အကောင်အထည်ဖော်ရန်အတွက် CHECKTABLE ကို သင့်လျော်စေသည်။

9. CHECKDB မအောင်မြင်သောအခါ

DBCC CHECKDB သည် အောက်ပါအပါအဝင် အမျိုးမျိုးသော အခြေအနေများတွင် ကျရှုံးလိမ့်မည်-

• DBCC CHECKDB လုပ်ဆောင်မှု ပုံမှန်မဟုတ်သောအဆုံးသတ်
• DBCC CHECKDB ကွပ်မျက်မှု အောင်မြင်စွာပြီးမြောက်သော်လည်း၊ ပြုပြင်စရာများ ဒေတာဘေ့စ်ကိုပြုပြင်ရန်ပျက်ကွက်။

ဤအခြေအနေများတွင်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ရှိ အကျင့်ပျက်ခြစားမှုများကို ဖြေရှင်းရန် ကျွန်ုပ်တို့ကို ကူညီရန် ပိုမိုကျွမ်းကျင်သောကိရိယာတစ်ခု လိုအပ်ပါသည်။

9.1 နိဒါန်း DataNumen SQL Recovery

DataNumen SQL Recovery ပိုမိုအဆင့်မြင့်သောစွမ်းရည်များကို ပံ့ပိုးပေးသည်-

• အကောင်းဆုံးပြန်လည်နာလန်ထူနှုန်း စက်မှုလုပ်ငန်းအတွက်။
• ဆိုးရွားစွာ ပျက်စီးနေသော ဒေတာဘေ့စ်ဖိုင်များကို ပြန်လည်ရယူပါ။
• ဇယားများ၊ အညွှန်းများ၊ အမြင်များ၊ အစပျိုးမှုများ၊ စည်းမျဉ်းများနှင့် ပုံသေများအပါအဝင် ဒေတာဘေ့စ်အရာဝတ္ထုအားလုံးကို ပြန်လည်ရယူပါ။
• သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများ၊ စကေးလုပ်ဆောင်ချက်များ၊ ဇယားအတွင်းတန်ဖိုးရှိသော လုပ်ဆောင်ချက်များ၊ နှင့် multistatement table-valued လုပ်ဆောင်ချက်များကို ပြန်လည်ရယူပါ။
• အပြီးတိုင်ဖျက်ထားသော မှတ်တမ်းများကို ပြန်လည်ရယူပါ။
• ကုဒ်ဝှက်ထားသော အရာဝတ္ထုများကို ကုဒ်ဝှက်ပါ။ SQL Server ဒေတာဘေ့စ။
• MDF ဖိုင်များကို အတွဲလိုက် ပြုပြင်ပါ။
• ပြီးပြည့်စုံသော ပြုပြင်မှုရွေးချယ်စရာများ။
• အဆင့်မြင့် သစ်ခုတ်ခြင်းနှင့် အစီရင်ခံခြင်း။
• အားလုံးအတွက် အထောက်အပံ့ SQL Server ဗားရှင်း။
• နည်းပညာပံ့ပိုးမှု ရရှိနိုင်မှု
• ပုံမှန်မွမ်းမံမှုများနှင့် တိုးတက်မှုများ

9.2 အောင်မြင်မှုနှုန်း နှိုင်းယှဉ်ခြင်း။

ပြန်လည်ထူထောင်ရေး အောင်မြင်မှုနှုန်း သိသိသာသာ ကွာခြားသည်-

• DBCC စစ်ဆေးခြင်း DB နှင့် စစ်ဆေးခြင်း 1.27% ပျမ်းမျှပြန်လည်နာလန်ထူနှုန်း
• DataNumen: 92.6% ပြန်လည်ထူထောင်ရေးနှုန်း

အောက်တွင် ပြီးပြည့်စုံသော ယှဉ်ပြိုင်မှု နှိုင်းယှဉ်ချက်ဖြစ်ပါသည်။

9.3 ပြင်းထန်သော အကျင့်ပျက်ခြစားမှုမှ ပြန်လည်ရယူခြင်း။

ပြင်းထန်သောကိစ္စများအတွက် အဆင့်မြင့်စွမ်းဆောင်ရည်များ-

• ရုပ်ပိုင်းဆိုင်ရာ ပျက်စီးနေသော သိုလှောင်မှုမှ ပြန်လည်ရယူခြင်း။
• ဖော်မတ်လုပ်ထားသော drives သို့မဟုတ် ပျက်စီးသွားသော စနစ်များမှ ပြန်လည်ရယူပါ။
• ဒစ်ခ်ပုံများ၊ အရန်ဖိုင်များ၊ virtual machine disk ဖိုင်များ၊ tempo များမှ ပြန်လည်ရယူပါ။rary ဖိုင်များ စသည်တို့

9.4 ပရော်ဖက်ရှင်နယ်ဖြေရှင်းနည်းများကို ဘယ်အချိန်မှာ စဉ်းစားရမလဲ

• မကြာသေးမီက အရန်သိမ်းဆည်းမှု မရရှိနိုင်ပါ။
• DBCC CHECKDB မအောင်မြင်ပါ။
• ဆိုးရွားသော အကျင့်ပျက်ခြစားမှု အခြေအနေများ
• အရေးကြီးသော လုပ်ငန်းဒေတာများကို ကိုင်တွယ်ဖြေရှင်းခြင်း။
• အချိန်က အရေးကြီးလာတဲ့အခါ
• အများဆုံးပြန်လည်နာလန်ထူသည့်အခါမရှိမဖြစ်လိုအပ်ပါသည်။

၇

11 ။ ကောက်ချက်

11.1 အဓိကအချက်များ အကျဉ်းချုပ်

11.1.1 မရှိမဖြစ် DBCC စစ်ဆေးခြင်း

ပြီးပြည့်စုံသော ဒေတာဘေ့စ်စစ်ဆေးခြင်းအတွက် အခြေခံ DBCC CHECKDB syntax ကို ကျွမ်းကျင်အောင်၊ စွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန်အတွက် NOINDEX နှင့် PHYSICAL_ONLY ရွေးချယ်မှုများကို အသုံးပြုပြီး CHECKTABLE ကို နားလည်ပါ။ tarဇယားအတည်ပြုချက်ကို ရရှိခဲ့သည်။ ဤအခြေခံအမိန့်များသည် အကျင့်ပျက်ခြစားမှုကို စောစီးစွာသိရှိနိုင်စေရန်နှင့် စနစ်တကျ သမာဓိစောင့်ကြပ်ခြင်းတို့ကို လုပ်ဆောင်ပေးသည့် ဒေတာဘေ့စ်ထိန်းသိမ်းမှု၏ အခြေခံအုတ်မြစ်ဖြစ်သည်။

11.1.2 အရေးကြီးသော အကောင်းဆုံးအလေ့အကျင့်များ သတိပေးချက်

ခိုင်မာမှုစစ်ဆေးမှုများမလုပ်ဆောင်မီ လက်ရှိအရန်သိမ်းဆည်းမှုများကို အမြဲထိန်းသိမ်းထားပါ၊ ဒေတာဘေ့စ်ဝေဖန်ချက်အပေါ်အခြေခံ၍ ပုံမှန် CHECKDB လုပ်ဆောင်ချက်များကို အချိန်ဇယားဆွဲပြီး အကျင့်ပျက်ခြစားမှုသတိပေးချက်များအတွက် အလိုအလျောက်စောင့်ကြည့်ခြင်းကို အကောင်အထည်ဖော်ပါ။ ပုံမှန်စောင့်ကြည့်ခြင်းမှတစ်ဆင့် ကြိုတင်ကာကွယ်ခြင်းသည် ဓာတ်ပြုမှုနည်းလမ်းများကို ကျော်လွန်ပြီး စံကိရိယာများ မလုံလောက်ပါက ပရော်ဖက်ရှင်နယ် ပြန်လည်ရယူရေးနည်းလမ်းများသည် အဖိုးတန်သော အရန်ရွေးချယ်မှုများကို ပေးဆောင်ကြောင်း သတိရပါ။

11.2 ဘယ်အချိန်မှာ DBCC CHECKDB နှင့် Advanced Solutions ကို အသုံးပြုရမည်နည်း။

အကျင့်ပျက်ခြစားမှုအခြေအနေများထက် ပြင်းထန်သော အကျင့်ပျက်ခြစားမှုအခြေအနေများအတွက် ပရော်ဖက်ရှင်နယ်ပြန်လည်ရယူရေးကိရိယာများကို သိမ်းဆည်းထားစဉ် ပုံမှန်သမာဓိစောင့်ကြပ်ကြည့်ရှုခြင်းနှင့် အသေးစားအဂတိလိုက်စားမှုဖြေရှင်းခြင်းအတွက် DBCC CHECKDB ကို အသုံးပြုပါ။ ဆုံးဖြတ်ချက်မူဘောင်သည် အရန်သိမ်းဆည်းနိုင်မှု၊ ဒေတာဝေဖန်နိုင်မှု၊ အချိန်ကန့်သတ်ချက်များနှင့် အကျင့်ပျက်ခြစားမှု ပြင်းထန်မှုကို ထည့်သွင်းစဉ်းစားသင့်သည်။ အောင်မြင်သော ဒေတာဘေ့စ် စီမံခန့်ခွဲသူများသည် ပုံမှန် CHECKDB စောင့်ကြည့်ခြင်းအား ပြည့်စုံသော အရန်ဗျူဟာများနှင့် စံချဉ်းကပ်မှုများ မလုံလောက်ကြောင်း သက်သေပြသည့်အခါ အဆင့်မြင့် ပြန်လည်ရယူခြင်းဆိုင်ရာ ရွေးချယ်မှုများကို သတိထားရန် ပေါင်းစပ်ထားသည်။

11.3 DBA များအတွက် အမြန်နေ့စဉ် ကျန်းမာရေး စစ်ဆေးမှုစာရင်း

DBCC CHECKDB ကိုအသုံးပြုခြင်းအပြင်၊ ဤမရှိမဖြစ်လိုအပ်သောနေ့စဉ်အလေ့အကျင့်များဖြင့် အကောင်းဆုံးဒေတာဘေ့စ်ကျန်းမာရေးကို ထိန်းသိမ်းပါ။

1. Backup Integrity ကို အတည်ပြုပါ။

• စီစဉ်ထားသော အရန်သိမ်းဆည်းမှုများကို အောင်မြင်စွာ အတည်ပြုပါ။
• မိတ္တူဖတ်နိုင်မှုကို အတည်ပြုရန် ပြန်လည်ရယူရန် VERIFYONLY ကိုသုံးပါ။
• ပြင်ပရှိမိတ္တူများကို တစ်ပြိုင်တည်းလုပ်ဆောင်ပြီး သုံးနိုင်ကြောင်း သေချာပါစေ။

ထံမှ အချက်အလက်များ ပိုမိုရရှိနိုင်ပါသည်။ ကျွန်ုပ်တို့၏ ပြည့်စုံသောလမ်းညွှန်ချက် SQL Server backup လုပ်ထား.

2. ညီညွတ်မှုအခြေအနေအား ပြန်လည်သုံးသပ်ပါ။

• နေ့ချင်းညချင်း လုပ်ဆောင်ခြင်းမှ အလိုအလျောက် DBCC CHECKDB ရလဒ်များကို စစ်ဆေးပါ။
• စောငျ့ရှောကျ SQL Server အကျင့်ပျက်ခြစားမှုသတိပေးချက်များအတွက် အမှားမှတ်တမ်းများ
• သမာဓိပျက်ကွက်မှုကို ချက်ချင်းစုံစမ်းပါ။

3. ဆာဗာကျန်းမာရေးကို စောင့်ကြည့်ပါ။

• CPU၊ Memory နှင့် Disk I/O တိုင်းတာချက်များကို စစ်ဆေးပါ။
• tempdb နေရာ ရရှိနိုင်မှုကို စစ်ဆေးပါ။
• ပိတ်ဆို့ထားသော လုပ်ငန်းစဉ်များနှင့် ကာလရှည်ကြာ မေးမြန်းမှုများကို ဖော်ထုတ်ပါ။

4. Deadlock လုပ်ဆောင်ချက်ကို ခြေရာခံပါ။

• စနစ်ကျန်းမာရေးဆိုင်ရာ ဖြစ်ရပ်များမှ မရပ်မနား ဂရပ်များကို ပြန်လည်သုံးသပ်ပါ။
• ပြဿနာရှိသောမေးခွန်းများကို ဖော်ထုတ်ပြီး ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များနှင့် အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။
• ပိတ်မိနေသော သားကောင်အရေအတွက်နှင့် လုပ်ငန်းအပေါ် သက်ရောက်မှုများကို စောင့်ကြည့်ပါ။

အရေးကြီးသတိပေးချက်

• မကြာခဏဒေတာဘေ့စ်ကျုံ့ခြင်းကိုရှောင်ကြဉ်ပါ။ - အကွဲအပြဲများကို တိုးစေပြီး စွမ်းဆောင်ရည်ကို ကျဆင်းစေသည်။ အမှန်တကယ်လိုအပ်သည့်အခါတွင် ကြီးမားသောဒေတာကို ဖျက်ပြီးနောက်မှသာ ကျုံ့သွားနိုင်သည်။
• စောင့်ကြည့်ခြင်းလုပ်ငန်းများကို အလိုအလျောက်လုပ်ပါ။ သုံးပြီး SQL Server အရေးကြီးသောပြဿနာများအတွက် သတိပေးချက်များပါရှိသော အေးဂျင့်အလုပ်များ သို့မဟုတ် ပြုပြင်ရေးအစီအစဉ်များ။
• ဘေးအန္တရာယ်ပြန်လည်ထူထောင်ရေးလုပ်ငန်းစဉ်များကို စမ်းသပ်ပါ။ အရန်သိမ်းဆည်းမှုများကို ပြန်လည်ရယူနိုင်ပြီး ပြန်လည်ရယူရေး ရည်မှန်းချက်များကို ရရှိနိုင်စေရန် အပတ်စဉ်။

ဤနေ့စဉ်စစ်ဆေးစာရင်းကို ပုံမှန် DBCC CHECKDB လုပ်ဆောင်ချက်များနှင့် ပေါင်းစပ်ခြင်းဖြင့်၊ သင်သည် ကြိုတင်စောင့်ကြည့်ခြင်းနှင့် ပြဿနာကို တုံ့ပြန်ခြင်းမှတစ်ဆင့် သင့်ဒေတာဘေ့စ်ပတ်ဝန်းကျင်အတွက် ပြီးပြည့်စုံသောအကာအကွယ်ကို ဖန်တီးပေးပါသည်။

ကိုးကား

1. Microsoft ကို လေ့လာပါ။ "DBCC စစ်ဆေးခြင်း (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
2. Microsoft ကို လေ့လာပါ။ "DBCC CHECKDB မှ တင်ပြထားသော ဒေတာဘေ့စ်ညီညွတ်မှု အမှားများကို ပြဿနာဖြေရှင်းပါ။" SQL Server မှတ်တမ်း. Microsoft ကော်ပိုရေးရှင်း။
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors