আমাদের কাছে একটি খুব বড় ডাটাবেস (~ 6TB) রয়েছে, যার লেনদেনের লগ ফাইলটি মুছে ফেলা হয়েছিল (এসকিউএল সার্ভারটি বন্ধ থাকা অবস্থায় We আমরা চেষ্টা করেছি:
- ডেটাবেস ডিটাচিং এবং রিটাচিং; এবং
- লেনদেনের লগ ফাইলটি মুছে ফেলা হচ্ছে
... তবে এখনও পর্যন্ত কিছুই কাজ করেনি।
আমরা বর্তমানে চলছে:
ALTER DATABASE <dbname> REBUILD
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')
... তবে ডাটাবেসের আকার দিলে সম্ভবত এটি কয়েক দিন সময় নিতে পারে।
প্রশ্নাবলি
উপরের কমান্ড এবং নীচের একটি পার্থক্য আছে?
DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)
আমরা কি
REPAIR_ALLOW_DATA_LOSS
পরিবর্তে মৃত্যুদণ্ড কার্যকর করা উচিত?
এটি লক্ষণীয় যে ডেটাটি অন্যান্য উত্স থেকে উত্পন্ন হয়েছে যাতে ডাটাবেসটি পুনর্নির্মাণ করা যায়, তবে আমরা সন্দেহ করি যে সমস্ত ডেটা পুনরায় প্রবেশের চেয়ে ডাটাবেসটি মেরামত করা আরও দ্রুত হবে।
হালনাগাদ
স্কোর রাখার জন্য: ALTER DATABASE/REBUILD LOG
কমান্ডটি প্রায় 36 ঘন্টা পরে সম্পন্ন হয়েছে এবং রিপোর্ট করেছে:
সতর্কতা: ডাটাবেস 'dbname' জন্য লগ পুনর্নির্মাণ করা হয়েছে। লেনদেনের ধারাবাহিকতা হারিয়ে গেছে। রেস্টোর চেইনটি নষ্ট হয়ে গেছে, এবং সার্ভারের আর আগের লগ ফাইলগুলির প্রসঙ্গ নেই, সুতরাং সেগুলি কী ছিল তা আপনার জানতে হবে।
শারীরিক ধারাবাহিকতা যাচাই করতে আপনার ডিবিসিসি CHECKDB চালানো উচিত। ডাটাবেসটি ডিবো-কেবল মোডে রাখা হয়েছে। আপনি যখন ডেটাবেসকে ব্যবহারের জন্য উপলব্ধ করতে প্রস্তুত হবেন তখন আপনাকে ডাটাবেস বিকল্পগুলি পুনরায় সেট করতে হবে এবং কোনও অতিরিক্ত লগ ফাইল মুছতে হবে।
এরপরে আমরা একটি DBCC CHECKDB
চালিয়েছি (প্রায় 13 ঘন্টা) যা সফল হয়েছিল। আসুন আমরা কেবল এটিই বলি যে আমরা সকলেই ডেটাবেস ব্যাকআপের গুরুত্ব (এবং প্রোজেক্ট ম্যানেজারগুলিকে সার্ভারে অ্যাক্সেস দেওয়ার ...) শিখেছি।