Saat mengerjakan database standby baru-baru ini, saya pergi ke DG Broker untuk memeriksa status dan menerima ini:
DGMGRL> show configuration Configuration - resp_ress_config Protection Mode: MaxPerformance Databases: resp - Primary database ress - Physical standby database Error: ORA-16766: Redo Apply is stopped
Hmm… standby saya tidak menerapkan redo. Ketika saya mencoba memulai pemulihan terkelola, saya mendapatkan yang berikut ini di log peringatan siaga:
Tue Dec 31 09:52:10 2013 Managed Standby Recovery starting Real Time Apply Tue Dec 31 09:52:10 2013 MRP0: Background Media Recovery terminated with error 38868 Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Managed Standby Recovery not using Real Time Apply Slave exiting with ORA-38868 exception Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Recovery Slave PR00 previously exited with exception 38868 MRP0: Background Media Recovery process shutdown (ress2)
Jadi ORA-38868 memberi tahu saya bahwa saya memiliki struktur direktori yang buruk. Pikiran pertama saya adalah bahwa ini terkait dengan pekerjaan yang saya buat di blog kemarin. Tapi pekerjaan itu ada di sisi utama. Saya melihat kembali log peringatan siaga dan menemukan kemunculan pertama kesalahan ini sekitar 2,5 bulan yang lalu. Jika ini adalah sistem produksi, saya bisa berada dalam masalah besar membiarkan masalah ini tidak diketahui untuk jangka waktu tersebut. Tetapi saya memiliki langkah-langkah untuk memperingatkan saya jika siaga produksi saya tertinggal dari yang utama untuk jangka waktu yang tidak dapat diterima. Ini hanyalah sistem pengujian yang dapat saya tiup dan mulai dari awal jika perlu. Tapi apa yang menyenangkan itu? Mari kita lihat apakah kita bisa memperbaiki masalahnya.
Perhentian pertama saya adalah Metalink. Tapi saya mendapat nol hit untuk kesalahan ORA-38868. Saat melakukan pencarian web, saya mendapatkan satu klik relevan yang menawarkan solusi dengan memulai ulang instance dan memulai ulang aplikasi ulang. Saya skeptis, tetapi mencoba perbaikan yang mudah. Seharusnya tidak mengherankan bahwa restart sederhana dari instance tidak memperbaiki masalah. Kesalahannya memberi tahu saya bahwa file kontrol saya rusak. Memulai ulang instance tidak akan memperbaiki kerusakan file kontrol. Karena Metalink dan Internet tidak ada gunanya, saya kira terserah saya untuk memperbaikinya. Jika semuanya gagal, saya hanya akan menghentikan standby dan membuatnya kembali.
Solusi awal saya adalah kembali ke primer dan membuat file kontrol siaga. Kemudian mulai standby dengan file kontrol standby. Saya yakin bahwa file kontrol baru dari primer akan menyelesaikan masalah. Namun, saya perlu mengajukan 2,5 bulan pengulangan yang sudah tidak tersedia lagi.
Saya sudah mencoba untuk menyelidiki menggunakan RMAN untuk memajukan siaga melalui cadangan tambahan. Tetapi ini tampaknya tidak termasuk dalam daftar prioritas hal-hal yang harus saya lakukan. Saya memiliki proyek yang akan datang di mana saya perlu tahu bagaimana melakukan ini dan proyek itu sekarang kurang dari satu bulan lagi. Jadi ini sepertinya waktu yang tepat untuk mempraktikkan teknik ini untuk proyek saya yang akan datang dan untuk memperbaiki masalah saya saat ini. Langkah-langkah untuk melakukannya ada di:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Langkah-langkah dalam dokumen ini tidak hanya memajukan standby saya, tetapi juga membuat ulang file kontrol, sehingga memperbaiki masalah saya.
