Oracle AI Database 23.26.2 আপনাকে একটি মাত্র Data Guard Broker কমান্ডের মাধ্যমে একটি standby pluggable database (PDB) এবং এর redo logs তৈরি করার সুবিধা দেয়, যা ফাইল কপি করার সেই দীর্ঘদিনের ম্যানুয়াল পদ্ধতিকে দূর করে দেয় যা ডিজাস্টার-রিকভারি (disaster-recovery) সেটআপের গতি কমিয়ে দিত।

কেন এটি গুরুত্বপূর্ণ

একটি physical standby PDB তৈরি করতে অনেকগুলো ম্যানুয়াল ধাপ অনুসরণ করতে হতো: প্রতিটি datafile স্ট্যান্ডবাই কন্টেইনারে কপি করা, explicit ALTER কমান্ডের মাধ্যমে standby redo logs (SRLs) তৈরি করা এবং পুরো কনফিগারেশনটি পুনরায় যাচাই করা। প্রতিটি ধাপে টাইপো (typo), ফাইল বাদ পড়া বা ভুল log group-এর ঝুঁকি থাকে, যা রিকভারি টেস্টিং বিলম্বিত করতে পারে অথবা সবচেয়ে খারাপ ক্ষেত্রে failover প্রক্রিয়াকে ব্যাহত করতে পারে। এই প্রক্রিয়াটি স্বয়ংক্রিয় করার ফলে ঝুঁকি কমে এবং DBA-রা উচ্চতর গুরুত্বপূর্ণ কাজে মনোযোগ দেওয়ার সুযোগ পান।

আগে যেভাবে standby PDB তৈরি করা হতো

Multitenant আর্কিটেকচারে, একটি primary CDB (container database) এক বা একাধিক PDB হোস্ট করে। একটি PDB সুরক্ষিত করার জন্য অ্যাডমিনিস্ট্রেটরদের যা করতে হতো:

  • Primary থেকে প্রতিটি datafile শনাক্ত করা এবং তা standby host-এ কপি করা।
  • Primary-এর redo-log লেআউটের সাথে মিল রেখে ম্যানুয়ালি SRLs তৈরি করা।
  • Standby-কে সিঙ্ক্রোনাইজ করার জন্য RMAN restore বা duplicate কমান্ড চালানো।
  • Standby-টি switchover গ্রহণ করতে পারবে কিনা তা নিশ্চিত করতে ধারাবাহিক ভেরিফিকেশন ধাপগুলো সম্পন্ন করা।

এই কাজের প্রক্রিয়াটি কয়েক ঘণ্টা পর্যন্ত সময় নিতে পারত, বিশেষ করে বড় PDB-এর ক্ষেত্রে, এবং সামান্য ভুলও standby-টিকে অকেজো করে দিতে পারত।

23.26.2 আপডেটটি কী করে

সর্বশেষ Oracle AI Database রিলিজটি প্রয়োজনীয় ধাপগুলোকে Data Guard Broker-এর ভেতরেই অন্তর্ভুক্ত করেছে। একটি মাত্র ADD PLUGGABLE DATABASE স্টেটমেন্ট প্রদানের মাধ্যমে, broker নিচের কাজগুলো করে:

  1. Primary-এর সাথে নতুন standby PDB-টিকে রেজিস্টার করে।
  2. পর্দার আড়ালে প্রয়োজনীয় datafiles কপি করে—এর জন্য কোনো RMAN restore বা ম্যানুয়াল ফাইল কপি করার প্রয়োজন হয় না।
  3. যথাযথ standby redo logs তৈরি করে এবং সেগুলো স্বয়ংক্রিয়ভাবে standby CDB-তে যুক্ত করে।
  4. PDB-টিকে READ ONLY মোডে রাখে, যা একটি physical standby switchover-এর জন্য প্রস্তুত থাকে।

টেস্টে ব্যবহৃত কমান্ডটি ছিল:

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

একটি বাস্তবধর্মী পরীক্ষা

লেখক cdb1-এর একটি primary PDB-এর সাথে মিল রেখে একটি secondary CDB (cdb2)-তে AMOL নামে একটি standby PDB তৈরি করেছেন। Broker মুহূর্তের মধ্যেই কাজটি সম্পন্ন করেছে। কোনো RMAN restore চলেনি, OS লগে কোনো ম্যানুয়াল ফাইল কপি দেখা যায়নি এবং কোনো ALTER DATABASE স্টেটমেন্ট ছাড়াই standby redo log গ্রুপগুলো ক্যাটালগে দেখা গেছে।

PDB-টি ওপেন করার সাথে সাথে এটি READ ONLY মোডে চলে যায়, যা এর physical-standby স্ট্যাটাস নিশ্চিত করে। Datafiles-এর একটি দ্রুত পরীক্ষা প্রমাণ করে যে সেগুলো standby সাইডে প্রোভিশন করা হয়েছে। Redo apply ইতিমধ্যেই চলছিল এবং broker রিপোর্ট করেছে যে কনফিগারেশনটি switchover-এর জন্য প্রস্তুত।

DBA-দের জন্য এর প্রভাব

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

এর একটি সীমাবদ্ধতা হলো Data Guard Broker-এর ইন্টারনাল লজিকের ওপর অধিক নির্ভরতা। কিছু DBA সূক্ষ্ম নিয়ন্ত্রণ বজায় রাখতে বা কাস্টম মনিটরিং টুলের সাথে ইন্টিগ্রেট করার জন্য প্রতিটি ধাপ নিজে স্ক্রিপ্ট করা পছন্দ করেন। জটিল সেটআপে—যেমন একাধিক নেটওয়ার্ক, হেটেরোজিনিয়াস স্টোরেজ (heterogeneous storage), বা নন-স্ট্যান্ডার্ড redo লেআউট—অ্যাডমিনিস্ট্রেটরদের এখনও যাচাই করার প্রয়োজন হতে পারে যে ব্রোকারের ডিফল্ট সেটিংস তাদের পলিসির সাথে সামঞ্জস্যপূর্ণ কিনা।

পরবর্তী বিষয়গুলো যা খেয়াল রাখতে হবে

Oracle এই অটোমেশনের আরও সম্প্রসারণের কথা ঘোষণা করেনি, তবে এই পদক্ষেপটি ইঙ্গিত দেয় যে ভবিষ্যতের রিলিজগুলোতে multitenant DR ওয়ার্কফ্লোর আরও বেশি অংশ ব্রোকারের আওতায় আসতে পারে। নিচের বিষয়গুলোর দিকে নজর রাখুন:

  • অতিরিক্ত standby টাইপের সাপোর্ট (যেমন, logical standby PDBs)।
  • বর্ধিত লগিং যা অডিট করার উদ্দেশ্যে ব্রোকারের সিদ্ধান্তগুলো প্রকাশ করবে।
  • থার্ড-পার্টি ব্যাকআপ টুলের সাথে সামঞ্জস্যতা যাচাই, যা আগে ম্যানুয়াল RMAN ধাপের ওপর নির্ভর করত।

আপনার প্রতিষ্ঠান যদি high-availability কনফিগারেশনে Oracle AI Database ব্যবহার করে থাকে, তবে প্রভাব বোঝার জন্য একটি non-production CDB-তে নতুন কমান্ডটি পরীক্ষা করে দেখা সবচেয়ে দ্রুততম উপায়।

সারকথা: Oracle AI Database 23.26.2 একটি বহু-ধাপ বিশিষ্ট এবং ভুল হওয়ার সম্ভাবনা থাকা standby PDB সেটআপকে একটি মাত্র লাইনের অপারেশনে রূপান্তরিত করেছে, যা multitenant এনভায়রনমেন্টের জন্য দ্রুততর এবং আরও নির্ভরযোগ্য ডিজাস্টার রিকভারি নিশ্চিত করে।