Oracle AI Database 23.26.2 Installs Standby PDB with One Data Guard Command

Oracle AI Database 23.26.2 ಕೇವಲ ಒಂದು Data Guard Broker ಕಮಾಂಡ್ ಮೂಲಕ standby pluggable database (PDB) ಮತ್ತು ಅದರ redo logs ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು (spin up) ಅನುಮತಿಸುತ್ತದೆ, ಇದು ವಿಪತ್ತಿನಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳುವ (disaster-recovery) ಪ್ರಕ್ರಿಯೆಯನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿಧಾನಗೊಳಿಸುತ್ತಿದ್ದ ಫೈಲ್‌ಗಳನ್ನು ಕೈಯಿಂದ ಕಾಪಿ ಮಾಡುವ ಕೆಲಸವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ಇದು ಏಕೆ ಮುಖ್ಯ

ಒಂದು physical standby PDB ಅನ್ನು ರಚಿಸಲು ಹಲವಾರು ಮ್ಯಾನುಯಲ್ ಕ್ರಮಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ: ಪ್ರತಿಯೊಂದು datafile ಅನ್ನು standby container ಗೆ ಕಾಪಿ ಮಾಡುವುದು, ALTER commands ಬಳಸಿ standby redo logs (SRLs) ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ಇಡೀ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಮರುಪರಿಶೀಲಿಸುವುದು. ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಟೈಪೋ (typo), ಫೈಲ್ ಮಿಸ್ ಆಗುವುದು ಅಥವಾ ಮಿಸ್‌ಮ್ಯಾಚ್ ಆದ ಲಾಗ್ ಗ್ರೂಪ್‌ನ ಅಪಾಯವಿರುತ್ತದೆ, ಇದು ರಿಕವರಿ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ವಿಳಂಬ ಮಾಡಬಹುದು ಅಥವಾ ಅತಿ ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, failover ಅನ್ನು ವಿಫಲಗೊಳಿಸಬಹುದು. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದರಿಂದ (automating) ಆ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು DBA ಗಳು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಕಾರ್ಯಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಈ ಮೊದಲು standby PDB ಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗುತ್ತಿತ್ತು

Multitenant architecture ನಲ್ಲಿ, ಒಂದು primary CDB (container database) ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು PDB ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಒಂದು PDB ಅನ್ನು ರಕ್ಷಿಸಲು, ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ಗಳು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು:

• Primary ನಿಂದ standby host ಗೆ ಪ್ರತಿಯೊಂದು datafile ಅನ್ನು ಗುರುತಿಸಿ ಕಾಪಿ ಮಾಡುವುದು.
• Primary ನ redo-log ಲೇಔಟ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ SRL ಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ರಚಿಸುವುದು.
• Standby ಅನ್ನು ಸಿಂಕ್ (sync) ಮಾಡಲು RMAN restores ಅಥವಾ duplicate commands ಗಳನ್ನು ರನ್ ಮಾಡುವುದು.
• Standby ಒಂದು switchover ಅನ್ನು ಸ್ವೀಕರಿಸಬಲ್ಲದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸರಣಿ ಪರಿಶೀಲನಾ ಹಂತಗಳನ್ನು (verification steps) ರನ್ ಮಾಡುವುದು.

ಈ ವರ್ಕ್‌ಫ್ಲೋ (workflow) ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ವಿಶೇಷವಾಗಿ ದೊಡ್ಡ PDB ಗಳಿಗೆ, ಮತ್ತು ಯಾವುದೇ ಸಣ್ಣ ತಪ್ಪೂ standby ಅನ್ನು ಬಳಕೆಗೆ ಅಸಾಧ್ಯವಾಗಿಸಬಹುದು.

23.26.2 ಅಪ್‌ಡೇಟ್ ಏನು ಮಾಡುತ್ತದೆ

ಇತ್ತೀಚಿನ Oracle AI Database ರಿಲೀಸ್ ಅಗತ್ಯವಿರುವ ಹಂತಗಳನ್ನು Data Guard Broker ನಲ್ಲಿ ಅಳವಡಿಸಿದೆ. ಕೇವಲ ಒಂದು ADD PLUGGABLE DATABASE ಸ್ಟೇಟ್‌ಮೆಂಟ್ ನೀಡುವ ಮೂಲಕ, broker ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತದೆ:

1. ಹೊಸ standby PDB ಅನ್ನು primary ನೊಂದಿಗೆ ನೋಂದಾಯಿಸುತ್ತದೆ (registers).
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 ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವಂತೆ, secondary CDB (cdb2) ನಲ್ಲಿ AMOL ಎಂಬ ಹೆಸರಿನ standby PDB ಅನ್ನು ರಚಿಸಿದರು. Broker ಈ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತಕ್ಷಣವೇ ಪೂರ್ಣಗೊಳಿಸಿತು. ಯಾವುದೇ RMAN restore ರನ್ ಆಗಲಿಲ್ಲ, OS ಲಾಗ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ಮ್ಯಾನುಯಲ್ ಫೈಲ್ ಕಾಪಿಗಳು ಕಂಡುಬರಲಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ALTER DATABASE ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳಿಲ್ಲದೆ standby redo log ಗ್ರೂಪ್‌ಗಳು ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡವು.

PDB ಅನ್ನು ಓಪನ್ ಮಾಡಿದ್ದಾಗ ಅದು READ ONLY ಮೋಡ್‌ಗೆ ಬದಲಾಯಿತು, ಇದು ಅದರ physical-standby ಸ್ಥಿತಿಯನ್ನು ಖಚಿತಪಡಿಸಿತು. Datafiles ಗಳ ಶೀಘ್ರ ಪರಿಶೀಲನೆಯು ಅವು standby ಕಡೆಯಲ್ಲೇ ಸಿದ್ಧಪಡಿಸಲಾಗಿದೆ (provisioned) ಎಂದು ಸಾಬೀತುಪಡಿಸಿತು. Redo apply ಈಗಾಗಲೇ ರನ್ ಆಗುತ್ತಿತ್ತು ಮತ್ತು broker ಕಾನ್ಫಿಗರೇಶನ್ switchover ಗೆ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡಿತು.

DBA ಗಳಿಗೆ ಇದರ ಪರಿಣಾಮಗಳು

ಈ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆಯು ಮಾನವ ತಪ್ಪುಗಳ (human error) ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ಲಾನಿಂಗ್‌ನಿಂದ ಪ್ರೊಡಕ್ಷನ್ standby ವರೆಗಿನ ಸಮಯವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ತಂಡಗಳು ಈಗ ಗಂಟೆಗಳ ಬದಲಿಗೆ ನಿಮಿಷಗಳಲ್ಲಿ standby PDB ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಬಹುದು, ಇದು ಪದೇ ಪದೇ ಹೊಸ ಸೇವೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಪರಿಸರಗಳಿಗೆ (environments) ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ.

ಇದರ ಮಿತಿ ಏನೆಂದರೆ Data Guard Broker ನ ಆಂತರಿಕ ತರ್ಕದ (internal logic) ಮೇಲೆ ಹೆಚ್ಚಿನ ಅವಲಂಬನೆ ಇರುತ್ತದೆ. ಕೆಲವು DBA ಗಳು ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣವನ್ನು (granular control) ಉಳಿಸಿಕೊಳ್ಳಲು ಅಥವಾ ಕಸ್ಟಮ್ ಮಾನಿಟರಿಂಗ್ ಟೂಲ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಪ್ರತಿಯೊಂದು ಹಂತವನ್ನು ತಾವೇ ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದನ್ನು ಬಯಸುತ್ತಾರೆ. ಸಂಕೀರ್ಣ ಸೆಟಪ್‌ಗಳಲ್ಲಿ—ಹಲವು ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ವಿವಿಧ ರೀತಿಯ ಸ್ಟೋರೇಜ್ (heterogeneous storage), ಅಥವಾ ಅಸಮಾನವಾದ redo ಲೇಔಟ್‌ಗಳು—ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ಗಳು broker ನ ಡಿಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ತಮ್ಮ ನೀತಿಗಳಿಗೆ (policies) ಅನುಗುಣವಾಗಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕಾಗಬಹುದು.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

Oracle ಈ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆಗೆ ಹೆಚ್ಚಿನ ವಿಸ್ತರಣೆಗಳನ್ನು ಘೋಷಿಸಿಲ್ಲ, ಆದರೆ ಈ ಕ್ರಮವು ಭವಿಷ್ಯದ ರಿಲೀಸ್‌ಗಳು ಹೆಚ್ಚಿನ multitenant DR ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು broker ಗೆ ತರಬಹುದು ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಇವುಗಳ ಮೇಲೆ ಗಮನವಿಡಿ:

• ಹೆಚ್ಚುವರಿ standby ಪ್ರಕಾರಗಳಿಗೆ ಬೆಂಬಲ (ಉದಾಹರಣೆಗೆ, logical standby PDB ಗಳು).
• ಆಡಿಟ್ ಉದ್ದೇಶಗಳಿಗಾಗಿ broker ನಿರ್ಧಾರಗಳನ್ನು ತೋರಿಸುವ ವಿಸ್ತೃತ ಲಾಗಿಂಗ್ (expanded logging).
• ಈ ಮೊದಲು ಮ್ಯಾನುಯಲ್ RMAN ಹಂತಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದ ಮೂರನೇ ಪಾರ್ಟಿ ಬ್ಯಾಕಪ್ ಟೂಲ್‌ಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯ ಪರಿಶೀಲನೆಗಳು (compatibility checks).

ನಿಮ್ಮ ಸಂಸ್ಥೆಯು Oracle AI Database ಅನ್ನು high-availability ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಅದರ ಪರಿಣಾಮವನ್ನು ಅಳೆಯಲು non-production CDB ನಲ್ಲಿ ಹೊಸ ಕಮಾಂಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗವಾಗಿದೆ.

ಸಾರಾಂಶ (Takeaway): Oracle AI Database 23.26.2 ಅನೇಕ ಹಂತಗಳಿರುವ ಮತ್ತು ತಪ್ಪುಗಳಿಗೆ ಒಳಗಾಗಬಹುದಾದ standby PDB ಸೆಟಪ್ ಅನ್ನು ಕೇವಲ ಒಂದು ಸಾಲಿನ ಕಾರ್ಯಾಚರಣೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇದು multitenant ಪರಿಸರಗಳಿಗೆ ವೇಗವಾದ ಮತ್ತು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾದ ವಿಪತ್ತಿನಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳುವ (disaster recovery) ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ.