Oracle AI Database 23.26.2 மூலம், ஒரு ஒற்றை Data Guard Broker கட்டளை மூலமே ஒரு standby pluggable database (PDB) மற்றும் அதன் redo logs-களை உருவாக்க முடியும். இது நீண்டகாலமாக disaster-recovery அமைப்புகளைத் தாமதப்படுத்தியிருந்த கோப்புகளைக் கையால் நகலெடுக்கும் (copy-files-by-hand) முறையைத் தவிர்க்கிறது.
இது ஏன் முக்கியமானது
ஒரு physical standby PDB-யை உருவாக்குவதற்குத் தொடர்ச்சியான கைமுறைச் செயல்பாடுகள் தேவைப்பட்டன: ஒவ்வொரு datafile-வையும் standby container-க்கு நகலெடுப்பது, explicit ALTER கட்டளைகளைப் பயன்படுத்தி standby redo logs (SRLs)-களை உருவாக்குவது மற்றும் முழுமையான கட்டமைப்பை (configuration) மீண்டும் சரிபார்ப்பது. ஒவ்வொரு படிநிலையிலும் தட்டச்சுப் பிழைகள் (typo), கோப்புகளைத் தவறவிடுதல் அல்லது பொருந்தாத log group போன்ற அபாயங்கள் உள்ளன. இவை recovery testing-ஐத் தாமதப்படுத்தலாம் அல்லது மிக மோசமான நிலையில், failover செயல்முறையைத் தடுக்கலாம். இந்தச் செயல்பாட்டைத் தானியக்கமாக்குவது (automating) அந்த அபாயங்களைக் குறைப்பதோடு, DBAs உயர்நிலைத் பணிகளில் கவனம் செலுத்தவும் வழிவகை செய்கிறது.
இதற்கு முன்பு standby PDB-கள் எவ்வாறு உருவாக்கப்பட்டன
Multitenant கட்டமைப்பில், ஒரு primary CDB (container database) ஒன்று அல்லது அதற்கு மேற்பட்ட PDB-களைக் கொண்டிருக்கும். ஒரு PDB-யைப் பாதுகாக்க, நிர்வாகிகள் பின்வருவனவற்றைச் செய்ய வேண்டியிருந்தது:
- Primary-யிலிருந்து ஒவ்வொரு datafile-வையும் கண்டறிந்து standby host-க்கு நகலெடுக்க வேண்டும்.
- Primary-யின் redo-log அமைப்பைப் பிரதிபலிக்கும் வகையில் SRL-களைக் கைமுறையாக உருவாக்க வேண்டும்.
- Standby-யை sync-இல் கொண்டு வர RMAN restores அல்லது duplicate கட்டளைகளை இயக்க வேண்டும்.
- Standby ஒரு switchover-ஐ ஏற்கத் தயாராக இருப்பதை உறுதி செய்யத் தொடர்ச்சியான சரிபார்ப்புப் படிநிலைகளை (verification steps) மேற்கொள்ள வேண்டும்.
இந்தச் செயல்முறை பல மணிநேரங்கள் நீடிக்கக்கூடும், குறிப்பாகப் பெரிய PDB-களுக்கு இது பொருந்தும். மேலும், இதில் ஏற்படும் சிறு தவறு கூட standby-யைப் பயன்படுத்த முடியாத நிலைக்குத் தள்ளக்கூடும்.
23.26.2 அப்டேட் என்ன செய்கிறது
சமீபத்திய Oracle AI Database வெளியீடு, தேவையான படிநிலைகளை Data Guard Broker-க்குள் ஒருங்கிணைத்துள்ளது. ஒரு ஒற்றை ADD PLUGGABLE DATABASE அறிக்கையை (statement) வழங்குவதன் மூலம், broker பின்வருவனவற்றைச் செய்கிறது:
- புதிய standby PDB-யை primary-யுடன் பதிவு செய்கிறது.
- தேவையான datafile-களைப் பின்னணியில் நகலெடுக்கிறது—இதற்கு RMAN restore அல்லது கைமுறை கோப்பு நகலெடுப்பு தேவையில்லை.
- பொருத்தமான standby redo logs-களை உருவாக்கி, அவற்றைச் தானாகவே standby CDB-யுடன் சேர்க்கிறது.
- 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 logs-இல் எந்த கைமுறை கோப்பு நகலெடுப்புகளும் தெரியவில்லை, மேலும் எந்த ALTER DATABASE அறிக்கைகளும் இன்றி standby redo log groups விபரங்கள் catalog-இல் தோன்றின.
PDB-யைத் திறந்தபோது அது READ ONLY நிலைக்கு மாறியது, இது அதன் physical-standby நிலையை உறுதிப்படுத்தியது. datafile-களை விரைவாகச் சரிபார்த்தபோது, அவை standby பக்கத்தில் ஒதுக்கப்பட்டிருப்பதை (provisioned) உறுதிப்படுத்தியது. Redo apply ஏற்கனவே இயங்கிக் கொண்டிருந்தது, மேலும் configuration switchover-க்குத் தயாராக இருப்பதாக broker தெரிவித்தது.
DBAs-க்கான தாக்கங்கள்
இந்தத் தானியக்கமாக்கல் மனிதத் தவறுகளுக்கான வாய்ப்பைக் குறைப்பதோடு, திட்டமிடலில் இருந்து production standby வரை எடுத்துக்கொள்ளும் நேரத்தையும் பெருமளவு குறைக்கிறது. குழுக்கள் இப்போது மணிநேரங்களுக்குப் பதிலாக நிமிடங்களிலேயே standby PDB-களை உருவாக்க முடியும், இது அடிக்கடி புதிய சேவைகளைத் தொடங்கும் (spin up) சூழல்களுக்கு மிகவும் பயனுள்ளதாக இருக்கும்.
இதன் ஒரு சவாலான அம்சம் (trade-off), Data Guard Broker-இன் உள் தர்க்கத்தை (internal logic) அதிகம் சார்ந்திருக்க வேண்டியிருக்கும் என்பதாகும். சில DBAs நுணுக்கமான கட்டுப்பாட்டை (granular control) வைத்திருக்க அல்லது தனிப்பயனாக்கப்பட்ட கண்காணிப்பு கருவிகளுடன் (custom monitoring tools) ஒருங்கிணைக்க, ஒவ்வொரு படிநிலையையும் தாங்களாகவே ஸ்கிரிப்ட் செய்ய விரும்புகிறார்கள். சிக்கலான அமைப்புகளில்—பல நெட்வொர்க்குகள், மாறுபட்ட சேமிப்பகங்கள் (heterogeneous storage) அல்லது தரமற்ற redo layouts—நிர்வாகிகள் broker-இன் இயல்புநிலை அமைப்புகள் (defaults) தங்களது கொள்கைகளுடன் ஒத்துப்போகின்றனவா என்பதை இன்னும் சரிபார்க்க வேண்டியிருக்கலாம்.
அடுத்து கவனிக்க வேண்டியவை
இந்தத் தானியக்கமாக்கலுக்கான கூடுதல் விரிவாக்கங்களை Oracle இன்னும் அறிவிக்கவில்லை, ஆனால் இந்த நகர்வு, எதிர்கால வெளியீடுகள் multitenant DR workflow-இன் அதிகப்படியான பகுதிகளை broker-க்குள் கொண்டு வரக்கூடும் என்பதைக் காட்டுகிறது. பின்வருவனவற்றைக் கவனியுங்கள்:
- கூடுதல் standby வகைகளுக்கான ஆதரவு (எ.கா., logical standby PDBs).
- தணிக்கை நோக்கங்களுக்காக (audit purposes) broker முடிவுகளை வெளிப்படுத்தும் விரிவான logging.
- இதற்கு முன்பு கைமுறை RMAN படிநிலைகளைச் சார்ந்திருந்த மூன்றாம் தரப்பு backup கருவிகளுடனான இணக்கத்தன்மை (compatibility) சோதனைகள்.
உங்கள் நிறுவனம் Oracle AI Database-ஐ high-availability கட்டமைப்பில் இயக்கினால், அதன் தாக்கத்தை மதிப்பிட non-production CDB-இல் புதிய கட்டளையைச் சோதிப்பதே விரைவான வழியாகும்.
சுருக்கம்: Oracle AI Database 23.26.2, பல படிநிலைகளைக் கொண்ட, பிழைகளுக்கு இடமளிக்கும் standby PDB அமைப்பை ஒரு ஒற்றை வரிச் செயல்பாடாக மாற்றுகிறது, இது multitenant சூழல்களுக்கு வேகமான மற்றும் நம்பகமான disaster recovery-யை வழங்குகிறது.