মিশন-ক্রিটিক্যাল ডেটাবেজ কেন রাত ৩টায় ব্যর্থ হয় — এবং কীভাবে এমন একটি তৈরি করবেন যা হয় না

আপনার ডেটাবেজ অফিস সময়ে ব্যর্থ হয় না, যখন একঘর ভর্তি ইঞ্জিনিয়ার ড্যাশবোর্ড দেখছেন। এটি ব্যর্থ হয় রাত ৩টায় — একটি লম্বা ছুটির দিনে, ব্যাকআপের মাঝপথে, এমন একটি ব্যাচ জব চলাকালীন যা কেউ ডকুমেন্ট করেনি, যখন সিস্টেমটি বোঝেন এমন একজনই মানুষ ঘুমিয়ে আছেন এবং তাঁকে পাওয়া যাচ্ছে না। ব্যাংক, ফার্মাসিউটিক্যাল কোম্পানি, টেলিকম ও সরকারি সিস্টেমের জন্য ১৮+ বছর প্রোডাকশন Oracle চালিয়ে আমি শিখেছি যে একটি সিস্টেম "চালু" আর একটি সিস্টেম "নিরাপদ" — এর মধ্যে পার্থক্য প্রায় কখনওই হার্ডওয়্যার বা লাইসেন্স টিয়ার নয়। এটি সেই নিরস, চাকচিক্যহীন ইঞ্জিনিয়ারিং যা বাজেট টানাটানিতে সবার আগে কাটা পড়ে: টেস্টেড রিকভারি, বাস্তব মনিটরিং এবং এমন high availability যা আসলেই ডিজাইন করা হয়েছিল — ধরে নেওয়া নয়।

ডেটাবেজ ঠিক রাত ৩টায়ই ব্যর্থ হয় কেন?

কারণ রাত ৩টা হলো সেই সময় যখন আপনার ডেটাবেজ সবচেয়ে বেশি খাটে আর সবচেয়ে কম নজরে থাকে। রাতের ব্যাকআপ, ব্যাচ জব, ইনডেক্স রিবিল্ড, log purge এবং কেউ মনে রাখে না এমন cron জব — সব একই সংকীর্ণ জানালায় একসাথে চলে — যখন redo জেনারেশন লাফিয়ে ওঠে, ডিস্ক সবচেয়ে দ্রুত ভরে, আর একমাত্র জেগে থাকা মানুষটি একজন সিকিউরিটি গার্ড।

ভাবুন, একটি সাধারণ এন্টারপ্রাইজ শিডিউল মধ্যরাত থেকে ভোর ৫টার মধ্যে কী কী ঠেসে ঢোকায়। RMAN ব্যাকআপ শুরু হয় ১টায়। মাস-শেষের ব্যাচ পোস্টিং শুরু হয় দেড়টায়। একটি materialized-view রিফ্রেশ চালু হয় ২টায়। ২০১৯ সালে কেউ একজন লিখেছিলেন এমন একটি OS-লেভেল cron জব আড়াইটায় পুরোনো লগ gzip করে। সবগুলো একই I/O, একই temp স্পেস, একই archive destination-এর জন্য প্রতিযোগিতা করে।

এদিকে archive log destination দিনের তুলনায় তিনগুণ হারে ভরছে — কারণ ব্যাকআপ ও ব্যাচ জব বিপুল redo তৈরি করে — আর মনিটরিং থ্রেশহোল্ড সেট করা হয়েছিল দিনের আচরণের ভিত্তিতে। কেউ গ্রাফটির ওপরে ওঠা দেখছে না।

একটি নীরব কারণও আছে: রাত ৩টা হলো যখন শিডিউলড পরিবর্তনগুলো নামে। পাসওয়ার্ড রোটেশন, সার্টিফিকেট নবায়ন, OS প্যাচিং উইন্ডো, নেটওয়ার্ক মেইনটেন্যান্স। এর যেকোনো একটি এমন একটি সুতো টানতে পারে যা ঠিক সেই মুহূর্তে খুলে যায় যখন কেউ লক্ষ্য করার জন্য আশেপাশে নেই। দিনের ব্যর্থতা ধরা পড়ে মিনিটে। রাতের ব্যর্থতা ধরা পড়ে সকাল ৯টায় — আপনার ব্যবহারকারীদের হাতে।

ক্লাসিক রাত ৩টার ব্যর্থতাগুলোর অ্যানাটমি

১৮+ বছর ধরে ফোন যাকে ঘুম থেকে তোলে সেই মানুষটি হয়ে আমি বলতে পারি, রাতের-ব্যর্থতার ক্যাটালগ ছোট এবং পুনরাবৃত্ত। এখানে সেগুলো, যাদের সাথে আমার বারবার দেখা হয় — প্রতিটির গল্প ও প্রতিরোধসহ।

১. Archive destination ভরে যায় — এবং ডেটাবেজ হ্যাং করে

এটি রাত ৩টার ইনসিডেন্টের রাজা। একটি ব্যাংক ক্লায়েন্ট আতঙ্কে আমাকে ফোন করল: "ডেটাবেজ ডাউন।" এটি ডাউন ছিল না — এটি হ্যাং ছিল, প্রতিটি সেশন জমে গিয়েছিল, কারণ রাতের ব্যাকআপ চলাকালীন flash recovery area ১০০%-এ পৌঁছেছিল, আর Oracle, ডিজাইন অনুযায়ীই, জায়গা না মেলা পর্যন্ত সব redo-উৎপাদক কাজ থামিয়ে দেয়।

নিষ্ঠুর অংশটি: তাদের সার্ভার মনিটরিং সবকিছু সবুজ দেখাচ্ছিল। CPU অলস, OS ভলিউমের ডিস্ক ঠিক। FRA থাকত আলাদা একটি mount-এ যা কেউ ড্যাশবোর্ডে যোগ করেনি।

-- The two queries that would have predicted it days earlier
SELECT * FROM v$recovery_area_usage;

SELECT space_limit/1024/1024/1024 AS limit_gb,
       space_used/1024/1024/1024  AS used_gb,
       ROUND(space_used/space_limit*100,1) AS pct_used
FROM   v$recovery_file_dest;

প্রতিরোধ: db_recovery_file_dest_size-এর ৮০%-এ অ্যালার্ট দিন, FRA-কে আপনার রাতের redo রেটের জন্য সাইজ করুন (দিনের গড় নয়), এবং RMAN ব্যাকআপ যেন ইতিমধ্যে ব্যাকআপ নেওয়া archivelog মুছে ফেলে তা নিশ্চিত করুন। এই একটিমাত্র failure mode-ই একটি মনিটরিং প্রজেক্টের খরচ উসুল করে দেয়।

২. Autoextend যখন ডিস্কের কিনারায় ঠেকে

Autoextend-কে একটি নিরাপত্তা জাল মনে হয়। আসলে এটি একটি স্পেস সমস্যাকে সবচেয়ে খারাপ মুহূর্ত পর্যন্ত পিছিয়ে দেওয়ার একটি উপায় — কারণ datafile সারা মাস দিব্যি বড় হয়, তারপর রাত ৩টায় ব্যাচ লোডের সময় ফাইলসিস্টেমের কাছে পরবর্তী extent চায় আর ফাইলসিস্টেম বলে না। Insert ব্যর্থ হয়, ব্যাচ জব অর্ধেক-কমিটেড অবস্থায় মারা যায়, আর সকাল শুরু হয় একটি ডেটা-পরিষ্কার অভিযানে।

প্রতিরোধ: শুধু বর্তমান tablespace ব্যবহার নয়, সম্ভাব্য autoextension-এর মোট যোগফলের বিপরীতে ফাইলসিস্টেম-এর হেডরুম মনিটর করুন। আমি অ্যালার্ট দিই যখন ডিস্কটি তার ওপর বসে থাকা ফাইলগুলোর ২০% বৃদ্ধি ধারণ করতে পারবে না। MAXSIZE-সহ autoextend এবং একটি বাস্তব ক্যাপাসিটি ফোরকাস্ট, সীমাহীন autoextend-কে প্রতিবারই হারায়।

৩. যে পাসওয়ার্ডের মেয়াদ ফুরাল মধ্যরাতে

একটি ফার্মা ক্লায়েন্টের অর্ডার-প্রসেসিং সিস্টেম মারা গেল ঠিক ০০:০০টায়। কিছুই ক্র্যাশ করেনি। একটি সিকিউরিটি নীতি কার্যকর হয়েছিল এবং অ্যাপ্লিকেশনের ডেটাবেজ অ্যাকাউন্ট তার ১৮০ দিনের পাসওয়ার্ড মেয়াদে ঠেকেছিল — মধ্যরাতে, কারণ Oracle তখনই এটি মূল্যায়ন করে। প্রতিটি নতুন কানেকশন ব্যর্থ হলো; কানেকশন পুল শুকিয়ে গেল; ০০:২০-এর মধ্যে অ্যাপ পড়ে গেল।

-- Accounts about to bite you
SELECT username, account_status, expiry_date
FROM   dba_users
WHERE  expiry_date < SYSDATE + 30
AND    account_status = 'OPEN'
ORDER  BY expiry_date;

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

৪. যে listener নীরবে মরে গেল

ইনস্ট্যান্স নিখুঁত ছিল। সার্ভার নিখুঁত ছিল। কিন্তু listener প্রসেসটি ঘণ্টাখানেক আগে মরে গিয়েছিল — একটি OS প্যাচ নেটওয়ার্ক স্ট্যাক রিস্টার্ট করেছিল আর কেউ listener-কে ফিরে আসার জন্য কনফিগার করেনি। বিদ্যমান কানেকশনগুলো কাজ করতে থাকল, তাই মনিটরিং "টেস্ট" (একটি দীর্ঘজীবী এজেন্ট সেশন) সবুজই রইল। শুধু নতুন কানেকশন ব্যর্থ হচ্ছিল, যার মানে সকালের শিফট এটি আবিষ্কার করল, রাতেরটি নয়।

প্রতিরোধ: আপনার হেলথ চেককে প্রতি কয়েক মিনিটে listener-এর মধ্য দিয়ে একটি টাটকা কানেকশন করতে হবে — tnsping এবং একটি আসল sqlplus লগইন — এবং listener-কে এমন একটি service manager-এর অধীনে থাকতে হবে যা এটি রিস্টার্ট করে। সম্পূর্ণ ডায়াগনস্টিক ধারাটি আমি হেঁটে দেখিয়েছি আমার listener ও TNS ট্রাবলশুটিং গাইডে।

৫. যে ব্যাকআপ চলল নাশতার সময় পর্যন্ত

ডেটাবেজের সাথে ব্যাকআপও বাড়ে, আর কেউ হিসাবটা আবার মেলায় না। ৫০০ GB ডেটাবেজের জন্য সাইজ করা একটি ব্যাকআপ উইন্ডো ৪ TB-তে গিয়ে নীরবে অপর্যাপ্ত হয়ে পড়ে — এবং একদিন যে RMAN জব আগে ভোর ৪টায় শেষ হতো তা সকাল ১০টাতেও স্টোরেজ পেটাচ্ছে, যখন ব্যবহারকারীরা এর সাথে I/O নিয়ে লড়ছেন আর হেল্পডেস্ক গলে যাচ্ছে।

প্রতিরোধ: প্রতি মাসে আপনার ব্যাকআপের সময়কালের ট্রেন্ড দেখুন; এটি তার উইন্ডোর ৬০% পেরোলেই পদক্ষেপ নিন — block change tracking-সহ incremental কৌশল, ভালো channel, বা compression। Duration creep হলো একটি ডেটাবেজ আপনাকে যেসব আগাম, সস্তা সতর্কবার্তা দেয় তার অন্যতম।

৬. যে standby ছয় সপ্তাহ ধরে out of sync ছিল

আমার দেখা সবচেয়ে বেদনাদায়কটি। একটি কোম্পানির Data Guard ছিল, এর জন্য টাকা দিয়েছিল, এর কারণে নিশ্চিন্তে ঘুমাত। প্রাইমারির স্টোরেজ মারা গেলে তারা failover করতে গেল — আর standby ৪৩ দিন পিছিয়ে। প্রাইমারিতে একটি পাসওয়ার্ড পরিবর্তন মাঝরাতে (অবশ্যই) redo shipping ভেঙে দিয়েছিল, এররটি alert log-এ অপঠিত পড়ে ছিল, আর apply lag কেউ দেখছিল না।

-- The one query that should page someone if it grows
SELECT name, value, time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag','apply lag');

প্রতিরোধ: paging অ্যালার্টসহ transport ও apply lag মনিটর করুন, এবং — এই অংশটাই সবাই বাদ দেয় — বছরে অন্তত দুবার একটি সত্যিকার switchover ড্রিল করুন। যে standby-তে আপনি কখনও switchover করেননি তা একটি গুজব, কোনো DR পরিকল্পনা নয়।

৭. যে wallet-এর মেয়াদ ফুরাল সময়সূচি মেনেই

সার্টিফিকেট ও wallet হলো ছাপা ফিউজওয়ালা টাইম বোমা। TDE wallet, listener-এর TLS সার্টিফিকেট, অ্যাপ্লিকেশন টিয়ারের ভেতরের সার্টিফিকেট — প্রতিটির একটি মেয়াদের তারিখ আছে যা বছরের পর বছর আগে থেকে জানা ছিল, তবু রাত ৩টায় মানুষকে চমকে দিতে সক্ষম হয়, যখন একটি রিস্টার্ট হঠাৎ wallet খুলতে পারে না বা একটি ক্লায়েন্ট handshake প্রত্যাখ্যান করে।

প্রতিরোধ: স্ট্যাকের প্রতিটি সার্টিফিকেট ও wallet তার মেয়াদের তারিখসহ ইনভেন্টরি করুন, ৬০ ও ৩০ দিন আগে অ্যালার্ট দিন, এবং নবায়নের মহড়া দিন। সমাধানটি দিনের আলোয় দশ মিনিট নেয়, আর অন্ধকারে পুরো একটি রাত।

গভীরতর কারণ: কেউ ধরতে পারল না কেন

ওই সাতটি ব্যর্থতার দিকে ফিরে তাকান। একটিও বিদঘুটে নয়, এবং একটিও আসলে প্রযুক্তির ব্যর্থতা নয়। প্রতিটিই প্রযুক্তির চারপাশের সিস্টেমের একটি ফাঁক — আর ফাঁকগুলো এত নির্ভরযোগ্যভাবে পুনরাবৃত্ত হয় যে আমি এখন ডেটাবেজ দেখার আগে সেগুলোই খুঁজি।

• তারা সার্ভার মনিটর করেছিল, ডেটাবেজ নয়। CPU, মেমরি, ping — সব সবুজ, যখন FRA ভরছিল, standby সরে যাচ্ছিল, আর listener মরে পড়ে ছিল। একটি নিখুঁত সুস্থ সার্ভারে একটি ডেটাবেজ সম্পূর্ণ হ্যাং থাকতে পারে। মনিটরিংকে ডেটাবেজের প্রশ্ন করতে হবে: আমি কি টাটকা কানেক্ট করতে পারি, স্পেস কি প্রবৃদ্ধির চেয়ে এগিয়ে, standby কি apply করছে, গত রাতের জবগুলো কি শেষ হয়েছে?
• এসকালেশনবিহীন অ্যালার্টিং। রাত ২:৪৭-এ এমন একটি ইনবক্সে ইমেইল যা খোলে সকাল ৯টায় — এটি অ্যালার্টিং নয়; এটি বাড়তি ধাপসহ লগিং। সত্যিকার অ্যালার্টিং একটি ফোন page করে, acknowledgement-এর জন্য নির্দিষ্ট কয়েক মিনিট অপেক্ষা করে, তারপর পরের ব্যক্তিকে page করে — স্বয়ংক্রিয়ভাবে।
• কোনো runbook নেই। প্রক্রিয়াটি যখন একজন সিনিয়র ব্যক্তির মাথায় থাকে, প্রতিটি ইনসিডেন্ট হয়ে ওঠে সেই ব্যক্তি ফোন ধরবেন কিনা তার পরীক্ষা। একটি runbook — সঠিক কমান্ড, প্রত্যাশিত আউটপুট, সিদ্ধান্তের পয়েন্ট — রাত ৩টার সংকটকে এমন একটি চেকলিস্টে রূপান্তর করে যা একজন মিড-লেভেল ইঞ্জিনিয়ার চালাতে পারেন।
• এক-ব্যক্তি নির্ভরতা। আমি এমন সিস্টেম অডিট করেছি যেখানে একজন DBA-র হাতে ছিল SYS পাসওয়ার্ড, ব্যাকআপ শিডিউল এবং সম্পূর্ণ রিকভারি জ্ঞান। সেই মানুষটি এমন একটি single point of failure যাকে হার্ডওয়্যার বাজেট কখনও দেখে না।

ফাঁকগুলো ঠিক করুন, আর একই কম্পোনেন্টগুলো ব্যর্থ হওয়া বন্ধ করে — বা বরং, সেগুলো ব্যর্থ হতেই থাকে, কিন্তু ব্যর্থতাগুলো হয়ে ওঠে non-event, যা মঙ্গলবার বিকেলে ৬০% থ্রেশহোল্ডে ধরা পড়ে।

যে সংখ্যাটি কেউ হিসাব করতে চায় না

অধিকাংশ প্রতিষ্ঠান কখনও এক ঘণ্টা ডাউনটাইমের বাস্তব একটি অঙ্ক বসায়নি — আর এই একটিমাত্র অনুপস্থিত সংখ্যাই কারণ কেন নির্ভরযোগ্যতা কম বাজেট পায়।

সৎভাবে হিসাব করুন। একটি ব্যাংকের জন্য এটি ব্যর্থ লেনদেন, রেগুলেটরি ঝুঁকি এবং এমন একটি আস্থার আঘাত যা আউটেজের চেয়ে মাসের পর মাস বেশি টিকে থাকে। একটি ফার্মা ডিস্ট্রিবিউটরের জন্য এটি এমন অর্ডার যা পাঠানো যায় না এবং একটি সরবরাহ শৃঙ্খল যা থমকে যায়। একটি টেলিকমের জন্য এটি সেকেন্ডে সেকেন্ডে রাজস্ব ফাঁস। ওভারটাইম, জরুরি কনসালট্যান্ট, ডেটা পুনরায় এন্ট্রি এবং সুনাম — সব যোগ করুন — আর অধিকাংশ "ঘটলে দেখা যাবে" সিস্টেম আসলে এমন একটি বাজেট লাইন রক্ষা করছে যা তারা যে ক্ষতির ঝুঁকিতে আছে তার চেয়ে অনেক ছোট। একবার এই সংখ্যাটি হাতে পেলে, এই গাইডের বাকিটা আর খরচ থাকে না, বীমা হয়ে ওঠে।

টিকে থাকা ডেটাবেজের তিনটি স্তম্ভ

একটি সত্যিকারের স্থিতিস্থাপক সিস্টেম তিনটি স্তম্ভের ওপর দাঁড়ায়। যেকোনো একটিতে দুর্বলতা পুরোটাকে নামিয়ে ফেলে — আর আমাকে যেসব ব্যর্থতা ঠিক করতে ডাকা হয় তার অধিকাংশই একটি দুর্বল স্তম্ভ যাকে সবাই ধরে নিয়েছিল শক্তিশালী।

স্তম্ভ ১ — High Availability: যে ব্যর্থতা আপনি আসতে দেখেননি তা টিকিয়ে থাকা

High availability হলো একটি কম্পোনেন্ট মারা গেলে — একটি নোড, একটি ডিস্ক, একটি নেটওয়ার্ক পথ — অনলাইন থাকা। Oracle-এর জন্য গোল্ড স্ট্যান্ডার্ড এখনও Real Application Clusters (RAC): একই ডেটাবেজ চালানো একাধিক সার্ভার, যাতে একটি নোড হারালে সেবা নেমে না যায়। কিন্তু RAC যা নয় এবং যেখানে আমি সবচেয়ে ব্যয়বহুল ভুল দেখি তা এখানে:

• RAC কোনো ব্যাকআপ নয়। এটি হার্ডওয়্যার ও ইনস্ট্যান্স ব্যর্থতা থেকে রক্ষা করে — একটি ড্রপ করা টেবিল, প্রতিটি নোডে তাৎক্ষণিকভাবে রেপ্লিকেটেড একটি করাপ্ট ব্লক, বা একটি খারাপ ডিপ্লয়মেন্ট থেকে নয়। একটি ভুলকে ক্লাস্টার করা কেবল ভুলটাকে highly available করে তোলে।
• RAC "সেট করে ভুলে যাওয়ার" জিনিস নয়। Interconnect ভুল কনফিগারেশন, অসম সার্ভিস প্লেসমেন্ট এবং অটেস্টেড failover-ই কারণ কেন ক্লাস্টার ঠিক সেই ঘটনার সময়ই ব্যর্থ হয় যা টিকিয়ে থাকতে সেটি কেনা হয়েছিল।
• খারাপভাবে করা RAC কোনো RAC না থাকার চেয়ে খারাপ — বেশি নড়াচড়া করা অংশ, ব্যর্থ হওয়ার বেশি উপায় এবং নিরাপত্তার একটি মিথ্যা অনুভূতি।

ঠিকভাবে করলে, RAC-এর সাথে সঠিক সার্ভিস ও কানেকশন ম্যানেজমেন্ট মানে একটি নোড উধাও হয়ে যেতে পারে আর আপনার ব্যবহারকারীরা প্রায় টেরই পান না। এটাই লক্ষ্য: ব্যর্থতা একটি non-event হিসেবে।

স্তম্ভ ২ — Disaster Recovery: যে পরিকল্পনা আপনি আশা করেন কখনও চালাতে হবে না

High availability ব্যর্থ কম্পোনেন্ট সামলায়। Disaster recovery ব্যর্থ সাইট সামলায় — আগুন, বন্যা, র‍্যানসমওয়্যার, একটি অঞ্চল অফলাইন, বা মানুষের ভুল যা আপনার প্রাইমারি করাপ্ট করে। দুটি সংখ্যা আপনার কৌশল নির্ধারণ করে, আর প্রতিটি ব্যবসার নিজেরটা জানা উচিত:

• RPO (Recovery Point Objective): আপনি কতটা ডেটা হারানো সহ্য করতে পারেন? সেকেন্ড? এক ঘণ্টা? এক দিন?
• RTO (Recovery Time Objective): ক্ষতি অগ্রহণযোগ্য হওয়ার আগে আপনি কতক্ষণ ডাউন থাকতে পারেন?

Oracle-এর জন্য Data Guard একটি সিঙ্ক্রোনাইজড স্ট্যান্ডবাই ডেটাবেজ রক্ষণাবেক্ষণ করে — প্রায়ই অন্য একটি সাইটে — দায়িত্ব নিতে প্রস্তুত। একটি সুশৃঙ্খল ব্যাকআপ কৌশলের (RMAN, ভ্যালিডেটেড, অফ-সাইট, এনক্রিপ্টেড) সাথে মিলিয়ে এটি "যদি আমরা সব হারাই" প্রশ্নের একটি বাস্তব উত্তর দেয়। কিন্তু এই পুরো গাইডের সবচেয়ে গুরুত্বপূর্ণ বাক্যটি হলো:

যে ব্যাকআপ আপনি কখনও রিস্টোর করেননি তা কোনো ব্যাকআপ নয়। এটি একটি আশা।

আমি বহু প্রতিষ্ঠানে ঢুকেছি যেখানে প্রতি রাতে একটি সবুজ "backup successful" আলো জ্বলে — অথচ এমন একটি ব্যাকআপ যা যখন সত্যিই দরকার তখন আসলে রিস্টোর করা যায়নি: হারানো archive log, একটি অটেস্টেড প্রক্রিয়া, এমন একটি টেপ যা কেউ পড়তে পারেনি। একমাত্র যে ব্যাকআপটি গোনায় ধরা হয় তা হলো যেটি থেকে আপনি প্রমাণ করেছেন যে পুনরুদ্ধার করতে পারেন, একটি শিডিউলে, একটি ড্রিল হিসেবে। এই ত্রৈমাসিকে আর কিছু টেস্ট না করলেও, আপনার রিস্টোর টেস্ট করুন।

স্তম্ভ ৩ — Performance: যে ব্যর্থতা ধীরে ধীরে আসে

প্রতিটি আউটেজ আকস্মিক নয়। আমাকে যে "ব্যর্থতার" জন্য সবচেয়ে বেশি ডাকা হয় তা কোনো ক্র্যাশ নয় — এটি এমন একটি সিস্টেম যা নীরবে এতটা অবনতি হয়েছে যে কার্যত অব্যবহার্য হয়ে গেছে। যে রিপোর্ট আগে সেকেন্ডে হতো তা এখন মিনিট নেয়। যে মাস-শেষ মধ্যরাতের মধ্যে শেষ হতো তা এখন দুপুর পর্যন্ত চলে। যেসব ব্যবহারকারী অভিযোগ করা বন্ধ করেছেন কারণ তাঁরা হাল ছেড়ে দিয়েছেন।

পারফরম্যান্স একটি নির্ভরযোগ্যতার সমস্যা, কারণ ব্যবহার করার পক্ষে খুব ধীর একটি সিস্টেম ব্যবসার জন্য ডাউন-ই। কারণগুলো খুব কমই রহস্যময়: অনুপস্থিত বা ভুল ইনডেক্স, ডেটা প্রবৃদ্ধির সাথে তাল না রাখা statistics, unbounded কোয়েরি, contention এবং এমন একটি ডেটা ভলিউম যা দ্বিগুণ হয়েছে অথচ ডিজাইন স্থির থেকে গেছে। সমাধান হলো পদ্ধতিগত ডায়াগনসিস — অনুমান নয়, বরং আসল execution plan ও wait event পড়া — এবং এমন ক্যাপাসিটি প্ল্যানিং যা ধরে নেয় আপনার ডেটা বাড়বেই, কারণ বাড়বে।

রাত ৩টার জন্য ডিজাইন: রেজিলিয়েন্স স্ট্যাক, স্তরে স্তরে

স্থিতিস্থাপকতা কোনো একটি পণ্য নয়; এটি একটি স্ট্যাক, আর প্রতিটি স্তর নিচের স্তরটি যেসব ব্যর্থতা কভার করতে পারে না সেগুলো কভার করে। এই ক্রমে তৈরি করুন — নিচ থেকে আগে — কারণ অটেস্টেড ব্যাকআপের ওপর একটি সুন্দর ক্লাস্টার হলো পচা সেতুর ওপর একটি স্পোর্টস কার।

স্তর ১ — টেস্টেড RMAN রিস্টোর। ভিত্তি, এবং একমাত্র স্তর যা সবকিছুর বিরুদ্ধে রক্ষা করে: করাপশন, র‍্যানসমওয়্যার, মানুষের ভুল, সম্পূর্ণ সাইট হারানো। সাপ্তাহিক RESTORE VALIDATE, মাসে একবার সত্যিকারের কিছু একটি scratch সার্ভারে রিস্টোর, ত্রৈমাসিকে একটি পূর্ণ, সময়-মাপা ড্রিল। আমার সম্পূর্ণ কৌশল — incremental level, block change tracking, retention, রিস্টোর ড্রিলগুলো নিজে — আছে RMAN ব্যাকআপ ও রিকভারি গাইডে।

স্তর ২ — Data Guard। একটি সিঙ্ক্রোনাইজড standby সার্ভার ও সাইট ব্যর্থতার জন্য "ব্যাকআপ থেকে রিস্টোর" (ঘণ্টা) কে "failover" (মিনিট)-এ রূপান্তর করে। এটি সম্পূর্ণ Oracle HA ক্যাটালগের সেরা ভ্যালু — যদি আপনি lag মনিটর করেন এবং switchover-এর মহড়া দেন, Data Guard 19c গাইড অনুযায়ী। একটি আনমনিটরড standby হলো ওপরের ব্যর্থতা #৬, নিজের রাতের অপেক্ষায়।

স্তর ৩ — RAC, যেখানে ব্যবসা এর যৌক্তিকতা দেয়। RAC আউটেজের কারণ হিসেবে instance ও node ব্যর্থতাকে সরিয়ে দেয়, যা গুরুত্বপূর্ণ যখন কয়েক মিনিটের ডাউনটাইমেও সত্যিকারের টাকা যায়। এটি খরচ ও জটিলতা যোগ করে, তাই এটি একটি ব্যবসায়িক সিদ্ধান্ত, ডিফল্ট নয় — কার সত্যিই এটি দরকার তা আমি লিখেছি RAC 19c গাইডে।

স্তর ৪ — প্রোঅ্যাকটিভ হেলথ চেক। যে স্তরটি বাকি তিনটিকে বাস্তব করে: শিডিউলড স্ক্রিপ্ট যা স্পেস হেডরুম, টাটকা কানেক্টিভিটি, standby lag, ব্যাকআপ সাফল্য, মেয়াদোত্তীর্ণ-হতে-চলা অ্যাকাউন্ট ও সার্টিফিকেট যাচাই করে — এবং একটি থ্রেশহোল্ড পেরোলেই একজন মানুষকে page করে। আমার কর্মরত স্ক্রিপ্ট সেট আছে Oracle হেলথ চেক গাইডে; নিয়ে নিন।

রাত ৩টার পরীক্ষা: প্রতিটি সিস্টেমে আমি যে চিন্তা-পরীক্ষাটি চালাই

এখানে সেই অনুশীলনটি যা আমি প্রতিটি ক্লায়েন্টের সাথে করি, আর এটি যেকোনো অডিট টুলের চেয়ে বেশি দুর্বলতা উন্মোচন করে। একটি কম্পোনেন্ট বেছে নিন — প্রাইমারি সার্ভার, স্টোরেজ অ্যারে, listener, সেই একজন সিনিয়র DBA — আর জিজ্ঞেস করুন: এটি যদি এই মুহূর্তে, রাত ৩টায়, মারা যায়, মিনিটে মিনিটে কী ঘটে?

সৎভাবে হেঁটে দেখুন। মিনিট ০: প্রাইমারি সার্ভার মারা যায়। মিনিট ১: কিছু কি লক্ষ্য করে? "সকালের রিপোর্টে কি দেখা যেত" নয় — এক-দুই মিনিটের মধ্যে কি একটি স্বয়ংক্রিয় চেক ব্যর্থ হয়? মিনিট ৩: সত্যিই কি একটি ফোন বাজে, আর কার? মিনিট ১০: সেই ব্যক্তি জেগে লগইন করেছেন — তিনি কি জানেন failover করতে হবে কিনা, আর কে সেটির অনুমোদন দেন? মিনিট ১৫: switchover কমান্ডটি — এটি কি একটি runbook-এ, নাকি কারও স্মৃতিতে? মিনিট ৩০: ব্যবহারকারীরা কি ফিরেছেন, আর কী ঘটেছে তা ব্যবসাকে বলছেন কে?

অধিকাংশ প্রতিষ্ঠান মিনিট ০ দিব্যি পার করে আর মিনিট ৩-এ ভেঙে পড়ে। Failure detection আছে; মানবিক তারের সংযোগটি নেই। আপনার ওয়াকথ্রুর কোনো মিনিটের উত্তর যদি হয় "মনে হয়..." বা "সম্ভবত কেউ একজন...", আপনি আপনার পরবর্তী প্রজেক্ট খুঁজে পেয়েছেন — আর সেটি ঠিক করা সাধারণত সস্তা।

যে ১০-দফা চেকলিস্ট আমাকে ঘুমাতে দেয়

এটি আক্ষরিক অর্থেই সেই তালিকা যার বিপরীতে আমি আমার নিজের সিস্টেমগুলো ধরে রাখি। দশটিই যখন সত্য, ফোন চুপ থাকে — আর যখন বাজে, কলটি ছোট হয়।

1. Archive/FRA ব্যবহারের অ্যালার্ট ৮০%-এ, রাতের redo রেটের জন্য সাইজ করা, ব্যাকআপের পর স্বয়ংক্রিয় archivelog মুছে ফেলাসহ।
2. স্পেস হেডরুম প্রতিদিন যাচাই — প্রতিটি ফাইলসিস্টেম ২০% datafile বৃদ্ধি ধারণ করতে পারে; autoextend MAXSIZE দিয়ে সীমাবদ্ধ।
3. প্রতি পাঁচ মিনিটে listener-এর মধ্য দিয়ে একটি টাটকা টেস্ট কানেকশন, সার্ভারের বাইরে থেকে, ব্যর্থতায় paging-সহ।
4. RMAN ব্যাকআপ সাফল্য এবং সময়কালের ট্রেন্ড সাপ্তাহিক পর্যালোচনা; উইন্ডোর ৬০% পেরোলে রিডিজাইন, আশা নয়।
5. গত ৯০ দিনে একটি সত্যিকার রিস্টোর সম্পন্ন, সময় মাপা, ডকুমেন্টেড, আমি ছাড়া অন্য কারও দ্বারা।
6. Standby transport ও apply lag থ্রেশহোল্ডে page হয়, এবং গত ছয় মাসে একটি switchover ড্রিল সম্পন্ন।
7. প্রতিটি অ্যাকাউন্ট মেয়াদ ও সার্টিফিকেট/wallet মেয়াদ ইনভেন্টরিভুক্ত, ৩০+ দিন আগে অ্যালার্টসহ।
8. শীর্ষ পাঁচটি failure scenario-র runbook, একজন জুনিয়র ইঞ্জিনিয়ার প্রস্তুতি ছাড়াই চালিয়ে টেস্ট করা।
9. একটি এসকালেশন চেইন যা স্বয়ংক্রিয়ভাবে দ্বিতীয় একজন মানুষকে page করে যদি প্রথমজন ১০ মিনিটে acknowledge না করেন।
10. প্রতিটি শিডিউলড জবের মাসিক পর্যালোচনা — ডেটাবেজ ও cron — যাতে রাত আড়াইটায় এমন কিছু না চলে যা কেউ ব্যাখ্যা করতে পারে না।

লক্ষ্য করুন তালিকায় কী নেই: কোনো নির্দিষ্ট লাইসেন্স, কোনো নির্দিষ্ট হার্ডওয়্যার। দশটির মধ্যে আটটি পয়েন্টের খরচ শৃঙ্খলা, টাকা নয়।

যে স্তম্ভ সবাই ভুলে যায়: হিউম্যান লেয়ার

আপনি প্রতিটি লাইসেন্স ও প্রতিটি সার্ভার কিনতে পারেন, তবু একটি কীস্ট্রোক দূরত্বে বিপর্যয়ের কাছে থাকতে পারেন — কারণ যাকে কেউ সত্যিকারভাবে বোঝে না এমন স্থিতিস্থাপক প্রযুক্তি ভঙ্গুর। আপনি একটি সত্যিকার ইনসিডেন্ট টিকিয়ে থাকবেন কিনা তা যে প্রশ্নগুলো নির্ধারণ করে সেগুলো মানবিক। যখন প্রাইমারি রাত ৩টায় ব্যর্থ হয়, কেউ কি জানে — তাৎক্ষণিকভাবে, স্বয়ংক্রিয়ভাবে — নাকি আপনি সকাল ৯টায় রাগান্বিত গ্রাহকদের কাছ থেকে জানেন? একটি ডকুমেন্টেড, অনুশীলিত runbook আছে, নাকি আপনি সর্বোচ্চ চাপের মধ্যে বানিয়ে বানিয়ে চলবেন? আপনার পুনরুদ্ধার কি একজন অপরিবর্তনীয় মানুষের ওপর নির্ভর করে যিনি ছুটিতে থাকতে পারেন, নাগালের বাইরে থাকতে পারেন, বা চলে গেছেন?

তিনটি অভ্যাস এই স্তরকে সুস্থ রাখে। প্রথমত, একটি সুস্থ on-call রোটেশন: কেউ পরপর দুই সপ্তাহ pager বহন করেন না, কারণ রাত ৩টায় একজন ক্লান্ত DBA এমন ধরনের ভুল করেন যা একটি ইনসিডেন্টকে একটি বিপর্যয়ে রূপান্তর করে। দ্বিতীয়ত, ফোনটি যিনি ধরতে পারেন সবচেয়ে কম অভিজ্ঞ সেই ব্যক্তির জন্য লেখা runbook — যদি শুধু আর্কিটেক্টই এটি অনুসরণ করতে পারেন, তবে এটি ডকুমেন্টেশন, runbook নয়। তৃতীয়ত, দোষারোপহীন postmortem: প্রতিটি ইনসিডেন্টের পর লিখে রাখুন কী ব্যর্থ হয়েছিল, টাইমলাইন কী ছিল এবং কোন ফাঁকটি এটি ঘটতে দিয়েছিল — কোনো অপরাধী না খুঁজে। Postmortem যে মুহূর্তে বিচার হয়ে ওঠে, মানুষ সেই near-miss-গুলো লুকাতে শুরু করে যা আপনাকে সতর্ক করত।

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

নির্ভরযোগ্য ডেটা থেকে ভালো সিদ্ধান্ত

নির্ভরযোগ্যতা ভিত্তি — কিন্তু সেই একই সুপরিচালিত ডেটাবেজ আপনার সবচেয়ে কম-ব্যবহৃত কৌশলগত সম্পদও। আধুনিক সুযোগটি হলো সেই বিশ্বাসযোগ্য অপারেশনাল ডেটাকে সিদ্ধান্তে রূপান্তর করা: ERP ইন্টিগ্রেশন যা আপনার সিস্টেমগুলোকে ম্যানুয়াল রি-কিয়িং-এ বাধ্য না করে সংযুক্ত করে, এবং AI যা আপনার টিমকে সাধারণ ভাষায় নিজেদের ডেটা নিয়ে প্রশ্ন করতে ও সেকেন্ডে উত্তর পেতে দেয়।

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

একটি নির্ভরযোগ্যতা ম্যাচুরিটি যাচাই

একটি দ্রুত, সৎ স্ব-মূল্যায়ন। প্রতিটির জন্য জিজ্ঞেস করুন "আমাদের কি এটি আছে?" নয়, বরং "আমরা কি এটি প্রমাণ করেছি?"

• Single points of failure — কোনো একটি সার্ভার, ডিস্ক বা মানুষ কি ব্যবসা নামিয়ে ফেলতে পারে? (যদি হ্যাঁ, সেটাই আপনার শীর্ষ অগ্রাধিকার।)
• টেস্টেড রিকভারি — গত ৯০ দিনে আপনি কি ব্যাকআপ থেকে end to end রিস্টোর করেছেন?
• RPO / RTO সংজ্ঞায়িত — আপনি কি আপনার লক্ষ্য জানেন, এবং আপনার আর্কিটেকচার কি আসলেই তা পূরণ করে?
• বাস্তব মনিটরিং — আপনার গ্রাহকদের আগে আপনি কি একটি ব্যর্থতা সম্পর্কে জানবেন?
• ডকুমেন্টেড ও মহড়া-দেওয়া runbook — আপনার সবচেয়ে সিনিয়র ব্যক্তি ছাড়া অন্য কেউ কি একটি পুনরুদ্ধার চালাতে পারবেন?
• পারফরম্যান্স হেডরুম — সিস্টেমটি কি দুই বছর আগের নয়, বরং দুই বছর পরে আপনার যে ডেটা ভলিউম থাকবে তার জন্য ডিজাইন করা?
• প্যাচ ও সিকিউরিটি অবস্থা — আপনি কি হালনাগাদ, নাকি নীরবে উন্মুক্ত?

অধিকাংশ প্রতিষ্ঠান যেসব কম্পোনেন্ট তারা কিনেছে সেগুলোতে ভালো স্কোর করে আর যেগুলো তাদের অনুশীলন করতে হতো সেগুলোতে খারাপ। সেই ফাঁকটাই ঠিক যেখানে রাত ৩টা বাস করে।

সাধারণ জিজ্ঞাসা (FAQ)

রাতে ডেটাবেজ ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ কী?

আমার অভিজ্ঞতায়, শিডিউলড জব চলাকালীন জায়গা ফুরিয়ে যাওয়া — ব্যাকআপ ও ব্যাচ প্রসেসিং একসাথে চলার সময় একটি archive log destination বা datafile ফাইলসিস্টেম ভরে যাওয়া। ডেটাবেজ ক্র্যাশ করে না; এটি হ্যাং করে, জায়গার জন্য অপেক্ষা করে, আর প্রতিটি সেশন এর সাথে জমে যায়। ৮০%-এ সেট করা থ্রেশহোল্ড অ্যালার্ট এবং redo জেনারেশনের সাথে সত্যিই তাল রাখে এমন একটি purge নীতি দিয়ে এটি প্রায় সবসময়ই প্রতিরোধযোগ্য।

আমার কত ঘন ঘন ডেটাবেজ রিস্টোর টেস্ট করা উচিত?

ন্যূনতম, প্রতি ত্রৈমাসিকে একটি সম্পূর্ণ end-to-end রিস্টোর ড্রিল, সাথে সাপ্তাহিক RMAN RESTORE VALIDATE এবং মাসে একবার একটি একক tablespace বা PDB একটি scratch সার্ভারে রিস্টোর। যে ব্যাকআপ আপনি কখনও রিস্টোর করেননি তা একটি আশা, ব্যাকআপ নয়। ত্রৈমাসিক ড্রিলটি সময় মেপে, ডকুমেন্ট করে এবং যিনি এটি ডিজাইন করেছেন তিনি ছাড়া অন্য কারও দ্বারা চালানো উচিত।

আমার কি Oracle RAC দরকার, নাকি Data Guard-ই যথেষ্ট?

অধিকাংশ প্রতিষ্ঠানের জন্য, একটি সুপরিচালিত single instance সাথে Data Guard এবং টেস্টেড ব্যাকআপ বাস্তবসম্মত failure mode-গুলো কভার করে: সার্ভার মৃত্যু, সাইট হারানো, করাপশন, মানুষের ভুল। RAC প্রায়-শূন্য-ডাউনটাইম instance failover যোগ করে, কিন্তু খরচ ও জটিলতাও যোগ করে, আর করাপশন বা ড্রপ করা টেবিলের বিরুদ্ধে এটি কিছুই করে না। RAC কিনুন যখন কয়েক মিনিটের ডাউনটাইমও সত্যিই অগ্রহণযোগ্য — DR-এর বিকল্প হিসেবে নয়।

ডেটাবেজ মনিটরিং-এর আসলে কী দেখা উচিত?

শুধু সার্ভার নয় — ডেটাবেজ নিজেই। archive destination ও tablespace-এর ব্যবহার হেডরুম থ্রেশহোল্ডসহ, listener-এর মধ্য দিয়ে ইনস্ট্যান্স একটি সত্যিকার টেস্ট কানেকশন গ্রহণ করছে কিনা, standby apply lag, ব্যাকআপ সম্পন্ন হওয়া ও সময়ের ট্রেন্ড, অ্যাকাউন্ট ও সার্টিফিকেট মেয়াদোত্তীর্ণের তারিখ এবং alert-log এরর দেখুন। শুধু CPU ও ping-এর গ্রাফ ডেটাবেজ হ্যাং থাকা অবস্থায়ও দিব্যি সবুজ দেখাবে।

Runbook কী, এবং এতে কী থাকা উচিত?

Runbook হলো ধাপে ধাপে লেখা এমন একটি রিকভারি ডকুমেন্ট যা একজন মিড-লেভেল ইঞ্জিনিয়ার কাউকে না জাগিয়েই রাত ৩টায় চালাতে পারেন। এতে থাকে সঠিক কমান্ড, প্রত্যাশিত আউটপুট, সিদ্ধান্তের পয়েন্ট, এসকালেশন কন্টাক্ট এবং প্রতিটি ধাপে কত সময় লাগা উচিত। কোনো প্রক্রিয়া যদি শুধু একজন মানুষের মাথায় থাকে, তাহলে প্রতিষ্ঠানটির একটি single point of failure আছে যে ব্যাজ পরে ঘোরে।

এত ব্যর্থতায় standby ডেটাবেজ জড়িত কেন?

কারণ একটি standby নীরবে ব্যর্থ হয়। পাসওয়ার্ড পরিবর্তন, একটি নেটওয়ার্ক পরিবর্তন বা একটি archive gap-এর পর log shipping ভেঙে যায়, আর ব্যবহারকারীর চোখে কিছুই বদলায় না — যতদিন না failover-এর দিন এসে আবিষ্কার করেন সপ্তাহের পর সপ্তাহের ডেটা নেই। প্রতিদিন apply lag মনিটর করুন এবং standby সত্যিই ব্যবহারযোগ্য তা প্রমাণ করতে বছরে অন্তত দুবার একটি সত্যিকার switchover ড্রিল চালান।

মূল কথা

স্থিতিস্থাপকতা এমন কোনো পণ্য নয় যা আপনি কেনেন; এটি এমন একটি ইঞ্জিনিয়ারিং শৃঙ্খলা যা আপনি রক্ষণাবেক্ষণ করেন। আমাকে যেসব ব্যয়বহুল ব্যর্থতা মেরামত করতে ডাকা হয় সেগুলো প্রায় কখনওই বিদঘুটে নয় — এগুলো এমন একটি ব্যাকআপ যা কখনও টেস্ট করা হয়নি, এমন একটি ক্লাস্টার যা কখনও টিউন করা হয়নি, এমন একটি পারফরম্যান্স সমস্যা যা আউটেজ হওয়া পর্যন্ত উপেক্ষিত ছিল, বা এমন একটি সিস্টেম যা সম্পূর্ণভাবে একজন মানুষের ওপর নির্ভর করত।

CoreStack-এ, সেই নিরস, বুলেটপ্রুফ স্তরটিই হলো কাজ: আপনার বাস্তব failure mode-এর জন্য ডিজাইন করা Oracle RAC ও high availability, আপনি আসলেই প্রমাণ করেছেন এমন ডিজাস্টার রিকভারি, বাড়ার সাথে টিকে থাকা পারফরম্যান্স এবং ERP ও AI ইন্টিগ্রেশন যা নির্ভরযোগ্য ডেটাকে সিদ্ধান্তে রূপান্তর করে — সেইসব নিয়ন্ত্রিত, ডেটা-সংবেদনশীল এন্টারপ্রাইজের জন্য ইঞ্জিনিয়ার করা যেখানে ডাউনটাইম কোনো অসুবিধা নয়, এটি একটি সংকট। এটি তৈরির সেরা সময় ছিল রাত ৩টার কলের আগে। দ্বিতীয় সেরা সময় এখন।