পুনরুদ্ধার করতে অক্ষম (ত্রুটি 3456)

Question

আমার এমন পরিস্থিতি রয়েছে যা নির্ণয় করা সহজ নয় এবং আমি ভেবেছিলাম যে এই ফোরামে যদি অন্যের কাছে পরামর্শ থাকে তবে তা জিজ্ঞাসা করব।

আমি উইন্ডোজ সার্ভার 2008R2 এন্টারপ্রাইজে এসকিউএল সার্ভার 2008 আর 2 স্ট্যান্ডার্ড এসপি 3 চালিয়ে যাচ্ছি।

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

1. শুরু করার আগে, টলব্যাকআপ 1 তৈরি করুন
2. থেকে পরিবর্তন FULLকরতে BULK_LOGGEDপুনরুদ্ধারের মডেল
3. নতুন ফাইলগোষ্ঠী যুক্ত করুন
4. ফাইলটি নতুন ফাইলগোষ্ঠীতে যুক্ত করুন
5. ডিফল্ট হিসাবে নতুন ফাইলগ্রুপ সেট করুন
6. সারণীতে নির্বাচন করুন (নতুন ফাইলগ্রুপে)
7. আসল টেবিলটি ফেলে দিন
8. মূল ফাইল মুছুন
9. আসল ফাইলগ্রুপ মুছুন
10. মূল সারণীর সাথে মেলে নতুন টেবিলের নাম পরিবর্তন করুন
11. আসল ফাইলগ্রুপের সাথে মেলে নতুন ফাইলগ্রুপের ফাইলের নাম পরিবর্তন করুন
12. মূল ফাইলের নামের সাথে মেলে ক্যাটালগের মধ্যে ফাইলের নাম পরিবর্তন করুন
13. আসল ফাইলের নামের সাথে মেলে ওএস স্তরে ফাইলের নাম পরিবর্তন করুন
14. আসল হিসাবে ডিফল্ট ফাইলগোষ্ঠী সেট করুন
15. অনলাইনে ডিবি আনুন
16. থেকে পরিবর্তন BULK_LOGGEDকরতে FULLপুনরুদ্ধারের মডেল
17. সমস্ত পদক্ষেপ সমাপ্ত হওয়ার পরে, টলব্যাকআপ 2 তৈরি করুন

পুনরুদ্ধার সার্ভারে ড্রাইভ লেটারের পরিবর্তনের কারণে সমস্ত ব্যাকআপ পুনরুদ্ধার করতে হবে পরিবর্তনের সাথে সরানো।

পুনরুদ্ধারের পদক্ষেপ:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

চূড়ান্ত টোগল পুনরুদ্ধার 100% এ যায় এবং তারপরে ত্রুটি 3456 এর সাথে ব্যর্থ হয়:

ডাটাবেস 'সোমডডিবি' এর জন্য 368 পৃষ্ঠাগুলি প্রক্রিয়া করা হয়েছে, ফাইল 1-তে 'সিস্টেমডেটা' ফাইল করুন।

ডাটাবেস 'সোমডডিবি' এর জন্য 7656520 পৃষ্ঠাগুলি প্রক্রিয়া করা হয়েছে, ফাইল 1-তে 'সিস্টেমডেটাপিডিএস' ফাইল করুন।

ডাটাবেস 'সোমডডিবি' এর জন্য 172430 পৃষ্ঠাগুলি প্রক্রিয়া করা হয়েছে, ফাইল 1-তে 'সিস্টেমডেটা_লগ' করুন।

এমএসজি 3456, স্তর 16, রাজ্য 1, লাইন 1
লগ রেকর্ড (210388: 123648: 232), পৃষ্ঠাতে (4: 8088), ডাটাবেস 'সোমডেবি' (ডাটাবেস আইডি 6) এর জন্য পুনরায় করতে পারেনি (210388: 123648: 232) । পৃষ্ঠা: এলএসএন = (0: 0: 1), টাইপ = ১১ লগ: ওপকোড = 4, প্রসঙ্গ 11, প্রিভেজ পেজ এলএসএন: (210388: 122007: 1)। ডাটাবেসের ব্যাকআপ থেকে পুনরুদ্ধার করুন, বা ডাটাবেসটি মেরামত করুন। এমএসজি 3013, স্তর 16, রাজ্য 1, লাইন 1 পুনরুদ্ধার করুন লগ অস্বাভাবিকভাবে শেষ হচ্ছে।

পুরো ডিবি ব্যাকআপ ঠিক আছে কিনা তা যাচাই করতে, আমি এটি পুনরুদ্ধার করেছিলাম CHECKDB, এবং কোনও ত্রুটি নেই।

সমস্ত প্রতিক্রিয়া স্বাগত জানাই।

আগাম ধন্যবাদ,

নেড ওটার

Comments

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

— থমাস কেজার

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

— নেডঅটার

ত্রুটিটি দুর্নীতির মতো দেখাচ্ছে। এটি একটি অভ্যন্তরীণ ত্রুটি। আপনি কি সমস্ত ব্যাকআপ ফাইলের অখণ্ডতা যাচাই করতে পারেন? তারা চেকসাম সঙ্গে আছে?

— usr ডিরেক্টরির

আমি CHECKDB চালিয়ে পুরো ডিবি ব্যাকআপের 0 টি ত্রুটি ছিল তা যাচাই করেছিলাম। আমাকে CHECKSUM ব্যবহার করা হয়েছে কিনা তা পরীক্ষা করে দেখতে হবে।

— নেডঅটার

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

— রবার্ট এল ডেভিস

Answer 1

3456 ত্রুটি কেন ছোঁড়া হবে তা বোঝার জন্য, আমাদের কিছুটা পিছন ফিরে নেওয়া উচিত এবং এসকিউএল সার্ভার পুনরুদ্ধারের এই কোণটি কীভাবে পরিচালনা করে তা বুঝতে হবে।

যখন এসকিউএল সার্ভার কোনও ক্রিয়াকলাপ পুনরায় করছে, এবং সেই পুনরায় একটি পৃষ্ঠা পরিবর্তন হয়, এটি একটি দ্রুত চেক করে। পৃষ্ঠা শিরোনামে চূড়ান্তভাবে একটি হতে চলেছে PageLSNযা এটি সর্বশেষ এলএসএনের ইঙ্গিত যা সেই পৃষ্ঠাটি রেকর্ড করেছিল যে পৃষ্ঠাটি সংশোধন করেছে। এটি এর মতো চিন্তা করুন, পৃষ্ঠাটি সর্বশেষ এলএসএনকে ট্র্যাক করে যা এতে পরিবর্তন করেছে। এই PageLSN।

প্রতিবার যখন কোনও লগইড পৃষ্ঠা সংশোধন অপারেশন হয়, সেই লগ রেকর্ডে কয়েকটি এলএসএন অন্তর্ভুক্ত থাকে। যথা, লগ রেকর্ডের এলএসএন (মনে করুন ... বর্তমান এলএসএন ), এবং তারপরে এটি পূর্ববর্তী পৃষ্ঠা এলএসএন ( PrevPageLSNএগিয়ে যাওয়া) বলে। সুতরাং আমরা যখন একটি পৃষ্ঠা পরিবর্তন করি, তখন লগ রেকর্ডে রাখা ডেটার টুকরোগুলির একটি হ'ল পৃষ্ঠাটি আপনাকে সর্বশেষ এলএসএন হিসাবে চিহ্নিত করে আপনি পৃষ্ঠাটি পরিবর্তন করার আগে ।

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

এটি কিছুটা বিভ্রান্তিকর হতে পারে, সুতরাং অনুক্রমিক পৃষ্ঠা পরিবর্তনগুলির নীচে এই চিত্রটি দেখুন এবং কীভাবে PageLSNএবং PrevPageLSNসম্পর্কিত:

আসুন ফিরে ঘুরে আসা যাক, যখন আপনি কোনও পৃষ্ঠায় কোনও ক্রিয়াকলাপ পুনরায় করা দরকার (পুনরুদ্ধার, পুনরুদ্ধার, এইচএ, ইত্যাদি) তখন এগুলি সমস্ত কার্যকর হয়। এসকিউএল সার্ভারকে যখন কোনও পৃষ্ঠার ক্রিয়াকলাপটি পুনরায় করা দরকার, PageLSNতখন পৃষ্ঠাটিতে PrevPageLSNলগ রেকর্ডটি অন্তর্ভুক্ত থাকা কোনওটির সাথে মেলে কিনা তা দেখার জন্য এটি একটি বিচক্ষণতা পরীক্ষা করে । যদি এটি সমান না হয়, তবে আপনি ত্রুটি 3456 নিক্ষেপ করতে দেখবেন।

পেজএলএসএন কি পূর্ববর্তী প্যাকেজ এলএসএন সমান ? কোন ??? থামান এবং ত্রুটি উত্থাপন 3456 ...

আসুন আপনার ত্রুটি বার্তাটি বিশ্লেষণ করুন, যার মধ্যে রয়েছে:

পৃষ্ঠায় (4: 8088) লেনদেনের আইডি (0: 1016710921) এর জন্য লগ রেকর্ড (210388: 123648: 232) পুনরায় করা যায়নি, ডাটাবেস 'সোমডডিবি' (ডাটাবেস আইডি 6)। পৃষ্ঠা: এলএসএন = (0: 0: 1) , টাইপ = 11. লগ: ওপকোড = 4, প্রসঙ্গ 11, প্রিভেজ পেজ এলএসএন: (210388: 122007: 1) । ডাটাবেসের ব্যাকআপ থেকে পুনরুদ্ধার করুন, বা ডাটাবেসটি মেরামত করুন। এমএসজি 3013, স্তর 16, রাজ্য 1, লাইন 1 পুনরুদ্ধার করুন লগ অস্বাভাবিকভাবে শেষ হচ্ছে।

আমি সেই দু'টি টুকরো ডেটা বোল্ড করে দিয়েছি যার মধ্যে একটি বৈষম্য রয়েছে যার ফলে ত্রুটি দেখা দিয়েছে। আপনি দেখতে পারেন যে, আমাদের PageLSNহয় 0: 0: 1 (এই পৃষ্ঠার হেডারের মধ্যে পাওয়া যায়নি), এবং আমাদের PrevPageLSNহয় 210388: 122007: 1 (এই লগ রেকর্ডে ডেটা আছে যা পুনরায় করা হতে প্রয়াস করার সময় পাওয়া যায়)। এগুলি অবশ্যই সমান নয়, অতএব ভুল 3

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

Comments

আমি জানি এটি কিছুক্ষণ হয়েছে তবে এখনও ... ভাল জিনিস, পুরো ব্যাখ্যাটির জন্য ধন্যবাদ!

— টমাস