在做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的原理，这样才能解决。所以学习懂原理会事半功倍