11gDG switchover: incorrect, ORA-00274 illegal recovery option SEESION

The following error occurs during DG switching:

 

ORA-00274: illegal recovery option SEESION

 

Problem description:

When I run the switch statement on the master database and then switch the slave database to the master database, this problem occurs:

The procedure is as follows:

(1) master database

 

SQL> select switchover_status from v$database; SWITCHOVER_STATUS----------------------------------------TO STANDBY

 

Then perform the switchover:

 

SQL> alter database commit to switchover to physical standby with sessionshutdown; Database altered. 

 

 

Then, I directly gave the master database to shutdown abort.

 

 

(2) slave Database

 

 

Then execute

alter database recovermanaged standby database disconnect from seesion;

 

The problem occurs.

 

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,000 00, "illegal recovery option % s"

// * Cause: An illegal option was specified for a recovery command.

// * Action: Correct the syntax and retry thecommand.

 

 

 

The slave database can view the alarm log:

 

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 initialized ed

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 initialized ed

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

User-specified limit on the amount of space thatwill be used by this

Database for recovery-related files, and does notreflect the amount

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

Find the cause in the log:

The data synchronization application is not complete, and then the original master database can only be started to the mount state, the original slave database is open for real-time application:

 

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. Now we can see that the switching status is OK;

 

 

Switch again

 

 

20:43:35 SQL> alter database commit to switchover to primary with sessionshutdown;

 

Database altered.

 

View the status in the original standby database:

 

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>

Switching is complete;

 

 

It took about 10 minutes to analyze the entire process, mainly to learn the analysis:

(1) how to find the problem? Search in the warning log

(2) If you find out how to analyze it, you need to understand the principle of DG so that you can solve it. So learning and understanding the principles will get twice the result with half the effort