with oracle 12c you can see this warning on alert log.
Warning: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE has been deprecated.
yes there is some changes for Oracle redo apply. “using current logfile” has depreceted, and when you use “ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT” is starts real time apply insted of apply from archivelog apply. so by default oracle no need to wait for redo log switch during standby apply. if you want apply from archibelog you can use “ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED LOGFILE DISCONNECT“.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> SELECT DATABASE_MODE, RECOVERY_MODE, PROTECTION_MODE FROM v$archive_dest_status WHERE DEST_ID=1;
DATABASE_MODE RECOVERY_MODE PROTECTION_MODE
--------------- ----------------------- --------------------
MOUNTED-STANDBY IDLE MAXIMUM PERFORMANCE
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.
SQL> SELECT DATABASE_MODE, RECOVERY_MODE, PROTECTION_MODE FROM v$archive_dest_status WHERE DEST_ID=1;
DATABASE_MODE RECOVERY_MODE PROTECTION_MODE
--------------- ----------------------- --------------------
MOUNTED-STANDBY MANAGED REAL TIME APPLY MAXIMUM PERFORMANCE
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED LOGFILE DISCONNECT
;
Database altered.
SQL> SELECT DATABASE_MODE, RECOVERY_MODE, PROTECTION_MODE FROM v$archive_dest_status WHERE DEST_ID=1;
DATABASE_MODE RECOVERY_MODE PROTECTION_MODE
--------------- ----------------------- --------------------
MOUNTED-STANDBY MANAGED MAXIMUM PERFORMANCE
Here is new description of managed recovery in oracle documantaton
Note:Several subclauses of managed_standby_recovery are no longer needed and have been deprecated. These clauses no longer appear in the syntax diagrams. Refer to the semantics of managed_standby_recovery.
managed_standby_recovery
Use the managed_standby_recovery clause to start and stop Redo Apply on a physical standby database. Redo Apply keeps the standby database transactionally consistent with the primary database by continuously applying redo received from the primary database.
A primary database transmits its redo data to standby sites. As the redo data is written to redo log files at the physical standby site, the log files become available for use by Redo Apply. You can use the managed_standby_recovery clause when your standby instance has the database mounted or is opened read-only.
Note:Beginning with Oracle Database 12c, real-time apply is enabled by default during Redo Apply. Real-time apply recovers redo from the standby redo log files as soon as they are written, without requiring them to be archived first at the physical standby database. You can disable real-time apply with the USINGARCHIVEDLOGFILE clause. Refer to:
- Oracle Data Guard Concepts and Administration for more information on real-time apply
- USING ARCHIVED LOGFILE Clause
Note:Parallelism is enabled by default during Redo Apply. The database computes the degree of parallelism. You can disable parallelism of these operations by specifying NOPARALLEL, or specify a degree of parallelism with PARALLELinteger, as shown in the respective syntax diagrams.
Restrictions on Managed Standby Recovery The same restrictions listed under general_recovery apply to this clause.
See Also:Oracle Data Guard Concepts and Administration for more information on the use of this clause
Restrictions on General Database Recovery
General recovery is subject to the following restrictions:
You can recover the entire database only when the database is closed.
Your instance must have the database mounted in exclusive mode.
You can recover tablespaces or data files when the database is open or closed, if the tablespaces or data files to be recovered are offline.
You cannot perform media recovery if you are connected to Oracle Database through the shared server architecture.
USING ARCHIVED LOGFILE Clause Specify USING ARCHIVED LOGFILE to start Redo Apply without enabling real-time apply.
DISCONNECT Specify DISCONNECT to indicate that Redo Apply should be performed in the background, leaving the current session available for other tasks. The FROM SESSION keywords are optional and are provided for semantic clarity.
NODELAY The NODELAY clause overrides the DELAY attribute on the LOG_ARCHIVE_DEST_n parameter on the primary database. If you do not specify the NODELAY clause, then application of the archived redo log file is delayed according to the DELAY attribute of the LOG_ARCHIVE_DEST_n setting (if any). If the DELAY attribute was not specified on that parameter, then the archived redo log file is applied immediately to the standby database.
If you specify real-time apply with the USING CURRENT LOGFILE clause, then any DELAY value specified for the LOG_ARCHIVE_DEST_n parameter at the primary for this standby is ignored, and NODELAY is the default.
UNTIL CHANGE Clause Use this clause to instruct Redo Apply to recover redo data up to, but not including, the specified system change number.
UNTIL CONSISTENT Use this clause to recover the standby database to a consistent SCN point so that the standby database can be opened in read only mode.
FINISH Specify FINISH to complete applying all available redo data in preparation for a failover.
Use the FINISH clause only in the event of the failure of the primary database. This clause overrides any specified delay intervals and applies all available redo immediately. After the FINISH command completes, this database can no longer run in the standby database role, and it must be converted to a primary database by issuing the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY statement.
CANCEL Specify CANCEL to stop Redo Apply immediately. Control is returned as soon as Redo Apply stops.
TO LOGICAL STANDBY Clause Use this clause to convert a physical standby database into a logical standby database.
THE DATABASE DIARY 