প্রস্তাবনা
এই ব্লগে MSSQL সার্ভারে টেবিল থেকে ডেটা ট্রানকেট এবং ডিলিট করার জন্য দায়বদ্ধ ব্যবহারকারী নির্ধারণ করার ধাপগুলো আলোচনা করা হয়েছে।
উদাহরণস্বরূপ: টেবিলটি কখন ট্রানকেট করা হয়েছে, টেবিল থেকে ডেটা কখন মুছে ফেলা হয়েছে? কে টেবিলটি ট্রানকেট করেছে এবং ডেটা মুছে ফেলেছে?
এই তথ্য সংগ্রহের কারণ
এটি জানার জন্য কেউ ইচ্ছাকৃতভাবে নাকি ভুলে ডেটা ডিলিট করেছে, যাতে দায়বদ্ধ ব্যক্তিকে শনাক্ত করে প্রতিরোধমূলক ব্যবস্থা নেওয়া যায়। আমরা গ্রাহকদের থেকে এই তথ্যের জন্য অনুরোধ পাই। ডেটা পার্জ অপারেশনের সঠিক সময় জানলে, লগ ব্যাকআপ অপারেশনের время 'stop at' ক্লজ দিয়ে ডেটা সহজে রিকভার করা যায়।
সমস্যার সারসংক্ষেপ
জানুয়ারি ৫, ২০২০ সন্ধ্যা ৫টা থেকে ৭টা মাঝপথে "dump_truncate" টেবিলটি ট্রানকেট করা হয়েছে এবং "dump_delete" টেবিল থেকে ডেটা "truncate_test" ডাটাবেস থেকে সরিয়ে ফেলা হয়েছে। সমাধান করতে হবে এমন কিছু প্রশ্ন:
- সমস্যাটি কী তা নির্ধারণ করতে হবে।
- "dump_delete" টেবিল থেকে কে ডেটা মুছে ফেলেছে?
- "dump_delete" টেবিল থেকে কতটি সারি ডিলিট করা হয়েছে?
- "dump_truncate" টেবিলটি কে ট্রানকেট করেছে?
- এই টেবিলগুলো কখন ট্রানকেট এবং ডিলিট করা হয়েছিল?
- সার্ভারে বর্তমান ব্যাকআপ শিডিউল নিম্নরূপ:
- প্রত্যেক রবিবার ফুল ব্যাকআপ নেওয়া হয়।
- প্রতিদিন দুপুর ১টা ডিফারেনশিয়াল ব্যাকআপ।
- প্রতি ১৫ মিনিটে লগ ব্যাকআপ তৈরি হয়।
পূর্বশর্তসমূহ:
- ডাটাবেস ফুল রিকভারি মোডে থাকতে হবে।
- ফুল, ডিফ এবং লগ ব্যাকআপ উপলব্ধ থাকতে হবে।
উচ্চস্তরের পদ্ধতি:
- কোন লগ ব্যাকআপে ডিলিট এবং ট্রানকেট অপারেশন আছে তা শনাক্ত করা।
- লগ ব্যাকআপ ব্যবহার করে ট্রানকেট এবং ডিলিট অপারেশনের বিবরণ শনাক্ত করা।
কোন লগ ব্যাকআপে ডিলিট ও ট্রানকেট অপারেশন আছে তা নির্ধারণ করা:
দ্রষ্টব্য: আমরা এই ধাপগুলো ডাটাবেসের একটি নতুন কপি তৈরি করে সম্পাদন করেছি।
- ২ জানুয়ারি রবিবারের ফুল ব্যাকআপ স্ট্যান্ডবাই মোডে রিস্টোর করুন।
- ৫ জানুয়ারির ডিফ ব্যাকআপ স্ট্যান্ডবাই মোডে রিস্টোর করুন।
- লগ ব্যাকআপ স্ট্যান্ডবাই মোডে রিস্টোর করুন। প্রতিটি লগ রিস্টোরের পর টেবিলের সারি গণনা করে দেখুন কোন লগ ব্যাকআপে ট্রানকেট এবং ডিলিট অপারেশনের লগ আছে।
যখন আমরা ৬টা বাজের লগ ব্যাকআপ রিস্টোর করলাম, "dump_truncate" টেবিলটি খালি ছিল এবং "dump_delete" টেবিল থেকে এন্ট্রি গায়েব ছিল। ফলে এটি নির্দেশ করে:
সন্ধ্যা ৫:৪৫ থেকে ৬টা মাঝপথে "dump_truncate" টেবিলটি ট্রানকেট করা হয়েছিল এবং "dump_delete" টেবিল থেকে ডেটা একই সাথে মুছে ফেলা হয়েছিল।
নিচের রিস্টোর কমান্ডগুলো চালাতে হবে:
লগ ব্যাকআপ ব্যবহার করে ট্রানকেট এবং ডিলিট অপারেশনের বিবরণ শনাক্ত করা:
স্টেপ ১: ৫:৪৫ থেকে ৬টা মাঝপথে অনুষ্ঠিত সকল ট্রানকেট এবং ডিলিট অপারেশনের ট্রানজ্যাকশন আইডি সংগ্রহ করা।
প্রশ্ন:
আমরা খুঁজে পেলাম যে ৫:৫০ বাজে দুটি অপারেশন, ডিলিট এবং ট্রানকেট, এক্সিকিউট হয়েছিল এবং এই অপারেশনগুলো RP Dev লগইন করেও করা হয়েছিল।
স্টেপ ২: ট্রানজ্যাকশন আইডির সাথে যুক্ত টেবিলের নাম খুঁজে বের করা।
ডিলিট অপারেশনের তথ্য পাওয়ার জন্য নিচের ধাপগুলো অনুসরণ করুন:
I) ডিলিট অপারেশনের অবজেক্ট আইডি এবং পার্টিশন আইডি নির্ধারণ করুন।
এই আউটপুট থেকে আমরা নিম্নলিখিত তথ্য অনুমান করতে পারি: Description এবং Transaction Name কলাম: ডিলিট অপারেশন সম্পাদিত হয়েছিল
- Begin Time: ডিলিট অপারেশন ২০২২/০১/০৫ ১৭:৫০:২২:৪৯৩-এ শুরু হয়েছিল।
- Login_Name: RP_DEV ডিলিট অপারেশন চালিয়েছিল।
- Lock Information: "HoBt" প্রিফিক্স দিয়ে শুরু হওয়া প্রতিটি সারি এক রো ডিলিশন নির্দেশ করে, মোট ৭ সারি।
- Object ID: ডেটা মুছে ফেলা টেবিলের সাথে যুক্ত অবজেক্ট আইডি।
- Partition Id: ডেটা ডিলিট করা অবজেক্টের পার্টিশন আইডি।
II) অবজেক্ট আইডি এবং পার্টিশন আইডি ধারণকারী টেবিল খুঁজে বের করুন।
প্রশ্ন:
এখন আমরা অনুমান করতে পারি যে "dump_delete" থেকে ডেটা RP DEV ইউজার দ্বারা ৫:৫০ বাজে ট্রানজ্যাকশন আইডি '0000:00016a96'-এর অধীনে সরানো হয়েছিল এবং মোট ৭ সারি ডিলিট করা হয়েছিল।
ট্রানকেট অপারেশনের তথ্য পাওয়ার জন্য নিচের ধাপগুলো অনুসরণ করুন:
I) ট্রানকেট অপারেশনের অবজেক্ট আইডি এবং পার্টিশন আইডি নির্ধারণ করুন।
আউটপুট:
এখন আমরা অনুমান করতে পারি যে "dump_delete" থেকে ডেটা RP DEV ইউজার দ্বারা ৫:৫০ বাজে ট্রানজ্যাকশন আইডি '0000:00016a96'-এর অধীনে সরানো হয়েছিল এবং মোট ৭ সারি ডিলিট করা হয়েছিল। (দ্রষ্টব্য: оригиনাল টেক্সটে এখানে পুনরাবৃত্তি আছে, সম্ভবত কপি-পেস্ট এরর। নিচে ট্রানকেটের জন্য সঠিক তথ্য দেওয়া হলো।)
ট্রানকেট অপারেশনের তথ্য পাওয়ার জন্য নিচের ধাপগুলো অনুসরণ করুন:
I) ট্রানকেট অপারেশনের অবজেক্ট আইডি এবং পার্টিশন আইডি নির্ধারণ করুন।
প্রশ্ন:
আউটপুট
ট্রানকেট অপারেশনের আউটপুট ডিলিট অপারেশন থেকে কিছুটা আলাদা।
Partition ID কলাম: এটি সঠিক পার্টিশন আইডি প্রদর্শন করছে না। এই তথ্য ডেসক্রিপশন কলামে পাওয়া যায়। পার্টিশন আইডি হাইলাইট করা আছে। পার্টিশন আইডিগুলো হলো 72057594043564032 এবং 72057594043629568।
Lock Description: লক ডেসক্রিপশনে সবসময় SCH_M_OBJECT row সঠিক অবজেক্ট আইডি দেখায়। অবজেক্ট আইডি: 885578193।
অবজেক্ট আইডি এবং পার্টিশন আইডি ধারণকারী টেবিল খুঁজে বের করুন।
প্রশ্ন:
আউটপুট
এখন আমরা প্রতিষ্ঠা করতে পারি যে "dump_truncate" ৫:৫০ বাজে RP_DEV ইউজার দ্বারা ট্রানজ্যাকশন আইডি '0000:00016a95'-এর অধীনে ট্রানকেট করা হয়েছিল।
উপসংহার
ঔডিটিং সক্ষম না থাকলে ডেটায় ট্রানকেট এবং ডিলিট অপারেশন কে করল সেটি জানা ভবিষ্যতে এটি পুনরাবৃত্তি নিরোধে সহায়ক। ডিলিট অপারেশনের ক্ষেত্রে ব্যবসায়িক দিক থেকে কত সারি মুছে ফেলা হয়েছে তা জানা যায়। রিকভারির জন্য সঠিক সময় জানা ডেটা রিকভারিতে খুব সাহায্যকর। এছাড়া ApexSQL Log এবং ApexSQL Recover போன்ற থার্ড-পার্টি টুলও ডেটা রিকভারির জন্য ব্যবহার করা যাবে। এই টুলগুলোর সম্পর্কে জানতে এই লিঙ্কটি দেখুন:
আমাদের এক্সপার্টরা আপনার নেক্সট জেন ডেটা প্ল্যাটফর্ম যাত্রায় গাইড করবেন।
মন্তব্য বা প্রশ্নের জন্য Feedback ট্যাব ব্যবহার করুন। আপনি আমাদের সাথে কথা বলতে পারেন।
