DataGuard - ORA-00261錯(cuò)誤及解決方法
2024-07-21 02:09:49
供稿：網(wǎng)友
在dataguard環(huán)境中如果我們?cè)谧鰂ailover的時(shí)候，可能會(huì)碰到ora-00261錯(cuò)誤，下面是該錯(cuò)誤的產(chǎn)生原因和解決方法。
如果是由于網(wǎng)絡(luò)問題而導(dǎo)致需要切換，那么通常standby端的rfs進(jìn)程并不會(huì)意識(shí)到primary已經(jīng)不可訪問，所以rfs進(jìn)程也不會(huì)釋放當(dāng)前的standby redo log文件。
如果是primary端的數(shù)據(jù)庫(kù)實(shí)例由于故障中斷，那么一般情況下standby端的rfs進(jìn)程會(huì)立刻意識(shí)到primary已經(jīng)不可訪問，也就會(huì)立刻釋放當(dāng)前的standby redo log文件。
只要rfs進(jìn)程沒有釋放standby redo log文件，那么執(zhí)行alter database recover managed standby database finish命令就會(huì)在alertlog文件中發(fā)現(xiàn)如下的報(bào)錯(cuò)信息
warning: log 4 of thread 1 is being archived or modified
recovery interrupted.
media recovery failed with error 261
如果在報(bào)上述錯(cuò)誤的時(shí)候，執(zhí)行switch，那么將會(huì)出現(xiàn)下面的錯(cuò)誤：
ora-16139: media recovery required
所以必須檢查alertlog文件，直到發(fā)現(xiàn)如下信息才表示rfs進(jìn)程已經(jīng)釋放了standby redo log文件，這時(shí)候才可以作finish：
rfs: possible network disconnect with primary database
促使rfs進(jìn)程釋放standby redo log 文件有兩種方法：
1． 等待rfs進(jìn)程的network timeout，通常需要等待8分鐘左右
2． 關(guān)閉standby數(shù)據(jù)庫(kù)，再重新開啟，這樣會(huì)強(qiáng)制rfs進(jìn)程釋放standby redo log
我們可以通過v$managed_standby視圖來監(jiān)控rfs進(jìn)程何時(shí)釋放
實(shí)行failover：
alter database recover managed standby database finish;
alertlog中將顯示如下信息，表示finish成功：
terminal incomplete recovery: until change 3738452
terminal incomplete recovery: end-of-redo log allocation
terminal incomplete recovery: log 4 reserved for thread 1 seq# 8772
terminal recovery changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0
switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
terminal incomplete recovery: clearing standby redo logs.
terminal incomplete recovery: thread 1 seq# 8772 redo required
terminal incomplete recovery: end-of-redo log /global/oradata/ctsdb/stdby_redo04.log
identified end-of-redo for thread 1 sequence 8772
terminal incomplete recovery: end checkpoint scn 3738453
media recovery complete
switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
terminal incomplete recovery: successful completion
begin: wait for standby logfiles to be archived
wed sep 1 13:42:28 2004
arc1: evaluating archive log 4 thread 1 sequence 8772
wed sep 1 13:42:28 2004
arc0: evaluating archive log 4 thread 1 sequence 8772
wed sep 1 13:42:28 2004
arc1: beginning to archive log 4 thread 1 sequence 8772
wed sep 1 13:42:28 2004
arc0: unable to archive log 4 thread 1 sequence 8772
wed sep 1 13:42:28 2004
creating archive destination log_archive_dest_1: '/global/oradata/ctsdb/archive/arch1_8772.log'
wed sep 1 13:42:28 2004
log actively being archived by another process
wed sep 1 13:42:28 2004
arc1: completed archiving log 4 thread 1 sequence 8772
wed sep 1 13:42:43 2004
end: all standby logfiles have been archived
resetting standby activation id 4038461969 (0xf0b60a11)
completed: alter database recover managed standby database finish
finsh成功之后再執(zhí)行switch：
alter database commit to switchover to primary;
switch成功之后，重新啟動(dòng)數(shù)據(jù)庫(kù)：
shutdown immediate;
startup;
