How to determine Until Time in restore

Question

Hi I have read
Restoring and Recovering with Recovery Manager on line:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmrecov.htm
I am not sure how to determine an Until Time during a restore, or in duplicating a database.
Can someone show a specific example?
The best thing I have found so far is this:
SQL> select max(next_change#)
from v$archived_log
where archived='YES'
group by thread#;
OR
SQL> select max(next_change#) from v$log_history;
as documented here:
RMAN-8060 Doing Duplicate Database on Recovered Database
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=189394.1
But that still leads to:
RMAN-06025: no backup of log thread 2 seq 2817 scn 3193354318 found to restore
RMAN-06025: no backup of log thread 2 seq 2816 scn 3192569562 found to restore
RMAN-06025: no backup of log thread 2 seq 2815 scn 3191725873 found to restore
RMAN-06025: no backup of log thread 1 seq 2437 scn 3191725871 found to restore
errors about half the time during duplication.
Thanks!
-John

Answer 1

Hi All,
We use the following query against the RMAN recovery catalog in our RMAN DUPLICATE scripting to identify the latest time that we can use.
SELECT TO_CHAR(MAX(recover_time),'DD-MON-RR HH24:MI:SS')
FROM
(SELECT b.completion_time recover_time
FROM dbinc a, rc_backup_piece b
WHERE a.db_key = b.db_key
AND a.db_name = '${SSID}'
AND b.backup_type in ('D','I')
AND b.status = 'A'
AND b.device_type = 'SBT_TAPE'
AND b.tag IS NOT NULL
AND b.tag != 'CTRLBKUP'
AND b.tag NOT LIKE 'TAG%'
UNION
SELECT next_time recover_time
FROM rc_backup_redolog
WHERE db_name = '${SSID}');
Additionally, you may need to account for a rare problem with the absolute_fuzzy_change# is higher than the checkpoint change number. Oracle Development said this should be fixed at some point in the future when I last talked with them on the topic in 02/2004.
We've coded around it (we're using Oracle EE 9.2.0.5+) by adding a couple of minutes between the incr backup and the archivelog)
Hope this helps,
Rich