একজন কর্মরত Oracle DBA হিসেবে আমি যে তিনটি ক্যালকুলেটর ব্যবহার করি: রিটেনশন টার্গেট থেকে UNDO ট্যাবলস্পেস সাইজ করুন, TEMP-এর একটা শুরুর হিসাব পান, এবং ডেটাবেজ সাইজ, চেঞ্জ রেট ও রিকভারি উইন্ডো থেকে RMAN ব্যাকআপ / Fast Recovery Area স্টোরেজ পরিকল্পনা করুন। সবকিছু আপনার ব্রাউজারেই চলে — কোনো ডেটা কোথাও পাঠানো হয় না।
Oracle-এর নিজস্ব গাইডলাইন তিনটি জিনিস থেকে undo সাইজ করে: কতক্ষণ undo রাখতে হবে (UNDO_RETENTION), ডেটাবেজ কত দ্রুত undo তৈরি করে (undo ব্লক প্রতি সেকেন্ড), এবং ব্লক সাইজ:
UNDO size = UNDO_RETENTION × undo_blocks_per_sec × DB_BLOCK_SIZE
আসল undo রেট পেতে V$UNDOSTAT কোয়েরি করুন (প্রতিটি রো ~১০-মিনিটের স্ন্যাপশট):
SELECT MAX(undoblks / ((end_time - begin_time) * 86400)) AS peak_ups
FROM v$undostat;
পিক মানটি ক্যালকুলেটরে দিন, একটি সেফটি বাফার রাখুন, এবং Flashback Query-র উপর নির্ভর করলে ট্যাবলস্পেসে RETENTION GUARANTEE লাগাতে পারেন — তবে মনে রাখুন এটি অপ্রত্যাশিতভাবে unexpired undo ওভাররাইট না করে বরং ORA-30036 দিয়ে ট্রানজেকশন ফেল করাবে, তাই হেডরুম দরকার। বারবার ORA-01555 "snapshot too old" পেলে বুঝবেন রিটেনশন বা ট্যাবলস্পেস আপনার দীর্ঘতম কোয়েরির তুলনায় ছোট। (এ নিয়ে বিস্তারিত লিখেছি undo, redo ও ORA-01555 গাইডে।)
TEMP-কে একটিমাত্র সূত্রে বাঁধা কঠিন, কারণ এটি পুরোপুরি ওয়ার্কলোড-নির্ভর — বড় sort, hash join, global temporary table ও index rebuild সবই TEMP থেকে টানে। বাস্তব পরিকল্পনার উপায় হলো একটি ভারী কোয়েরির সবচেয়ে বড় work area-কে একসাথে চলা এমন কোয়েরির সংখ্যা দিয়ে গুণ করে হেডরুম যোগ করা:
TEMP ≈ max_work_area × concurrent_heavy_sessions × (1 + headroom)
ফলাফলটিকে একটি floor ধরুন, চূড়ান্ত সত্য নয়। আসল পিকে (মাস-শেষের রিপোর্ট, বড় ব্যাচ জব, index maintenance) V$TEMPSEG_USAGE ও V$SORT_USAGE দেখুন, এবং TEMP autoextend + দৃঢ় MAXSIZE দিয়ে কনফিগার করুন যাতে একটি runaway sort পুরো ডিস্ক ভরে ফেলতে না পারে।
আপনার Fast Recovery Area-কে রিকভারি উইন্ডো মেটানোর মতো যথেষ্ট ধরে রাখতে হবে — অর্থাৎ কত দিন পেছন পর্যন্ত রিস্টোর করতে হতে পারে। ক্যালকুলেটর তিনটি অংশ যোগ করে:
DB_RECOVERY_FILE_DEST_SIZE অনুমানের যথেষ্ট উপরে রাখুন, একটি RECOVERY WINDOW OF n DAYS রিটেনশন পলিসি রাখুন, এবং DELETE OBSOLETE দিয়ে স্পেস ফেরত নিন। FRA ছোট রাখা একটি ক্লাসিক ৩টা-রাতের আউটেজ — archiver থেমে যায়, ডেটাবেজ হ্যাং করে। সম্পূর্ণ ব্যাকআপ-রিকভারি প্লেবুকের জন্য দেখুন RMAN ব্যাকআপ ও রিকভারি গাইড।
আপনার undo রিটেনশন টার্গেট (সেকেন্ডে) × পিক undo ব্লক প্রতি সেকেন্ড × ডেটাবেজ ব্লক সাইজ গুণ করুন: UNDO size = UNDO_RETENTION × undo_blocks_per_sec × DB_BLOCK_SIZE। undo রেট V$UNDOSTAT থেকে নিন, ১৫–৩০% সেফটি বাফার যোগ করুন, এবং UNDO_RETENTION আপনার টার্গেটে সেট করুন। এই ক্যালকুলেটর হিসাবটি করে দেয়।
UNDO_RETENTION অন্তত আপনার দীর্ঘতম কোয়েরি বা দরকারি সবচেয়ে পেছনের Flashback Query-র সমান রাখুন। OLTP-তে ৯০০ সেকেন্ড (১৫ মিনিট) একটি সাধারণ শুরু, কিন্তু দীর্ঘ কোয়েরিসহ রিপোর্টিং/ব্যাচ সিস্টেমে অনেক বেশি লাগে। ORA-01555 "snapshot too old" দেখলে রিটেনশন বা undo ট্যাবলস্পেস আপনার কোয়েরির দৈর্ঘ্যের তুলনায় ছোট।
একটিমাত্র সূত্র নেই — TEMP একসাথে চলা sort, hash join ও GTT-র উপর নির্ভর করে। বাস্তব শুরুর বিন্দু হলো একটি ভারী কোয়েরির সবচেয়ে বড় work area × পিকে একসাথে চলা এমন কোয়েরির সংখ্যা + হেডরুম। তারপর আসল লোডে V$TEMPSEG_USAGE ও V$SORT_USAGE দিয়ে যাচাই করুন এবং autoextend + MAXSIZE ব্যবহার করুন।
রিকভারি উইন্ডোর জন্য রাখা full ব্যাকআপ, incremental (মোটামুটি দৈনিক পরিবর্তিত ডেটা), এবং উইন্ডোজুড়ে তৈরি archived redo যোগ করুন — প্রতিটি কম্প্রেশনে কমে। মোটের উপরে DB_RECOVERY_FILE_DEST_SIZE সেট করুন এবং V$RECOVERY_FILE_DEST মনিটর করুন। এই ক্যালকুলেটরের RMAN ট্যাব তিনটিই অনুমান করে।
না। তিনটি ক্যালকুলেটরই সম্পূর্ণ আপনার ব্রাউজারে সাধারণ JavaScript দিয়ে চলে। আপনি যা টাইপ করেন কিছুই আপলোড, লগ বা সংরক্ষণ হয় না — প্রোডাকশন পরিকল্পনার সংখ্যা দিয়ে নিরাপদে ব্যবহার করা যায়।
এগুলো তথ্যভিত্তিক পরিকল্পনা-অনুমান, গ্যারান্টি নয়। আসল undo, temp ও ব্যাকআপ সাইজ ব্লক ডেনসিটি, ডিলিট, redo ভলিউম ও ওয়ার্কলোড স্পাইকে পাল্টায়। ফলাফলকে যৌক্তিক শুরুর বিন্দু ধরুন, তারপর স্টোরেজ নির্ধারণের আগে নিজের ডেটাবেজের dynamic performance view দিয়ে নিশ্চিত হন।