RE: RMAN Backup Question

I don't see how you can have a consistent backup of your PRD database until=  the entire backup completes.
Therefore, IMO - your suspicions are correct. If you specifed 23:01 - the Thu backup would be used.

Nick

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Daiminger, Helmut Sent: 24 January 2005 14:46
To: oracle-l_at_freelists.org
Subject: RMAN Backup Question

Hi!

We recently did a restore of our production database to a different box. But RMAN was using an older backup to do that.

The scenario was like this:

PRD Database:
- full db backup + archive logs taken from 20:00 - 23:00 on Wednesday (Jan 19)
- full db backup + archive logs taken from 20:00 - 23:00 on Thursday (Jan 20)

On Friday (Jan 21), we then did a "restore until time" to Thursday (Jan 20), 20:30 to a different box.

But RMAN was not using the backup from Thursday (Jan 20), but was using the one from Wednesday and applying all the archived logs (which was taking a long time).

The question is: why was RMAN not using the backup from Thursday? Is the backup not consistent to the starting time at 20:00 (like it would be with a consistent export)?

I can't find anything in Robert Freeman's book about that phenomenon.

This is 9.2 on HP-UX 11i.

Thanks,
Helmut

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




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D

This message is intended solely for the use of the individual or organisati=
on to whom it is addressed.  It may contain privileged or confidential info=
rmation.  If you have received this message in error, please notify the ori=
ginator immediately.  If you are not the intended recipient, you should not=
 use, copy, alter, or disclose the contents of this message.  All informati=
on or opinions expressed in this message and/or any attachments are those o=
f the author and are not necessarily those of VarTecTelecom Europe Ltd or i=
ts affiliates. VarTec Telecom Europe Ltd accepts no responsibility for loss=
 or damage arising from its use, including damage from virus.=20


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D


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