在做DG切換的時候遇到這樣一個錯誤:
ORA-00274: illegal recovery option SEESION
問題描述:
當我在主庫運行切換語句後,然後在備庫切換到主庫時遇到這樣一個問題:
操作如下:
(1) 主庫
SQL> select switchover_status from v$database; SWITCHOVER_STATUS----------------------------------------TO STANDBY
再執行切換:
SQL> alter database commit to switchover to physical standby with sessionshutdown; Database altered.
然後又直接把主庫給shutdown abort了
(2) 備庫
然後在備庫執行該
alter database recovermanaged standby database disconnect from seesion;
就出現問題了
20:42:20 SQL>alter database recover managed standby database disconnect from seesion;
alter database recover managed standby databasedisconnect from seesion
*
ERROR at line 1:
ORA-00274: illegal recovery option SEESION
20:42:25 SQL>!oerr ora 00274
00274, 00000, "illegal recovery option%s"
// *Cause: An illegal option was specified for a recovery command.
// *Action: Correct the syntax and retry thecommand.
再備庫通過警示日誌查看:
alter database commit to switchover to primary with sessionshutdown
ALTER DATABASE SWITCHOVER TO PRIMARY (felix)
Maximum wait for role transition is 15 minutes.
Database not available for switchover
End-Of-REDO archived log file has been received
End-Of-REDO archived log file has not been recovered
Incompleterecovery SCN:0:1453729 archive SCN:0:1477550
Database not available for switchover
End-Of-REDOarchived log file has been received
End-Of-REDO archived log file has not been recovered
Incompleterecovery SCN:0:1453729 archive SCN:0:1477550
Switchover: Media recovery required - standby notin limbo
ORA-16139 signalled during: alter database committo switchover to primary with session shutdown...
Sat Jul 05 20:42:19 2014
alter database open
AUDIT_TRAIL initialization parameter is changed toOS, as DB is NOT compatible for database opened with read-only access
Sat Jul 05 20:42:19 2014
SMON: enabling cache recovery
Dictionary check beginning
Dictionary check complete
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (noasync multimaster replication found)
Physical standby database opened for read onlyaccess.
Completed: alter database open
Sat Jul 05 20:42:20 2014
db_recovery_file_dest_size of 4122 MB is 0.00%used. This is a
user-specified limit on the amount of space thatwill be used by this
database for recovery-related files, and does notreflect the amount of
space available in the underlying filesystem orASM diskgroup.
Sat Jul 05 20:43:22 2014
alter database recover managed standby databasedisconnect from session
Attempt to start background Managed StandbyRecovery process (felix)
Sat Jul 05 20:43:22 2014
MRP0 started with pid=24, OS id=7281
MRP0: Background Managed Standby Recovery processstarted (felix)
Serial Media Recovery started
Managed Standby Recovery not using Real Time Apply
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Errors in file/u01/app/oracle/diag/rdbms/felix_st1/felix/trace/felix_mrp0_7281.trc:
ORA-00313: open failed for members of log group 1of thread 1
ORA-00312: online log 1 thread 1:'/u01/app/oracle/oradata/felix/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1/u01/app/oracle/oradata/felix/redo01.log
Clearing online log 1 of thread 1 sequence number106
通過日誌尋找到原因:
是資料未完成同步應用,然後只能把原來主庫啟動到mount狀態下,原備庫open後進行即時應用:
20:42:38 SQL>alter database recover managed standby database disconnect fromsession;
Database altered.
20:43:28 SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------------------------------
TO PRIMARY
Ok,在此我們可以看到切換狀態已經ok了;
再進行切換
20:43:35 SQL>alter database commit to switchover to primary with sessionshutdown;
Database altered.
在原備庫查看狀態:
22:41:27 SQL>select NAME,OPEN_MODE,SWITCHOVER#,SWITCHOVER_STATUS,DATABASE_ROLEfrom v$database;
NAME OPEN_MODE SWITCHOVER#SWITCHOVER_STATUS DATABASE_ROLE
------------------ -------------- --------------------------------- ------------------
FELIX READ WRITE 3596915957 TO STANDBY PRIMARY
22:41:56 SQL>
算是完成切換;
分析整個過程用了十分鐘左右,主要是要學會分析:
(1) 怎麼找問題?要到警告日誌裡面進行尋找
(2) 找到了怎麼分析,要理解DG的原理,這樣才能解決。所以學習懂原理會事半功倍