Oracle AI Database 23.26.2 ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ Data Guard Broker ਕਮਾਂਡ ਨਾਲ ਇੱਕ standby pluggable database (PDB) ਅਤੇ ਇਸਦੇ redo logs ਤਿਆਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਫਾਈਲਾਂ ਨੂੰ ਹੱਥ ਨਾਲ ਕਾਪੀ ਕਰਨ ਦੀ ਉਹ ਰੁਟੀਨ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜਿਸ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ disaster-recovery ਸੈੱਟਅੱਪਾਂ ਨੂੰ ਹੌਲੀ ਕੀਤਾ ਹੋਇਆ ਸੀ।

ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਇੱਕ physical standby PDB ਬਣਾਉਣ ਲਈ ਕਈ ਮੈਨੂਅਲ ਕਾਰਵਾਈਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ: ਹਰ datafile ਨੂੰ standby container ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ, explicit ALTER ਕਮਾਂਡਾਂ ਨਾਲ standby redo logs (SRLs) ਬਣਾਉਣਾ, ਅਤੇ ਪੂਰੀ configuration ਦੀ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰਨਾ। ਹਰ ਕਦਮ ਵਿੱਚ ਟਾਈਪੋ (typo), ਫਾਈਲ ਰਹਿ ਜਾਣ, ਜਾਂ ਮਿਸਮੈਚਡ log group ਦਾ ਖਤਰਾ ਹੁੰਦਾ ਹੈ, ਜੋ recovery testing ਵਿੱਚ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਸਭ ਤੋਂ ਮਾੜੇ ਮਾਮਲੇ ਵਿੱਚ, failover ਨੂੰ ਵਿਗਾੜ ਸਕਦਾ ਹੈ। ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨ ਨਾਲ ਉਹਨਾਂ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ DBAs ਨੂੰ ਉੱਚ-ਪੱਧਰ ਦੇ ਕੰਮਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।

ਪਹਿਲਾਂ standby PDBs ਕਿਵੇਂ ਬਣਾਏ ਜਾਂਦੇ ਸਨ

Multitenant architecture ਵਿੱਚ, ਇੱਕ primary CDB (container database) ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ PDBs ਨੂੰ ਹੋਸਟ ਕਰਦਾ ਹੈ। ਇੱਕ PDB ਦੀ ਰੱਖਿਆ ਕਰਨ ਲਈ, ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ ਨੂੰ ਇਹ ਕਰਨਾ ਪੈਂਦਾ ਸੀ:

  • Primary ਤੋਂ standby host ਤੱਕ ਹਰ datafile ਦੀ ਪਛਾਣ ਕਰਨਾ ਅਤੇ ਉਸਨੂੰ ਕਾਪੀ ਕਰਨਾ।
  • ਮੈਨੂਅਲੀ SRLs ਬਣਾਉਣਾ ਜੋ primary ਦੇ redo-log layout ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਣ।
  • Standby ਨੂੰ sync ਵਿੱਚ ਲਿਆਉਣ ਲਈ RMAN restores ਜਾਂ duplicate ਕਮਾਂਡਾਂ ਚਲਾਉਣਾ।
  • ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ standby switchover ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਟੈਪਸ ਦੀ ਇੱਕ ਲੜੀ ਚਲਾਉਣਾ।

ਇਹ ਵਰਕਫਲੋ ਕਈ ਘੰਟੇ ਲੈ ਸਕਦਾ ਸੀ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ PDBs ਲਈ, ਅਤੇ ਕਿਸੇ ਵੀ ਗਲਤੀ ਕਾਰਨ standby ਵਰਤੋਂ ਯੋਗ ਨਹੀਂ ਰਹਿ ਸਕਦਾ ਸੀ।

23.26.2 ਅੱਪਡੇਟ ਕੀ ਕਰਦਾ ਹੈ

ਨਵੀਨਤਮ Oracle AI Database ਰਿਲੀਜ਼ ਲੋੜੀਂਦੇ ਕਦਮਾਂ ਨੂੰ Data Guard Broker ਵਿੱਚ ਹੀ ਸ਼ਾਮਲ ਕਰ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਸਿੰਗਲ ADD PLUGGABLE DATABASE ਸਟੇਟਮੈਂਟ ਜਾਰੀ ਕਰਕੇ, broker:

  1. ਨਵੇਂ standby PDB ਨੂੰ primary ਨਾਲ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ।
  2. ਪਿੱਛੇ ਹੀ (behind the scenes) ਲੋੜੀਂਦੇ 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 logs ਵਿੱਚ ਕੋਈ ਮੈਨੂਅਲ ਫਾਈਲ ਕਾਪੀ ਨਹੀਂ ਦਿਖਾਈ ਦਿੱਤੀ, ਅਤੇ standby redo log groups ਬਿਨਾਂ ਕਿਸੇ ALTER DATABASE ਸਟੇਟਮੈਂਟ ਦੇ ਕੈਟਾਲਾਗ ਵਿੱਚ ਦਿਖਾਈ ਦਿੱਤੇ।

PDB ਨੂੰ ਖੋਲ੍ਹਣ 'ਤੇ ਇਹ READ ONLY ਮੋਡ ਵਿੱਚ ਬਦਲ ਗਿਆ, ਜਿਸ ਨਾਲ ਇਸਦੀ physical-standby ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਹੋ ਗਈ। Datafiles ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਕੀਤੀ ਗਈ ਜਾਂਚ ਨੇ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਕਿ ਉਹਨਾਂ ਨੂੰ standby ਪਾਸੇ ਪ੍ਰੋਵੀਜ਼ਨ (provision) ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ। Redo apply ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਿਹਾ ਸੀ, ਅਤੇ broker ਨੇ ਰਿਪੋਰਟ ਦਿੱਤੀ ਕਿ configuration switchover ਲਈ ਤਿਆਰ ਹੈ।

DBAs ਲਈ ਪ੍ਰਭਾਵ

ਆਟੋਮੇਸ਼ਨ ਮਨੁੱਖੀ ਗਲਤੀ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਯੋਜਨਾਬੰਦੀ ਤੋਂ ਲੈ ਕੇ production standby ਤੱਕ ਦੇ ਸਮੇਂ ਨੂੰ ਬਹੁਤ ਘਟਾ ਦਿੰਦੀ ਹੈ। ਟੀਮਾਂ ਹੁਣ ਘੰਟਿਆਂ ਦੀ ਬਜਾਏ ਮਿੰਟਾਂ ਵਿੱਚ standby PDBs ਪ੍ਰੋਵੀਜ਼ਨ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਉਹਨਾਂ ਵਾਤਾਵਰਣਾਂ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਕੀਮਤੀ ਹੈ ਜੋ ਅਕਸਰ ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ।

ਇਸਦਾ ਇੱਕ ਨੁਕਸਾਨ Data Guard Broker ਦੇ ਅੰਦਰੂਨੀ ਲੌਜਿਕ (internal logic) 'ਤੇ ਵਧਦੀ ਨਿਰਭਰਤਾ ਹੈ। ਕੁਝ DBAs ਵਿਸਤ੍ਰਿਤ ਕੰਟਰੋਲ ਰੱਖਣ ਲਈ ਜਾਂ ਕਸਟਮ ਮਾਨੀਟਰਿੰਗ ਟੂਲਜ਼ ਨਾਲ ਜੋੜਨ ਲਈ ਹਰ ਕਦਮ ਨੂੰ ਖੁਦ ਸਕ੍ਰਿਪਟ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਗੁੰਝਲਦਾਰ ਸੈੱਟਅੱਪਾਂ ਵਿੱਚ—ਜਿਵੇਂ ਕਿ ਕਈ ਨੈੱਟਵਰਕ, ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੇ ਸਟੋਰੇਜ (heterogeneous storage), ਜਾਂ ਗੈਰ-ਮਿਆਰੀ redo layouts—ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਕਿ broker ਦੇ ਡਿਫੌਲਟ ਉਹਨਾਂ ਦੀਆਂ ਨੀਤੀਆਂ ਦੇ ਅਨੁਕੂਲ ਹਨ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

Oracle ਨੇ ਇਸ ਆਟੋਮੇਸ਼ਨ ਦੇ ਹੋਰ ਵਿਸਤਾਰ ਦੀ ਘੋਸ਼ਣਾ ਨਹੀਂ ਕੀਤੀ ਹੈ, ਪਰ ਇਹ ਕਦਮ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਭਵਿੱਖ ਦੀਆਂ ਰਿਲੀਜ਼ਾਂ multitenant DR ਵਰਕਫਲੋ ਦੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨੂੰ broker ਵਿੱਚ ਲਿਆ ਸਕਦੀਆਂ ਹਨ। ਇਹਨਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ:

  • ਵਾਧੂ standby ਕਿਸਮਾਂ ਲਈ ਸਹਾਇਤਾ (ਜਿਵੇਂ ਕਿ, logical standby PDBs)।
  • ਵਿਸਤ੍ਰਿਤ ਲੌਗਿੰਗ ਜੋ ਆਡਿਟ ਉਦੇਸ਼ਾਂ ਲਈ broker ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀ ਹੈ।
  • Third-party ਬੈਕਅੱਪ ਟੂਲਜ਼ ਨਾਲ ਅਨੁਕੂਲਤਾ ਜਾਂਚ, ਜੋ ਪਹਿਲਾਂ ਮੈਨੂਅਲ RMAN ਸਟੈਪਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਸਨ।

ਜੇਕਰ ਤੁਹਾਡੀ ਸੰਸਥਾ Oracle AI Database ਨੂੰ high-availability ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਚਲਾਉਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਭਾਵ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ non-production CDB 'ਤੇ ਨਵੀਂ ਕਮਾਂਡ ਦਾ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

ਸਿੱਖਿਆ (Takeaway): Oracle AI Database 23.26.2 ਇੱਕ ਬਹੁ-ਪੜਾਵੀ ਅਤੇ ਗਲਤੀ-ਪੂਰਨ standby PDB ਸੈੱਟਅੱਪ ਨੂੰ ਇੱਕ ਸਿੰਗਲ-ਲਾਈਨ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜੋ multitenant ਵਾਤਾਵਰਣਾਂ ਲਈ ਤੇਜ਼ ਅਤੇ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ disaster recovery ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।