SQL ডাটাবেস পুনরুদ্ধার মুলতুবি: ১৫টি প্রমাণিত সমাধান [২০২৫ নির্দেশিকা]

যখন আপনার SQL ডাটাবেস 'রিকভারি পেন্ডিং' অবস্থায় আটকে যায়, তখন আপনার ডাটাবেসটি অ্যাক্সেসযোগ্য থাকে না এবং কার্যক্রম থেমে যায়। এই বিশদ নির্দেশিকাটি SQL ডাটাবেসের 'রিকভারি পেন্ডিং' সমস্যা সমাধানের জন্য ১৫টি পরীক্ষিত পদ্ধতি প্রদান করে, যার মধ্যে সাধারণ রিস্টার্ট থেকে শুরু করে উন্নত জরুরি মেরামত পর্যন্ত অন্তর্ভুক্ত রয়েছে।

১. SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি অবস্থা বোঝা

কোনও সমাধানের চেষ্টা করার আগে, সঠিক সমাধান বেছে নেওয়ার জন্য SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি থাকা সমস্যার কারণ কী তা বোঝা অত্যন্ত গুরুত্বপূর্ণ।

১.১ মুলতুবি পুনরুদ্ধার বলতে কী বোঝায়?

মুলতুবি থাকা পুনরুদ্ধার ইঙ্গিত দেয় যে SQL Server এটি শনাক্ত করে যে একটি ডাটাবেস পুনরুদ্ধারের প্রয়োজন, কিন্তু পুনরুদ্ধার প্রক্রিয়া শুরু করতে পারে না। “Recovering” সক্রিয় পুনরুদ্ধার প্রক্রিয়া চলমান থাকাকে বোঝায়, কিন্তু “Recovery Pending”-এর অর্থ হলো কোনো বাধার কারণে পুনরুদ্ধার প্রক্রিয়াটি আটকে আছে।

মূল ডাটাবেস অবস্থাগুলির মধ্যে রয়েছে:

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

১.২ SQL ডাটাবেস পুনরুদ্ধার মুলতুবি থাকার সাধারণ কারণগুলি

SQL db পুনরুদ্ধারের মুলতুবি সমস্যাগুলি সাধারণত নিম্নলিখিত সাধারণ কারণগুলির কারণে ঘটে:

• অনুপস্থিত বা দূষিত লেনদেন লগ ফাইল (LDF)
• পুনরুদ্ধারের সময় পর্যাপ্ত ডিস্ক স্থান নেই
• হার্ডওয়্যার ব্যর্থতা এবং অপ্রত্যাশিত সিস্টেম বন্ধ হয়ে যাওয়া
• দূষিত MDF ডাটাবেস ফাইল
• ফাইল অনুমতি সংক্রান্ত সমস্যা অ্যাক্সেসে বাধা দিচ্ছে
• SQL Server পরিষেবা চালুর সময় সংক্রান্ত সমস্যা
• FILESTREAM কনফিগারেশন ত্রুটি
• সার্ভার মাইগ্রেশনের পরে ভুল ফাইল পাথ

১.৩ ডাটাবেসের অবস্থা কীভাবে পরীক্ষা করবেন

এই পদ্ধতিগুলি ব্যবহার করে আপনার ডাটাবেসের অবস্থা যাচাই করুন:

ব্যবহার SQL Server ম্যানেজমেন্ট স্টুডিও:

1. আপনার সাথে সংযুক্ত করুন SQL Server উদাহরণ
2. বিস্তৃত করা ডেটাবেস ফোল্ডারের
3. "(পুনরুদ্ধার মুলতুবি)" অবস্থা দেখানো ডাটাবেসগুলি সন্ধান করুন

T-SQL কমান্ড ব্যবহার করে:

SELECT name, state_desc FROM sys.databases WHERE state_desc = 'RECOVERY_PENDING';

২. প্রাথমিক রোগ নির্ণয়ের পদক্ষেপ

যেকোনো SQL ডাটাবেস পুনরুদ্ধারের জন্য মুলতুবি থাকা সমাধানের চেষ্টা করার আগে সঠিক রোগ নির্ণয় অপরিহার্য।

2.1 চেক SQL Server ত্রুটি লগ

ত্রুটি লগে পুনরুদ্ধারের মুলতুবি অবস্থা কী কারণে ঘটেছে সে সম্পর্কে গুরুত্বপূর্ণ তথ্য থাকে।

1. খোলা SQL Server ম্যানেজমেন্ট স্টুডিও
2. নেভিগেট করুন ম্যানেজমেন্ট -> SQL Server লগ
3. সাম্প্রতিক ত্রুটিগুলি দেখতে বর্তমান লগে ডাবল-ক্লিক করুন।
4. আপনার ডাটাবেসের সাথে সম্পর্কিত ত্রুটি বার্তাগুলি সন্ধান করুন।

বিকল্পভাবে, T-SQL ব্যবহার করুন:

EXEC sp_readerrorlog;

২.২ উইন্ডোজ ইভেন্ট লগ পরীক্ষা করুন

1. প্রেস উইন্ডোজ কী + আর
2. আদর্শ ইভেন্টvwr.msc এবং এন্টার টিপুন
   
3. নেভিগেট করুন উইন্ডোজ লগ -> পদ্ধতি এবং আবেদন
4. খোঁজা SQL Server সমস্যাটি ঘটে যাওয়ার সময় সম্পর্কিত ত্রুটিগুলি

২.৩ ফাইল অ্যাক্সেসিবিলিটি যাচাই করুন

1. আপনার ডাটাবেস ফাইলের অবস্থানগুলিতে নেভিগেট করুন
2. MDF এবং LDF ফাইল উভয়ই বিদ্যমান কিনা তা যাচাই করুন।
3. ড্রাইভগুলি অনলাইনে আছে এবং অ্যাক্সেসযোগ্য কিনা তা পরীক্ষা করুন
4. নেটওয়ার্ক ড্রাইভগুলি সঠিকভাবে মাউন্ট করা আছে কিনা তা নিশ্চিত করুন

১০. সমাধান নং ৭: রিস্টার্ট করুন SQL Server সেবা

পুনরায় চালু SQL Server এই পরিষেবাগুলো সময়গত সমস্যা বা অস্থায়ী রিসোর্স দ্বন্দ্বের কারণে সৃষ্ট SQL ডাটাবেস পুনরুদ্ধারের অনেক অমীমাংসিত সমস্যার সমাধান করে।

৩.১ যখন সার্ভিস রিস্টার্ট কাজ করে

এই পদ্ধতিটি এর জন্য কার্যকর:

• স্টার্টআপের সময় অস্থায়ী রিসোর্স লক
• প্রাপ্যতা বিলম্বের কারণ
• পরিষেবা নির্ভরতা সময়ের সমস্যা
• ছোটখাটো কনফিগারেশন দ্বন্দ্ব

৩.২ কীভাবে পুনরায় চালু করবেন SQL Server সেবা

1 পদ্ধতি: SQL Server কনফিগারেশন ম্যানেজার

1. খোলা SQL Server কনফিগারেশন ম্যানেজার
2. ক্লিক SQL Server সেবা
3. ডানদিকে ক্লিক করুন SQL Server উদাহরণস্বরূপ, যেমন SQL Server (এমএসএসকিউএল সার্ভার)
4. নির্বাচন করা আবার শুরু
5. পরিষেবা সম্পূর্ণরূপে পুনরায় চালু হওয়া পর্যন্ত অপেক্ষা করুন।

পদ্ধতি ২: পরিষেবা কনসোল

1. প্রেস উইন্ডোজ কী + আর
2. আদর্শ services.msc এবং এন্টার টিপুন
   
3. খোঁজো SQL Server উদাহরণস্বরূপ, যেমন SQL Server (এমএসএসকিউএল সার্ভার)
4. ডান ক্লিক করুন এবং নির্বাচন করুন আবার শুরু

পদ্ধতি 3: পাওয়ারশেল

Restart-Service -Name "MSSQLSERVER" -Force

৩.৩ রিস্টার্ট-পরবর্তী যাচাইকরণ

1. সম্পূর্ণরূপে চালু হওয়ার জন্য ২-৩ মিনিট অপেক্ষা করুন।
2. SSMS-এ ডাটাবেসের অবস্থা পরীক্ষা করুন
3. যেকোনো নতুন বার্তার জন্য ত্রুটি লগ যাচাই করুন
4. ডাটাবেস সংযোগ পরীক্ষা করুন

৪. সমাধান #২: ডিস্ক স্পেস সমস্যা পরীক্ষা করে সমাধান করুন

অপর্যাপ্ত ডিস্ক স্পেস হলো SQL ডেটাবেস রিকভারি পেন্ডিং সমস্যার একটি সাধারণ কারণ। রিকভারি অপারেশনের জন্য টেম্পোরারি ফাইল এবং লগ বৃদ্ধির জন্য অতিরিক্ত জায়গার প্রয়োজন হয়।

৪.১ ডিস্ক স্পেস সমস্যা চিহ্নিত করা

1. খোলা ফাইল এক্সপ্লোরার
2. ডাটাবেস ফাইল ধারণকারী ড্রাইভে নেভিগেট করুন
3. খালি জায়গা আছে কিনা তা পরীক্ষা করুন
4. পুনরুদ্ধার কার্যক্রমের জন্য কমপক্ষে ১০-২০% খালি জায়গা নিশ্চিত করুন।

৪.২ ডিস্কের জায়গা খালি করা

1. অপ্রয়োজনীয় টেম্পোরারি ফাইলগুলো মুছে ফেলুন
2. পরিষ্কার SQL Server স্থান-সঙ্কটজনক হলে ফাইলগুলির ব্যাকআপ নিন
3. অপ্রয়োজনীয় ফাইলগুলি অন্য ড্রাইভে সরান
4. সম্ভব হলে অন্যান্য ডাটাবেস ফাইল সঙ্কুচিত করুন

ডাটাবেস ফাইল সঙ্কুচিত করুন (সাবধানে ব্যবহার করুন):

DBCC SHRINKFILE (logicalfilename, target_size);

৪.৩ স্থান সংশোধনের পরে অনলাইনে ডাটাবেস সেট করা

একবার জায়গা খালি হয়ে গেলে, ডাটাবেসটি অনলাইনে আনার চেষ্টা করুন:

ALTER DATABASE [DatabaseName] SET ONLINE;

৫. সমাধান #৩: সেট করুন SQL Server বিলম্বিত পরিষেবা শুরু

বিন্যাস SQL Server সিস্টেম বুটের সময় স্টোরেজ সিস্টেম বা নেটওয়ার্ক ড্রাইভ প্রস্তুত না থাকার কারণে সৃষ্ট SQL ডাটাবেস রিকভারি পেন্ডিং সমস্যা ডিলেড স্টার্টের মাধ্যমে সমাধান করা হয়।

৫.১ সময়ের সমস্যাগুলি বোঝা

সময় নির্ধারণের সমস্যা দেখা দেয় যখন:

• SAN অথবা নেটওয়ার্ক স্টোরেজ শুরু হতে সময় নেয়
• প্রারম্ভিক বুটের সময় ড্রাইভ লেটার বরাদ্দ করা হয় না
• নেটওয়ার্ক ড্রাইভের প্রমাণীকরণ প্রয়োজন
• স্টোরেজ কন্ট্রোলারদের আরম্ভের সময় প্রয়োজন

৫.২ বিলম্বিত সূচনা কনফিগার করা

1. প্রেস উইন্ডোজ কী + আর
2. আদর্শ services.msc এবং এন্টার টিপুন
   
3. খোঁজো SQL Server উদাহরণস্বরূপ, যেমন SQL Server (এমএসএসকিউএল সার্ভার)
4. ডান ক্লিক করুন এবং নির্বাচন করুন প্রোপার্টি
5. পরিবর্তন প্রারম্ভকালে টাইপ থেকে স্বয়ংক্রিয় (বিলম্বিত শুরু)
   
   
6. ক্লিক OK
7. পরীক্ষা করার জন্য সিস্টেমটি পুনরায় চালু করুন।

৫.৩ সময়ের জন্য বিকল্প সমাধান

আরও নিয়ন্ত্রণের জন্য, একটি নির্ধারিত কাজ তৈরি করুন:

1. খোলা কাজের সূচি
2. ক্লিক অ্যাকশন -> বেসিক টাস্ক তৈরি করুন
3. ইনপুট নাম এবং বিবরণ কাজটি, যেমন “শুরুতে বিলম্ব” SQL Server সেবা"
4. সেট ট্রিগার থেকে যখন কম্পিউটার চালু হয়
5. সেট কর্ম থেকে একটি প্রোগ্রাম শুরু করুন
6. সেট প্রোগ্রাম/স্ক্রিপ্ট সম্পূর্ণ পথের দিকে Sqlservr.exe সম্পর্কে, এইরকম: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Binn\sqlservr.exe। আপনি এটি খুঁজে পেতে উইন্ডোজে অনুসন্ধান ফাংশন ব্যবহার করতে পারেন।
7. সমাপ্তি পৃষ্ঠায়, নির্বাচন করুন এই টাস্কের জন্য প্রোপার্টিজ ডায়ালগ খুলুন যখন আমি ফিনিশ ক্লিক করি.
   
8. ক্লিক শেষ.
9. টাস্ক প্রোপার্টিজ ডায়ালগে, ক্লিক করুন ট্রিগারসমূহ ট্যাব
10. ট্রিগারটি নির্বাচন করুন এবং ক্লিক করুন সম্পাদন করা
    
    
11. উন্নত সেটিংসে, চেক করুন এর জন্য বিলম্বের কাজ: এবং সময় ৩ মিনিট নির্ধারণ করুন।
    
12. ক্লিক ঠিক আছে.

৬. সমাধান #৪: ফাইল অনুমতি এবং অ্যাক্সেস অধিকার ঠিক করুন

অনুমতি সংক্রান্ত সমস্যা প্রতিরোধ করে SQL Server ডাটাবেস ফাইল অ্যাক্সেস করা থেকে, SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি অবস্থায় পৌঁছানো। ডাটাবেস অপারেশনের জন্য সঠিক ফাইল অনুমতি অপরিহার্য।

৬.১ সাধারণ অনুমতি সংক্রান্ত সমস্যা

• SQL Server পরিষেবা অ্যাকাউন্টে ফাইল অ্যাক্সেসের অধিকার নেই
• অ্যান্টিভাইরাস সফটওয়্যার ফাইল অ্যাক্সেস ব্লক করছে
• নিরাপত্তা নীতি পরিবর্তিত হয়েছে
• নেটওয়ার্ক শেয়ার অনুমতি সংক্রান্ত সমস্যা

৬.২ ফোল্ডারের অনুমতি সংশোধন করা

1. ডাটাবেস ফাইল ফোল্ডারে নেভিগেট করুন
2. ফোল্ডারে ডান ক্লিক করুন এবং নির্বাচন করুন প্রোপার্টি
3. ক্লিক করুন নিরাপত্তা ট্যাব
4. ক্লিক সম্পাদন করা
5. যুক্ত করুন SQL Server যদি পরিষেবা অ্যাকাউন্ট অনুপস্থিত থাকে
6. প্রদান সম্পূর্ণ নিয়ন্ত্রণ অনুমতি
7. ক্লিক OK পরিবর্তনগুলি প্রয়োগ করতে

কমান্ড লাইন (icacls) ব্যবহার করে:

icacls "C:\Data" /grant "NT SERVICE\MSSQLSERVER":F /T

৬.৩ পরিষেবা অ্যাকাউন্টের বিবেচনা

যাচাই করুন SQL Server পরিষেবা অ্যাকাউন্ট:

1. খোলা SQL Server কনফিগারেশন ম্যানেজার
2. ক্লিক SQL Server সেবা
3. মনে রাখবেন লগ ইন করুন কি কারণে SQL Server
4. এই অ্যাকাউন্টের যথাযথ অনুমতি আছে কিনা তা নিশ্চিত করুন।

৭. সমাধান #৫: ম্যানুয়াল ফাইল পাথ সংশোধন

ডাটাবেস ফাইলগুলি সরানো হলে বা ড্রাইভ লেটার পরিবর্তন হলে ফাইল পাথের সমস্যা দেখা দেয়। এই পদ্ধতিটি আপডেট হয় SQL Serverপ্রকৃত ফাইলগুলি সরানো ছাড়াই এর অভ্যন্তরীণ ফাইলের রেফারেন্স।

৭.১ যখন পথের সমস্যা দেখা দেয়

• সার্ভার হার্ডওয়্যার পরিবর্তন
• ড্রাইভ লেটার পুনঃঅ্যাসাইনমেন্ট
• নেটওয়ার্ক পাথ পরিবর্তন
• ডাটাবেস ফাইল স্থানান্তর

৭.২ ফাইল পাথ সংশোধন করা

1. ত্রুটি লগে বর্তমান ফাইল পাথগুলি সনাক্ত করুন
2. প্রকৃত ডাটাবেস ফাইলগুলি সনাক্ত করুন
3. পাথ আপডেট করতে ALTER DATABASE ব্যবহার করুন

ডেটা ফাইলের পথ আপডেট করুন:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalDataFileName', FILENAME = 'C:\NewPath\DatabaseName.mdf');

লগ ফাইলের পথ আপডেট করুন:

ALTER DATABASE [DatabaseName] 
MODIFY FILE (NAME = 'LogicalLogFileName', FILENAME = 'C:\NewPath\DatabaseName_Log.ldf');

৭.৩ যাচাইকরণের ধাপ

1. আবার শুরু SQL Server সেবা
2. ডাটাবেসের অবস্থা পরীক্ষা করুন
3. পাথ-সম্পর্কিত বার্তাগুলির জন্য ত্রুটি লগ যাচাই করুন
4. ডাটাবেস সংযোগ পরীক্ষা করুন

৮. সমাধান #৬: ডাটাবেস অফলাইনে নিয়ে যান তারপর অনলাইনে

এই সাধারণ অবস্থা পরিবর্তনটি একটি সুষ্ঠু অবস্থা রূপান্তর ঘটাতে এবং অস্থায়ী লকগুলি অপসারণ করার মাধ্যমে SQL ডেটাবেস পুনরুদ্ধারের অপেক্ষাধীন ছোটখাটো সমস্যা সমাধান করতে পারে।

৮.১ যখন এই পদ্ধতিটি কাজ করে

• রাজ্যের ছোটখাটো অসঙ্গতি
• অস্থায়ী সম্পদ লক
• সহজ পুনরুদ্ধার প্রক্রিয়া রিসেট
• অ-গুরুত্বপূর্ণ ত্রুটির শর্তাবলী

৮.২ অফলাইন/অনলাইন পদ্ধতি

1. ডাটাবেসের সাথে কোনও সক্রিয় সংযোগ নেই তা নিশ্চিত করুন
2. অফলাইন কমান্ডটি কার্যকর করুন
3. কয়েক সেকেন্ড অপেক্ষা করুন
4. অনলাইন কমান্ডটি কার্যকর করুন

নিরাপদ পদ্ধতি (সংযোগ বন্ধ হওয়ার জন্য অপেক্ষা করছে):

ALTER DATABASE [DatabaseName] SET OFFLINE;
ALTER DATABASE [DatabaseName] SET ONLINE;

তাৎক্ষণিক পদ্ধতি (সংযোগ বন্ধ করে):

ALTER DATABASE [DatabaseName] SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [DatabaseName] SET ONLINE;

৮.৩ ঝুঁকি এবং বিবেচনা

সতর্কতা: ROLLBACK IMMEDIATE ব্যবহার করলে অপ্রয়োজনীয় লেনদেন থেকে ডেটা নষ্ট হতে পারে। শুধুমাত্র প্রয়োজনে ব্যবহার করুন এবং ব্যবহারকারীরা লগ আউট হয়েছেন কিনা তা নিশ্চিত করুন।

৯. সমাধান #৭: অটো ক্লোজ ফিচারটি অক্ষম করুন

অটো ক্লোজ বৈশিষ্ট্যটি SQL ডাটাবেস পুনরুদ্ধারের ক্ষেত্রে মুলতুবি থাকা সমস্যা তৈরি করতে পারে যখন ডাটাবেসগুলি ঘন ঘন খোলা এবং বন্ধ হয়, যা পুনরুদ্ধারের ক্রিয়াকলাপের সময় সময়গত দ্বন্দ্ব তৈরি করে।

৯.১ অটো ক্লোজের প্রভাব বোঝা

• শেষ ব্যবহারকারী সংযোগ বিচ্ছিন্ন করার পরে ডাটাবেস বন্ধ হয়ে যায়
• প্রতিবার ডাটাবেস খোলার সময় পুনরুদ্ধার করতে হবে
• ঘন ঘন পুনরুদ্ধার চক্র তৈরি করে
• অন্যান্য কার্যক্রমে হস্তক্ষেপ করতে পারে

৯.২ অটো ক্লোজ অক্ষম করা

টি-এসকিউএল ব্যবহার করে:

ALTER DATABASE [DatabaseName] SET AUTO_CLOSE OFF;

ব্যবহার SQL Server ম্যানেজমেন্ট স্টুডিও:

1. ডাটাবেসে ডান-ক্লিক করুন
2. নির্বাচন করা প্রোপার্টি
3. যান অপশন সমূহ পৃষ্ঠা
4. সেট অটো বন্ধ থেকে মিথ্যা
5. ক্লিক OK

৯.৩ সম্পর্কিত অটো সেটিংস

আরও ভালো পারফরম্যান্সের জন্য AUTO_SHRINK নিষ্ক্রিয় করার কথাও বিবেচনা করুন:

ALTER DATABASE [DatabaseName] SET AUTO_SHRINK OFF;

১০. সমাধান #৮: ত্রুটিপূর্ণ লগ ফাইল মুছে ফেলুন এবং রিস্টার্ট করুন।

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

১০.১ যখন লগ মুছে ফেলা উপযুক্ত হয়

⚠️ গুরুত্বপূর্ণ সতর্কতা: এই পদ্ধতির ফলে ডেটা নষ্ট হয়!

শুধুমাত্র তখনই ব্যবহার করুন যখন:

• ডেভেলপমেন্ট/পরীক্ষা ডাটাবেস নিয়ে কাজ করা
• লগ ফাইলটি সম্পূর্ণরূপে দূষিত।
• অন্য কোনও পুনরুদ্ধারের বিকল্প নেই
• সাম্প্রতিক ব্যাকআপগুলি উপলব্ধ

১০.২ লগ ফাইল মুছে ফেলার পদ্ধতি

1. থামুন SQL Server সম্পূর্ণরূপে পরিষেবা
2. ডাটাবেস ফাইলের অবস্থানে নেভিগেট করুন
3. .LDF ফাইলটি মুছে ফেলুন (.MDF ফাইলটি রাখুন)
4. শুরু SQL Server সেবা
5. SQL Server স্বয়ংক্রিয়ভাবে একটি নতুন লগ ফাইল তৈরি করবে

10.3 গুরুত্বপূর্ণ সতর্কতা

ডেটা ক্ষতির প্রভাব:

• সমস্ত অপ্রতিশ্রুতিবদ্ধ লেনদেন স্থায়ীভাবে হারিয়ে যায়।
• লগ চেইনটি নষ্ট হয়ে গেছে - ডিফারেনশিয়াল ব্যাকআপগুলি অবৈধ।
• পয়েন্ট-ইন-টাইম পুনরুদ্ধার অসম্ভব হয়ে ওঠে
• শুধুমাত্র উৎপাদন-বহির্ভূত পরিবেশে ব্যবহার করুন

১১. সমাধান #৯: ডাটাবেস বিচ্ছিন্ন করুন এবং পুনরায় সংযুক্ত করুন

বিচ্ছিন্নকরণ এবং পুনরায় সংযুক্তকরণ বল SQL Server হারিয়ে যাওয়া বা দূষিত লগ ফাইলগুলি পুনর্নির্মাণ করতে। লগ ফাইলগুলি সমস্যাযুক্ত হলে এই পদ্ধতিটি SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি থাকা সমস্যাগুলি সমাধান করতে পারে।

১১.১ যখন ডিটাচ/পুনরায় সংযুক্তি কাজ করে

• লগ ফাইল অনুপস্থিত
• ক্ষতিগ্রস্ত লগ ফাইল হেডার
• লগ ফাইলের পথ পরিবর্তন
• সহজ দুর্নীতির দৃশ্যপট

১১.২ স্ট্যান্ডার্ড ডিটাচ/পুনরায় সংযুক্তি পদ্ধতি

1. প্রথমে ডাটাবেসকে জরুরি মোডে সেট করুন
2. মাল্টি-ইউজার মোডে পরিবর্তন করুন
3. ডাটাবেসটি আলাদা করুন
4. শুধুমাত্র MDF ফাইল ব্যবহার করে পুনরায় সংযুক্ত করুন

-- Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
ALTER DATABASE [DatabaseName] SET MULTI_USER;

-- Detach database
EXEC sp_detach_db '[DatabaseName]';

-- Re-attach with single file (MDF only)
EXEC sp_attach_single_file_db 
    @DBName = '[DatabaseName]', 
    @physname = N'C:\Data\DatabaseName.mdf';

১১.৩ বিকল্প সংযুক্তি পদ্ধতি

একাধিক ফাইল দৃশ্যকল্পের জন্য:

CREATE DATABASE [DatabaseName] 
ON (FILENAME = 'C:\Data\DatabaseName.mdf'),
   (FILENAME = 'C:\Data\DatabaseName_2.ndf')
FOR ATTACH;

১২. সমাধান #১০: লেনদেন লগ ফাইল পুনর্নির্মাণ করুন

লগ পুনর্নির্মাণ একটি নতুন লেনদেন লগ ফাইল তৈরি করে যখন মূল ফাইলটি অনুপস্থিত থাকে বা অপূরণীয়ভাবে ক্ষতিগ্রস্ত হয়। এই পদ্ধতিটি SQL db পুনরুদ্ধারের মুলতুবি থাকা সমস্যাগুলি সমাধান করে কিন্তু এর ফলে ডেটা ক্ষতি হয়।

১২.১ যখন কাঠের কাঠ পুনর্নির্মাণ প্রয়োজন হয়

• হার্ডওয়্যার ব্যর্থতার পরে LDF ফাইলগুলি অনুপস্থিত
• গুরুতরভাবে ক্ষতিগ্রস্ত লেনদেন লগ
• লগ ফাইলের পথ পরিবর্তন যা সংশোধন করা যাবে না
• জরুরি পুনরুদ্ধারের পরিস্থিতি

১২.২ লগ পুনর্নির্মাণ প্রক্রিয়া

⚠️ সতর্কতা: এর ফলে ডেটা নষ্ট হয়!

1. ডাটাবেসকে জরুরি মোডে সেট করুন
2. REBUILD LOG কমান্ড ব্যবহার করুন
3. নতুন লগ ফাইলের অবস্থান নির্দিষ্ট করুন
4. ডাটাবেস অনলাইনে আনুন

ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

ALTER DATABASE [DatabaseName] REBUILD LOG ON 
(NAME = 'DatabaseName_Log', FILENAME = 'C:\Logs\DatabaseName_Log.ldf');
GO

ALTER DATABASE [DatabaseName] SET ONLINE;
GO

১২.৩ ডেটা ক্ষতির প্রভাব বোঝা

লগ পুনর্নির্মাণের কারণ:

• সমস্ত অপ্রতিশ্রুতিবদ্ধ লেনদেনের ক্ষতি
• ভাঙা লগ সিকোয়েন্স নম্বর
• পরবর্তী লগ ব্যাকআপ প্রয়োগ করতে অক্ষমতা
• পয়েন্ট-ইন-টাইম পুনরুদ্ধার অসম্ভব হয়ে ওঠে

১৩. সমাধান #১১: জরুরি অবস্থা মোড মেরামত ডিবিসিসি চেকডিবি

দুর্নীতির কারণে সৃষ্ট SQL ডাটাবেস পুনরুদ্ধারের জন্য জরুরি অবস্থা মোড মেরামত একটি শেষ অবলম্বন পদ্ধতি। এই পদ্ধতিটি ডাটাবেস মেরামত করতে পারে তবে উল্লেখযোগ্য ডেটা ক্ষতি হতে পারে।

১৩.১ জরুরি অবস্থা মোড বোঝা

⚠️ চরম সতর্কতা: ডেটা হারানোর উচ্চ ঝুঁকি!

জরুরি অবস্থা মোড ব্যবহার করুন শুধুমাত্র যখন:

• অন্য সব পদ্ধতি ব্যর্থ হয়েছে
• কোনও সাম্প্রতিক ব্যাকআপ উপলব্ধ নেই
• সম্পূর্ণ ক্ষতির চেয়ে কিছু তথ্য পুনরুদ্ধার ভালো।
• ডাটাবেসটি মারাত্মকভাবে দূষিত।

১৩.২ জরুরি মেরামত পদ্ধতি

1. প্রথমে দূষিত ডাটাবেস ফাইলের ব্যাকআপ নিন
2. ডাটাবেসকে জরুরি মোডে সেট করুন
3. একক-ব্যবহারকারী মোডে স্যুইচ করুন
4. মেরামত বিকল্প সহ CHECKDB চালান
5. মাল্টি-ইউজার মোডে ফিরে যান

-- Step 1: Set to emergency mode
ALTER DATABASE [DatabaseName] SET EMERGENCY;
GO

-- Step 2: Single user mode
ALTER DATABASE [DatabaseName] SET SINGLE_USER;
GO

-- Step 3: Repair with no data loss
DBCC CHECKDB ([DatabaseName], REPAIR_REBUILD) WITH ALL_ERRORMSGS;
GO

-- Step 4: Return to multi-user
ALTER DATABASE [DatabaseName] SET MULTI_USER;
GO

১৩.৩ মেরামত-পরবর্তী মূল্যায়ন

1. মেরামতের কাজের জন্য CHECKDB আউটপুট পর্যালোচনা করুন
2. অনুপস্থিত টেবিল বা ডেটা পরীক্ষা করুন
3. গুরুত্বপূর্ণ অ্যাপ্লিকেশন কার্যকারিতা যাচাই করুন
4. অতিরিক্ত ডেটা হারিয়ে গেলে ব্যাকআপ থেকে পুনরুদ্ধার করার কথা বিবেচনা করুন।

১৪. সমাধান #১২: FILESTREAM কনফিগারেশন পরীক্ষা করে ঠিক করুন

FILESTREAM কনফিগারেশন সমস্যাগুলির কারণে SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যা হতে পারে। এই পদ্ধতিটি FILESTREAM-নির্দিষ্ট পুনরুদ্ধার ব্যর্থতার সমাধান করে।

১৪.১ ফাইলস্ট্রিম-সম্পর্কিত পুনরুদ্ধার সমস্যা

• FILESTREAM ড্রাইভার সংযোগ ব্যর্থতা
• কনফিগারেশনের মধ্যে অমিল SQL Server এবং ওএস
• সার্ভিস চালুর সময়কার সমস্যা
• FILESTREAM কন্টেইনারগুলির সাথে অনুমতি সংক্রান্ত সমস্যা

১৪.২ ফাইলস্ট্রিম সমস্যা সমাধান

1. FILESTREAM কনফিগারেশন স্তর পরীক্ষা করুন
2. উইন্ডোজ বৈশিষ্ট্য সক্রিয় আছে কিনা তা যাচাই করুন
3. প্রয়োজনীয় পরিষেবাগুলি পুনরায় চালু করুন
4. FILESTREAM কন্টেইনারের অনুমতি পরীক্ষা করুন

FILESTREAM কনফিগারেশন পরীক্ষা করুন:

SELECT SERVERPROPERTY('FilestreamEffectiveLevel') AS CurrentLevel;

ইনস্ট্যান্স লেভেলে FILESTREAM সক্ষম করুন:

EXEC sp_configure 'filestream access level', 2;
RECONFIGURE;

১৪.৩ ফাইলস্ট্রিমের সেরা অনুশীলনসমূহ

• রিস্টার্টের পরেও কনফিগারেশন সামঞ্জস্যপূর্ণ রাখুন
• FILESTREAM কন্টেইনার পাথগুলি অ্যাক্সেসযোগ্য কিনা তা যাচাই করুন
• উইন্ডোজ FILESTREAM বৈশিষ্ট্যটি সঠিকভাবে সক্রিয় আছে কিনা তা পরীক্ষা করুন।
• FILESTREAM-সম্পর্কিত ত্রুটি বার্তাগুলি পর্যবেক্ষণ করুন

১৫. সমাধান #১৩: আপডেট SQL Server সংস্করণ/পরিষেবা প্যাক

পুরাতন SQL Server সংস্করণগুলি, বিশেষ করে RTM রিলিজগুলিতে, পরিচিত বাগ রয়েছে যা SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যা সৃষ্টি করে। সর্বশেষ পরিষেবা প্যাকগুলিতে আপডেট করলে এই সমস্যাগুলি সমাধান হয়।

১৫.১ পুরোনো সংস্করণগুলিতে জ্ঞাত সমস্যা

• SQL Server ২০০৫ আরটিএম পুনরুদ্ধারের বাগ
• পুনরুদ্ধার প্রক্রিয়ার জন্য সার্ভিস প্যাক-নির্দিষ্ট সংশোধন
• প্রান্তের কেসগুলিকে সম্বোধন করে ক্রমবর্ধমান আপডেট
• নতুন উইন্ডোজ সংস্করণের সাথে সামঞ্জস্যের সমস্যা

১৫.২ আপডেট প্রক্রিয়া

1. বর্তমান পরীক্ষা করুন SQL Server সংস্করণ
2. সর্বশেষ উপলব্ধ সার্ভিস প্যাকটি সনাক্ত করুন
3. থেকে ডাউনলোড করুন মাইক্রোসফ্ট ডাউনলোড সেন্টার
4. রক্ষণাবেক্ষণের সময়সূচী নির্ধারণ করুন
5. সার্ভিস প্যাক ইনস্টল করুন
6. পরিষেবাগুলি পুনরায় চালু করুন
7. ডাটাবেসের কার্যকারিতা যাচাই করুন

বর্তমান সংস্করণটি পরীক্ষা করুন:

SELECT @@VERSION;

১৫.৩ আপডেট-পরবর্তী যাচাইকরণ

1. সংস্করণ নম্বর পরিবর্তন করা হয়েছে তা নিশ্চিত করুন
2. সমস্ত ডাটাবেস সঠিকভাবে অনলাইনে আছে কিনা তা পরীক্ষা করুন।
3. মৌলিক কার্যকারিতা পরীক্ষা চালান
4. নতুন কোনও সমস্যার জন্য ত্রুটি লগগুলি পর্যবেক্ষণ করুন

১৬. সমাধান #১৪: ব্যাকআপ থেকে ডাটাবেস পুনরুদ্ধার করুন

যখন রিপেয়ার পদ্ধতির মাধ্যমে SQL ডাটাবেস রিকভারির অমীমাংসিত সমস্যাগুলো সমাধান করা যায় না, তখন একটি পরিচিত ও ভালো ব্যাকআপ থেকে রিস্টোর করা সবচেয়ে নির্ভরযোগ্য সমাধান প্রদান করে, যেখানে ডেটা হারানোর সীমাও অনুমানযোগ্য থাকে।

১৬.১ যখন ব্যাকআপ পুনরুদ্ধারই সমাধান

• একাধিক মেরামতের প্রচেষ্টা ব্যর্থ হয়েছে
• গুরুত্বপূর্ণ উৎপাদন তথ্যের নিশ্চয়তা প্রয়োজন
• গ্রহণযোগ্য ডেটা হারানোর উইন্ডো বিদ্যমান
• মেরামতের জন্য দুর্নীতি এতটাই ব্যাপক যে

১৬.২ সম্পূর্ণ ডাটাবেস পুনরুদ্ধার প্রক্রিয়া

1. সর্বশেষ ব্যবহারযোগ্য ব্যাকআপটি শনাক্ত করুন।
2. পুনরুদ্ধারের জন্য পর্যাপ্ত ডিস্ক স্থান নিশ্চিত করুন
3. ডাটাবেস অফলাইনে নিন অথবা প্রয়োজনে বাদ দিন
4. ব্যাকআপ ফাইল থেকে পুনরুদ্ধার করুন
5. লগ ব্যাকআপ প্রয়োগ করুন যদি পাওয়া যায়

সম্পূর্ণ ব্যাকআপ থেকে মৌলিক পুনরুদ্ধার:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH REPLACE;

পয়েন্ট-ইন-টাইম পুনরুদ্ধারের জন্য লগ ব্যাকআপ সহ পুনরুদ্ধার করুন:

RESTORE DATABASE [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName.bak'
WITH NORECOVERY, REPLACE;

RESTORE LOG [DatabaseName] 
FROM DISK = 'C:\Backups\DatabaseName_Log.trn'
WITH RECOVERY;

16.3 যাচাইকরণ এবং পরীক্ষা

1. ডাটাবেস সফলভাবে অনলাইন হয়েছে কিনা তা যাচাই করুন
2. CHECKDB দিয়ে ডেটা অখণ্ডতা পরীক্ষা করুন
3. গুরুত্বপূর্ণ অ্যাপ্লিকেশন ফাংশন পরীক্ষা করুন
4. ত্রুটি ছাড়াই ব্যাকআপ/পুনরুদ্ধার সম্পন্ন হয়েছে তা নিশ্চিত করুন।

16.4 রেফারেন্স

আপনি আমাদের থেকে আরও তথ্য জানতে পারেন ব্যাকআপ এবং পুনরুদ্ধারের জন্য বিস্তারিত নির্দেশিকা SQL Server ডাটাবেস.

১৭. সমাধান #১৫: পেশাদার SQL পুনরুদ্ধার সরঞ্জাম

যখন ম্যানুয়াল পদ্ধতিগুলি SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যাগুলি সমাধান করতে ব্যর্থ হয়, তখন বিশেষায়িত পুনরুদ্ধার সফ্টওয়্যার গুরুতরভাবে দূষিত ডাটাবেস থেকে ডেটা বের করতে পারে যা স্ট্যান্ডার্ড পদ্ধতির মাধ্যমে মেরামত করা যায় না।

১৩.২ কখন তৃতীয় পক্ষের সরঞ্জামগুলি বিবেচনা করবেন

• ম্যানুয়াল মেরামতের ক্ষমতার বাইরেও মারাত্মক দুর্নীতি
• কোনও ব্যাকআপ ছাড়াই গুরুত্বপূর্ণ ডেটা
• একাধিক ব্যর্থ ম্যানুয়াল মেরামতের প্রচেষ্টা
• সময়-সমালোচনামূলক পুনরুদ্ধারের প্রয়োজনীয়তা

17.2 DataNumen SQL Recovery

DataNumen SQL Recovery একটি শক্তিশালী হয় SQL Server ডাটাবেস পুনরুদ্ধার টুল।

এটি ব্যবহারের ধাপগুলি নিচে দেওয়া হল:

1. বন্ধ করুন SQL Server সার্ভিস।
   
2. ডাটাবেসের ফাইলগুলির একটি কপি তৈরি করুন যা পুনরুদ্ধারের অপেক্ষায় রয়েছে, যার মধ্যে প্রাথমিক MDF ফাইল এবং দ্বিতীয় NDF ফাইল উভয়ই অন্তর্ভুক্ত।
3. শুরু করুন SQL Server সার্ভিস।
4. শুরু DataNumen SQL Recovery.
5. পুনরুদ্ধার করা ডাটাবেসের উৎস হিসেবে মূল ফাইলের পরিবর্তে কপিটি নির্বাচন করুন।
6. “স্টার্ট রিকভারি”-তে ক্লিক করুন এবং ডাটাবেস পুনরুদ্ধার করতে নির্দেশাবলী অনুসরণ করুন।
7. পুনরুদ্ধার প্রক্রিয়ার পরে, একটি নতুন পুনরুদ্ধার ডাটাবেস প্রদর্শিত হবে SQL Server যেখানে সমস্ত পুনরুদ্ধার করা তথ্য রয়েছে।

১৮. উন্নত সমস্যা সমাধানের পরিস্থিতি

জটিল পরিবেশে SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যা সমাধানের জন্য বিশেষ পদ্ধতির প্রয়োজন।

১৮.১ একাধিক ডাটাবেস ফাইল সমস্যা

একাধিক ডেটা ফাইল (NDF) সহ ডাটাবেসগুলির যত্ন সহকারে পরিচালনা প্রয়োজন:

• কোন ফাইলগ্রুপগুলি প্রভাবিত হচ্ছে তা চিহ্নিত করুন
• অ্যাক্সেসযোগ্যতার জন্য সমস্ত NDF ফাইল পরীক্ষা করুন
• ফাইলগ্রুপ-নির্দিষ্ট পুনরুদ্ধারের বিকল্পগুলি বিবেচনা করুন
• শুধুমাত্র পঠনযোগ্য ফাইলগ্রুপগুলি যথাযথভাবে পরিচালনা করুন

১৮.২ সর্বদা উপলব্ধ গ্রুপ

SQL db পুনরুদ্ধার মুলতুবি আছে সবসময় পরিবেশ:

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

১৮.৩ ক্লাস্টার এবং উচ্চ প্রাপ্যতার পরিস্থিতি

SQL ডাটাবেস পুনরুদ্ধার মুলতুবি আছে ফেইলওভার ক্লাস্টার এবং উচ্চ প্রাপ্যতা পরিস্থিতি:

• শেয়ার করা স্টোরেজ অ্যাক্সেসিবিলিটি যাচাই করুন
• ক্লাস্টার নোড যোগাযোগ পরীক্ষা করুন
• ফেইলওভার ক্লাস্টার লগ পর্যালোচনা করুন
• সঠিক DNS রেজোলিউশন নিশ্চিত করুন

১৮.৪ WMI এবং সিস্টেম-স্তরের সমস্যা

সিস্টেম-স্তরের সমস্যাগুলি ডাটাবেসের সমস্যা তৈরি করতে পারে:

• WMI রিপোজিটরি দুর্নীতি
• ব্যর্থ উইন্ডোজ আপডেট
• রেজিস্ট্রি দুর্নীতি
• পরিষেবা নির্ভরতা সমস্যা

19. প্রতিরোধ কৌশল

SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যাগুলি দেখা দেওয়ার পরে সেগুলি ঠিক করার চেয়ে প্রতিরোধ করা বেশি কার্যকর।

19.1 ব্যাকআপ সর্বোত্তম অভ্যাস

1. স্বয়ংক্রিয় পূর্ণ ব্যাকআপ সময়সূচী বাস্তবায়ন করুন
2. নিয়মিত ডিফারেনশিয়াল ব্যাকআপ কনফিগার করুন
3. ঘন ঘন লেনদেন লগ ব্যাকআপ সেট আপ করুন
4. নিয়মিত ব্যাকআপ পুনরুদ্ধার পদ্ধতি পরীক্ষা করুন
5. আলাদা স্টোরেজ সিস্টেমে ব্যাকআপ সংরক্ষণ করুন
6. RESTORE VERIFYONLY ব্যবহার করে ব্যাকআপের অখণ্ডতা যাচাই করুন

19.2 মনিটরিং এবং রক্ষণাবেক্ষণ

1. ডিস্ক স্পেস পর্যবেক্ষণ সতর্কতা সেট আপ করুন
2. নিয়মিত DBCC CHECKDB কার্যক্রমের সময়সূচী নির্ধারণ করুন
3. মনিটর SQL Server প্রতিদিন ত্রুটি লগ
4. বাস্তবায়ন কর্মক্ষমতা বেসলাইন পর্যবেক্ষণ
5. কনফিগার করুন SQL Server গুরুতর ত্রুটির জন্য এজেন্ট সতর্কতা

১৯.৩ অবকাঠামোগত বিবেচনা

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

19.4 SQL Server কনফিগারেশনের সেরা অনুশীলন

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

২০. সমস্যা সমাধানের সিদ্ধান্ত বৃক্ষ এবং পদ্ধতি

SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি থাকা সমস্যার সম্মুখীন হলে এই পদ্ধতিগত পদ্ধতি অনুসরণ করুন।

২০.১ পদ্ধতিগত রোগ নির্ণয় পদ্ধতি

1. প্রথমে ত্রুটি লগ পরীক্ষা করুন – সর্বদা শুরু করুন SQL Server এবং উইন্ডোজ লগ
2. ফাইল অ্যাক্সেসযোগ্যতা যাচাই করুন - নিশ্চিত করুন যে সমস্ত ডাটাবেস ফাইল বিদ্যমান এবং পঠনযোগ্য।
3. ডিস্কের স্থান পরীক্ষা করুন - পুনরুদ্ধার কার্যক্রমের জন্য পর্যাপ্ত স্থান নিশ্চিত করুন
4. প্রথমে সহজ সমাধানগুলি চেষ্টা করে দেখুন – পরিষেবা পুনরায় চালু, অফলাইন/অনলাইন
5. জটিল মেরামতের অগ্রগতি - সহজ পদ্ধতিগুলি ব্যর্থ হওয়ার পরেই
6. ব্যাকআপ থেকে পুনরুদ্ধার করার কথা বিবেচনা করুন - যখন মেরামতের ঝুঁকি খুব বেশি থাকে

২০.২ সঠিক সমাধান পদ্ধতি নির্বাচন করা

কম ঝুঁকি (প্রথমে চেষ্টা করুন):

• আবার শুরু SQL Server সেবা
• ডিস্কের স্থান পরীক্ষা করে সমাধান করুন
• ফাইলের অনুমতি ঠিক করুন
• অফলাইন/অনলাইন ডাটাবেস

মাঝারি ঝুঁকি:

• ফাইল পাথ সংশোধন
• অটো ক্লোজ অক্ষম করুন
• FILESTREAM কনফিগারেশন সংশোধন
• পরিষেবা বিলম্বিত শুরু

উচ্চ ঝুঁকি (ডেটা হারানোর সম্ভাবনা):

• লগ ফাইল মুছে ফেলুন এবং পুনরায় চালু করুন।
• ডাটাবেস বিচ্ছিন্ন/পুনরায় সংযুক্ত করুন
• লেনদেন লগ পুনর্নির্মাণ করুন
• জরুরী মোড মেরামতের সাথে ডিবিসিসি চেকডিবি

২০.৩ কখন আরও জোর দিতে হবে

পেশাদার সাহায্য নিন যখন:

• একাধিক উচ্চ-ঝুঁকিপূর্ণ পদ্ধতি ব্যর্থ হয়েছে
• ডাটাবেসে অপরিবর্তনীয় গুরুত্বপূর্ণ তথ্য রয়েছে
• দুর্নীতি একাধিক ডাটাবেসকে প্রভাবিত করে
• সিস্টেম-স্তরের সমস্যা সন্দেহ করা হচ্ছে
• সময়ের সীমাবদ্ধতার জন্য নিশ্চিত ফলাফল প্রয়োজন

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

প্রশ্ন: "রিকভারিং" এবং "রিকভারি পেন্ডিং" ডাটাবেস অবস্থার মধ্যে পার্থক্য কী?

A: "পুনরুদ্ধার" অর্থ ডাটাবেস সক্রিয়ভাবে পুনরুদ্ধার কার্যক্রম সম্পাদন করছে এবং সম্পূর্ণ হলে স্বয়ংক্রিয়ভাবে অনলাইনে আসবে। "পুনরুদ্ধার মুলতুবি" অর্থ SQL Server ফাইল অনুপস্থিত থাকা, অপর্যাপ্ত স্থান বা ডেটা করাপশনের মতো কোনো বাধার কারণে রিকভারি প্রক্রিয়া শুরু করা যাচ্ছে না। রিকভারি পেন্ডিং থাকায় এটি সমাধানের জন্য ম্যানুয়াল হস্তক্ষেপ প্রয়োজন।

প্রশ্ন: SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি থাকা সমস্যার সম্মুখীন হলে আমার প্রথমে কোন সমাধানটি চেষ্টা করা উচিত?

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

প্রশ্ন: অন্য একটি সমাধান পদ্ধতি চেষ্টা করার আগে আমার কতক্ষণ অপেক্ষা করা উচিত?

সার্ভিস রিস্টার্টের ক্ষেত্রে, সম্পূর্ণ চালু হওয়ার জন্য ২-৩ মিনিট অপেক্ষা করুন। অফলাইন/অনলাইনের মতো সাধারণ অবস্থা পরিবর্তনের জন্য ৩০-৬০ সেকেন্ড অপেক্ষা করুন। DBCC CHECKDB-এর মতো জটিল মেরামতের জন্য, ডাটাবেসের আকারের উপর নির্ভর করে কয়েক ঘণ্টা সময় দিন। রিকভারি প্রক্রিয়া একবার শুরু হয়ে গেলে তাতে বাধা দেবেন না।

প্রশ্ন: SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যাগুলি সমাধান করার সময় কি আমি ডেটা হারাব?

ডেটা হারানোর পরিমাণ ব্যবহৃত পদ্ধতির উপর নির্ভর করে। সার্ভিস রিস্টার্ট, ডিস্ক স্পেস ফিক্স এবং পারমিশন কারেকশনের মতো নিরাপদ পদ্ধতিগুলোতে কোনো ডেটা নষ্ট হয় না। ইমার্জেন্সি মোড রিপেয়ার, লগ রিביל্ডিং বা লগ ফাইল ডিলিট করার মতো উচ্চ-ঝুঁকিপূর্ণ পদ্ধতিগুলোর ফলে উল্লেখযোগ্য পরিমাণে ডেটা নষ্ট হতে পারে। সর্বদা প্রথমে নিরাপদ পদ্ধতিগুলো চেষ্টা করুন।

প্রশ্ন: আমি কি SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যাগুলি প্রতিরোধ করতে পারি?

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

প্রশ্ন: আমার কি ব্যবসায়িক সময়ের মধ্যে উৎপাদন ডাটাবেস মেরামতের চেষ্টা করা উচিত?

কর্মঘণ্টার মধ্যে প্রোডাকশন ডেটাবেসে কখনোই উচ্চ-ঝুঁকিপূর্ণ মেরামতের পদ্ধতি প্রয়োগ করার চেষ্টা করবেন না। জটিল মেরামতের জন্য রক্ষণাবেক্ষণের নির্দিষ্ট সময় নির্ধারণ করুন। তবে, সার্ভিস রিস্টার্ট বা ডিস্ক স্পেস ঠিক করার মতো নিরাপদ পদ্ধতিগুলো যদি গুরুত্বপূর্ণ কার্যক্রমে বাধা সৃষ্টি করে, তাহলে সেগুলো তাৎক্ষণিকভাবে প্রয়োগ করা যেতে পারে।

প্রশ্ন: মেরামতের চেষ্টা করার পরিবর্তে কখন আমার ব্যাকআপ থেকে পুনরুদ্ধার করা উচিত?

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

প্রশ্ন: আমার ডাটাবেস ফাইলগুলি দূষিত নাকি অ্যাক্সেসযোগ্য নয় তা আমি কীভাবে জানব?

A: চেক করুন SQL Server নির্দিষ্ট ত্রুটি বার্তাগুলির জন্য ত্রুটি লগ। ফাইল অ্যাক্সেসিবিলিটি সমস্যাগুলি "ফাইল খুঁজে পাচ্ছে না" বা অনুমতি ত্রুটি দেখায়। দুর্নীতি সাধারণত চেকসাম ত্রুটি, পৃষ্ঠা-স্তরের ত্রুটি, বা ধারাবাহিকতা লঙ্ঘন দেখায়। ডাটাবেস অ্যাক্সেসযোগ্য হলে দুর্নীতির জন্য নিশ্চিতভাবে পরীক্ষা করতে DBCC CHECKDB ব্যবহার করুন।

প্রশ্ন: মেরামতের চেষ্টা করার আগে ডাটাবেস ফাইলগুলি অনুলিপি করার সবচেয়ে নিরাপদ উপায় কী?

উ: থামো SQL Server সম্পূর্ণরূপে পরিষেবা প্রদান করুন, তারপর MDF এবং LDF উভয় ফাইলই একটি ব্যাকআপ স্থানে অনুলিপি করুন। বিকল্পভাবে, যদি ডাটাবেসটি এখনও অ্যাক্সেসযোগ্য থাকে তবে ডাটাবেস ব্যাকআপ কমান্ড ব্যবহার করুন। কখনই ফাইল কপি করবেন না যখন SQL Server চলছে কারণ এটি অসঙ্গত কপি তৈরি করতে পারে।

প্রশ্ন: SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি সমস্যাগুলি কি একসাথে একাধিক ডাটাবেসকে প্রভাবিত করতে পারে?

উত্তর: হ্যাঁ, সিস্টেম-স্তরের সমস্যা যেমন অপর্যাপ্ত ডিস্ক স্থান, পরিষেবা অ্যাকাউন্ট সমস্যা, স্টোরেজ ব্যর্থতা, অথবা SQL Server কনফিগারেশন ত্রুটি একাধিক ডাটাবেসকে প্রভাবিত করতে পারে। বৃহত্তর সিস্টেম সমস্যাগুলি সনাক্ত করার জন্য সর্বদা পরীক্ষা করুন যে অন্যান্য ডাটাবেসগুলি একই ধরণের সমস্যার সম্মুখীন হচ্ছে কিনা।

প্রশ্ন: আমার ডাটাবেস পুনরুদ্ধার পদ্ধতি কতবার পরীক্ষা করা উচিত?

A: গুরুত্বপূর্ণ ডাটাবেসের জন্য মাসিক এবং গুরুত্বপূর্ণ ডাটাবেসের জন্য ত্রৈমাসিক ভিত্তিতে পুনরুদ্ধার পদ্ধতি পরীক্ষা করুন। পয়েন্ট-ইন-টাইম পুনরুদ্ধার, লগ সিকোয়েন্স পুনরুদ্ধার এবং জরুরি পুনরুদ্ধার পদ্ধতির মতো বিভিন্ন পুনরুদ্ধার পরিস্থিতির পরীক্ষা অন্তর্ভুক্ত করুন। জরুরি পরিকল্পনার জন্য প্রতিটি পরীক্ষার নথি এবং সময় নির্ধারণ করুন।

প্রশ্ন: কখন আমার মাইক্রোসফট সাপোর্টের সাথে যোগাযোগ করা উচিত অথবা পেশাদার সাহায্য নেওয়া উচিত?

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

প্রশ্ন: তৃতীয় পক্ষের SQL পুনরুদ্ধার সরঞ্জামগুলি কি বিনিয়োগের যোগ্য?

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

প্রশ্ন: যদি SQL ডাটাবেস পুনরুদ্ধারের মুলতুবি থাকা সমস্যা বারবার দেখা দেয়, তাহলে আমার কী করা উচিত?

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

22. উপসংহার এবং দ্রুত রেফারেন্স

সাধারণ সার্ভিস রিস্টার্ট থেকে শুরু করে জটিল জরুরি মেরামত পর্যন্ত, এই ১৫টি প্রমাণিত পদ্ধতি ব্যবহার করে SQL ডাটাবেস রিকভারি সংক্রান্ত অমীমাংসিত সমস্যা সমাধান করা যেতে পারে।

২২.১ দ্রুত সমাধানের সারাংশ সারণী

ফিক্স পদ্ধতি	ঝুঁকি স্তর	ডেটা হারানোর ঝুঁকি	সর্বোত্তম জন্য ব্যবহৃত
আবার শুরু SQL Server	কম	না	সময় সংক্রান্ত সমস্যা, অস্থায়ী লক
ডিস্কের স্থান পরীক্ষা করুন	কম	না	স্থান-সম্পর্কিত ব্যর্থতা
দেরিতে আরম্ভ	কম	না	স্টোরেজ টাইমিং সমস্যা
ফিক্স অনুমতি	কম	না	অ্যাক্সেস অস্বীকার ত্রুটি
ফাইল পাথ ঠিক করুন	কম	না	পথ পরিবর্তন, স্থানান্তর
অফলাইন / অনলাইন	মধ্যম	যত্সামান্য	রাজ্যের অসঙ্গতি
অটো ক্লোজ অক্ষম করুন	কম	না	ঘন ঘন খোলা/বন্ধ চক্র
লগ ফাইল মুছে ফেলুন	উচ্চ	হাঁ	দূষিত লগ, ডেভেলপার পরিবেশ
বিচ্ছিন্ন/পুনরায় সংযুক্ত করুন	উচ্চ	হাঁ	হারিয়ে যাওয়া বা দূষিত লগ
লগগুলি পুনর্নির্মাণ করুন	উচ্চ	হাঁ	হারিয়ে যাওয়া LDF ফাইলগুলি
DBCC CHECKDB এর মাধ্যমে জরুরি মেরামত	সুউচ্চ	হাঁ	চরম দুর্নীতি, শেষ অবলম্বন
FILESTREAM ঠিক করুন	মধ্যম	না	FILESTREAM কনফিগারেশন সমস্যা
আপডেট SQL Server	মধ্যম	না	পরিচিত সংস্করণের বাগগুলি
ব্যাকআপ থেকে পুনঃস্থাপন	কম	নিয়ন্ত্রিত	যখন মেরামতের পদ্ধতি ব্যর্থ হয়
পুনরুদ্ধারের সরঞ্জাম	মধ্যম	পরিবর্তনশীল	মারাত্মক দুর্নীতি, কোনও ব্যাকআপ নেই

২২.২ জরুরি প্রতিক্রিয়া চেকলিস্ট

প্রথম ৫ মিনিট:

1. চেক SQL Server ত্রুটি লগ
2. ডাটাবেস ফাইলের অ্যাক্সেসযোগ্যতা যাচাই করুন
3. উপলব্ধ ডিস্ক স্থান পরীক্ষা করুন
4. পরিষেবা পুনরায় চালু করার চেষ্টা করুন
5. নথি ত্রুটি বার্তা

পরবর্তী ১৫ মিনিট:

1. সার্ভিস রিস্টার্ট ব্যর্থ হলে অফলাইন/অনলাইনে চেষ্টা করুন।
2. স্পষ্ট অনুমতি সংক্রান্ত সমস্যাগুলি পরীক্ষা করে ঠিক করুন
3. ফাইলের পাথগুলি সঠিক কিনা তা যাচাই করুন
4. উইন্ডোজ ইভেন্ট লগ পর্যালোচনা করুন
5. ব্যাকআপের প্রাপ্যতা মূল্যায়ন করুন

22.3 অতিরিক্ত সম্পদ

• মাইক্রোসফট SQL Server পুনরুদ্ধারের ডকুমেন্টেশন
• মাইক্রোসফট SQL Server সাপোর্ট ফোরাম

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

---

লেখক সম্পর্কে

ইউয়ান সেং একজন সিনিয়র ডাটাবেস অ্যাডমিনিস্ট্রেটর (DBA) যার ১০ বছরেরও বেশি অভিজ্ঞতা রয়েছে SQL Server পরিবেশ এবং এন্টারপ্রাইজ ডাটাবেস ব্যবস্থাপনা। তিনি আর্থিক পরিষেবা, স্বাস্থ্যসেবা এবং উৎপাদন সংস্থা জুড়ে শত শত ডাটাবেস পুনরুদ্ধারের পরিস্থিতি সফলভাবে সমাধান করেছেন।

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

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

সম্পর্কে প্রশ্ন আছে SQL Server পুনরুদ্ধারের প্রয়োজন নাকি অতিরিক্ত ডাটাবেস সমস্যা সমাধানের নির্দেশিকা প্রয়োজন? ইউয়ান স্বাগত জানায়? প্রতিক্রিয়া এবং পরামর্শ এই প্রযুক্তিগত সম্পদ উন্নত করার জন্য।