Oracle AI Database 23.26.2 memungkinkan Anda untuk membuat standby pluggable database (PDB) dan redo log-nya dengan satu perintah Data Guard Broker, menghilangkan rutinitas salin-file-secara-manual yang selama ini memperlambat pengaturan pemulihan bencana (disaster recovery).

Mengapa ini penting

Membuat physical standby PDB memerlukan serangkaian tindakan manual: menyalin setiap datafile ke container standby, membangun standby redo logs (SRL) dengan perintah ALTER eksplisit, dan memeriksa ulang seluruh konfigurasi. Setiap langkah membawa risiko salah ketik, file yang terlewat, atau grup log yang tidak cocok, yang dapat menunda pengujian pemulihan atau, dalam kasus terburuk, merusak failover. Mengotomatiskan proses ini mengurangi risiko tersebut dan membebaskan DBA untuk fokus pada tugas-tugas tingkat tinggi.

Bagaimana standby PDB dibuat sebelumnya

Dalam arsitektur multitenant, sebuah primary CDB (container database) menampung satu atau lebih PDB. Untuk melindungi PDB, administrator harus:

  • Mengidentifikasi dan menyalin setiap datafile dari host primary ke host standby.
  • Membuat SRL secara manual yang mencerminkan tata letak redo-log primary.
  • Menjalankan restore RMAN atau perintah duplicate untuk menyinkronkan standby.
  • Menjalankan serangkaian langkah verifikasi untuk memastikan standby dapat menerima switchover.

Alur kerja ini bisa memakan waktu beberapa jam, terutama untuk PDB yang besar, dan kesalahan sekecil apa pun dapat membuat standby tidak dapat digunakan.

Apa yang dilakukan pembaruan 23.26.2

Rilis Oracle AI Database terbaru menyematkan langkah-langkah yang diperlukan ke dalam Data Guard Broker. Dengan menjalankan satu pernyataan ADD PLUGGABLE DATABASE, broker akan:

  1. Mendaftarkan PDB standby baru ke primary.
  2. Menyalin datafile yang diperlukan di balik layar—tidak perlu restore RMAN atau salin file secara manual.
  3. Menghasilkan standby redo logs yang sesuai, menambahkannya ke standby CDB secara otomatis.
  4. Membiarkan PDB dalam mode READ ONLY, siap untuk physical standby switchover.

Perintah yang digunakan dalam pengujian adalah:

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

Pengujian dunia nyata

Penulis membuat sebuah standby PDB bernama AMOL pada CDB sekunder (cdb2) yang mencerminkan PDB primary pada cdb1. Broker menyelesaikan operasi tersebut secara instan. Tidak ada restore RMAN yang berjalan, tidak ada salinan file manual yang muncul di log OS, dan grup standby redo log muncul di katalog tanpa pernyataan ALTER DATABASE apa pun.

Membuka PDB mengubah statusnya menjadi READ ONLY, mengonfirmasi status physical-standby-nya. Pemeriksaan cepat pada datafile membuktikan bahwa file tersebut telah disediakan di sisi standby. Redo apply sudah berjalan, dan broker melaporkan bahwa konfigurasi siap untuk switchover.

Implikasi bagi DBA

Otomatisasi ini mengurangi kemungkinan kesalahan manusia dan memangkas waktu dari perencanaan hingga standby produksi. Tim kini dapat menyediakan standby PDB dalam hitungan menit, bukan jam, yang sangat berharga untuk lingkungan yang sering menjalankan layanan baru.

Kompensasinya adalah ketergantungan yang lebih ketat pada logika internal Data Guard Broker. Beberapa DBA lebih suka membuat skrip untuk setiap langkah sendiri guna mempertahankan kontrol granular atau untuk berintegrasi dengan alat pemantauan khusus. Dalam pengaturan yang kompleks—beberapa jaringan, penyimpanan heterogen, atau tata letak redo yang tidak standar—administrator mungkin masih perlu memverifikasi bahwa pengaturan default broker selaras dengan kebijakan mereka.

Apa yang perlu diperhatikan selanjutnya

Oracle belum mengumumkan perluasan lebih lanjut untuk otomatisasi ini, tetapi langkah ini menunjukkan bahwa rilis di masa mendatang dapat memasukkan lebih banyak alur kerja DR multitenant ke dalam broker. Perhatikan:

  • Dukungan untuk tipe standby tambahan (misalnya, logical standby PDB).
  • Logging yang diperluas yang menampilkan keputusan broker untuk tujuan audit.
  • Pemeriksaan kompatibilitas dengan alat pencadangan pihak ketiga yang sebelumnya bergantung pada langkah RMAN manual.

Jika organisasi Anda menjalankan Oracle AI Database dalam konfigurasi high-availability, menguji perintah baru pada CDB non-produksi adalah cara tercepat untuk mengukur dampaknya.

Kesimpulan: Oracle AI Database 23.26.2 mengubah pengaturan standby PDB yang terdiri dari banyak langkah dan rentan kesalahan menjadi operasi satu baris, memberikan pemulihan bencana yang lebih cepat dan lebih andal untuk lingkungan multitenant.