RE: RMAN Backup Question

  • From: "Nick Tilbury @ Northampton" <ntilbury@xxxxxxxxxxxx>
  • To: <HELMUT.DAIMINGER@xxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 24 Jan 2005 14:56:20 -0000

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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Daiminger, Helmut
Sent: 24 January 2005 14:46
To: oracle-l@xxxxxxxxxxxxx
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
--
//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

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

Other related posts: