Oracle AI Database 23.26.2 membolehkan anda menyediakan standby pluggable database (PDB) dan log redo-nya dengan satu arahan Data Guard Broker sahaja, sekali gus menghapuskan rutin salin-fail-secara-manual yang selama ini melambatkan persediaan pemulihan bencana (disaster recovery).

Mengapa ini penting

Penciptaan PDB standby fizikal memerlukan rantaian tindakan manual: menyalin setiap datafile ke bekas (container) standby, membina standby redo logs (SRL) dengan arahan ALTER yang eksplisit, dan menyemak semula keseluruhan konfigurasi. Setiap langkah membawa risiko kesilapan taip, fail yang tertinggal, atau kumpulan log yang tidak sepadan, yang boleh melambatkan ujian pemulihan atau, dalam kes terburuk, merosakkan proses failover. Automasi proses ini mengurangkan risiko tersebut dan membebaskan DBA untuk fokus pada tugas yang lebih tinggi tahapnya.

Bagaimana PDB standby dibina sebelum ini

Dalam seni bina multitenant, sebuah CDB (container database) utama menghoskan satu atau lebih PDB. Untuk melindungi PDB, pentadbir perlu:

  • Mengenal pasti dan menyalin setiap datafile daripada hos utama ke hos standby.
  • Mencipta SRL secara manual yang mencerminkan susun atur redo-log utama.
  • Menjalankan pemulihan RMAN atau arahan pendua (duplicate) untuk menyelaraskan standby.
  • Menjalankan siri langkah pengesahan untuk memastikan standby boleh menerima switchover.

Aliran kerja ini boleh memakan masa beberapa jam, terutamanya untuk PDB yang besar, dan sebarang kesilapan boleh menyebabkan standby tidak dapat digunakan.

Apa yang dilakukan oleh kemas kini 23.26.2

Versi Oracle AI Database terbaharu menyatukan langkah-langkah yang diperlukan ke dalam Data Guard Broker. Dengan mengeluarkan satu pernyataan ADD PLUGGABLE DATABASE, broker tersebut:

  1. Mendaftarkan PDB standby baharu dengan yang utama.
  2. Menyalin datafile yang diperlukan di sebalik tabir—tiada pemulihan RMAN atau salinan fail manual diperlukan.
  3. Menjana standby redo logs yang sesuai, dan menambahnya ke dalam CDB standby secara automatik.
  4. Meninggalkan PDB dalam mod READ ONLY, sedia untuk switchover standby fizikal.

Arahan yang digunakan dalam ujian tersebut adalah:

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

Ujian dunia nyata

Penulis mencipta sebuah PDB standby bernama AMOL pada CDB sekunder (cdb2) yang mencerminkan PDB utama pada cdb1. Broker tersebut menyelesaikan operasi tersebut dengan serta-merta. Tiada pemulihan RMAN dijalankan, tiada salinan fail manual muncul dalam log OS, dan kumpulan standby redo log muncul dalam katalog tanpa sebarang pernyataan ALTER DATABASE.

Membuka PDB tersebut menukarkannya kepada mod READ ONLY, mengesahkan status standby fizikalnya. Semakan pantas terhadap datafile membuktikan ia telah disediakan pada bahagian standby. Redo apply sudah pun berjalan, dan broker melaporkan konfigurasi sedia untuk switchover.

Implikasi kepada DBA

Automasi ini mengurangkan kemungkinan ralat manusia dan memendekkan masa daripada perancangan ke standby pengeluaran (production). Pasukan kini boleh menyediakan PDB standby dalam masa beberapa minit berbanding berjam-jam, yang mana sangat berharga untuk persekitaran yang menyediakan perkhidmatan baharu dengan kerap.

Kesannya adalah kebergantungan yang lebih ketat pada logik dalaman Data Guard Broker. Sesetengah DBA lebih suka menulis skrip bagi setiap langkah sendiri untuk mengekalkan kawalan terperinci atau untuk menyepadukannya dengan alat pemantauan tersuai. Dalam persediaan yang kompleks—pelbagai rangkaian, storan heterogen, atau susun atur redo yang tidak standard—pentadbir mungkin masih perlu mengesahkan bahawa tetapan lalai broker selaras dengan polisi mereka.

Apa yang perlu diperhatikan seterusnya

Oracle belum mengumumkan pelanjutan lanjut untuk automasi ini, tetapi langkah tersebut menunjukkan bahawa versi masa hadapan mungkin akan memasukkan lebih banyak aliran kerja DR multitenant ke dalam broker. Perhatikan:

  • Sokongan untuk jenis standby tambahan (cth., PDB standby logikal).
  • Log yang diperluas yang memaparkan keputusan broker untuk tujuan audit.
  • Semakan keserasian dengan alat sandaran pihak ketiga yang sebelum ini bergantung pada langkah RMAN manual.

Jika organisasi anda menjalankan Oracle AI Database dalam konfigurasi ketersediaan tinggi (high-availability), menguji arahan baharu pada CDB bukan pengeluaran adalah cara terpantas untuk menilai impaknya.

Rumusan: Oracle AI Database 23.26.2 menukarkan persediaan PDB standby yang melibatkan pelbagai langkah dan terdedah kepada ralat kepada operasi satu baris, memberikan pemulihan bencana yang lebih pantas dan boleh dipercayai untuk persekitaran multitenant.