Setelah pemadaman listrik baru-baru ini di situs DR kami, saya menemukan bahwa siaga di sana telah berhenti menerapkan log. Rupanya dalam arsip redo logs terdapat transaksi yang menumbuhkan file data tetapi disk di situs siaga tidak memiliki cukup ruang disk untuk memungkinkan transaksi tersebut diselesaikan. Jadi standby menghentikan pemulihan terkelola, sebagaimana mestinya.
Kami biasanya menyimpan arsip redo log selama 7 hari. Sayangnya, pada saat saya menemukan situasi ini, 15 hari telah berlalu dan arsip redo log "hilang". Tanpa log redo yang diarsipkan untuk diterapkan, satu-satunya solusi adalah membangun kembali database dari awal. Basis data ini berukuran sekitar 7 TB, jadi membangun kembali dari awal bukanlah hal yang sepele.
Yang utama adalah database RAC 11.2.0.2 3-node yang berjalan di Linux. Siaga adalah database RAC dua simpul, jelas merupakan versi Oracle dan OS yang sama.
Inilah cara kami menyelesaikan membangun kembali siaga:
- Kami menempatkan yang utama dalam mode pencadangan panas dan mengambil snapshot basis data berbasis disk.
- Snapshot disalin ke media eksternal. Catatan:pengiriman melalui WAN terlalu memakan waktu.
- Media eksternal dibawa langsung ke situs DR.
- LOG_ARCHIVE_DEST_STATE_n untuk standby disetel ke DEFER.
- Basis data siaga dihapus dari konfigurasi DG Broker: HAPUS DATABASE siaga pertahankan TUJUAN;
- Titik pemasangan database siaga telah dihapus. Bagaimanapun, database pada dasarnya tidak berguna pada saat ini.
- Titik pemasangan baru telah dibuat dan snapshot ditulis ke disk di situs DR.
- Setelah transfer file selesai (sekitar 5 hari), kami memberi tahu penyimpanan kami untuk memperbarui snapshot di situs DR dengan snapshot yang lebih baru. Ini dilakukan melalui WAN karena hanya perubahan yang dikirim, yang jauh lebih kecil daripada database.
- File kontrol siaga telah dibuat: ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/dir/path’;
- Untuk mempermudah, kami ingin menggunakan satu instance standby sampai kami menjalankannya. Jadi kami membuat PFILE dari RAC SPFILE standby dan kemudian menggunakan editor teks untuk memodifikasi file parameter untuk menghapus parameter yang mengetahui RAC. Kami menghapus CLUSTER_DATABASE, menetapkan parameter UNDO_TABLESPACE khusus-instans yang akan digunakan untuk semua instans “*.”, menghapus parameter THREAD, dll. Database siaga normal kami memiliki dua instans, STANDBY1 dan STANDBY2. Di node 1, kami menempatkan pfile di $ORACLE_HOME/dbs/initstandby.ora alih-alih initstandby1.ora sehingga database instance tunggal dapat menemukan file parameternya. Kami melakukan hal serupa untuk file kata sandi.
- Kami menyalin file kontrol standby dari langkah 9 ke file kontrol di snapshot database.
- Dengan file pfile dan pswd di tempat untuk database instance tunggal, kami melakukan STARTUP MOUNT.
- Kami membuat log redo standby yang kami perlukan. Dalam kasus kami, primer juga memiliki log redo siaga untuk memfasilitasi operasi peralihan dan log redo siaga dari primer bukan bagian dari snapshot. Jadi kami harus menghapus SRL yang tidak melakukan perjalanan.
- Di bagian utama, setel LOG_ARCHIVE_DEST_STATE_n ke ENABLE.
- Dalam contoh utama, dilakukan ALTER SYSTEM SWITCH LOGFILE;
- Terverifikasi di log peringatan utama dan siaga bahwa standby menerima log, yaitu memverifikasi bahwa pengangkutan log berfungsi.
- Mengaktifkan standby terkelola:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PUTUSKAN DARI SESI;
- Terverifikasi di log peringatan siaga bahwa log sedang diterapkan, yaitu penerapan terverifikasi sekarang berfungsi.
Pada titik ini, kami memiliki database siaga yang telah dicadangkan dan dijalankan. Kami membuat tabel sederhana di primer dan memasukkan satu baris data di dalamnya, melakukan sakelar log lagi, dan kemudian membuka standby dalam mode READ ONLY untuk memverifikasi bahwa transaksi diputar ulang di standby sebagaimana mestinya. Setelah kami puas bahwa database siaga berfungsi, kami perlu menjadikannya database RAC. Yah semuanya sudah di tempat untuk ini menjadi database RAC karena dulu. Untuk menyelesaikan pekerjaan, kami hanya mematikan database standby instance tunggal (SHUTDOWN ABORT) di SQL*Plus dan kemudian menggunakan srvctl untuk memulai standby sebagai database RAC:
srvctl start database -d standby -o mount
Satu-satunya hal yang tersisa pada saat ini adalah menambahkan standby kembali ke konfigurasi DG Broker (dalam DGMGRL): ADD DATABASE standby
Ketika ini pertama kali terjadi, saya gugup bagaimana ini akan menjadi database yang begitu besar. Tidak ada operasi di atas yang bergantung pada ukuran selain menyalin file ke dan dari media. Tapi semuanya berjalan dengan baik.
Untuk memastikan kami tidak mengalami situasi ini di masa mendatang, kami menambahkan peringatan ke Kontrol Grid Oracle Enterprise Manager kami. Saya sekarang akan menerima peringatan PERINGATAN ketika pengiriman log atau penerapan log terlambat 12 jam dan peringatan KRITIS ketika terlambat 24 jam. Itu akan memberi kami banyak waktu untuk memperbaiki masalah apa pun sebelum log redo yang diarsipkan dihapus secara otomatis setelah 7 hari, atau paling tidak, ubah proses untuk menahan lebih banyak hari dari redo log yang diarsipkan hingga kami benar-benar memperbaiki situasinya.
