অনলাইন পৃষ্ঠা পুনরুদ্ধার হিট 1000 সীমা


13

আমাকে এমন একটি ডাটাবেস পুনরুদ্ধার করার চেষ্টা করা হয়েছে যা দুর্নীতির কারণে ভুগেছে (আই / ও ব্যর্থতার কারণে, যা পরে সংশোধন করা হয়েছে)। আমি ডেটাবেস বা এটিতে কী আছে তার সাথে পরিচিত নই।

আমাকে একটি পুরানো (weeks 3 সপ্তাহ) পূর্ণ ব্যাকআপ এবং একাধিক লেনদেন লগ দেওয়া হয়েছে ... তবে লেনদেনের লগগুলি অনুপস্থিত রয়েছে, তাই আমি কেবল একটি নির্দিষ্ট তারিখ পর্যন্ত পুনরুদ্ধার করতে পারি। এখানে 2.5 সপ্তাহের মতো ডেটা নিখোঁজ রয়েছে (এবং এই ডাটাবেসে ক্রমাগত প্রচুর ডেটা যুক্ত হচ্ছে) added

আমাকে দুর্নীতিগ্রস্থ ডাটাবেসের একটি অনুলিপিও দেওয়া হয়েছে (যা অ্যাক্সেসযোগ্য তবে প্রচুর পৃষ্ঠাগুলি দুর্নীতিগ্রস্থ / নিখোঁজ রয়েছে)।

আমি টিপিকাল DBCC CHECKDBকমান্ডগুলি চেষ্টা করেছি (এখনও নেই repair_allow_data_loss, এটি আমার শেষ অবলম্বন হবে যদি অন্য কিছু না করে)।

অনেকগুলি এসে ডেটাবেজে যাওয়ার পরে (ডিবি 1.5 টেরাবাইট ছোট দৈত্য এবং আমি যা কিছু করি তা ধীর এবং কিছুটা সময় নেয়), আমি একটি অনলাইন পৃষ্ঠা দুর্নীতিগ্রস্থ পৃষ্ঠাগুলির জন্য সুপরিচিত ভাল ব্যাকআপ থেকে পুনরুদ্ধার করার চেষ্টা করেছি।

এটি করার জন্য, আমি একটি স্ক্রিপ্ট করেছি RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'যা DBCC CHECKDBআউটপুট থেকে অনেকগুলি কমান্ড তৈরি করে (যেমন: একটি রেজেক্স এবং একটি স্বতন্ত্র) ... এতদূর ভাল, এটি এমন এক পর্যায়ে কাজ করেছে যেখানে বলা হয়েছে যে আমি 1000 পৃষ্ঠার সীমাতে পৌঁছেছি said প্রতি ফাইল প্রতি (এই ডিবিতে 8 টি ফাইল রয়েছে) পুনরুদ্ধার কমান্ড প্রতি।

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

আমি চেষ্টা করেছি RESTORE DATABASE <foo> WITH RECOVERYকিন্তু এটিও কাজ করে না, এটি আমার কাছে এমন লগের জন্য জিজ্ঞাসা করে যা আমার কাছে নেই।

আমি কীভাবে এখান থেকে কিছু পুনরুদ্ধার করার চেষ্টা করতে পারি সে সম্পর্কে কারও কি কোনও টিপস রয়েছে? বা অনলাইনে পুনরুদ্ধার কীভাবে "সম্পূর্ণ" করবেন যাতে আমি আরও পৃষ্ঠা পুনরুদ্ধার করার চেষ্টা চালিয়ে যেতে পারি? আমি যদি অফলাইন পুনরুদ্ধার করার চেষ্টা করি (মূলত WITH NORECOVERYসবকিছুতে যুক্ত করে এবং শেষে এটিকে ফিরিয়ে আনার চেষ্টা করি) তবে আমার কি একই সমস্যা হবে?

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

কিছু ডেটা ক্ষতি গ্রহনযোগ্য হবে তবে ডিবিতে সামঞ্জস্যতা কমপক্ষে অর্জন করার চেষ্টা করা উচিত।

দুর্নীতিগ্রস্থ ডাটাবেসটি এখনও-অনলাইন এবং ক্লায়েন্টরা এতে কাজ করছে (সুতরাং এটি নতুন ডেটা পেতে থাকে) সুতরাং ল্যাব বেঞ্চে আমি যে কোনও প্রক্রিয়া করি তা পরবর্তী সময়ে উত্পাদন ডাটাবেসে পুনরায় প্রজননযোগ্য হওয়া উচিত (ডাউনটাইম এটির পক্ষে কঠিন হবে)।

এটি এসকিউএল সার্ভার 2014 এন্টারপ্রাইজ

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


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

উত্তর:


16

মানক পদ্ধতিটি হ'ল:

  1. পুনরুদ্ধার করতে হবে যে পৃষ্ঠা আইডি পান।
  2. একটি সম্পূর্ণ ডাটাবেস দিয়ে একটি পৃষ্ঠা পুনরুদ্ধার শুরু করুন।
  3. অতি সাম্প্রতিক ডিফারেনশিয়াল ব্যাকআপ প্রয়োগ করুন।
  4. পরবর্তী লগ ব্যাকআপ প্রয়োগ করুন।
  5. নতুন লগ ব্যাকআপ তৈরি করুন।
  6. নতুন লব ব্যাকআপ পুনরুদ্ধার করুন।

নতুন লগ ব্যাকআপ প্রয়োগ করার পরে, পৃষ্ঠা পুনরুদ্ধার সম্পন্ন হবে এবং পৃষ্ঠাগুলি তারপরে ব্যবহারযোগ্য হবে।

উদাহরণ পুনরুদ্ধার

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

তথ্যসূত্র: পুনরুদ্ধার পৃষ্ঠা (এসকিউএল সার্ভার) (মাইক্রোসফ্ট ডক্স) তথ্যসূত্র: পুনরুদ্ধার বিবৃতি (লেনদেন-এসকিউএল) (মাইক্রোসফ্ট ডক্স)

তবে, আপনার TLOG ব্যাকআপগুলিতে আপনার গর্ত রয়েছে এবং উপরের পদ্ধতিটি পুনরুদ্ধার করা আপনার ডাটাবেসটিকে এমন একটি অবস্থায় ফিরিয়ে আনতে পারে যা আপনি চান না।


আপনি একটি জটিল পরিস্থিতিতে আছেন।

  1. আপনার ডাটাবেসে দূষিত পৃষ্ঠা রয়েছে এবং আপনার সংস্থা ক্রমাগত সমস্যাযুক্ত একটি ডাটাবেসে নতুন ডেটা যুক্ত করছে। এর ফলে ডাটাবেসের মোট ডাউনটাইম হতে পারে। আপনি কি ঝুঁকি নিতে চান?

  2. কাউকে দায়ী করা হচ্ছে এবং আপনি এটির যত বেশি সমাধান করার চেষ্টা করবেন তত বেশি পরিচালন এই সিদ্ধান্ত নিতে ঝুঁকতে পারে যে আপনি শেষ পর্যন্ত সেই ব্যক্তি হতে পারেন। আপনি কি ঝুঁকি নিতে চান?

  3. আপনি নিযুক্ত ছিলেন না এমন একটি ভূমিকা গ্রহণ করে আপনি নিজেকে একটি কঠিন পরিস্থিতিতে ফেলছেন। আপনি এমন কিছু অর্জনের চেষ্টা করছেন যা আপনার সংস্থা ডিবিএ বা আপনার বহিরাগত পরামর্শদাতার পক্ষে সক্ষম ছিল না। এটি একটি মহৎ অঙ্গভঙ্গি হিসাবে মনে হতে পারে, আপনি নিজেকে ঝুঁকির মধ্যে ফেলছেন। আপনি সম্ভবত "প্রতিশ্রুতিবদ্ধ" এমন কিছু দিয়েছেন যা আপনি কখনই পূরণ করতে সক্ষম হবেন না। আপনি কি ঝুঁকি নিতে চান?

  4. যখন কেউ ডাটাবেসের সাথে কাজ করে এমন ডেটা অনুসন্ধান করে যেগুলি দুর্নীতিগ্রস্থ, তারা সম্ভবত একটি ত্রুটি বার্তা গ্রহণ করবে। প্রতিদিনের কাজ ইতিমধ্যে প্রভাবিত হচ্ছে। অনিবার্যতার সাথে যতক্ষণ অপেক্ষা করবেন তত বেশি উত্পাদনশীলতা প্রভাবিত হবে। আপনি কি ঝুঁকি নিতে চান? (এই প্রশ্নটি পরিচালনার সাথেও উত্থাপিত হতে পারে)

  5. আপনার সংস্থার ব্যাকআপ পদ্ধতিটি ত্রুটিযুক্ত বলে মনে হচ্ছে (অন্যথায় টিএলওজি ব্যাকআপগুলি কীভাবে অনুপস্থিত হবে?) এবং আপনি এখনও আপনার প্রোডাকশন ডাটাবেসটি চালিয়ে যাচ্ছেন যেন কোনও সমস্যা নেই। আপনি কি ঝুঁকি নিতে চান?

আমি আপনাকে যে সেরা প্রস্তাব দিতে পারি তা হ'ল প্রোডাকশন বন্ধ করে মাইক্রোসফ্টকে কল করা! বা কমপক্ষে মাইক্রোসফ্ট কল করুন এবং সম্ভবত উত্পাদন বন্ধ।

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

আপনি যত বেশি অপেক্ষা করেন তত বেশি ব্যয়বহুল পুনরুদ্ধার হয়ে উঠতে পারে।


পৃষ্ঠা পুনরুদ্ধার সীমাবদ্ধতা হিসাবে, এখানে অফিসিয়াল ডকুমেন্টেশন থেকে একটি উদ্ধৃতি:

পেজের সর্বাধিক সংখ্যা যে একটা ক্রম পুনঃস্থাপন কোনো একক ফাইলে পুনরুদ্ধার করা যেতে পারে 1000 । তবে আপনার যদি কোনও ফাইলে ক্ষুদ্র সংখ্যক ক্ষতিগ্রস্থ পৃষ্ঠাগুলির বেশি থাকে তবে পৃষ্ঠাগুলির পরিবর্তে পুরো ফাইলটি পুনরুদ্ধার করুন।

( জোর আমার)

তথ্যসূত্র: পুনরুদ্ধার বিবৃতি - যুক্তি (লেনদেন-এসকিউএল) (মাইক্রোসফ্ট ডক্স)


যখন সমস্ত কিছু স্বাভাবিক অবস্থায় ফিরে আসে, তখন ডিবিএ এবং / বা বাহ্যিক পরামর্শদাতারা আপনার ডাটাবেসের জন্য আলাদা ব্যাকআপ / পুনরুদ্ধার নীতি / পদ্ধতি বাস্তবায়নের বিষয়ে বিবেচনা করতে চাইতে পারেন। এটি 7x24 আপ হিসাবে থাকতে হবে আপনি কোনও ব্যাকআপ প্রক্রিয়া থাকার ঝুঁকি নিতে পারবেন না যা কোনও পরিস্থিতিতে পর্যাপ্ত পুনরুদ্ধার ক্ষমতা সরবরাহ করে না।


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

1

আমি দেখতে পাচ্ছি যে আপনি এই দুর্নীতিগ্রস্থ ডাটাবেসটি বিশেষত 1 টিবির বেশি আকারের মেরামত করতে ডেটা রিকভারি "বিশেষজ্ঞদের" সাথে কাজ করার সহ বিভিন্ন পদ্ধতির চেষ্টা করেছেন। এটি প্রক্রিয়াটিকে আরও শক্ত এবং সময়ের বিরুদ্ধে প্রতিযোগিতা করে তোলে। অভিজ্ঞ ডিবিএ হিসাবে আমি একই ধরণের পরিস্থিতি নিয়ে এসেছি যেখানে বেশিরভাগ সময় পুনরুদ্ধার করার জন্য ভাল ব্যাকআপ পাওয়া যায়। খারাপ ব্যাকআপ এবং দুর্নীতিগ্রস্থ ডাটাবেস উত্তরাধিকার সূত্রে ক্ষেত্রে আমি স্টারার ফিনিক্স এসকিউএল ডেটাবেস মেরামত সরঞ্জাম নামে একটি তৃতীয় পক্ষের সরঞ্জামের উপর প্রচুরভাবে নির্ভর করেছি । এই সরঞ্জামটি দূষিত ডাটাবেসগুলি (.mdf এবং .ndf) মেরামত করার জন্য সুপরিচিত। নীচে সরঞ্জামটির কয়েকটি কার্যকারিতা রয়েছে:

  • দুর্নীতিগ্রস্থ এসকিউএল ডেটাবেস (.mdf এবং .ndf) ফাইলগুলি মেরামত করে
  • সারণী, ট্রিগার, সূচি, কী, নিয়ম এবং সঞ্চিত পদ্ধতি পুনরুদ্ধার করে
  • এসকিউএল ডাটাবেস থেকে মুছে ফেলা রেকর্ড পুনরুদ্ধার সম্পাদন করে

  • পরবর্তী পর্যায়ে পুনরুদ্ধার সম্পাদন করতে ডাটাবেসের স্ক্যান ফলাফল সংরক্ষণ করে

  • এমএসএসকিউএল, এইচটিএমএল, এক্সএলএস এবং সিএসভি ফর্ম্যাটে মেরামত করা ফাইল সংরক্ষণের অনুমতি দেয়
  • এমএস এসকিউএল সার্ভার 2016, 2014, 2012,2008 এবং পুরানো সংস্করণগুলিকে সমর্থন করে

সরঞ্জামটির অ।

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

ডাউনলোড করতে নির্দ্বিধায় এবং এটি সাহায্য করে কিনা তা দেখুন। এখানে ডাউনলোড করুন

এই সাইটে কীভাবে সরঞ্জামটি কাজ করে সে সম্পর্কে আমি একটি ব্লগও লিখেছিলাম: সামোসকিএল ব্লগগুলি

আপনাকে দিনের নায়ক বানানোর জন্য ধন্যবাদ এবং এইচটিএইচ!

পুনশ্চ. যখন এই ঝড়টি শেষ হয়ে যায়, তখন ম্যানেজমেন্টকে বলতে ভুলবেন না যে বিশেষত এই জাতীয় ডেটাবেসের জন্য তাদের ব্যাকআপ প্রক্রিয়াগুলির একটি বৃহত্তর রূপরেখা প্রয়োজন needs এই দৃশ্যের পুনরাবৃত্তি সম্পূর্ণ অগ্রহণযোগ্য! :)

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.