Oracle প্যাচিং সঠিকভাবে: OPatch, Datapatch দিয়ে Release Update এবং শূন্য-ডাউনটাইম RAC

আন-প্যাচড ডেটাবেজ থেকেই বহু ব্রিচ ও আউটেজ শুরু হয়। তবুও প্যাচিং হলো সেই কাজ যা DBA-রা সবচেয়ে বেশি পিছিয়ে দেন, কারণ একটি ভুল প্যাচ প্রোডাকশন সিস্টেম নামিয়ে দিতে পারে। এটি ভীতিকর হওয়ার দরকার নেই। Oracle একটি অনুমানযোগ্য ত্রৈমাসিক সময়সূচিতে নিরাপত্তা ও স্থিতিশীলতা ফিক্স পাঠায়, আর সেগুলো নিরাপদে প্রয়োগের জন্য একটি সুসংজ্ঞায়িত, পুনরাবৃত্তিযোগ্য প্রক্রিয়া আছে - এমনকি Real Application Clusters-এ কোনো ডাউনটাইম ছাড়াই। এই গাইডে পুরো ওয়ার্কফ্লো তুলে ধরা হয়েছে: পরিভাষা, বিপর্যয় ঠেকানো প্যাচের আগের চেক, একটি Release Update প্রয়োগ ও যাচাই, একটি RAC ক্লাস্টারের মধ্য দিয়ে নোড-বাই-নোড রোলিং প্যাচ, এবং কিছু ভুল হলে rollback করা।

১. কেন প্যাচিং ঐচ্ছিক নয়

প্রতি ত্রৈমাসিকে Oracle নিরাপত্তা দুর্বলতা ও স্থিতিশীলতা বাগের জন্য ফিক্স প্রকাশ করে। আক্রমণকারীরা সেই একই অ্যাডভাইজরি পড়ে, তাই একটি আন-প্যাচড ডেটাবেজ হলো একটি পরিচিত, নথিভুক্ত লক্ষ্য। নিরাপত্তা ছাড়াও, ঠিক করা বহু বাগ হলো ঠিক সেই "এটি এলোমেলোভাবে হ্যাং করল" বা "optimizer একটি বাজে প্ল্যান বেছে নিল" সমস্যা যা DBA-রা সপ্তাহের পর সপ্তাহ খুঁজে বেড়ায়। প্যাচিং হলো প্রতিরোধমূলক রক্ষণাবেক্ষণ, আর এটি বাদ দিলে ঝুঁকি দূর হয় না - এটি শুধু ঝুঁকিটিকে আরও খারাপ একটি মুহূর্তে ঠেলে দেয়।

প্যাচিং পিছিয়ে দেওয়ার কারণ হলো প্রোডাকশন ভাঙার ভয়। সেই ভয়ের নিরাময় হলো প্রক্রিয়া। যথাযথ চেক, একটি ব্যাকআপ এবং একটি জানা rollback পথসহ প্রয়োগ করা প্যাচ একটি কম-নাটকীয়, পুনরাবৃত্তিযোগ্য কাজ।

২. যে পরিভাষাগুলো আপনার জানা দরকার

Oracle-এর প্যাচ শব্দভাণ্ডার নতুনদের বিভ্রান্ত করে, তাই চলুন এটিকে বাস্তব করি:

• Release Update (RU): প্রধান ত্রৈমাসিক প্যাচ বান্ডল - নিরাপত্তা এবং রিগ্রেশন-টেস্টেড ফিক্স। বেশিরভাগ সাইট এটিই প্রয়োগ করে।
• Release Update Revision (RUR): একটি RU-এর একটি ছোট ফলো-আপ যাতে শুধু অতিরিক্ত ফিক্স থাকে, সেসব সাইটের জন্য যারা এক ধাপ বেশি রক্ষণশীল থাকতে চায়।
• OPatch: যে টুল প্যাচগুলোকে Oracle Home-এ (ডিস্কে থাকা সফটওয়্যার বাইনারি) ইনস্টল করে।
• Datapatch: যে টুল একটি প্যাচের প্রয়োজনীয় SQL-স্তরের পরিবর্তন ডেটাবেজের ভেতরে প্রয়োগ করে (ডেটা ডিকশনারি, প্যাকেজ)।
• OJVM patch: ইন-ডেটাবেজ Java VM-এর জন্য একটি আলাদা প্যাচ, প্রায়ই RU-এর পাশাপাশি প্রয়োগ করা হয়।

মূল মানসিক মডেল: OPatch সফটওয়্যার পরিবর্তন করে, Datapatch ডেটাবেজ পরিবর্তন করে। একটি প্যাচ তখনই সত্যিকারভাবে প্রয়োগ হয় যখন দুটোই চালানো হয়।

৩. প্যাচের আগের প্রস্তুতি - যেখান থেকে নিরাপত্তা আসে

প্রায় প্রতিটি প্যাচিং বিপর্যয়ের সূত্র একটি বাদ পড়া প্রি-চেকে গিয়ে ঠেকে। এগুলো প্রতিবার করুন, ব্যতিক্রম ছাড়াই।

-- 1. Update OPatch itself first - RUs often need a recent OPatch
$ORACLE_HOME/OPatch/opatch version

-- 2. Record what is currently installed (keep this output)
$ORACLE_HOME/OPatch/opatch lsinventory

-- 3. Check the new patch for conflicts BEFORE applying
cd /stage/patch/PATCH_NUMBER
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

-- 4. Confirm free space in the Oracle Home and archive area

আর অবিচ্ছেদ্য ধাপটি: প্যাচ করার আগে একটি ব্যাকআপ নিন। ন্যূনতম ডেটাবেজের একটি টাটকা RMAN backup, এবং আদর্শভাবে Oracle Home-এর একটি OS-স্তরের কপি বা স্ন্যাপশট যাতে আপনি দ্রুত বাইনারি পুনরুদ্ধার করতে পারেন। প্যাচ README পুরোপুরি পড়ুন - এটি সংস্করণ-নির্দিষ্ট ধাপ তালিকাভুক্ত করে যা সাধারণ গাইড করতে পারে না।

৪. একটি Release Update প্রয়োগ (Single Instance)

চেক পাস হয়ে গেলে এবং হাতে একটি ব্যাকআপ থাকলে, কার্যপ্রণালী সরল। সেই Oracle Home থেকে চলা ডেটাবেজ ও listener বন্ধ করুন, তারপর প্রয়োগ করুন।

-- Stop databases and listener using this ORACLE_HOME
srvctl stop database -d ORCL     # or SHUTDOWN IMMEDIATE
lsnrctl stop

-- Apply the Release Update to the Oracle Home
cd /stage/patch/PATCH_NUMBER
$ORACLE_HOME/OPatch/opatch apply

-- Bring the database back up
lsnrctl start
srvctl start database -d ORCL    # or STARTUP

৫. Datapatch - যে ধাপটি মানুষ ভুলে যায়

বাইনারি প্যাচ হয়ে যাওয়ার পর এবং ডেটাবেজ খোলা থাকলে, ডেটাবেজে SQL-স্তরের পরিবর্তন প্রয়োগ করতে Datapatch চালান। এটি বাদ দেওয়াই সেই ক্লাসিক ভুল যা একটি ডেটাবেজকে অর্ধেক-প্যাচড অবস্থায় রেখে দেয়।

-- With the database open, run from the patched Oracle Home
cd $ORACLE_HOME/OPatch
./datapatch -verbose

-- Verify what actually got applied in the database
SELECT patch_id, action, status, description
FROM   dba_registry_sqlpatch
ORDER  BY action_time;

যদি DBA_REGISTRY_SQLPATCH-এ RU-টি SUCCESS স্ট্যাটাসে দেখায়, তাহলে ডেটাবেজ দিকটি সম্পন্ন। একটি multitenant সেটআপে, Datapatch CDB এবং সব খোলা PDB-তে প্রয়োগ হয় - তাই নিশ্চিত করুন যে আপনার প্রয়োজনীয় প্রতিটি pluggable database এটি চলার সময় খোলা ছিল, একটি বিষয় যা multitenant গাইডে আলোচনা করা হয়েছে।

৬. RAC-এ শূন্য-ডাউনটাইম প্যাচিং

এখানেই Real Application Clusters তার লাইসেন্স অর্জন করে। যেহেতু একই ডেটাবেজ একাধিক নোডে চলে, আপনি একবারে একটি নোড প্যাচ করতে পারেন যখন বাকিগুলো ব্যবহারকারীদের সেবা দিতে থাকে - কোনো সার্ভিস আউটেজ ছাড়াই একটি রোলিং প্যাচ।

-- Rolling patch, node by node, using opatchauto (run as root)
-- Node 1: opatchauto relocates services, patches, brings it back
$ORACLE_HOME/OPatch/opatchauto apply /stage/patch/PATCH_NUMBER

-- When node 1 is confirmed healthy, repeat on node 2, then node 3...
-- Datapatch runs once after the last node, against the open database

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

৭. Rollback - সবসময় ফিরে আসার পথ জানুন

যে প্যাচ ঠিকমতো আচরণ করে না সেটি সরিয়ে ফেলা যায়। এই পথ না জেনে কখনো একটি প্যাচ শুরু করবেন না।

-- Roll the software patch out of the Oracle Home
$ORACLE_HOME/OPatch/opatch rollback -id PATCH_NUMBER

-- Then reverse the database changes with Datapatch
cd $ORACLE_HOME/OPatch
./datapatch -verbose

প্যাচ করার ঠিক পরে একটি পূর্ণ-ডেটাবেজ "কিছু একটা গভীরভাবে ভুল" পরিস্থিতির জন্য, প্যাচের আগে নেওয়া একটি guaranteed restore point আপনাকে কয়েক মিনিটের মধ্যে পুরো ডেটাবেজ রিওয়াইন্ড করতে দেয়। দুটোই স্তরে স্তরে রাখা - সাধারণ ক্ষেত্রে patch rollback, সবচেয়ে খারাপ ক্ষেত্রে Flashback - এটিই প্যাচিংকে কম-ঝুঁকিপূর্ণ করে তোলে।

৮. সাধারণ ভুল এবং কীভাবে সেগুলো সামলাবেন

• OPatch conflict detected: আগে প্রয়োগ করা একটি one-off patch RU-এর সাথে ওভারল্যাপ করে। prereq চেক এটি আগেই ধরে ফেলে; README-এর নির্দেশনা অনুযায়ী প্যাচের SQL merge দিয়ে বা সাংঘর্ষিক প্যাচটি রোল করে এটি সমাধান করুন।
• OPatch version too old: RU-গুলোর প্রায়ই বেস ইনস্টলে আসা OPatch-এর চেয়ে নতুন একটি OPatch দরকার হয়। প্রথমে OPatch আপডেট করুন - এটি একটি কারণেই ধাপ এক।
• Datapatch কিছু করার নেই বলে জানায়, কিন্তু RU ইনস্টল করা আছে: সাধারণত ডেটাবেজ খোলা ছিল না, অথবা আপনি ভুল Oracle Home থেকে Datapatch চালিয়েছেন। ডেটাবেজ খোলা রেখে প্যাচড হোম থেকে আবার চালান।
• প্যাচের মাঝপথে জায়গার ব্যর্থতা: Oracle Home ভরে গেছে। প্রি-চেকে ফাঁকা জায়গা নিশ্চিত করুন যাতে লাইভ অবস্থায় এটি কখনো না ঘটে।

৯. আসলে কত ঘন ঘন প্যাচ করা উচিত?

প্রতিটি Release Update প্রকাশের দিনই প্রয়োগ করা লক্ষ্য নয় - যুক্তিসঙ্গতভাবে বর্তমান ও অনুমানযোগ্য থাকাই লক্ষ্য। বেশিরভাগ প্রোডাকশন সাইটের জন্য একটি সুস্থ ছন্দ হলো একটি RU তার প্রকাশের এক থেকে দুই ত্রৈমাসিকের মধ্যে প্রয়োগ করা, একটু সময় মাঠে কাটানোর পর। যারা অতিরিক্ত রক্ষণশীলতা চায় তারা এর বদলে Release Update Revision-এর জন্য অপেক্ষা করে, যা একটি প্রমাণিত RU-এর উপর শুধু অতিরিক্ত ফিক্স যোগ করে।

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

দুটি সামঞ্জস্য নিয়ম অনেক কষ্ট বাঁচায়। প্রতিটি Oracle Home একই প্যাচ স্তরে রাখুন - অমিল RAC নোড বা তার primary-র চেয়ে ভিন্ন স্তরে থাকা একটি standby হলো বিপদ ডেকে আনা। আর Data Guard-এ, প্রথমে standby প্যাচ করুন, এটি যাচাই করুন, তারপর switch over করে পুরনো primary প্যাচ করুন, যাতে আপনার হাতে সবসময় ফিরে যাওয়ার জন্য একটি প্যাচড, সুস্থ ডেটাবেজ থাকে।

১০. একটি বাস্তব ত্রৈমাসিক: কোনো আউটেজ ছাড়াই একটি ব্যাংক কোর প্যাচিং

একটি তিন-নোড RAC ক্লাস্টারে থাকা একটি ব্যাংকিং ক্লায়েন্টের ত্রৈমাসিক নিরাপত্তা RU-তে বর্তমান থাকা দরকার ছিল, কিন্তু কোর সিস্টেম একটি maintenance outage নিতে পারত না। পদ্ধতিটি ছিল একটি সুশৃঙ্খল রোলিং প্যাচ: OPatch আপডেট করা, একটি staging কপির বিপরীতে conflict ও prerequisite চেক চালানো, একটি RMAN backup সহ একটি guaranteed restore point নেওয়া, তারপর opatchauto দিয়ে একবারে একটি নোড RU প্রয়োগ করা, প্রতিটি ধাপে সার্ভিস relocation ও নোড স্বাস্থ্য নিশ্চিত করা। শেষ নোডের পর Datapatch একবার চলল, আর DBA_REGISTRY_SQLPATCH সফলতা নিশ্চিত করল। ব্যবহারকারীরা পুরো সময় লেনদেন করল; একমাত্র দৃশ্যমান চিহ্ন ছিল একটি সংক্ষিপ্ত কানেকশন রিব্যালেন্স। এটিই প্যাচিং যেমন হওয়া উচিত - রুটিন, প্রমাণ-ভিত্তিক এবং ব্যবসার কাছে অদৃশ্য। এটি একটি নিয়মিত health check এবং একটি কঠোর নিরাপত্তা বেসলাইনের সাথে স্বাভাবিকভাবে জোড়া মেলে।

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

OPatch ও Datapatch-এর মধ্যে পার্থক্য কী?

OPatch প্যাচটিকে Oracle Home-এ ইনস্টল করে - এটি ডিস্কে থাকা সফটওয়্যার বাইনারি পরিবর্তন করে। Datapatch ডেটাবেজের ভেতরে সংশ্লিষ্ট SQL-স্তরের পরিবর্তন প্রয়োগ করে, যেমন ডেটা ডিকশনারি ও প্যাকেজ আপডেট। একটি Release Update তখনই সম্পূর্ণ প্রয়োগ হয় যখন দুটোই চালানো হয়; শুধু OPatch চালালে ডেটাবেজ অর্ধেক-প্যাচড অবস্থায় থেকে যায়।

Oracle Release Update (RU) কী?

Release Update হলো Oracle-এর প্রধান ত্রৈমাসিক প্যাচ বান্ডল, যাতে একটি রিলিজের নিরাপত্তা ফিক্স ও রিগ্রেশন-টেস্টেড স্থিতিশীলতা ফিক্স থাকে। বেশিরভাগ সাইট বর্তমান থাকার জন্য RU প্রয়োগ করে। Release Update Revision (RUR) হলো একটি ছোট, আরও রক্ষণশীল ফলো-আপ, যাতে একটি নির্দিষ্ট RU-এর উপর শুধু অতিরিক্ত ফিক্স থাকে।

আমি কি ডাউনটাইম ছাড়া Oracle RAC প্যাচ করতে পারি?

হ্যাঁ। যেহেতু RAC একই ডেটাবেজ একাধিক নোডে চালায়, আপনি একবারে একটি নোড প্যাচ করেন - একটি রোলিং প্যাচ - তাই বাকি নোডগুলো পুরো সময় ব্যবহারকারীদের সেবা দিতে থাকে। opatchauto-এর মতো টুল যে নোডটি প্যাচ করা হচ্ছে সেখান থেকে সার্ভিস সরিয়ে নেয় এবং পরে ফিরিয়ে আনে, আর শেষে খোলা ডেটাবেজের বিপরীতে Datapatch একবার চলে।

একটি প্যাচ সত্যিই ডেটাবেজে প্রয়োগ হয়েছে কিনা আমি কীভাবে যাচাই করব?

Datapatch চালানোর পর DBA_REGISTRY_SQLPATCH কোয়েরি করুন। এটি প্রতিটি প্যাচ, অ্যাকশন এবং স্ট্যাটাস SUCCESS কিনা তা দেখায়। সফটওয়্যারের দিকে, opatch lsinventory Oracle Home-এ ইনস্টল করা প্যাচ দেখায়। দুটো মিলে একটি সম্পূর্ণ প্রয়োগ নিশ্চিত করে।

যেকোনো Oracle প্যাচ প্রয়োগের আগে আমার কী করা উচিত?

OPatch আপডেট করুন, opatch lsinventory দিয়ে বর্তমান inventory রেকর্ড করুন, নতুন প্যাচের বিপরীতে conflict ও prerequisite চেক চালান, ফাঁকা জায়গা নিশ্চিত করুন এবং একটি ব্যাকআপ নিন - একটি RMAN ব্যাকআপ এবং আদর্শভাবে Oracle Home-এর একটি কপি, সেই সাথে একটি guaranteed restore point। সংস্করণ-নির্দিষ্ট ধাপের জন্য প্যাচ README পুরোপুরি পড়ুন।