DBCC CHECKDB: MS এর সম্পূর্ণ নির্দেশিকা SQL Server ডাটাবেস স্বাস্থ্য (২০২৫)

DBCC CHECKDB হল SQL Serverএর প্রধান ডাটাবেস ইন্টিগ্রিটি টুল। উদাহরণ সহ এটি কীভাবে ব্যবহার করবেন, দুর্নীতি ঠিক করবেন এবং কর্মক্ষমতা অপ্টিমাইজ করবেন তা শিখুন।

৩. DBCC CHECKDB চালানো: ধাপে ধাপে

3.1 পূর্বশর্তগুলি

যেকোনো DBCC CHECKDB অপারেশন সম্পাদন করার আগে নীচে চেকলিস্টটি দেওয়া হল:

• ডাটাবেস ব্যাকআপ সম্পূর্ণ করুন - দুর্নীতি ধরা পড়লে বা মেরামতের কাজ প্রয়োজন হলে আপনার নিরাপত্তার জাল হিসেবে অখণ্ডতা পরীক্ষা চালানোর আগে একটি সম্পূর্ণ ব্যাকআপ তৈরি করুন।
• যথাযথ অনুমতি - DBCC CHECKDB কমান্ড চালানোর জন্য আপনার sysadmin অথবা db_owner এর অনুমতি প্রয়োজন।
• পর্যাপ্ত সিস্টেম রিসোর্স:
  • মেমোরি: ডাটাবেস আকারের ২৫%
  • টেম্পডিবি স্থান: ডাটাবেস আকারের ১০-১৫%
  • সিপিইউ: রক্ষণাবেক্ষণের সময় ৫০-৭০% প্রাপ্যতা
  • I/O: ভারী পঠন অপারেশন আশা করা হচ্ছে
• ডাটাবেস অ্যাক্সেসযোগ্যতা - যাচাই করুন যে আপনার ডাটাবেস অ্যাক্সেসযোগ্য এবং সীমাবদ্ধ অবস্থায় নেই, কারণ CHECKDB-এর সমস্ত ডাটাবেস পৃষ্ঠাগুলিতে পড়ার অ্যাক্সেস প্রয়োজন।

3.2 মৌলিক কমান্ড

মিost মৌলিক DBCC CHECKDB কমান্ডের তিনটি সাধারণ রূপ রয়েছে:

(১) বর্তমান ডাটাবেস পরীক্ষা করুন (কোনও প্যারামিটার নেই):

DBCC CHECKDB

(২) নাম অনুসারে একটি ডাটাবেস পরীক্ষা করুন:

DBCC CHECKDB ('YourDatabaseName')

(3) আইডি অনুসারে একটি ডাটাবেস পরীক্ষা করুন:

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

এই মৌলিক কমান্ডটি নির্দিষ্ট ডাটাবেসের সম্পূর্ণ অখণ্ডতা পরীক্ষা করে, সমস্ত টেবিল, সূচী এবং সিস্টেম কাঠামো পরীক্ষা করে। স্ট্যান্ডার্ড নামের কোনও স্পেস ছাড়াই ডাটাবেসের জন্য, আপনি উদ্ধৃতিগুলি বাদ দিতে পারেন। কমান্ডটি সম্পূর্ণ না হওয়া পর্যন্ত চলবে, অগ্রগতি বার্তা এবং চূড়ান্ত ফলাফল প্রদর্শন করবে। এই মৌলিক বাক্য গঠনটি ছোট ডাটাবেসের জন্য বা যখন আপনার পর্যাপ্ত রক্ষণাবেক্ষণের সময় থাকে তখন নিখুঁতভাবে কাজ করে।

নিচে DBCC CHECKDB চালানোর একটি স্ক্রিনশট দেওয়া হল SQL Server ম্যানেজমেন্ট স্টুডিও (SSMS):

৩.৩ সম্পূর্ণ বিকল্প

নিচে 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	সকল ত্রুটি দেখায় (ডিফল্ট: প্রতি বস্তুর জন্য ২০০)	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)

৪. আপনার ফলাফল বোঝা

DBCC CHECKDB এর কার্যকরকরণ সফলভাবে সম্পন্ন হয়েছে কিনা তার উপর ভিত্তি করে বিভিন্ন ফলাফল দেবে। আসুন সেগুলি বিস্তারিতভাবে ব্যাখ্যা করি।

৪.১ CHECKDB কার্যকরকরণ সফলভাবে সম্পন্ন হয়েছে

যদি DBCC CHECKDB কার্যকরকরণ সফলভাবে সম্পন্ন হয়, তাহলে এটি আপনার ডাটাবেসের স্বাস্থ্যের অবস্থার উপর নির্ভর করে বিভিন্ন ধরণের ফলাফল রিপোর্ট করবে।

৪.১.১ কোন সমস্যা পাওয়া যায়নি

যদি 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.

এই ফলাফলটি নির্দেশ করে যে আপনার ডাটাবেস সমস্ত পরীক্ষিত কাঠামো জুড়ে নিখুঁত অখণ্ডতা বজায় রেখেছে।

৪.১.২ দুর্নীতির ত্রুটি পাওয়া গেছে

যখনই DBCC CHECKDB কোনও দুর্নীতির ত্রুটি সনাক্ত করে, তখন এটি নিম্নলিখিত কাঠামো সহ একটি ত্রুটি বার্তা রিপোর্ট করবে:
তীব্রতা স্তর নির্দেশিকা:

• স্তর 16-19: ব্যবহারকারী-সংশোধনযোগ্য ত্রুটি, প্রায়শই ছোটখাটো দুর্নীতি
• স্তর 20-24: সিস্টেমের ত্রুটি, গুরুতর দুর্নীতি, যার জন্য তাৎক্ষণিক মনোযোগ প্রয়োজন
• স্তর 25: মারাত্মক ত্রুটি, ডাটাবেস অ্যাক্সেসযোগ্য নাও হতে পারে

সাধারণ ত্রুটির মধ্যে রয়েছে:

• পৃষ্ঠা চেকসাম ব্যর্থতা (বার্তা 824)
• বরাদ্দ ত্রুটি (বার্তা 8928)
• সূচকের ধারাবাহিকতা সমস্যা (বার্তা 8964)

বার্তার কাঠামো বোঝা প্রতিক্রিয়ামূলক পদক্ষেপগুলিকে অগ্রাধিকার দিতে এবং উপযুক্ত পুনরুদ্ধার কৌশল নির্ধারণে সহায়তা করে।

৪.১.৩ সাধারণ তথ্যমূলক এবং সতর্কীকরণ বার্তা

সমস্ত 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'.

৪.২ 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 আপনার ডাটাবেসের দুর্নীতি ঠিক করতে।

৫. দুর্নীতির ত্রুটি সংশোধন করা

৫.১ ব্যাকআপ এবং পুনরুদ্ধার: সবচেয়ে নিরাপদ সমাধান

যখন DBCC CHECKDB দুর্নীতির ত্রুটি সনাক্ত করে, তখন একটি পরিষ্কার ব্যাকআপ থেকে পুনরুদ্ধার করা সবচেয়ে নিরাপদ এবং most নির্ভরযোগ্য সমাধান। এই পদ্ধতিটি তথ্যের অখণ্ডতা নিশ্চিত করে এবং অন্তর্নিহিত দুর্নীতির কারণগুলি দূর করে। পুনরুদ্ধার করার আগে, ব্যাকআপ অখণ্ডতা যাচাই করুন যাচাইকৃতভাবে পুনরুদ্ধার করুন কমান্ড ব্যবহার করুন, এবং ডেটা ক্ষতি কমাতে পয়েন্ট-ইন-টাইম পুনরুদ্ধারের বিকল্পগুলি বিবেচনা করুন। মূল কারণ বিশ্লেষণের জন্য দুর্নীতির বিবরণ নথিভুক্ত করুন, কারণ হার্ডওয়্যার সমস্যা বা সফ্টওয়্যার বাগগুলির পুনরাবৃত্তি রোধ করার জন্য অতিরিক্ত মনোযোগের প্রয়োজন হতে পারে।

৫.২ পৃষ্ঠা-স্তরের দুর্নীতি সমাধান

ছোট ডেটা অংশকে প্রভাবিত করে এমন বিচ্ছিন্ন পৃষ্ঠার দুর্নীতির জন্য, SQL Server এন্টারপ্রাইজ সংস্করণে পৃষ্ঠা পুনরুদ্ধারের ক্ষমতা রয়েছে যা সম্পূর্ণ ডাটাবেস পুনরুদ্ধার ছাড়াই নির্দিষ্ট ক্ষতিগ্রস্ত পৃষ্ঠাগুলি মেরামত করে। এই উন্নত কৌশলটির জন্য সম্পূর্ণ পুনরুদ্ধার মডেল এবং বর্তমান লগ ব্যাকআপ প্রয়োজন।

ধাপে ধাপে পৃষ্ঠা পুনরুদ্ধার প্রক্রিয়া:

1. ক্ষতিগ্রস্ত পৃষ্ঠাটি সনাক্ত করুন CHECKDB ত্রুটি বার্তা থেকে (যেমন, পৃষ্ঠা 1:256)
2. একটি বর্তমান লগ ব্যাকআপ নিন সাম্প্রতিক লেনদেন ক্যাপচার করতে:

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

3. ক্ষতিগ্রস্ত পৃষ্ঠাটি পুনরুদ্ধার করুন মি থেকেost সাম্প্রতিক পূর্ণ ব্যাকআপ:

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

4. ডিফারেনশিয়াল ব্যাকআপ প্রয়োগ করুন (যদি পাওয়া যায়):

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

5. সমস্ত লগ ব্যাকআপ প্রয়োগ করুন ক্রমানুসারে, সদ্য তৈরি করাটি সহ:

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

6. একটি চূড়ান্ত লগ ব্যাকআপ নিন এবং পুনরুদ্ধার করুন পৃষ্ঠাটি বর্তমান আনতে:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

অ-গুরুত্বপূর্ণ তথ্যের বিকল্প: যদি দুর্নীতি অ-গুরুত্বপূর্ণ ডেটাকে প্রভাবিত করে, তাহলে আপনি দুর্নীতিগ্রস্ত কাঠামো পুনর্নির্মাণের আগে নতুন টেবিলে অ-প্রভাবিত সারি রপ্তানি করতে পারেন:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

৫.৩ সূচক দুর্নীতির দ্রুত সমাধান

সূচক দুর্নীতি প্রায়শই পুনর্নির্মাণ ক্রিয়াকলাপগুলিতে ভাল সাড়া দেয় যা অন্তর্নিহিত টেবিল ডেটাকে প্রভাবিত না করে সূচক কাঠামো পুনরায় তৈরি করে:

ALTER INDEX ALL ON YourTable REBUILD

এই পদ্ধতিটি বিশেষ করে নন-ক্লাস্টারড ইনডেক্স দুর্নীতির ক্ষেত্রে ভালো কাজ করে, কারণ পুনর্নির্মাণ সোর্স টেবিল ডেটা থেকে সূচক পৃষ্ঠাগুলি পুনরুত্পাদন করে, কার্যকরভাবে সমস্ত মূল তথ্য সংরক্ষণ করে দুর্নীতি দূর করে।

৬. REPAIR_REBUILD এবং REPAIR_ALLOW_DATA_LOSS ব্যবহার করুন

যদি পূর্ববর্তী সমস্ত পদ্ধতি ব্যর্থ হয় বা সম্ভব না হয়, তাহলে আপনি ডাটাবেস মেরামত করতে REPAIR_REBUILD এবং REPAIR_ALLOW_DATA_LOSS বিকল্পগুলি ব্যবহার করতে পারেন।

৬.১ মেরামত_পুনর্নির্মাণ (নিরাপদ বিকল্প):

• জন্য ব্যবহার করুন: সূচক দুর্নীতি এবং ছোটখাটো বরাদ্দ ত্রুটি
• ডেটা নিরাপত্তা: ডেটা মুছে না ফেলেই দুর্নীতি ঠিক করার চেষ্টা করা হচ্ছে
• ঝুঁকির মাত্রা: কম - কোনও ডেটা ক্ষতির সম্ভাবনা নেই
• সাধারণ পরিস্থিতি: নন-ক্লাস্টারড ইনডেক্স দুর্নীতি, ছোটখাটো মেটাডেটা সমস্যা
• কমান্ডের উদাহরণ: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

৬.২ মেরামত_অবশ্যই_তথ্য_ক্ষতি (শেষ অবলম্বন):

• জন্য ব্যবহার করুন: ব্যাকআপ অনুপলব্ধ থাকলে গুরুতর দুর্নীতি
• ডেটা নিরাপত্তা: ডাটাবেসের কার্যকারিতা পুনরুদ্ধার করতে দূষিত ডেটা মুছে ফেলতে পারে
• ঝুঁকির মাত্রা: উচ্চ - স্থায়ী ডেটা ক্ষতি সম্ভব
• সাধারণ পরিস্থিতি: পৃষ্ঠার দুর্নীতি, সিস্টেম টেবিলের ক্ষতি, বরাদ্দ শৃঙ্খলে ত্রুটি
• কমান্ডের উদাহরণ: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

৬.৩ এই বিকল্পগুলির জন্য সর্বোত্তম অনুশীলন:

• সর্বদা পরীক্ষা সম্ভব হলে ডাটাবেস কপি মেরামতের কাজ
• সর্বদা ব্যাক আপ নিন এই বিকল্পগুলি চালানোর আগে
• সমস্ত পরিবর্তন নথিভুক্ত করুন সম্মতি এবং সমস্যা সমাধানের উদ্দেশ্যে
• ডাটাবেসকে একক-ব্যবহারকারী মোডে সেট করুন মেরামতের কাজ শুরু করার আগে

সাধারণত, আমাদের চেষ্টা করা উচিত মেরামত_পুনর্নির্মাণ প্রথম বিকল্প। যদি এটি ব্যর্থ হয়, তাহলে চেষ্টা করুন REPAIR_ALLOW_DATA_LOSS বিকল্প।

৬.৪ মেরামতের_অল_ডেটা_লস ফলাফল

৬.৪.১ ডেটা ক্ষতির সাথে মেরামত সফল হয়

কখনও কখনও REPAIR_ALLOW_DATA_LOSS বিকল্পটি সফল হবে, কিন্তু কিছু তথ্য 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 ফাইল স্থির DataNumen SQL Recovery
SQL Server 2014	ত্রুটি 10_1.mdf (Msg 8909 এর পরে Msg 8939) (600 রেকর্ড lost REPAIR_ALLOW_DATA_LOSS সহ)	ত্রুটি 10_1_fixed.mdf (কোন রেকর্ড নেই lost)
SQL Server 2014	ত্রুটি 10_2.mdf (বার্তা ৮৯০৯ এর পরে বার্তা ৮৯৩৯) (৬০০০ রেকর্ড (৫০%) lost REPAIR_ALLOW_DATA_LOSS সহ)	ত্রুটি 10_2_fixed.mdf (মাত্র ১০০টি রেকর্ড lost)
SQL Server 2014	Error7.mdf (১০০টি রেকর্ড lost REPAIR_ALLOW_DATA_LOSS সহ)	ত্রুটি 7_ফিক্সড.এমডিএফ (শুধুমাত্র একটি রেকর্ড lost)

৬.৪.২ মেরামত ব্যর্থতা - পেশাদার সমাধান বিবেচনা করুন

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 ফাইল স্থির DataNumen SQL Recovery
SQL Server 2014	ত্রুটি 1_3.mdf (একক বার্তা ৮২৪)	ত্রুটি 1_3_fixed.mdf
SQL Server 2014	ত্রুটি 1_1.mdf (ক্রমাগত বার্তা 824 ত্রুটি)	ত্রুটি 1_1_fixed.mdf
SQL Server 2014	ত্রুটি 1_2.mdf ((৮২৪ নম্বর বার্তার পরে ৭৯০৯ নম্বর বার্তা)	ত্রুটি 1_2_fixed.mdf
SQL Server 2014	ত্রুটি 4_1.mdf (৮৯৯২ নম্বর বার্তার পরে ৩৮৫২ নম্বর বার্তা)	ত্রুটি 4_1_fixed.mdf
SQL Server 2014	ত্রুটি 4_2.mdf (৮৯৯২ নম্বর বার্তার পরে ৩৮৫২ নম্বর বার্তা)	ত্রুটি 4_2_fixed.mdf
SQL Server 2014	ত্রুটি 5.mdf (বার্তা ৮৯৪৫)	ত্রুটি 5_ফিক্সড.এমডিএফ
SQL Server 2014	ত্রুটি 6.mdf (বার্তা ৮৯৪৫)	ত্রুটি 6_ফিক্সড.এমডিএফ
SQL Server 2014	ত্রুটি 2.mdf (বার্তা ৮৯৪৫)	ত্রুটি 2_ফিক্সড.এমডিএফ
SQL Server 2014	ত্রুটি 11.mdf (বার্তা ৮৯৪৫)	ত্রুটি 11_ফিক্সড.এমডিএফ
SQL Server 2014	ত্রুটি 3.mdf (বার্তা ৮৯৪৫)	ত্রুটি 3_ফিক্সড.এমডিএফ
SQL Server 2014	Error8.mdf (বার্তা ৮৯৪৫)	Error8_fixed.mdf
SQL Server 2014	ত্রুটি 9.mdf (বার্তা ৮৯৪৫)	ত্রুটি 9_ফিক্সড.এমডিএফ

7. সর্বোত্তম অভ্যাস

৬.১ নিয়মিত CHECKDB কার্যক্রমের সময়সূচী নির্ধারণ

গুরুত্বপূর্ণ উৎপাদন ডাটাবেসের জন্য সাপ্তাহিক DBCC CHECKDB এক্সিকিউশন বাস্তবায়ন করুন, উচ্চ-লেনদেন সিস্টেমের জন্য দৈনিক চেক সহ। কর্মক্ষমতার প্রভাব কমাতে কম-ব্যবহারের সময়কালে অপারেশনের সময়সূচী নির্ধারণ করুন এবং ডাটাবেসের আকার এবং রক্ষণাবেক্ষণ উইন্ডোর উপর ভিত্তি করে পূর্ণ চেক এবং PHYSICAL_ONLY বিকল্পগুলির মধ্যে আবর্তন বিবেচনা করুন। স্বয়ংক্রিয় সময়সূচীর মাধ্যমে SQL Server এজেন্ট কেন্দ্রীভূত পর্যবেক্ষণ এবং সতর্কতা ক্ষমতা প্রদানের সাথে সাথে ধারাবাহিক সম্পাদন নিশ্চিত করে।

৬.২ কর্মক্ষমতা প্রভাব ব্যবস্থাপনা

DBCC CHECKDB অপারেশনগুলি উল্লেখযোগ্য সিস্টেম রিসোর্স ব্যবহার করে, যা সম্ভাব্যভাবে সমসাময়িক ব্যবহারকারীর কার্যকলাপকে প্রভাবিত করে। পারফরম্যান্স প্রভাবের ধরণগুলি বোঝার জন্য চেকের সময় CPU ব্যবহার, মেমরি খরচ এবং ডিস্ক I/O পর্যবেক্ষণ করুন। রুটিন চেকের জন্য NOINDEX বিকল্পগুলি ব্যবহার করার কথা বিবেচনা করুন, মাসিক রক্ষণাবেক্ষণ উইন্ডোর জন্য সম্পূর্ণ বৈধতা সংরক্ষণ করুন। অখণ্ডতা পরীক্ষার সময়কালে প্রত্যাশা পরিচালনা করার জন্য কোয়েরি টাইমআউট এক্সটেনশন এবং ব্যবহারকারীর যোগাযোগ কৌশল বাস্তবায়ন করুন।

৬.৩ রক্ষণাবেক্ষণ উইন্ডো পরিকল্পনা

ব্যাকআপ অপারেশন, ইনডেক্স পুনর্নির্মাণ এবং পরিসংখ্যান আপডেটের মতো অন্যান্য রক্ষণাবেক্ষণ কার্যক্রমের সাথে DBCC CHECKDB সময়সূচীর সমন্বয় করুন। কর্মক্ষমতা হ্রাস বা সময়সীমার সমস্যা সৃষ্টি করতে পারে এমন রিসোর্স-নিবিড় অপারেশনগুলিকে ওভারল্যাপ করা এড়িয়ে চলুন। ডাটাবেসের আকার বৃদ্ধির অনুমানের উপর ভিত্তি করে রক্ষণাবেক্ষণ উইন্ডো পরিকল্পনা করুন, ডেটা ভলিউম বৃদ্ধির সাথে সাথে সম্পূর্ণ অখণ্ডতা যাচাইয়ের জন্য পর্যাপ্ত সময় নিশ্চিত করুন।

৬.৪ স্বয়ংক্রিয় পর্যবেক্ষণ এবং সতর্কতা

কনফিগার করুন SQL Server DBCC CHECKDB দুর্নীতি শনাক্ত করলে এজেন্টদের তাৎক্ষণিকভাবে প্রশাসকদের অবহিত করার জন্য সতর্কীকরণ। লগ পার্সিং সমাধান বাস্তবায়ন করুন যা অখণ্ডতা পরীক্ষার ফলাফলগুলি বের করে এবং শ্রেণীবদ্ধ করে, প্রবণতা বিশ্লেষণ এবং সক্রিয় সমস্যা সনাক্তকরণ সক্ষম করে। দুর্নীতির তীব্রতার বিভিন্ন স্তরের জন্য প্রতিক্রিয়া সময়সীমা এবং দায়িত্বশীল কর্মীদের সংজ্ঞায়িত করে এমন ক্রমবর্ধমান পদ্ধতি তৈরি করুন।

৭. ডিবিসিসি চেকটেবল: হালকা বিকল্প

৭.১ CHECKDB এর পরিবর্তে কখন CHECKTABLE ব্যবহার করবেন

DBCC CHECKTABLE পৃথক টেবিলের জন্য ফোকাসড ইন্টিগ্রিটি চেকিং প্রদান করে, যা এটিকে আদর্শ করে তোলে tarনির্দিষ্ট ডাটাবেস অবজেক্টের সমস্যা সমাধান এবং রক্ষণাবেক্ষণের জন্য geted। নির্দিষ্ট টেবিলের পারফরম্যান্স সমস্যাগুলি তদন্ত করার সময়, সম্পূর্ণ ডাটাবেস চেকের মধ্যে গুরুত্বপূর্ণ ব্যবসায়িক টেবিলগুলি যাচাই করার সময়, অথবা যখন সময়ের সীমাবদ্ধতা সম্পূর্ণ ডাটাবেস যাচাইকরণে বাধা দেয় তখন CHECKTABLE ব্যবহার করুন। এই পদ্ধতিটি বৃহৎ ডাটাবেসে বিশেষভাবে মূল্যবান প্রমাণিত হয় যেখানে সম্পূর্ণ CHECKDB অপারেশন উপলব্ধ রক্ষণাবেক্ষণের সময়সীমা অতিক্রম করে।

৭.২ ডিবিসিসি চেকটেবল সিনট্যাক্স এবং উদাহরণ

মৌলিক CHECKTABLE কমান্ড tarনির্দিষ্ট টেবিল পায়:

DBCC CHECKTABLE('YourTable')

CHECKDB এর মতো, CHECKTABLE বিভিন্ন বিকল্প সমর্থন করে যার মধ্যে রয়েছে পারফরম্যান্স অপ্টিমাইজেশনের জন্য NOINDEX এবং দুর্নীতি সমাধানের জন্য মেরামতের পরামিতি। আপনি সুনির্দিষ্ট টেবিল সনাক্তকরণের জন্য স্কিমার নামও নির্দিষ্ট করতে পারেন:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

এই tarগেটেড পদ্ধতির মাধ্যমে ব্যবসায়িক সময়ের মধ্যে সিস্টেমের কর্মক্ষমতা বজায় রেখে গ্রানুলার ইন্টিগ্রিটি যাচাইকরণ সম্ভব হয়।

৭.৩ বৃহৎ ডাটাবেসের জন্য কর্মক্ষমতা সুবিধা

CHECKTABLE অপারেশনগুলি সম্পূর্ণ ডাটাবেস চেকের তুলনায় উল্লেখযোগ্যভাবে দ্রুত সম্পন্ন হয়, যা গুরুত্বপূর্ণ টেবিলগুলির ঘন ঘন অখণ্ডতা যাচাইকরণকে সক্ষম করে। এই পদ্ধতিটি সাপ্তাহিক বা মাসিক সময়সূচীর জন্য ব্যাপক CHECKDB অপারেশনগুলি সংরক্ষণ করার সময় প্রয়োজনীয় ব্যবসায়িক টেবিলগুলির দৈনিক যাচাইকরণের অনুমতি দেয়। হ্রাসকৃত রিসোর্স খরচ CHECKTABLE কে ন্যূনতম ব্যবহারকারীর প্রভাব সহ উৎপাদন পরিবেশ সম্পাদনের জন্য উপযুক্ত করে তোলে।

৮. যখন CHECKDB ব্যর্থ হয়

DBCC CHECKDB বিভিন্ন পরিস্থিতিতে ব্যর্থ হবে, যার মধ্যে রয়েছে:

• DBCC CHECKDB এক্সিকিউশন অস্বাভাবিকভাবে শেষ হয়ে যায়
• DBCC CHECKDB কার্যকরকরণ সফলভাবে সম্পন্ন হয়েছে, কিন্তু মেরামতের বিকল্প ডাটাবেস মেরামত করতে ব্যর্থ।

এই পরিস্থিতিতে, ডাটাবেসের দুর্নীতি ঠিক করতে আমাদের আরও পেশাদার সরঞ্জামের প্রয়োজন।

9.1 এর ভূমিকা DataNumen SQL Recovery

DataNumen SQL Recovery আরও উন্নত ক্ষমতা প্রদান করে:

• সেরা পুনরুদ্ধারের হার ইণ্ডাস্ট্রিতে.
• মারাত্মকভাবে দূষিত ডাটাবেস ফাইলগুলি পুনরুদ্ধার করুন।
• টেবিল, ইনডেক্স, ভিউ, ট্রিগার, নিয়ম এবং ডিফল্ট সহ সমস্ত ডাটাবেস অবজেক্ট পুনরুদ্ধার করুন।
• সঞ্চিত পদ্ধতি, স্কেলার ফাংশন, ইনলাইন টেবিল-ভ্যালুড ফাংশন এবং মাল্টিস্টেটমেন্ট টেবিল-ভ্যালুড ফাংশন পুনরুদ্ধার করুন।
• স্থায়ীভাবে মুছে ফেলা রেকর্ড পুনরুদ্ধার করুন।
• এনক্রিপ্ট করা বস্তুগুলি ডিক্রিপ্ট করুন SQL Server ডাটাবেস।
• ব্যাচে MDF ফাইল মেরামত করুন।
• ব্যাপক মেরামতের বিকল্প।
• উন্নত লগিং এবং রিপোর্টিং.
• সবার জন্য সমর্থন SQL Server সংস্করণ।
• প্রযুক্তিগত সহায়তা প্রাপ্যতা
• নিয়মিত আপডেট এবং উন্নতি

৮.২ সাফল্যের হার তুলনা

পুনরুদ্ধারের সাফল্যের হার উল্লেখযোগ্যভাবে পৃথক:

• ডিবিসিসি চেকডিবি এবং চেকটেবল: ৮০% গড় পুনরুদ্ধারের হার
• DataNumen: ৮০% সুস্থতার হার

নীচে একটি সম্পূর্ণ প্রতিযোগিতামূলক তুলনা:

9.3 গুরুতর দুর্নীতি থেকে পুনরুদ্ধার

গুরুতর ক্ষেত্রে উন্নত ক্ষমতা:

• শারীরিকভাবে ক্ষতিগ্রস্ত স্টোরেজ থেকে পুনরুদ্ধার
• ফরম্যাট করা ড্রাইভ বা ক্র্যাশ হওয়া সিস্টেম থেকে পুনরুদ্ধার
• ডিস্ক ইমেজ, ব্যাকআপ ফাইল, ভার্চুয়াল মেশিন ডিস্ক ফাইল, টেম্পো থেকে পুনরুদ্ধার করুনrary ফাইল, ইত্যাদি

৮.৫ কখন পেশাদার সমাধান বিবেচনা করবেন

• সাম্প্রতিক ব্যাকআপের কোনও উপলভ্যতা নেই
• DBCC CHECKDB ব্যর্থ হয়েছে
• গুরুতর দুর্নীতির পরিস্থিতি
• গুরুত্বপূর্ণ ব্যবসায়িক তথ্য নিয়ে কাজ করা
• যখন সময় সংকটময়
• যখন সর্বাধিক পুনরুদ্ধার অপরিহার্য

10. প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

11. উপসংহার

11.1 মূল পয়েন্টের সারাংশ

৯.১.১ অপরিহার্য DBCC CHECKDB কমান্ডের সংক্ষিপ্তসার

ব্যাপক ডাটাবেস চেকিংয়ের জন্য মৌলিক DBCC CHECKDB সিনট্যাক্স আয়ত্ত করুন, কর্মক্ষমতা অপ্টিমাইজেশনের জন্য NOINDEX এবং PHYSICAL_ONLY বিকল্পগুলি ব্যবহার করুন এবং CHECKTABLE বুঝতে পারেন tarগেটেড টেবিল যাচাইকরণ। এই মৌলিক কমান্ডগুলি সক্রিয় ডাটাবেস রক্ষণাবেক্ষণের ভিত্তি তৈরি করে, যা প্রাথমিক দুর্নীতি সনাক্তকরণ এবং পদ্ধতিগত অখণ্ডতা পর্যবেক্ষণ সক্ষম করে।

৯.১.২ গুরুত্বপূর্ণ সর্বোত্তম অনুশীলনের অনুস্মারক

অখণ্ডতা পরীক্ষা চালানোর আগে সর্বদা বর্তমান ব্যাকআপ বজায় রাখুন, ডাটাবেসের সমালোচনার উপর ভিত্তি করে নিয়মিত CHECKDB অপারেশনের সময়সূচী করুন এবং তাৎক্ষণিক দুর্নীতির সতর্কতার জন্য স্বয়ংক্রিয় পর্যবেক্ষণ বাস্তবায়ন করুন। মনে রাখবেন যে নিয়মিত পর্যবেক্ষণের মাধ্যমে প্রতিরোধ প্রতিক্রিয়াশীল পদ্ধতির চেয়েও বেশি, এবং পেশাদার পুনরুদ্ধার সমাধানগুলি মূল্যবান ব্যাকআপ বিকল্প প্রদান করে যখন স্ট্যান্ডার্ড সরঞ্জামগুলি অপর্যাপ্ত প্রমাণিত হয়।

৯.২ কখন DBCC CHECKDB বনাম অ্যাডভান্সড সলিউশন ব্যবহার করবেন

নিয়মিত অখণ্ডতা পর্যবেক্ষণ এবং ছোটখাটো দুর্নীতি সমাধানের জন্য DBCC CHECKDB ব্যবহার করুন, এবং অন্তর্নির্মিত মেরামত ক্ষমতার বাইরে গুরুতর দুর্নীতির পরিস্থিতির জন্য পেশাদার পুনরুদ্ধার সরঞ্জাম সংরক্ষণ করুন। সিদ্ধান্ত কাঠামোতে ব্যাকআপের প্রাপ্যতা, ডেটার সমালোচনা, সময়ের সীমাবদ্ধতা এবং দুর্নীতির তীব্রতা বিবেচনা করা উচিত। সফল ডাটাবেস প্রশাসকরা নিয়মিত CHECKDB পর্যবেক্ষণকে ব্যাপক ব্যাকআপ কৌশল এবং উন্নত পুনরুদ্ধারের বিকল্পগুলির সচেতনতার সাথে একত্রিত করেন যখন স্ট্যান্ডার্ড পদ্ধতিগুলি অপর্যাপ্ত প্রমাণিত হয়।

১১.৩ DBA-এর জন্য দ্রুত দৈনিক স্বাস্থ্য চেকলিস্ট

DBCC CHECKDB চালানোর পাশাপাশি, এই প্রয়োজনীয় দৈনন্দিন অনুশীলনগুলির মাধ্যমে সর্বোত্তম ডাটাবেস স্বাস্থ্য বজায় রাখুন:

১. ব্যাকআপের অখণ্ডতা যাচাই করুন

• নির্ধারিত ব্যাকআপগুলি সফলভাবে সম্পন্ন হয়েছে তা নিশ্চিত করুন
• ব্যাকআপ পঠনযোগ্যতা যাচাই করতে RESTORE VERIFYONLY ব্যবহার করুন।
• নিশ্চিত করুন যে অফসাইট কপিগুলি সিঙ্ক্রোনাইজ করা হয়েছে এবং অ্যাক্সেসযোগ্য।

এছাড়াও আপনি আরও তথ্য পেতে পারেন আমাদের বিস্তৃত নির্দেশিকা SQL Server ব্যাকআপ.

2. ধারাবাহিকতার স্থিতি পর্যালোচনা করুন

• রাতারাতি চালানো থেকে স্বয়ংক্রিয় DBCC CHECKDB ফলাফল পরীক্ষা করুন
• মনিটর SQL Server দুর্নীতির সতর্কতার জন্য ত্রুটি লগ
• যেকোনো সততা ব্যর্থতা অবিলম্বে তদন্ত করুন

3. সার্ভারের স্বাস্থ্য পর্যবেক্ষণ করুন

• CPU, মেমরি এবং ডিস্ক I/O মেট্রিক্স পরীক্ষা করুন
• tempdb স্থানের প্রাপ্যতা যাচাই করুন
• অবরুদ্ধ প্রক্রিয়া এবং দীর্ঘস্থায়ী কোয়েরিগুলি সনাক্ত করুন

৪. অচলাবস্থার কার্যকলাপ ট্র্যাক করুন

• সিস্টেম হেলথ ইভেন্ট থেকে অচলাবস্থার গ্রাফ পর্যালোচনা করুন
• সমস্যাযুক্ত প্রশ্নগুলি সনাক্ত করুন এবং উন্নয়ন দলগুলির সাথে অপ্টিমাইজ করুন
• অচলাবস্থার শিকারের সংখ্যা এবং ব্যবসায়িক প্রভাব পর্যবেক্ষণ করুন

গুরুত্বপূর্ণ অনুস্মারক

• ঘন ঘন ডাটাবেস সঙ্কুচিত হওয়া এড়িয়ে চলুন - এটি ফ্র্যাগমেন্টেশন বৃদ্ধি করে এবং কর্মক্ষমতা হ্রাস করে। শুধুমাত্র যখন সত্যিই প্রয়োজন হয় তখন বড় ডেটা মুছে ফেলার পরে সঙ্কুচিত হয়।
• স্বয়ংক্রিয় পর্যবেক্ষণের কাজগুলি ব্যবহার SQL Server এজেন্টের চাকরি বা রক্ষণাবেক্ষণ পরিকল্পনা, গুরুত্বপূর্ণ সমস্যার জন্য সতর্কতা সহ।
• দুর্যোগ পুনরুদ্ধার পদ্ধতি পরীক্ষা করুন ব্যাকআপ পুনরুদ্ধারযোগ্য এবং পুনরুদ্ধারের লক্ষ্যগুলি অর্জনযোগ্য তা নিশ্চিত করার জন্য সাপ্তাহিক।

এই দৈনিক চেকলিস্টটি নিয়মিত DBCC CHECKDB কার্যক্রমের সাথে একত্রিত করে, আপনি সক্রিয় পর্যবেক্ষণ এবং দ্রুত সমস্যা প্রতিক্রিয়ার মাধ্যমে আপনার ডাটাবেস পরিবেশের জন্য ব্যাপক সুরক্ষা তৈরি করেন।

12. তথ্যসূত্র

1. মাইক্রোসফট লার্ন। "ডিবিসিসি চেকডিবি (ট্রানজ্যাক্ট-এসকিউএল)।" SQL Server ডকুমেন্টেশন. মাইক্রোসফট কর্পোরেশন।
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. মাইক্রোসফট লার্ন। "DBCC CHECKDB দ্বারা রিপোর্ট করা ডাটাবেস ধারাবাহিকতা ত্রুটির সমস্যা সমাধান করুন।" SQL Server ডকুমেন্টেশন. মাইক্রোসফট কর্পোরেশন।
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors