Performing user-managed Database-18.6, about user-managed Media Recovery

18.6, about user-managed Media Recovery
To complete the recovery, Oracle recommends using the recover statement. You can also use the ALTER DATABASE recover statement, but the recover statement is simpler.

18.6.1, preconditions of performing user-managed Recovery
To begin any kind of media recovery, you must adhere to the following restrictions:
(1) Must have Administrator privileges
(2) All recovery sessions must be coordinated
(3) When one session completes a non-conforming media recovery, another session cannot initiate a consistent media recovery
(4) If you connect to a database through a shared server process, you cannot start media recovery

18.6.2, applying Logs automatically with the RECOVER command--use the RECOVER command to automatically apply the log
Oracle recommends using the Recover command instead of the ALTER DATABASE recover command to complete media recovery. When using SQL statements to complete media recovery, the simplest way is to complete automatic recovery. Automatic recovery does not need to apply each archive log as it does for manual recovery.
When using SQL statements to complete media recovery, there are two options to automatically apply the required archive logs:
(1) Before executing the recover command, perform set AutoRecovery on
Sql> set AutoRecovery on
sql> Recover database;

(2) Specify automatic for the recover command
sql> recover automatic database;

Note: If you complete a non-conformance recovery or restore a backup control file, the database will only speculate on the required archive log name, and you may need to apply the redo log file manually.

18.6.3, Recovering when archived Logs is in the default location--archive log
As the log is used, the database suggests a file name. The database rebuilds the proposed archive log file name by associating initialization parameters Log_archive_dest_n and Log_archive_format. Therefore, if all archived log files are placed in Log_archive_dest_n, and Log_archive_format is not changed, the database can automatically recommend and apply archive logs to complete media recovery.

18.6.4, resetting the archived Log Destination
Edit the Log_archive_dest_n and Log_archive_format initialization parameter files, execute the ALTER SYSTEM statement to change the default location of the archive log

18.6.5, overriding the archived Log Destination
In some cases, reread the current settings of the archive location parameter:
(1) Copy the archive log to another location using the operating system command
(2) Specify a new location using the Set Logsource ' statement or recover automatic database from ' xxx '
Reread archived log resources without affecting the location of online redo logs being archived

18.6.6, responding to unsuccessful application of Redo Logs
Recover statement, after the database has successfully applied the archive log, it returns: Log applied. In large cases, the redo log needs to be manually applied. If the suggested file is incorrect or provides an incorrect file name, the database returns:
Ora-00308:cannot Open Archived Log "/oracle/oradata/trgt/arch/arcr_1_811.arc"
Ora-27037:unable to obtain file status
SVR4 error:2: No such file or directory
Additional Information:3
Recovery can continue until the correct archive log or redo log is applied. After the log is applied, the database may return the following error message:

18.6.7, interrupting user-managed media recovery--interrupt Medium recovery
In some cases, you need to interrupt media recovery:
(1) When the redo log is applied, enter the Cancel
(2) using the operating system interrupt signal: CTRL + C