DBCC CHECKDB៖ ការណែនាំពេញលេញចំពោះ MS SQL Server សុខភាពមូលដ្ឋានទិន្នន័យ (2025)

អំពើពុករលួយនៃមូលដ្ឋានទិន្នន័យគឺរាល់ SQL Server សុបិន្តអាក្រក់របស់អ្នកគ្រប់គ្រង។ នៅពេលដែលទិន្នន័យអាជីវកម្មសំខាន់ៗមិនអាចចូលប្រើបាន ឬមិនអាចជឿទុកចិត្តបាន គost អាចជាការបំផ្លិចបំផ្លាញ។ មគ្គុទ្ទេសក៍ដ៏ទូលំទូលាយនេះគ្របដណ្តប់អ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវដឹងអំពីការប្រើប្រាស់ DBCC CHECKDB ដើម្បីរក្សាសុខភាពមូលដ្ឋានទិន្នន័យ និងការពារអំពើពុករលួយ បូករួមទាំងដំណោះស្រាយសង្គ្រោះកម្រិតខ្ពស់សម្រាប់ពេលដែលឧបករណ៍ស្តង់ដារមិនគ្រប់គ្រាន់។

១.២. សារៈសំខាន់នៃ SQL Server សុខភាពមូលដ្ឋានទិន្នន័យ

១.១ អ្វី​ទៅ​ជា​ការ​ខូច​ខាត​មូលដ្ឋាន​ទិន្នន័យ គosts អាជីវកម្ម

ថ្ងៃនេះ មost អាជីវកម្មរក្សាទុកទិន្នន័យសំខាន់របស់ពួកគេនៅក្នុងមូលដ្ឋានទិន្នន័យ។ នៅពេលដែលអំពើពុករលួយនៃមូលដ្ឋានទិន្នន័យកើតឡើង ផលវិបាកគឺមហន្តរាយ៖

• ការខាតបង់ផ្នែកហិរញ្ញវត្ថុ ជាមធ្យម 2.3 លានដុល្លារក្នុងមួយឆ្នាំ ដោយសារការបាត់បង់ទិន្នន័យ ជាមួយនឹងការបរាជ័យផ្នែករឹង និងអំពើពុករលួយជាមូលហេតុចម្បង (EMC Corporation)
• អត្រាបិទអាជីវកម្ម បង្ហាញថា 50% នៃអាជីវកម្មខ្នាតតូចដែលជួបប្រទះការបាត់បង់ទិន្នន័យដោយសារតែការបរាជ័យផ្នែករឹងបានចាកចេញពីអាជីវកម្មក្នុងរយៈពេល 94 ឆ្នាំ ខណៈដែល XNUMX% នៃអាជីវកម្មដែលមានការបាត់បង់ទិន្នន័យមហន្តរាយមិនអាចរស់បានទាល់តែសោះ។
• ប្រេកង់ខូចទិន្នន័យ ប៉ះពាល់ដល់ 20% នៃកម្មវិធីបេសកកម្មសំខាន់ៗជារៀងរាល់ឆ្នាំ ដែលបណ្តាលឱ្យមានការរំខានដល់ការបន្តអាជីវកម្ម (ការស្រាវជ្រាវ Gartner)
• អំពើពុករលួយទាក់ទងនឹងផ្នែករឹង មានចំនួន 67% នៃឧប្បត្តិហេតុបាត់បង់ទិន្នន័យទាំងអស់តាមរយៈការគាំងដ្រាយវ៍រឹង និងការបរាជ័យរបស់ប្រព័ន្ធ ដោយ 40% នៃការបាត់បង់ទិន្នន័យត្រូវបានសន្មតដោយផ្ទាល់ថាមានបញ្ហាផ្នែករឹង។
• អំពើពុករលួយផ្នែកទន់ គosts មានចាប់ពីរាប់ពាន់ទៅរាប់លានដុល្លារ អាស្រ័យលើភាពធ្ងន់ធ្ងរ និងវិសាលភាព ដោយ 82% នៃអាជីវកម្មជួបប្រទះនឹងការដាច់ភ្លើងដោយមិនបានគ្រោងទុក ដែលអំពើពុករលួយជាមូលហេតុឈានមុខគេ។

1.2 ហេតុអ្វីបានជាការពិនិត្យសុខភាពជាទៀងទាត់មានសារៈសំខាន់

មនុស្សត្រូវការការពិនិត្យសុខភាពជាប្រចាំ ដើម្បីរកមើលជំងឺដែលអាចកើតមានបានទាន់ពេលវេលា។ ដូចគ្នានេះដែរ មូលដ្ឋានទិន្នន័យក៏ត្រូវការការត្រួតពិនិត្យសុខភាពជាប្រចាំផងដែរ៖

1. ស្វែងរកអំពើពុករលួយដែលអាចកើតមាននៅដំណាក់កាលដំបូង និងដោះស្រាយវាឱ្យទាន់ពេលវេលា ការពារបញ្ហាកុំឱ្យកាន់តែធ្ងន់ធ្ងរ និងរីករាលដាល ដែលអាចនាំឱ្យមានមហន្តរាយដល់អាជីវកម្ម។
2. ត្រូវប្រាកដថាមូលដ្ឋានទិន្នន័យដំណើរការក្នុងដំណើរការល្អបំផុត។
3. គost នៃការត្រួតពិនិត្យសុខភាពមូលដ្ឋានទិន្នន័យសកម្មគឺទាបជាងការសង្គ្រោះទិន្នន័យដែលមានប្រតិកម្មបន្ទាប់ពីគ្រោះមហន្តរាយមូលដ្ឋានទិន្នន័យកើតឡើង។

1.3 សេចក្តីណែនាំអំពីពាក្យបញ្ជាសុចរិតភាពមូលដ្ឋានទិន្នន័យ

SQL Server ផ្តល់​នូវ​ពាក្យ​បញ្ជា​ដែល​មាន​ស្រាប់​ជា​ច្រើន​សម្រាប់​ការ​រក្សា​សុខភាព​មូលដ្ឋាន​ទិន្នន័យ ដោយ​មាន DBCC ពិនិត្យ បម្រើជា មost ឧបករណ៍ត្រួតពិនិត្យភាពត្រឹមត្រូវដ៏ទូលំទូលាយមាន។ ពាក្យបញ្ជាទាំងនេះធ្វើការជាមួយគ្នាដើម្បីផ្ទៀងផ្ទាត់ទិដ្ឋភាពផ្សេងគ្នានៃរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យរបស់អ្នក ពីតារាងនីមួយៗរហូតដល់ភាពស៊ីសង្វាក់គ្នានៃមូលដ្ឋានទិន្នន័យទាំងមូល បង្កើតយុទ្ធសាស្ត្រថែទាំពេញលេញដែលរក្សាទិន្នន័យរបស់អ្នកឱ្យមានសុវត្ថិភាព និងអាចចូលប្រើប្រាស់បាន។

2. តើអ្វីទៅជា DBCC CHECKDB

DBCC ពិនិត្យ is SQL Serverឧបករណ៍ចម្បងសម្រាប់ផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃមូលដ្ឋានទិន្នន័យ និងកំណត់បញ្ហាអំពើពុករលួយ។

• វាគឺជាសេចក្តីថ្លែងការណ៍ T-SQL មិនមែនជាឧបករណ៍ GUI ទេ។
• អ្នកអាចប្រតិបត្តិវាតាមវិធីទូទៅដូចជា SQL Server ស្ទូឌីយោគ្រប់គ្រង (SSMS), SQL Server ភ្នាក់ងារ SQLCMD ជាដើម។

2.1 អ្វីដែល CHECKDB ពិតជាពិនិត្យនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់អ្នក។

នៅពេលអ្នកដំណើរការ DBCC CHECKDB ពាក្យបញ្ជាដំណើរការស្រទាប់សុពលភាពច្រើននៅទូទាំងរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យរបស់អ្នក៖

• ការផ្ទៀងផ្ទាត់ទំព័រ Checksums ដើម្បីស្វែងរកអំពើពុករលួយ និងបញ្ហាទាក់ទងនឹងផ្នែករឹង
• ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃសន្ទស្សន៍ ដើម្បីធានាបាននូវការទាញយកទិន្នន័យ និងដំណើរការសំណួរត្រឹមត្រូវ។
• ការត្រួតពិនិត្យរចនាសម្ព័ន្ធបែងចែក ដើម្បីបញ្ជាក់ការប្រើប្រាស់ទំហំត្រឹមត្រូវ និងការបែងចែកទំព័រ
• ការពិនិត្យភាពត្រឹមត្រូវនៃឯកសារយោង រវាងតារាងដែលពាក់ព័ន្ធ និងទំនាក់ទំនងគន្លឹះបរទេស
• ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃតារាងប្រព័ន្ធ ដើម្បីធានា SQL Serverទិន្នន័យមេតាខាងក្នុងរបស់នៅតែអាចទុកចិត្តបាន។
• ការផ្ទៀងផ្ទាត់តំណភ្ជាប់ទំព័រទិន្នន័យ ដើម្បីបញ្ជាក់ភាពត្រឹមត្រូវនៃខ្សែសង្វាក់ទំព័រត្រឹមត្រូវ។
• ភាពស៊ីសង្វាក់គ្នានៃគ្រោងការណ៍មូលដ្ឋានទិន្នន័យ ដើម្បីធ្វើសុពលភាពនិយមន័យ និងភាពអាស្រ័យវត្ថុ

ការត្រួតពិនិត្យដ៏ទូលំទូលាយទាំងនេះគ្របដណ្តប់ទាំងទិន្នន័យអ្នកប្រើប្រាស់ និងរចនាសម្ព័ន្ធប្រព័ន្ធ ដោយផ្តល់នូវការមើលឃើញពេញលេញទៅក្នុងស្ថានភាពសុខភាពនៃមូលដ្ឋានទិន្នន័យរបស់អ្នក។

3. ដំណើរការ DBCC CHECKDB៖ ជំហានដោយជំហាន

3.1 តម្រូវការជាមុន

ខាងក្រោមនេះគឺជាបញ្ជីត្រួតពិនិត្យមុនពេលប្រតិបត្តិប្រតិបត្តិការ DBCC CHECKDB ណាមួយ៖

• ការបម្រុងទុកមូលដ្ឋានទិន្នន័យពេញលេញ - បង្កើតការបម្រុងទុកពេញលេញ មុនពេលដំណើរការការត្រួតពិនិត្យសុចរិតភាពជាសំណាញ់សុវត្ថិភាពរបស់អ្នក ប្រសិនបើអំពើពុករលួយត្រូវបានរកឃើញ ឬប្រតិបត្តិការជួសជុលក្លាយជាចាំបាច់។
• ការអនុញ្ញាតត្រឹមត្រូវ។ - អ្នកត្រូវការការអនុញ្ញាត sysadmin ឬ db_owner ដើម្បីប្រតិបត្តិពាក្យបញ្ជា DBCC CHECKDB
• ធនធានប្រព័ន្ធគ្រប់គ្រាន់៖
  • អង្គចងចាំ៖ ២៥% នៃទំហំមូលដ្ឋានទិន្នន័យ
  • ចន្លោះ Tempdb៖ 10-15% នៃទំហំមូលដ្ឋានទិន្នន័យ
  • ស៊ីភីយូ៖ ភាពអាចរកបាន 50-70% កំឡុងពេលថែទាំ
  • I/O៖ រំពឹងថានឹងមានប្រតិបត្តិការអានខ្លាំង
• ភាពងាយស្រួលនៃមូលដ្ឋានទិន្នន័យ - ផ្ទៀងផ្ទាត់ថាមូលដ្ឋានទិន្នន័យរបស់អ្នកអាចចូលប្រើបាន និងមិនស្ថិតក្នុងស្ថានភាពដាក់កម្រិតទេ ព្រោះ 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/spatial indexes)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
ការត្រួតពិនិត្យលទ្ធផល	ALL_ERRORMSGS	បង្ហាញកំហុសទាំងអស់ (លំនាំដើម៖ ២០០ ក្នុងមួយវត្ថុ)	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	ការប៉ាន់ស្មានទំហំ 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 រកឃើញកំហុសអំពើពុករលួយ វានឹងរាយការណ៍សារកំហុសដែលមានរចនាសម្ព័ន្ធដូចខាងក្រោម៖
ការណែនាំអំពីកម្រិតភាពធ្ងន់ធ្ងរ៖

• កម្រិត ២៥០-១ ០០០ ៈ កំហុសដែលអាចកែបានដោយអ្នកប្រើប្រាស់ ជាញឹកញាប់មានអំពើពុករលួយតិចតួច
• កម្រិត ២៥០-១ ០០០ ៈ កំហុសប្រព័ន្ធ អំពើពុករលួយធ្ងន់ធ្ងរដែលទាមទារការយកចិត្តទុកដាក់ជាបន្ទាន់
• កំរិត ១៖ កំហុសធ្ងន់ធ្ងរ មូលដ្ឋានទិន្នន័យអាចមិនអាចចូលដំណើរការបាន។

កំហុសទូទៅរួមមាន:

• ទំព័រ 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 បោះបង់កំឡុងពេលប្រតិបត្តិរបស់វា ដោយសារហេតុផលផ្សេងៗ វានឹងរាយការណ៍សារកំហុស ហើយបន្ថែមកំណត់ហេតុបញ្ហាជាមួយនឹងលេខកូដរដ្ឋខាងក្រោម៖

រដ្ឋ (State)	ការពិពណ៌នា
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. ស្តារទំព័រដែលខូច ពី most ការបម្រុងទុកពេញលេញនាពេលថ្មីៗនេះ៖

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 REPAIR_REBUILD (ជម្រើសសុវត្ថិភាពជាង)៖

• ប្រើ​សម្រាប់: សន្ទស្សន៍អំពើពុករលួយ និងកំហុសក្នុងការបែងចែកតិចតួច
• សុវត្ថិភាពទិន្នន័យ៖ ការប៉ុនប៉ងជួសជុលអំពើពុករលួយដោយគ្មានការលុបទិន្នន័យ
• កម្រិតហានិភ័យ៖ ទាប - គ្មានការបាត់បង់ទិន្នន័យរំពឹងទុក
• សេណារីយ៉ូធម្មតា៖ អំពើពុករលួយលិបិក្រមដែលមិនមែនជាចង្កោម បញ្ហាទិន្នន័យមេតាតិចតួច
• ឧទាហរណ៍ពាក្យបញ្ជា៖ DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (រមណីយដ្ឋានចុងក្រោយ)៖

• ប្រើ​សម្រាប់: អំពើពុករលួយធ្ងន់ធ្ងរ នៅពេលដែលការបម្រុងទុកមិនអាចប្រើបាន
• សុវត្ថិភាពទិន្នន័យ៖ អាចលុបទិន្នន័យដែលខូច ដើម្បីស្តារមុខងារមូលដ្ឋានទិន្នន័យឡើងវិញ
• កម្រិតហានិភ័យ៖ ខ្ពស់ - ការបាត់បង់ទិន្នន័យជាអចិន្ត្រៃយ៍អាចធ្វើទៅបាន
• សេណារីយ៉ូធម្មតា៖ ខូចទំព័រ ខូចតារាងប្រព័ន្ធ កំហុសខ្សែសង្វាក់បែងចែក
• ឧទាហរណ៍ពាក្យបញ្ជា៖ DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 ការអនុវត្តល្អបំផុតសម្រាប់ជម្រើសទាំងនេះ៖

• សាកល្បងជានិច្ច ប្រតិបត្តិការជួសជុលលើច្បាប់ចម្លងមូលដ្ឋានទិន្នន័យនៅពេលដែលអាចធ្វើទៅបាន
• បម្រុងទុកជានិច្ច មុនពេលដំណើរការជម្រើសទាំងនេះ
• រៀបចំឯកសារផ្លាស់ប្តូរទាំងអស់។ សម្រាប់គោលបំណងអនុលោមភាព និងដោះស្រាយបញ្ហា
• កំណត់មូលដ្ឋានទិន្នន័យទៅជាទម្រង់អ្នកប្រើប្រាស់តែមួយ មុនពេលដំណើរការជួសជុល

ជាធម្មតាយើងគួរតែព្យាយាម REPAIR_REBUILD ជម្រើសដំបូង។ ប្រសិនបើវាបរាជ័យបន្ទាប់មកព្យាយាម 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	Error10_1.mdf (Msg 8909 តាមដោយ Msg 8939) (600 records lost ជាមួយ REPAIR_ALLOW_DATA_LOSS)	Error10_1_fixed.mdf (គ្មានកំណត់ត្រា lost)
SQL Server 2014	Error10_2.mdf (Msg 8909 តាមដោយ Msg 8939) (6000 records(50%) lost ជាមួយ REPAIR_ALLOW_DATA_LOSS)	Error10_2_fixed.mdf (មានតែ 100 កំណត់ត្រា lost)
SQL Server 2014	កំហុស ៩.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 (សារតែមួយ 824)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (កំហុស Msg 824 បន្ត)	កំហុស1_1_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 (សារ 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (សារ 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (សារ 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (សារ 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (សារ 5028)	Error3_fixed.mdf
SQL Server 2014	កំហុស ៩.mdf (សារ 5125)	កំហុស ៩_fixed.mdf
SQL Server 2014	Error9.mdf (សារ 3313)	Error9_fixed.mdf

7. ការអនុវត្តល្អបំផុត

7.1 ការកំណត់កាលវិភាគប្រតិបត្តិការ CHECKDB ទៀងទាត់

អនុវត្តការប្រតិបត្តិ DBCC CHECKDB ប្រចាំសប្តាហ៍សម្រាប់មូលដ្ឋានទិន្នន័យផលិតកម្មសំខាន់ៗ ជាមួយនឹងការត្រួតពិនិត្យប្រចាំថ្ងៃសម្រាប់ប្រព័ន្ធប្រតិបត្តិការខ្ពស់។ កំណត់ពេលប្រតិបត្តិការកំឡុងពេលប្រើប្រាស់តិច ដើម្បីកាត់បន្ថយផលប៉ះពាល់នៃដំណើរការ ហើយពិចារណាបង្វិលរវាងការត្រួតពិនិត្យពេញលេញ និងជម្រើស PHYSICAL_ONLY ដោយផ្អែកលើទំហំមូលដ្ឋានទិន្នន័យ និងបង្អួចថែទាំ។ ការកំណត់កាលវិភាគដោយស្វ័យប្រវត្តិតាមរយៈ SQL Server ភ្នាក់ងារធានានូវការប្រតិបត្តិជាប់លាប់ ខណៈពេលដែលផ្តល់នូវសមត្ថភាពត្រួតពិនិត្យ និងការជូនដំណឹងជាកណ្តាល។

7.2 ការគ្រប់គ្រងផលប៉ះពាល់លើការអនុវត្ត

ប្រតិបត្តិការ DBCC CHECKDB ប្រើប្រាស់ធនធានប្រព័ន្ធសំខាន់ៗ ដែលអាចមានផលប៉ះពាល់ដល់សកម្មភាពអ្នកប្រើប្រាស់ដំណាលគ្នា។ ត្រួតពិនិត្យការប្រើប្រាស់ស៊ីភីយូ ការប្រើប្រាស់អង្គចងចាំ និងឌីស I/O កំឡុងពេលពិនិត្យ ដើម្បីយល់ពីគំរូផលប៉ះពាល់នៃដំណើរការ។ ពិចារណាប្រើជម្រើស NOINDEX សម្រាប់ការត្រួតពិនិត្យជាប្រចាំ ដោយរក្សាសុពលភាពពេញលេញសម្រាប់បង្អួចថែទាំប្រចាំខែ។ អនុវត្តការពន្យាពេលអស់ពេលនៃសំណួរ និងយុទ្ធសាស្ត្រទំនាក់ទំនងរបស់អ្នកប្រើប្រាស់ ដើម្បីគ្រប់គ្រងការរំពឹងទុកក្នុងអំឡុងពេលត្រួតពិនិត្យភាពត្រឹមត្រូវ។

7.3 ការរៀបចំផែនការថែទាំបង្អួច

សំរបសំរួលកាលវិភាគ DBCC CHECKDB ជាមួយសកម្មភាពថែទាំផ្សេងទៀតដូចជា ប្រតិបត្តិការបម្រុងទុក ការបង្កើតលិបិក្រមឡើងវិញ និងការធ្វើបច្ចុប្បន្នភាពស្ថិតិ។ ជៀសវាងការត្រួតស៊ីគ្នាលើប្រតិបត្តិការដែលពឹងផ្អែកខ្លាំងលើធនធានដែលអាចបង្កឱ្យមានការថយចុះនៃការអនុវត្ត ឬបញ្ហាអស់ពេល។ រៀបចំផែនការថែទាំបង្អួចដោយផ្អែកលើការព្យាករណ៍កំណើនទំហំមូលដ្ឋានទិន្នន័យ ដោយធានាបាននូវពេលវេលាគ្រប់គ្រាន់សម្រាប់ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវពេញលេញ នៅពេលដែលបរិមាណទិន្នន័យកើនឡើង។

7.4 ការត្រួតពិនិត្យ និងការជូនដំណឹងដោយស្វ័យប្រវត្តិ

Configure SQL Server ភ្នាក់ងារជូនដំណឹងដើម្បីជូនដំណឹងដល់អ្នកគ្រប់គ្រងភ្លាមៗនៅពេលដែល DBCC CHECKDB កំណត់អត្តសញ្ញាណអំពើពុករលួយ។ អនុវត្តដំណោះស្រាយញែកកំណត់ហេតុដែលស្រង់ចេញ និងចាត់ថ្នាក់លទ្ធផលត្រួតពិនិត្យសុចរិតភាព បើកការវិភាគនិន្នាការ និងការកំណត់បញ្ហាសកម្ម។ បង្កើតនីតិវិធីបង្កើនដែលកំណត់ពេលវេលាឆ្លើយតប និងបុគ្គលិកទទួលខុសត្រូវសម្រាប់កម្រិតភាពធ្ងន់ធ្ងរនៃអំពើពុករលួយផ្សេងៗគ្នា។

8. DBCC checkTABLE: ជម្មើសជំនួសស្រាល

8.1 ពេលណាត្រូវប្រើ CHECKTABLE ជំនួសឱ្យ CHECKDB

DBCC CHECKTABLE ផ្តល់នូវការត្រួតពិនិត្យសុចរិតភាពដែលផ្តោតលើតារាងនីមួយៗ ដែលធ្វើឱ្យវាល្អសម្រាប់ tarទទួលបានការដោះស្រាយបញ្ហា និងថែទាំវត្ថុមូលដ្ឋានទិន្នន័យជាក់លាក់។ ប្រើ CHECKTABLE នៅពេលស៊ើបអង្កេតបញ្ហាដំណើរការជាមួយតារាងជាក់លាក់ ធ្វើឱ្យតារាងអាជីវកម្មសំខាន់ៗមានសុពលភាពរវាងការត្រួតពិនិត្យមូលដ្ឋានទិន្នន័យពេញលេញ ឬនៅពេលដែលមានឧបសគ្គពេលវេលារារាំងការធ្វើឱ្យមូលដ្ឋានទិន្នន័យពេញលេញ។ វិធីសាស្រ្តនេះបង្ហាញថាមានតម្លៃជាពិសេសនៅក្នុងមូលដ្ឋានទិន្នន័យធំដែលប្រតិបត្តិការ CHECKDB ពេញលេញលើសពីបង្អួចថែទាំដែលមាន។

8.2 DBCC CheckTABLE វាក្យសម្ព័ន្ធ និងឧទាហរណ៍

ពាក្យបញ្ជា checkTABLE មូលដ្ឋាន tarទទួលបានតារាងជាក់លាក់៖

DBCC CHECKTABLE('YourTable')

ដូច CHECKDB ដែរ CHECKTABLE គាំទ្រជម្រើសផ្សេងៗរួមទាំង NOINDEX សម្រាប់ការបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការ និងប៉ារ៉ាម៉ែត្រជួសជុលសម្រាប់ដំណោះស្រាយអំពើពុករលួយ។ អ្នកក៏អាចបញ្ជាក់ឈ្មោះគ្រោងការណ៍សម្រាប់ការកំណត់អត្តសញ្ញាណតារាងច្បាស់លាស់ផងដែរ៖

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

នេះ targeted approach អនុញ្ញាតឱ្យមានការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវជាលំដាប់ ខណៈពេលដែលរក្សាដំណើរការប្រព័ន្ធក្នុងអំឡុងពេលម៉ោងធ្វើការ។

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 ការងើបឡើងវិញពីអំពើពុករលួយធ្ងន់ធ្ងរ

សមត្ថភាពកម្រិតខ្ពស់សម្រាប់ករណីធ្ងន់ធ្ងរ៖

• ការងើបឡើងវិញពីការផ្ទុកដែលខូចរាងកាយ
• ការងើបឡើងវិញពីដ្រាយដែលបានធ្វើទ្រង់ទ្រាយឬប្រព័ន្ធគាំង
• ងើបឡើងវិញពីរូបភាពថាស ឯកសារបម្រុងទុក ឯកសារថាសម៉ាស៊ីននិម្មិត សង្វាក់rarឯកសារ y ជាដើម។

9.4 ពេលណាត្រូវពិចារណាដំណោះស្រាយវិជ្ជាជីវៈ

• មិនមានការបម្រុងទុកថ្មីៗទេ។
• DBCC CHECKDB បរាជ័យ
• សេណារីយ៉ូអំពើពុករលួយធ្ងន់ធ្ងរ
• ដោះស្រាយជាមួយទិន្នន័យអាជីវកម្មសំខាន់ៗ
• នៅពេលដែលពេលវេលាមានសារៈសំខាន់
• នៅពេលដែលការងើបឡើងវិញអតិបរមាគឺចាំបាច់

សំនួរចម្លើយ

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. ឯកសារយោង

1. Microsoft រៀន។ "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
2. Microsoft រៀន។ "ដោះស្រាយបញ្ហាភាពស៊ីសង្វាក់គ្នានៃមូលដ្ឋានទិន្នន័យដែលបានរាយការណ៍ដោយ DBCC CHECKDB ។" SQL Server ឯកសារ. សាជីវកម្ម Microsoft ។
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors