What methods of point-in-time recovery are available?

Jake from SF

https://docs.oracle.com/cd/E11882_01/backup.112/e10642/osrecvry.htm#BRADV90034

For A,C,D:
Performing Time-Based or Change-Based Incomplete Recovery
This section describes how to specify an SCN or time for the end point of recovery. If your database is affected by seasonal time changes (for example, daylight savings time), then you may experience a problem if a time appears twice in the redo log and you want to recover to the second, or later time. To handle time changes, perform cancel-based or change-based recovery.

To perform change-based or time-based recovery:

Follows Step 1 through Step 8 in “Performing Closed Database Recovery”.

Issue the RECOVER DATABASE UNTIL statement to begin recovery. If recovering to an SCN, then specify as a decimal number without quotation marks. For example, to recover through SCN 10034 issue:

RECOVER DATABASE UNTIL CHANGE 10034;
If recovering to a time, then the time is always specified using the following format, delimited by single quotation marks: ‘YYYY-MM-DD:HH24:MI:SS’. The following statement recovers the database up to a specified time:

RECOVER DATABASE UNTIL TIME ‘2000-12-31:12:47:30’
Apply the necessary redo log files to recover the restored data files. The database automatically terminates the recovery when it reaches the correct time, and returns a message indicating whether recovery is successful.

Note:
Unless recovery is automated, the database supplies the name from LOG_ARCHIVE_DEST_1 and asks you to stop or proceed with after each log. If the control file is a backup, then after the archived logs are applied you must supply the names of the online logs.
Follow Steps 4 and 5 in “Performing Cancel-Based Incomplete Recovery”.

For B:
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/osrecvry.htm#BRADV90034
Performing Cancel-Based Incomplete Recovery
In cancel-based recovery, recovery proceeds by prompting you with the suggested file names of archived redo log files. Recovery stops when you specify CANCEL instead of a file name or when all redo has been applied to the data files.

To perform cancel-based recovery:

Follow Step1 through Step 8 in “Performing Closed Database Recovery”.

Begin cancel-based recovery by issuing the following command in SQL*Plus:

RECOVER DATABASE UNTIL CANCEL
Note:
If you fail to specify the UNTIL clause on the RECOVER command, then the database assumes a complete recovery and does not open until all redo is applied.
The database applies the necessary redo log files to reconstruct the restored data files. The database supplies the name it expects to find from LOG_ARCHIVE_DEST_1 and requests you to stop or proceed with applying the log file. If the control file is a backup, then you must supply the names of the online redo logs if you want to apply the changes in these logs.

Continue applying redo log files until the last log has been applied to the restored data files, then cancel recovery by executing the following command:

CANCEL
The database indicates whether recovery is successful. If you cancel before all the data files have been recovered to a consistent SCN and then try to open the database, then you get an ORA-1113 error if more recovery is necessary. You can query V$RECOVER_FILE to determine whether more recovery is needed, or if a backup of a data file was not restored before starting incomplete recovery.

Open the database with the RESETLOGS option. You must always reset the logs after incomplete recovery or recovery with a backup control file. For example:

ALTER DATABASE OPEN RESETLOGS;
If you attempt to use OPEN RESETLOGS when you should not, or if you neglect to reset the log when you should, then the database returns an error and does not open the database. Correct the problem and try again.

See Also:
“About User-Managed Media Recovery Problems” for descriptions of situations that can cause ALTER DATABASE OPEN RESETLOGS to fail
After opening the database with the RESETLOGS option, check the alert log.

Note:
The easiest way to locate trace files and the alert log is to run the following SQL query: SELECT NAME, VALUE FROM V$DIAG_INFO.
When you open with the RESETLOGS option, the database returns different messages depending on whether recovery was complete or incomplete. If the recovery was complete, then the following message appears in the alert log:

RESETLOGS after complete recovery through change scn
If the recovery was incomplete, then this message is reported in the alert log, where scn refers to the end point of incomplete recovery:

RESETLOGS after incomplete recovery UNTIL CHANGE scn
Also check the alert log to determine whether the database detected inconsistencies between the data dictionary and the control file. Table 29-3 describes two possible scenarios.