11gDG切换：错误，ORA-00274 illegal recovery option SEESION
在做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的原理，这样才能解决。所以学习懂原理会事半功倍