Saya sedang dalam proses mengganti perangkat keras untuk cluster RAC 3-simpul yang ada. Sistem ini juga merupakan yang utama untuk database siaga RAC 2-node. Untuk mengganti perangkat keras, rencana saya adalah untuk sementara memperluas cluster menjadi konfigurasi 6-node, 3 server lama dan 3 server baru. Setelah instance saya berjalan di perangkat keras baru dan aplikasi saya terhubung ke instance baru, saya akan menghapus instance lama dan menghentikan server lama, kembali ke konfigurasi 3-node.
Setelah memperluas cluster ke keenam node, akhir pekan lalu saya memulai instance baru di node baru. Untuk membuat hidup saya lebih mudah, saya hanya memanfaatkan DBCA untuk pekerjaan ini. Setelah menjalankan DBCA, saya memilih untuk bekerja pada database RAC, lalu memilih Manajemen Instance dan kemudian Add New Instance. Berjalan melalui wizard saya membiarkan DBCA mengurus semua detail untuk saya. Kedengarannya sederhana.
Pagi ini, saya mendapat laporan lag arsip seperti biasa. Tampilannya mirip dengan berikut ini:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Saya mengirim ini ke Kotak Masuk saya dua kali sehari. Sekilas membantu saya menentukan apakah standby saya menerima dan menerapkan transaksi dari primer. Saya telah mengatur semua database siaga saya ke penundaan penerapan empat jam. Dan utama saya telah ARCHIVE_LAG_TARGET disetel ke satu jam. Ini berarti penundaan penerapan setidaknya 4 jam tetapi tidak boleh lebih dari 5 jam. Seperti yang dapat kita lihat di atas, kita memiliki dua database standby yang telah melampaui batas maksimal penerapan 5 jam. Di atas saya sudah standby dengan apply lag 1 hari 21 jam! Jadi saya segera tahu ada sesuatu yang salah. Dan tidak perlu ilmuwan roket untuk mengetahui bahwa menambahkan instance baru ke primer mungkin berkontribusi pada masalah.
Seperti yang saya katakan di awal posting ini, saya memiliki sistem siaga RAC 2-node. Salah satu contoh adalah "menerapkan contoh" dan contoh lainnya duduk di sana relatif menganggur. Di log peringatan instance apply saya, saya melihat pesan kesalahan berikut:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Karena database standby saya disetel ke STANDBY_FILE_MANAGEMENT=AUTO, bagian pertama dari pesan masuk akal. Saat Anda menambahkan instans baru ke database RAC, Anda harus menyediakan Undo Tablespace hanya untuk instans tersebut dan Anda juga harus menyediakan grup redo log online yang didedikasikan untuk utas instans tersebut. DBCA secara khusus menanyakan kepada saya pertanyaan yang berkaitan dengan struktur file undo dan redo. Pada isi alert log di atas, kita dapat melihat bahwa standby berhasil menambahkan datafile 342, yang merupakan tablespace Undo saya. Tetapi standby tidak dapat menambahkan log redo online. Jika Anda ingin standby dapat secara otomatis menambahkan log redo online, Anda perlu menentukan parameter OMF, yang saya enggan lakukan. Karena penambahan file redo log online mengakibatkan kesalahan, standby menghentikan pemulihan media. Siaga masih menerima log.
Saya tidak menemukan banyak di Metalink atau dengan melakukan pencarian Google tentang cara mengatasi masalah ini, tetapi berikut adalah langkah-langkah yang saya ambil untuk mengaktifkan dan menjalankan Pemulihan Media. Pada database standby (saya melakukan ini pada instance apply tetapi harus dapat dijalankan pada instance apa pun di database standby RAC):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Ini seharusnya tidak mengejutkan karena kita tahu Pemulihan Terkelola dibatalkan. Tapi untuk kelengkapannya, saya sertakan langkah ini. Jika Anda harus menambahkan redo log ke standby yang sedang menerapkan transaksi, maka Anda memerlukan langkah ini.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
Di atas adalah persis apa yang dijalankan pada primer. Perlu menambahkan redo log pada standby persis seperti yang dilakukan pada primary. Ulangi untuk setiap grup redo log yang ditambahkan pada primer. Karena saya menambahkan 3 instance ke database RAC utama saya, saya harus menambahkan tiga utas di sini.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Mulai pemulihan terkelola. Semuanya akan baik-baik saja sekarang dan kami dapat memverifikasi di log peringatan instance yang berlaku:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Kami juga dapat memverifikasi bahwa penundaan penerapan semakin pendek. Di standby, lakukan hal berikut:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
Untuk informasi latar belakang tentang cara mengelola online redo logs untuk database standby fisik Anda, lihat Metalink note 740675.1 Online Redo Logs in a Standby.
