Oracle AI Database 23.26.2 آپ کو ایک ہی Data Guard Broker کمانڈ کے ذریعے اسٹینڈ بائی پلگ ایبل ڈیٹا بیس (PDB) اور اس کے redo logs تیار کرنے کی سہولت دیتا ہے، جس سے فائلوں کو دستی طور پر کاپی کرنے کا وہ روٹین ختم ہو جاتا ہے جو طویل عرصے سے ڈیزاسٹر ریکوری (disaster-recovery) سیٹ اپس کی رفتار کو کم کر رہا تھا۔

یہ کیوں اہم ہے

ایک فزیکل اسٹینڈ بائی PDB بنانے کے لیے کئی دستی اقدامات درکار ہوتے تھے: ہر datafile کو اسٹینڈ بائی کنٹینر میں کاپی کرنا، واضح ALTER کمانڈز کے ذریعے standby redo logs (SRLs) بنانا، اور پوری کنفیگریشن کی دوبارہ جانچ کرنا۔ ہر مرحلے میں ٹائپو (typo)، فائل کے چھوٹ جانے، یا لاگ گروپ کے غلط ہونے کا خطرہ ہوتا ہے، جو ریکوری ٹیسٹنگ میں تاخیر کر سکتا ہے یا بدترین صورت میں failover کو ناکام بنا سکتا ہے۔ اس عمل کو خودکار (automate) کرنے سے یہ خطرات کم ہو جاتے ہیں اور DBAs کو اعلیٰ سطح کے کاموں پر توجہ مرکوز کرنے کا موقع ملتا ہے۔

پہلے اسٹینڈ بائی PDBs کیسے بنائے جاتے تھے

Multitenant architecture میں، ایک primary CDB (container database) ایک یا ایک سے زیادہ PDBs کی میزبانی کرتا ہے۔ ایک PDB کی حفاظت کے لیے، ایڈمنسٹریٹرز کو یہ کرنا پڑتا تھا:

  • Primary سے standby host تک ہر datafile کی شناخت کرنا اور اسے کاپی کرنا۔
  • دستی طور پر SRLs بنانا جو primary کے redo-log لے آؤٹ کے مطابق ہوں۔
  • Standby کو سنک (sync) میں لانے کے لیے RMAN restores یا duplicate کمانڈز چلانا۔
  • تصدیقی مراحل (verification steps) کا ایک سلسلہ چلانا تاکہ اس بات کو یقینی بنایا جا سکے کہ standby switchover قبول کر سکتا ہے۔

یہ ورک فلو کئی گھنٹوں تک جاری رہ سکتا تھا، خاص طور پر بڑے PDBs کے لیے، اور کسی بھی غلطی کی وجہ سے standby ناقابل استعمال ہو سکتا تھا۔

23.26.2 اپ ڈیٹ کیا کرتی ہے

Oracle AI Database کا تازہ ترین ورژن مطلوبہ مراحل کو Data Guard Broker میں شامل کر دیتا ہے۔ محض ایک ADD PLUGGABLE DATABASE اسٹیٹمنٹ کے ذریعے، broker درج ذیل کام کرتا ہے:

  1. نئے standby PDB کو primary کے ساتھ رجسٹر کرتا ہے۔
  2. پس منظر میں ضروری datafiles کو کاپی کرتا ہے—اس کے لیے کسی RMAN restore یا دستی فائل کاپی کی ضرورت نہیں ہوتی۔
  3. مناسب standby redo logs تیار کرتا ہے اور انہیں خودکار طور پر standby CDB میں شامل کر دیتا ہے۔
  4. PDB کو READ ONLY موڈ میں رکھتا ہے، جو فزیکل اسٹینڈ بائی switchover کے لیے تیار ہوتا ہے۔

ٹیسٹ میں استعمال ہونے والی کمانڈ یہ تھی:

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

ایک حقیقی دنیا کا ٹیسٹ

مصنف نے cdb1 پر موجود primary PDB کی نقل (mirror) کے طور پر ایک ثانوی CDB (cdb2) پر AMOL نامی ایک standby PDB بنایا۔ Broker نے یہ آپریشن فوری طور پر مکمل کر لیا۔ کوئی RMAN restore نہیں چلا، OS logs میں کوئی دستی فائل کاپی نظر نہیں آئی، اور standby redo log گروپس بغیر کسی ALTER DATABASE اسٹیٹمنٹ کے کیٹلاگ میں ظاہر ہو گئے۔

PDB کو کھولنے سے وہ READ ONLY موڈ میں چلا گیا، جس سے اس کے physical-standby ہونے کی تصدیق ہوئی۔ Datafiles کی فوری جانچ سے ثابت ہوا کہ انہیں standby سائیڈ پر فراہم (provision) کر دیا گیا تھا۔ Redo apply پہلے ہی چل رہا تھا، اور broker نے رپورٹ کیا کہ کنفیگریشن switchover کے لیے تیار ہے۔

DBAs کے لیے اثرات

یہ خودکاری (automation) انسانی غلطی کے امکان کو کم کرتی ہے اور منصوبہ بندی سے لے کر پروڈکشن اسٹینڈ بائی تک کے وقت میں نمایاں کمی لاتی ہے۔ ٹیمیں اب گھنٹوں کے بجائے منٹوں میں standby PDBs فراہم کر سکتی ہیں، جو کہ ان ماحول کے لیے خاص طور پر قیمتی ہے جہاں نئی سروسز کثرت سے شروع کی جاتی ہیں۔

اس کا ایک پہلو Data Guard Broker کے اندرونی منطق (internal logic) پر زیادہ انحصار ہے۔ کچھ DBAs باریک بینی سے کنٹرول برقرار رکھنے یا کسٹم مانیٹرنگ ٹولز کے ساتھ انٹیگریٹ کرنے کے لیے ہر مرحلے کو خود اسکرپٹ کرنا پسند کرتے ہیں۔ پیچیدہ سیٹ اپس میں—جیسے متعدد نیٹ ورکس، مختلف قسم کا اسٹوریج (heterogeneous storage)، یا غیر معیاری redo لے آؤٹ—ایڈمنسٹریٹرز کو اب بھی اس بات کی تصدیق کرنے کی ضرورت پڑ سکتی ہے کہ broker کی ڈیفالٹ سیٹنگز ان کی پالیسیوں کے مطابق ہیں۔

آگے کیا دیکھنا ہے

Oracle نے اس خودکاری کے مزید توسیع کا اعلان نہیں کیا ہے، لیکن یہ اقدام ظاہر کرتا ہے کہ مستقبل کے ریلیزز multitenant DR ورک فلو کے مزید حصوں کو broker میں منتقل کر سکتے ہیں۔ ان چیزوں پر نظر رکھیں:

  • اضافی اسٹینڈ بائی اقسام کے لیے سپورٹ (مثلاً، logical standby PDBs)۔
  • وسیع تر لاگنگ جو آڈٹ کے مقاصد کے لیے broker کے فیصلوں کو ظاہر کرے۔
  • تھرڈ پارٹی بیک اپ ٹولز کے ساتھ مطابقت (compatibility) کی جانچ، جو پہلے دستی RMAN مراحل پر انحصار کرتے تھے۔

اگر آپ کا ادارہ high-availability کنفیگریشن میں Oracle AI Database چلا رہا ہے، تو اثرات کا اندازہ لگانے کا تیز ترین طریقہ غیر پیداواری (non-production) CDB پر نئی کمانڈ کا تجربہ کرنا ہے۔

خلاصہ: Oracle AI Database 23.26.2 کئی مراحل پر مشتمل اور غلطی کے امکان والے standby PDB سیٹ اپ کو ایک ہی لائن کے آپریشن میں بدل دیتا ہے، جو multitenant ماحول کے لیے تیز رفتار اور زیادہ قابل اعتماد ڈیزاسٹر ریکوری فراہم کرتا ہے۔