Oracle AI Database 23.26.2 ഉപയോഗിച്ച് ഒരു സിംഗിൾ Data Guard Broker കമാൻഡ് വഴി ഒരു standby pluggable database (PDB)-ഉം അതിന്റെ redo logs-ഉം വേഗത്തിൽ സജ്ജീകരിക്കാൻ (spin up) സാധിക്കും. ഇത് ഡിസാസ്റ്റർ റിക്കവറി (disaster-recovery) ക്രമീകരണങ്ങളെ കാലങ്ങളായി മന്ദഗതിയിലാക്കിയിരുന്ന ഫയലുകൾ നേരിട്ട് കോപ്പി ചെയ്യേണ്ടി വരുന്ന രീതി ഒഴിവാക്കുന്നു.

ഇതിന്റെ പ്രാധാന്യം

ഒരു ഫിസിക്കൽ standby PDB നിർമ്മിക്കുന്നതിന് നിരവധി മാനുവൽ നടപടികൾ ആവശ്യമായിരുന്നു: ഓരോ datafile-ഉം standby container-ലേക്ക് കോപ്പി ചെയ്യുക, പ്രത്യേക ALTER കമാൻഡുകൾ ഉപയോഗിച്ച് standby redo logs (SRLs) നിർമ്മിക്കുക, കൂടാതെ മുഴുവൻ കോൺഫിഗറേഷനും വീണ്ടും പരിശോധിക്കുക എന്നിവയാണവ. ഓരോ ഘട്ടത്തിലും ടൈപ്പിംഗ് പിശകുകൾ (typo), ഫയലുകൾ വിട്ടുപോവുക, അല്ലെങ്കിൽ തെറ്റായ log group ഉപയോഗിക്കുക തുടങ്ങിയ റിസ്കുകൾ ഉണ്ട്. ഇത് റിക്കവറി ടെസ്റ്റിംഗിനെ വൈകിപ്പിക്കുകയോ അല്ലെങ്കിൽ ഏറ്റവും മോശമായ സാഹചര്യത്തിൽ failover തടസ്സപ്പെടുത്തുകയോ ചെയ്തേക്കാം. ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നത് ഇത്തരം റിസ്കുകൾ കുറയ്ക്കുകയും DBAs-ന് ഉയർന്ന തലത്തിലുള്ള ജോലികളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ സമയം നൽകുകയും ചെയ്യുന്നു.

മുൻപ് standby PDB-കൾ എങ്ങനെയാണ് നിർമ്മിച്ചിരുന്നത്

Multitenant ആർക്കിടെക്ചറിൽ, ഒരു primary CDB (container database) ഒന്നോ അതിലധികമോ PDB-കൾ ഉൾക്കൊള്ളുന്നു. ഒരു PDB സംരക്ഷിക്കുന്നതിനായി അഡ്മിനിസ്ട്രേറ്റർമാർ താഴെ പറയുന്നവ ചെയ്യേണ്ടി വരുമായിരുന്നു:

  • ഓരോ datafile-ഉം തിരിച്ചറിഞ്ഞ് primary-യിൽ നിന്ന് standby host-ലേക്ക് കോപ്പി ചെയ്യുക.
  • Primary-യുടെ redo-log ലേഔട്ടിന് അനുസൃതമായി SRL-കൾ മാനുവലായി നിർമ്മിക്കുക.
  • Standby സിൻക്രൊണൈസ് ചെയ്യുന്നതിനായി RMAN restore അല്ലെങ്കിൽ duplicate കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുക.
  • Standby-ക്ക് ഒരു switchover സ്വീകരിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കാൻ പരിശോധനകൾ നടത്തുക.

വലിയ PDB-കളുടെ കാര്യത്തിൽ ഈ പ്രക്രിയയ്ക്ക് മണിക്കൂറുകൾ എടുത്തേക്കാം, കൂടാതെ ചെറിയൊരു പിശക് പോലും standby ഉപയോഗശൂന്യമാക്കിയേക്കാം.

23.26.2 അപ്‌ഡേറ്റ് ചെയ്യുന്നത് എന്താണ്

ഏറ്റവും പുതിയ Oracle AI Database റിലീസ് ആവശ്യമായ ഘട്ടങ്ങളെ Data Guard Broker-ലേക്ക് ഉൾപ്പെടുത്തിയിരിക്കുന്നു. ഒരു സിംഗിൾ ADD PLUGGABLE DATABASE സ്റ്റേറ്റ്‌മെന്റ് നൽകുന്നതിലൂടെ, broker താഴെ പറയുന്നവ ചെയ്യുന്നു:

  1. പുതിയ standby PDB-യെ primary-യുമായി രജിസ്റ്റർ ചെയ്യുന്നു.
  2. ആവശ്യമായ datafiles പശ്ചാത്തലത്തിൽ (behind the scenes) കോപ്പി ചെയ്യുന്നു—ഇതിനായി 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-യുടെ പകർപ്പായി, cdb2 എന്ന സെക്കൻഡറി CDB-യിൽ AMOL എന്ന പേരിൽ ഒരു standby PDB രചയിതാവ് നിർമ്മിച്ചു. Broker ഈ പ്രക്രിയ നിമിഷങ്ങൾക്കുള്ളിൽ പൂർത്തിയാക്കി. RMAN restore പ്രവർത്തിച്ചില്ല, OS ലോഗുകളിൽ മാനുവൽ ഫയൽ കോപ്പികൾ ഒന്നും കണ്ടില്ല, കൂടാതെ ALTER DATABASE സ്റ്റേറ്റ്‌മെന്റുകൾ ഇല്ലാതെ തന്നെ standby redo log ഗ്രൂപ്പുകൾ കാറ്റലോഗിൽ പ്രത്യക്ഷപ്പെട്ടു.

PDB തുറന്നപ്പോൾ അത് READ ONLY മോഡിലേക്ക് മാറി, ഇത് അതിന്റെ physical-standby സ്റ്റാറ്റസ് സ്ഥിരീകരിച്ചു. Datafiles പരിശോധിച്ചപ്പോൾ അവ standby സൈഡിൽ സജ്ജീകരിച്ചിട്ടുണ്ടെന്ന് (provisioned) തെളിഞ്ഞു. Redo apply ഇതിനകം തന്നെ പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു, കൂടാതെ കോൺഫിഗറേഷൻ ഒരു switchover-ന് തയ്യാറാണെന്ന് broker റിപ്പോർട്ട് ചെയ്തു.

DBAs-നുള്ള പ്രത്യാഘാതങ്ങൾ

ഈ ഓട്ടോമേഷൻ മനുഷ്യസഹജമായ പിശകുകൾ കുറയ്ക്കുകയും പ്ലാനിംഗ് മുതൽ പ്രൊഡക്ഷൻ standby വരെയുള്ള സമയം ഗണ്യമായി കുറയ്ക്കുകയും ചെയ്യുന്നു. ടീമുകൾക്ക് ഇനി മണിക്കൂറുകൾക്ക് പകരം മിനിറ്റുകൾക്കുള്ളിൽ standby PDB-കൾ സജ്ജീകരിക്കാൻ കഴിയും, ഇത് പുതിയ സർവീസുകൾ ഇടയ്ക്കിടെ സജ്ജീകരിക്കുന്ന സാഹചര്യങ്ങളിൽ വളരെ വിലപ്പെട്ടതാണ്.

ഇതിന്റെ ഒരു പരിമിതി Data Guard Broker-ന്റെ ഇന്റേണൽ ലോജിക്കിന്മേലുള്ള അമിതമായ ആശ്രയത്വമാണ്. കൂടുതൽ നിയന്ത്രണം (granular control) നിലനിർത്താനോ അല്ലെങ്കിൽ കസ്റ്റം മോണിറ്ററിംഗ് ടൂളുകളുമായി സംയോജിപ്പിക്കാനോ ചില DBAs ഓരോ ഘട്ടവും സ്വന്തമായി സ്ക്രിപ്റ്റ് ചെയ്യാൻ താൽപ്പര്യപ്പെടുന്നു. സങ്കീർണ്ണമായ സെറ്റപ്പുകളിൽ—ഒന്നിലധികം നെറ്റ്‌വർക്കുകൾ, വ്യത്യസ്തതരം സ്റ്റോറേജ് (heterogeneous storage), അല്ലെങ്കിൽ നോൺ-സ്റ്റാൻഡേർഡ് redo ലേഔട്ടുകൾ എന്നിവയുള്ള സാഹചര്യങ്ങളിൽ—broker-ന്റെ ഡിഫോൾട്ട് ക്രമീകരണങ്ങൾ തങ്ങളുടെ പോളിസികളുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് അഡ്മിനിസ്ട്രേറ്റർമാർ പരിശോധിക്കേണ്ടി വന്നേക്കാം.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

ഈ ഓട്ടോമേഷനിൽ കൂടുതൽ വിപുലീകരണങ്ങൾ വരുത്തുമെന്ന് Oracle പ്രഖ്യാപിച്ചിട്ടില്ല, എങ്കിലും ഭാവി റിലീസുകളിൽ കൂടുതൽ multitenant DR വർക്ക്ഫ്ലോകൾ broker-ലേക്ക് കൊണ്ടുവന്നേക്കാം എന്ന് ഈ നീക്കം സൂചിപ്പിക്കുന്നു. താഴെ പറയുന്നവ ശ്രദ്ധിക്കുക:

  • കൂടുതൽ standby തരങ്ങൾക്കുള്ള പിന്തുണ (ഉദാഹരണത്തിന്, logical standby PDB-കൾ).
  • ഓഡിറ്റിംഗ് ആവശ്യങ്ങൾക്കായി broker എടുക്കുന്ന തീരുമാനങ്ങൾ വ്യക്തമാക്കുന്ന വിപുലമായ ലോഗിംഗ് (logging).
  • മുമ്പ് മാനുവൽ RMAN സ്റ്റെപ്പുകളെ ആശ്രയിച്ചിരുന്ന തേർഡ് പാർട്ടി ബാക്കപ്പ് ടൂളുകളുമായുള്ള പൊരുത്തപ്പെടൽ (compatibility) പരിശോധനകൾ.

നിങ്ങളുടെ സ്ഥാപനം Oracle AI Database ഒരു high-availability കോൺഫിഗറേഷനിൽ ആണ് പ്രവർത്തിപ്പിക്കുന്നതെങ്കിൽ, അതിന്റെ ആഘാതം മനസ്സിലാക്കാൻ ഒരു non-production CDB-യിൽ പുതിയ കമാൻഡ് പരീക്ഷിച്ചു നോക്കുന്നതാണ് ഏറ്റവും വേഗത്തിലുള്ള വഴി.

ചുരുക്കത്തിൽ: Oracle AI Database 23.26.2, പല ഘട്ടങ്ങളിലൂടെയും പിശകുകൾ സംഭവിക്കാൻ സാധ്യതയുള്ളതുമായ standby PDB സജ്ജീകരണത്തെ ഒരു സിംഗിൾ-ലൈൻ ഓപ്പറേഷനാക്കി മാറ്റുന്നു. ഇത് multitenant എൻവയോൺമെന്റുകൾക്ക് വേഗതയേറിയതും കൂടുതൽ വിശ്വസനീയവുമായ ഡിസാസ്റ്റർ റിക്കവറി നൽകുന്നു.