Re: Need a lesson in RMAN for RAC

You all had some great things to point out, but I still have a little bit of mystery. Sorry about the delay - been busy. =) Alex, I checked the various controlfiles and they appear to be ok. However, as it is a week later since my problem, I am not exactly sure which controlfile was actually restored during my little scenario in the beginning. To that end, is there a way to do a dry run on a previous incarnation without shutting down the database? I see that the validateoption of restore is supposed to do a dry run, but I cannot attempt it on
the previous incarnation (without stopping the database; startup force nomount)

Hemant, there are no fuzzy files, and no "BEGIN BACKUP" commands. The datestamps of the archived logs is what has me the most confused at this point in time:
LUMQA1_SQL > select NAME,FIRST_CHANGE#,to_char(FIRST_TIME,'DD-MON-YYYY HH24:MI:SS'),

               NEXT_CHANGE#,to_char(NEXT_TIME,'DD-MON-YYYY HH24:MI:SS')     from v$archived_log
    where first_time < '01-SEP-2007'
    order by NEXT_TIME desc
/
  2 3 4 5 6

NAME                                     FIRST_CHANGE# TO_CHAR(FIRST_TIME,'

---------------------------------------- ------------- --------------------
------------ --------------------
+DATA/lumqa/2_3_631971295.dbf                  2997861 31-AUG-2007
22:00:10      3097750 02-SEP-2007 02:01:44
+DATA/lumqa/1_4_631971295.dbf                  3004658 31-AUG-2007
22:11:27      3051322 01-SEP-2007 09:00:40
+DATA/lumqa/1_3_631971295.dbf                  2876764 30-AUG-2007
12:09:54      3004658 31-AUG-2007 22:11:27
+DATA/lumqa/2_2_631971295.dbf                  2877457 30-AUG-2007
12:09:56      2997861 31-AUG-2007 22:00:10
+DATA/lumqa/2_34_629052887.dbf                 3331608 29-AUG-2007
17:51:55      3331784 29-AUG-2007 17:53:38
+DATA/lumqa/1_39_629052887.dbf                 3331605 29-AUG-2007
17:51:53      3331781 29-AUG-2007 17:53:37
+DATA/lumqa/2_33_629052887.dbf                 3245386 28-AUG-2007
18:07:51      3331608 29-AUG-2007 17:51:55
+DATA/lumqa/1_38_629052887.dbf                 3258246 28-AUG-2007
21:08:10      3331605 29-AUG-2007 17:51:53
+DATA/lumqa/1_37_629052887.dbf                 3168436 27-AUG-2007
22:00:35      3258246 28-AUG-2007 21:08:10
+DATA/lumqa/2_32_629052887.dbf                 3146903 27-AUG-2007
17:55:54      3245386 28-AUG-2007 18:07:51
                                                589921 27-JUL-2007
17:38:36       679439 28-JUL-2007 16:59:26
                                                589921 27-JUL-2007
17:38:36       679439 28-JUL-2007 16:59:26
                                                589921 27-JUL-2007
17:38:36       679439 28-JUL-2007 16:59:26
+DATA/lumqa/2_2_629052887.dbf                   589921 27-JUL-2007
17:38:36       679439 28-JUL-2007 16:59:26

14 rows selected.

Why are there 3 blank-name rows, all for the same change #? Where are sequences 2_3 through 2_31 for 629052887? The biggest question is why do I need to recover with archived log 2_2_629052887.dbf if my "set until" timestamp is 5:51pm, but not if it is 4:51pm? That is the biggest mystery yet.

On 9/7/07, Alex Gorbachev <ag_at_oracloid.com> wrote:
>
> At the moment of failure, I would check what is the SCN of each
> datafile. Check controlfile SCN, current incarnation and etc. I
> remember that quite a few confusing situation like that were explained
> after some research and matching it all to what was originally
> restored.
>
> You didn't mention your controlfile restore - would there be any problem?
>
> Have you compared which backup pieces were used in failing and
> succeeded restores? And what controlfiles were used.
>

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l