Oracle ক্যাপাসিটি প্ল্যানিং: UNDO, TEMP, Redo ও ব্যাকআপ স্টোরেজ কীভাবে সাইজ করবেন

আমার নেওয়া প্রায় প্রতিটি "ডেটাবেজ ডাউন" কল কোনো-না-কোনো এমন স্পেসে গিয়ে ঠেকেছে যেটা কেউ ইচ্ছা করে সাইজ করেনি। archived-redo গন্তব্য ভরে archiver থেমে গেছে; একটি undo ট্যাবলস্পেস মাস-শেষের রিপোর্টের জন্য ছোট ছিল; একটি TEMP ট্যাবলস্পেস কোয়ার্টার-শেষের sort ধরে রাখতে পারেনি; একটি ব্যাকআপ এরিয়া ভরে জব ফেল করতে শুরু করেছে। এগুলোর একটিও বিরল বাগ নয় — এগুলো এমন ক্যাপাসিটি সিদ্ধান্ত যা ইচ্ছা করে না নিয়ে ডিফল্টে ছেড়ে দেওয়া হয়েছিল। এই গাইড আপনাকে দেয় Oracle ডেটাবেজের যে অংশগুলো আসলে ফুরিয়ে যায় — UNDO, TEMP, redo ও archived redo, এবং RMAN ব্যাকআপ / Fast Recovery Area — সেগুলো সাইজ করার একটি বাস্তব, গণিত-ভিত্তিক উপায়; সাথে datafile গ্রোথ পূর্বাভাস ও এমন মনিটরিং যাতে আপনি আর কখনো চমকে না যান।

১. ক্যাপাসিটি প্ল্যানিং একটি নির্ভরযোগ্যতার সমস্যা, স্টোরেজের কাজ নয়

সাইজিংকে এককালীন ক্রয়ের প্রশ্ন — "কত ডিস্ক কিনব?" — ভেবে ভুলে যাওয়া সহজ। কিন্তু Oracle-এ যে উপাদানগুলো ভরে যায় সেগুলো ভদ্রভাবে ফেল করে না। archived-redo গন্তব্য ভরলে ডেটাবেজ ধীর হয় না; এটি থেমে যায়, কারণ archive না-হওয়া online redo log ওভাররাইট করতে Oracle রাজি নয়। UNDO রিটেনশন মেটাতে না পারলে দীর্ঘ রিপোর্ট ORA-01555-এ মারা যায়। TEMP ফুরালে একটি sort ORA-01652-এ ফেল করে এবং কোয়েরিটি — প্রায়ই একটি গুরুত্বপূর্ণ কোয়েরি — শেষ হতে পারে না। প্রতিটিই স্টোরেজ-সংখ্যার ছদ্মবেশে একটি নির্ভরযোগ্যতার ঘটনা।

এ কারণেই আমি ক্যাপাসিটিকে RAC ও Data Guard-এর পাশে availability ইঞ্জিনিয়ারিংয়ের অংশ ধরি। সুখবর: অনেক availability সমস্যার তুলনায় ক্যাপাসিটি অত্যন্ত পূর্বানুমেয়। আপনি ইনপুট মাপতে পারেন, একটি সূত্র প্রয়োগ করতে পারেন, হেডরুম যোগ করতে পারেন, এবং প্রবণতা মনিটর করতে পারেন। একবার ঠিকমতো করলে, এটি সবচেয়ে বাজে ধরনের আউটেজ — নীরব, ধীরে-জমা-হওয়াটা — একটি রুটিন, নির্ধারিত ক্রয়ে পরিণত করে।

২. যে পাঁচটি জিনিস আসলে ফুরিয়ে যায়

সূত্রের আগে ম্যাপটা দেখুন। বেশিরভাগ Oracle স্পেস ঘটনা ঠিক এই বালতিগুলোর একটিতে পড়ে, আর প্রতিটির নিজস্ব মাপা, সাইজ করা ও মনিটর করার উপায় আছে:

নতুন সিস্টেমের জন্য এই ক্রমে কাজ করুন, আর পুরনো সিস্টেমে নির্দিষ্ট সময় পরপর এগুলো পুনরায় দেখুন। গাইডের বাকি অংশ প্রতিটি নিয়ে আলাদা কথা বলে।

৩. UNDO সাইজিং — গণিত, শিল্প নয়

UNDO পরিবর্তিত ডেটার "আগের" ইমেজ ধরে রাখে যাতে ট্রানজেকশন rollback করতে পারে এবং — আরও বেশি ক্ষেত্রে — দীর্ঘ কোয়েরি একটি কনসিস্টেন্ট পয়েন্ট-ইন-টাইম ভিউ দেখতে পারে। এর সাইজ একটি পরিষ্কার সূত্রে নিয়ন্ত্রিত:

UNDO size = UNDO_RETENTION (sec) × undo_blocks_per_sec × DB_BLOCK_SIZE

যে একমাত্র ইনপুট আপনাকে মাপতে হয় তা হলো undo জেনারেশন রেট, আর Oracle সেটি দশ-মিনিটের বাকেটে রেকর্ড করে রাখে:

-- Peak and average undo generation, and your longest query
SELECT ROUND(MAX(undoblks/((end_time-begin_time)*86400))) AS peak_ups,
       ROUND(AVG(undoblks/((end_time-begin_time)*86400))) AS avg_ups,
       MAX(maxquerylen)                                    AS longest_query_sec
FROM   v$undostat;

UNDO_RETENTION আপনার দীর্ঘতম কোয়েরির উপরে হেডরুমসহ সেট করুন, তারপর ট্যাবলস্পেস এমনভাবে সাইজ করুন যাতে গণিতটা আসলেই মানা হয় — ট্যাবলস্পেস সূত্রের চাহিদার চেয়ে ছোট হলে রিটেনশন সেটিংয়ের বদলে একটা ইচ্ছা মাত্র। রিড কনসিস্টেন্সি, ORA-01555 ও RETENTION GUARANTEE ট্রেড-অফের পূর্ণ আলোচনার জন্য দেখুন undo, redo ও ORA-01555 গাইড। সংখ্যাটির জন্য আপনার পিক রেট, রিটেনশন ও ব্লক সাইজ সাইজিং ক্যালকুলেটরে দিন আর উত্তর পড়ুন।

৪. TEMP সাইজিং — পিক সাইজ করুন, তারপর যাচাই

TEMP সেখানে যেখানে Oracle মেমরিতে না-আঁটা কাজ ফেলে: বড় sort, hash join, বড় row source-এ ORDER BY ও GROUP BY, global temporary table ও index build। এটি একক সূত্রকে প্রতিরোধ করে কারণ এর চাহিদা পুরোপুরি concurrency নিয়ে — একটি ডেটাবেজ মাসের পর মাস ছোট TEMP-এ সুখে চলতে পারে, তারপর যে রাতে তিনটি ভারী রিপোর্ট একসাথে চলে সেই একরাতে সেটি ফুরিয়ে যায়। বাস্তব উপায় হলো সেই ওভারল্যাপের জন্য সাইজ করা:

TEMP ≈ largest_work_area × concurrent_heavy_sessions × (1 + headroom)

তারপর বাস্তবতার সাথে যাচাই করুন। আসল পিকে — মাস-শেষ, কোয়ার্টার-শেষ, বড় ওভারনাইট ব্যাচ — কে আসলে TEMP ব্যবহার করছে দেখুন:

-- Live TEMP usage by session, largest first
SELECT s.sid, s.username, u.tablespace,
       ROUND(u.blocks * ts.block_size/1024/1024) AS mb_used,
       u.segtype
FROM   v$tempseg_usage u
JOIN   v$session       s  ON s.saddr = u.session_addr
JOIN   dba_tablespaces ts ON ts.tablespace_name = u.tablespace
ORDER  BY u.blocks DESC;

সংখ্যার মতোই গুরুত্বপূর্ণ দুটি ডিজাইন নিয়ম। প্রথমত, TEMP autoextend দিয়ে কিন্তু দৃঢ় MAXSIZE দিয়ে কনফিগার করুন, যাতে একটি runaway sort ডিস্ক ভরে পুরো ইনস্ট্যান্স নামিয়ে দিতে না পারে। দ্বিতীয়ত, মনে রাখুন উদার PGA_AGGREGATE_TARGET আরও sort মেমরিতে রাখে ও TEMP চাহিদা কমায় — কখনো কখনো TEMP চাপ সমাধানের সবচেয়ে সস্তা উপায় ডিস্ক কেনা নয়, PGA টিউন করা। ক্যালকুলেটরের TEMP ট্যাব যাচাইয়ের শুরুর সংখ্যাটি দেয়।

৫. Redo ও archived redo সাইজিং

Redo হলো সেই পরিবর্তন-লগ যা রিকভারি সম্ভব করে, আর archived redo হলো সেই স্ট্রিম যা RMAN-এর point-in-time রিকভারির জন্য দরকার। দুটি প্রশ্ন আপনার সাইজিং ঠিক করে। প্রথমত, online redo log কি যথেষ্ট বড় যাতে গ্রুপগুলো স্বাস্থ্যকর ছন্দে সুইচ করে — পিকে মোটামুটি ১৫ থেকে ৩০ মিনিটে একবার, ৯০ সেকেন্ডে নয়? অবিরাম সুইচিং মানে ছোট log ও checkpoint চাপ:

-- Log switches per hour over the last two days
SELECT TO_CHAR(first_time,'YYYY-MM-DD HH24') AS hour, COUNT(*) AS switches
FROM   v$log_history
WHERE  first_time > SYSDATE - 2
GROUP  BY TO_CHAR(first_time,'YYYY-MM-DD HH24')
ORDER  BY hour;

দ্বিতীয়ত — এবং এটিই ক্যাপাসিটির প্রশ্ন — আপনি প্রতিদিন কত archived redo তৈরি করেন? এই সংখ্যা আপনার archive গন্তব্য এবং, যেমন দেখব, ব্যাকআপ এরিয়ার একটি বড় অংশ চালায়:

-- Archived redo volume per day (GB)
SELECT TO_CHAR(completion_time,'YYYY-MM-DD') AS day,
       ROUND(SUM(blocks*block_size)/1024/1024/1024,1) AS gb
FROM   v$archived_log
WHERE  completion_time > SYSDATE - 14
GROUP  BY TO_CHAR(completion_time,'YYYY-MM-DD')
ORDER  BY day;

Redo ভলিউম প্রায় সবসময় পরিবর্তিত ডেটার ভলিউম ছাড়িয়ে যায়, কারণ index maintenance, অনেক ব্লক ছোঁয়া update, ও reorganization সব রো-পরিবর্তনের অনুপাতের বাইরে redo তৈরি করে। এ কারণেই নিচের ব্যাকআপ অনুমান archived redo-কে raw চেঞ্জ রেটের চেয়ে বড় একটি আলাদা লাইন হিসেবে ধরে।

৬. RMAN ব্যাকআপ ও Fast Recovery Area সাইজিং

ব্যাকআপ এরিয়া সেখানে যেখানে ভালো উদ্দেশ্য একটি কঠিন মেঝেতে ধাক্কা খায়: আপনার রিকভারি উইন্ডো মেটাতে যা যা দরকার তা শারীরিকভাবে ধরে রাখতে হবে — অর্থাৎ কত দিন পেছন পর্যন্ত রিস্টোর করতে পারতে হবে। তিনটি অংশ যোগ হয়:

• Full ব্যাকআপ। উইন্ডোর চেয়ে অন্তত একটি পুরনো full প্লাস বর্তমান দরকার, প্রতিটি RMAN কম্প্রেশন ও খালি ব্লক বাদ দেওয়ায় ছোট।
• Incremental ব্যাকআপ। মোটামুটি আপনার দৈনিক পরিবর্তিত ডেটা, কম্প্রেসড, উইন্ডোজুড়ে জমা (সাপ্তাহিক-full কৌশলে)।
• Archived redo। সবচেয়ে পুরনো রাখা ব্যাকআপের পর থেকে সব — সাধারণত সবচেয়ে বড় একক লাইন, আগের সেকশন অনুযায়ী।

সাপ্তাহিক-full-প্লাস-দৈনিক-incremental কৌশলের একটি কনজারভেটিভ অনুমান দেখতে এমন:

FRA ≈ (fulls_kept × compressed_full)
    + (daily_change × compression_factor × retention_days)
    + (daily_archive × compression_factor × retention_days)
    + control-file / spfile autobackup-এর ছোট মার্জিন

DB_RECOVERY_FILE_DEST_SIZE মোটের যথেষ্ট উপরে সেট করুন, একটি CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS দিন, এবং DELETE OBSOLETE-কে স্পেস ফেরত নিতে দিন। যে সংখ্যাটা কখনো কমাবেন না তা হলো মার্জিন: FRA ফুরালে archiver থামে ও ডেটাবেজ হ্যাং করে। সম্পূর্ণ ব্যাকআপ-রিকভারি পদ্ধতি RMAN ব্যাকআপ ও রিকভারি গাইডে; স্টোরেজ সংখ্যাটির জন্য ক্যালকুলেটরের RMAN ট্যাব তিনটি লাইনই আপনার ডেটাবেজ সাইজ, চেঞ্জ রেট ও উইন্ডো থেকে অনুমান করে।

৭. Datafile গ্রোথ পূর্বাভাস

উপরের চারটি উপাদান steady-state অপারেশন নিয়ে; datafile সাইজিং ভবিষ্যৎ নিয়ে। সবচেয়ে বেশি যে ভুল দেখি তা হলো আজকের ডেটার জন্য datafile সাইজ করে আট মাস পর চমকে যাওয়া। সমাধান হলো গ্রোথ প্রবণতা মেপে প্রক্ষেপণ করা। একটি সহজ, নির্ভরযোগ্য উপায় হলো সময়ের সাথে মোট segment সাইজ ট্র্যাক করে মাসিক ডেল্টা বের করা:

-- Total used size per tablespace (run and record monthly, or trend from AWR)
SELECT tablespace_name,
       ROUND(SUM(bytes)/1024/1024/1024,1) AS used_gb
FROM   dba_segments
GROUP  BY tablespace_name
ORDER  BY used_gb DESC;

যদি একটি schema মাসে ২০ GB বাড়ে এবং এক বছর স্টোরেজ ছুঁতে না হয়, তবে আজকের ফুটপ্রিন্টের উপরে অন্তত ২৪০ GB রানওয়ে দরকার — প্লাস অনিবার্য ডেটা-লোডিং স্পাইকের হেডরুম। datafile autoextend ও যুক্তিসঙ্গত MAXSIZE দিয়ে কনফিগার করুন যাতে স্বল্পমেয়াদি স্পাইক স্বয়ংক্রিয়ভাবে শোষিত হয়, কিন্তু autoextend-কে shock absorber ভাবুন, ক্যাপাসিটি প্ল্যান নয়: একটি datafile নীরবে autoextend হয়ে ডিস্ক ভরানো একই আউটেজের ধীর সংস্করণ মাত্র। ডিস্ক প্রবণতা অনুযায়ী প্ল্যান করুন; autoextend-কে গোলমাল সামলাতে দিন।

৮. মনিটরিং, যাতে আর কখনো চমকে না যান

সাইজিং একটি স্ন্যাপশট; মনিটরিং সেটিকে সত্য রাখে। তিনটি অ্যালার্ট বেশিরভাগ স্পেস আউটেজ ঠেকায়, আর তিনটিই আরামদায়ক লিড টাইম নিয়ে ফায়ার করা উচিত — ৯৯%-এ নয়। tablespace ব্যবহার, undo ফ্রি স্পেস, এবং সবচেয়ে বেশি FRA দেখুন:

-- Fast Recovery Area usage — alert well before this climbs high
SELECT name,
       ROUND(space_limit/1024/1024/1024,1)            AS limit_gb,
       ROUND(space_used/1024/1024/1024,1)             AS used_gb,
       ROUND(space_used/NULLIF(space_limit,0)*100,1)  AS pct_used
FROM   v$recovery_file_dest;

-- Tablespace usage percentage
SELECT tablespace_name,
       ROUND(used_percent,1) AS pct_used
FROM   dba_tablespace_usage_metrics
ORDER  BY used_percent DESC;

যে থ্রেশহোল্ড গুরুত্বপূর্ণ তা হলো লিড টাইম, শতাংশ নয়। একটি tablespace মাসে ২০ GB বাড়লে ৮০%-এ অ্যালার্ট আপনাকে সপ্তাহ দিতে পারে; ডেটা-লোডিংয়ের এক খারাপ বিকেলে সেটি ২০ GB বাড়তে পারলে ৮০% দেয় এক বিকেল। জিনিসটা কত দ্রুত ভরতে পারে তা দিয়ে থ্রেশহোল্ড সেট করুন, তাহলে পেজার অ্যালার্টের আগেই ক্রয়াদেশ সই করাতে পারবেন। নিয়মিত ডেটাবেজ হেলথ চেক এই প্রবণতা পর্যালোচনার স্বাভাবিক জায়গা।

৯. একটি বাস্তব উদাহরণ: নতুন ৮০০ GB ফার্মা ERP ডেটাবেজ সাইজিং

একটি সত্যিকারের go-live-এর মতো করে সব একসাথে সাজাই। একটি ফার্মাসিউটিক্যাল ক্লায়েন্ট একটি ৮০০ GB (used) Oracle ডেটাবেজে ERP চালু করছে, ৮ KB ব্লক সাইজ, ২১-দিনের রিকভারি উইন্ডো ও ভ্যালিডেটেড ব্যাকআপ প্রয়োজন। শুরু থেকে শেষ পর্যন্ত যুক্তি এখানে।

UNDO। শুরুর লোড টেস্টিং দেখায় পিক undo রেট প্রায় ৪০০ ব্লক/সেকেন্ড ও দীর্ঘতম রিপোর্টিং কোয়েরি ৫০ মিনিটের কাছাকাছি। আমি UNDO_RETENTION ৪,৮০০ সেকেন্ড (৮০ মিনিট, হেডরুমসহ) সেট করি এবং UNDO সাইজ করি ৪০০ × ৪,৮০০ × ৮ KB ≈ ১৫ GB, আরাম ও ভবিষ্যৎ গ্রোথের জন্য ২০ GB-তে রাউন্ড করি।

TEMP। সবচেয়ে ভারী মাস-শেষ costing রিপোর্ট প্রতিটি প্রায় ৪ GB work area ব্যবহার করে, এবং close-এর সময় ছয়টি পর্যন্ত ওভারল্যাপ করতে পারে। সেটি ৪ × ৬ = ২৪ GB পিক; ৫০% হেডরুমসহ আমি একটি ৪০ GB TEMP ট্যাবলস্পেস দিই, autoextend চালু, MAXSIZE ডিস্ক সীমার নিচে ক্যাপ করা।

Redo/archive। লোড টেস্টিংয়ের চেঞ্জ ট্র্যাকিং steady state-এ দিনে প্রায় ৪০ GB archived redo দেখায়, ডেটা মাইগ্রেশনে বেশি, তাই আমি archive পাথ সাইজ করি ও ব্যাকআপ গণিতে ৪০ GB/দিন ধরি।

Backup / FRA। সাপ্তাহিক full প্লাস দৈনিক incremental, ৪০% কম্প্রেশন সেভিং, ৩% দৈনিক চেঞ্জ রেট ও ২১-দিন উইন্ডো নিয়ে: তিনটি কম্প্রেসড full, উইন্ডোজুড়ে incrementals, এবং ২১ দিনের কম্প্রেসড archived redo। ক্যালকুলেটর এটিকে low-terabyte-এ নামায়; আমি DB_RECOVERY_FILE_DEST_SIZE এর উপরে মার্জিনসহ ও একটি ২১-দিন recovery-window পলিসি সেট করি।

Datafiles। ব্যবসা বছর-এক-এ মাসে ২৫ GB গ্রোথ প্রক্ষেপণ করে। আজকের ৮০০ GB-র উপরে সেটি ৩০০ GB রানওয়ে, তাই আমি datafile ও অন্তর্নিহিত ASM স্টোরেজ প্রায় ১.২ TB-র জন্য দিই, autoextend shock absorber হিসেবে। এই প্রতিটি সংখ্যা একটি ভ্যালিডেশন ডকুমেন্টে যুক্তিযুক্ত — যা একটি নিয়ন্ত্রিত ফার্মা পরিবেশে ঐচ্ছিক নয়।

১০. সাধারণ ক্যাপাসিটি-প্ল্যানিং ভুল

• autoextend-কে প্ল্যান ভাবা। autoextend স্পাইক শোষণ করে; কত ডিস্ক দরকার তা ঠিক করে না। সীমাহীন রাখলে এটি একটি tablespace সমস্যাকে পুরো-ডিস্ক সমস্যায় বদলে দেয় যা পুরো ইনস্ট্যান্স নামায়।
• UNDO বা TEMP গড়ের জন্য সাইজ করা। দুটিই পিকে ফেল করে — ওভারল্যাপিং রিপোর্ট, মাস-শেষ sort। দৈনিক গড় নয়, সবচেয়ে খারাপ বাস্তব concurrency-র জন্য সাইজ করুন।
• ব্যাকআপ গণিতে archived redo ভুলে যাওয়া। FRA সাধারণত full ব্যাকআপ নয়, archive-এ প্রভাবিত। অনুমান নয়, V$ARCHIVED_LOG থেকে মাপুন।
• নির্দিষ্ট শতাংশে অ্যালার্ট করা। ধীর-বাড়া বনাম স্পাইকি tablespace-এ ৯০% খুব ভিন্ন লিড টাইম মানে। শতাংশ নয়, time-to-full দিয়ে অ্যালার্ট করুন।
• কখনো পুনরায় না দেখা। go-live-এ সাইজ করা প্ল্যান প্রথম নতুন মডিউল বা ইউজার সার্জের পর বাসি। মাসে গ্রোথ ট্রেন্ড করুন ও বড় পরিবর্তনের পর পুনরায় সাইজ করুন।

এর প্রতিটি সামনে থেকে এড়ানো সস্তা এবং প্রোডাকশনে ঘটলে ব্যয়বহুল। ক্যাপাসিটি সেই কম কয়েকটি ক্ষেত্রের একটি যেখানে কয়েক ঘণ্টার গণিত সত্যিই আপনাকে নিরবচ্ছিন্ন রাতের ঘুম কিনে দেয়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Oracle ক্যাপাসিটি প্ল্যানিং কী?

Oracle ক্যাপাসিটি প্ল্যানিং হলো একটি ডেটাবেজের প্রয়োজনীয় স্টোরেজ এমনভাবে সাইজ করা যাতে স্পেস ফুরিয়ে না গিয়ে নির্ভরযোগ্যভাবে চলে: ডেটা গ্রোথের জন্য datafile, রিড কনসিস্টেন্সির জন্য UNDO, sort/hash-এর জন্য TEMP, রিকভারির জন্য redo ও archived redo, এবং রিকভারি উইন্ডোর জন্য RMAN ব্যাকআপ এরিয়া। এটি আসল সংখ্যা থেকে গণিত, মনিটরিং দিয়ে যাচাই করা।

UNDO ট্যাবলস্পেস সাইজ কীভাবে হিসাব করব?

UNDO size = UNDO_RETENTION × undo_blocks_per_sec × DB_BLOCK_SIZE। পিক undo রেট V$UNDOSTAT থেকে নিন, ১৫–৩০% হেডরুম যোগ করুন, এবং সেট করা রিটেনশন মেটাতে ট্যাবলস্পেস যথেষ্ট বড় করুন।

Oracle-এ TEMP ট্যাবলস্পেস কত বড় হওয়া উচিত?

একক সূত্র নেই। সবচেয়ে বড় work area × পিকে একসাথে চলা ভারী সেশন + হেডরুম দিয়ে সাইজ করুন, তারপর V$TEMPSEG_USAGE ও V$SORT_USAGE দিয়ে যাচাই করুন এবং autoextend + MAXSIZE ব্যবহার করুন।

RMAN ব্যাকআপ স্টোরেজ ও FRA কীভাবে সাইজ করব?

রিকভারি উইন্ডোর জন্য রাখা full, incrementals, ও উইন্ডোজুড়ে archived redo যোগ করুন — প্রতিটি কম্প্রেশনে কমে। মোটের উপরে DB_RECOVERY_FILE_DEST_SIZE সেট করুন ও V$RECOVERY_FILE_DEST মনিটর করুন।

FRA-তে স্পেস ফুরালে কী হয়?

FRA ভরলে Oracle redo archive করতে পারে না, archiver থামে, ও স্পেস মুক্ত না হওয়া পর্যন্ত ডেটাবেজ হ্যাং করে — ক্লাসিক রাত ৩টার আউটেজ। অনুমানের উপরে সাইজ করে, DELETE OBSOLETE-সহ recovery-window পলিসি দিয়ে, ও আগেভাগে অ্যালার্ট দিয়ে ঠেকান।

Oracle ক্যাপাসিটি কত ঘনঘন পর্যালোচনা করা উচিত?

মাসে গ্রোথ প্রবণতা দেখুন এবং যেকোনো বড় পরিবর্তনের পর সাইজিং পুনরায় দেখুন: নতুন মডিউল, ডেটা মাইগ্রেশন, ইউজার সার্জ, বা রিটেনশন পলিসি পরিবর্তন। tablespace, undo ও FRA-র অবিরাম মনিটরিং সবসময় চলা উচিত যাতে ধীর গ্রোথ আউটেজ হওয়ার অনেক আগে ধরা পড়ে।