Re: Minimizing backup induced downtime

On Jul 12, 2:23 pm, Alexander Skwar <use..._at_alexander.skwar.name> wrote:
> · rogergor..._at_gmail.com <rogergor..._at_gmail.com>:
>
> > Alex:
> >>Suppose you're doing a RMAN backup at 22:30. At 22:45 it's
> >>done, ie. also writing to tape is finished at that time.
> >>At 23:00, the server dies and the tapes are still intact.
> >>With that magical RMAN thing, how will you be able to recover
> >>anything that's changed in the database after 22:46? My, maybe
> >>ncomplete, understanding of how RMAN works, is, that it can
> >>take a backup of an Oracle database without the need for having
> >>it shutdown (thus a hot backup). But how will RMAN allow me
> >>to recover something, which hasn't been backed up?
>
> > I've done just such a test and it works magically. I'm beginning to
> > think that you either aren't running in archive log mode, or you don't
> > know what that is.
>
> I am running the databases in archive log mode and I know what it is.
> But the problem is, that the logs aren't backed up. They are, at best,
> backed up until 22:45. Then the backup is finished. Everything that's
> stored on the disks/in the database between 22:46 and 22:59 has not
> been backed up yet.
>
> It's possible that I don't understand something here. But how
> can you recover the database, so that it is in the state it was at
> 22:55? Remember, the archive log files are lost. I'm really
> interested - how can that be done? I mean, on tape (or on some
> other secure location/medium) there's the database the way it
> was up until 22:45, at best. Isn't it? From where does RMAN/Oracle
> pull the data about what has been done between 22:46 and 22:59,
> if archive logs aren't available?
>
> > Sooner or later your luck will run out.
>
> Hm. Not impossible. ACK.
>
> > What if the server dies
> > during your ZFS snapshot or your export? Then you have to go back
> > even farther?
>
> But isn't it the same with RMAN or "old school hotbackups running in,
> archive redo log mode"? Suppose you're doing a copy to a secure
> medium (tape/off site disk/whatever) only every 24hrs - how would
> RMAN/archive redo log be an improvement in this case?
>
> > I posted some helpful info in the other thread on places to look for
> > help with RMAN (sample RMAN scripts in $ORACLE_HOME/rdbms/demo) but
> > you clearly did not see that.
>
> Nope. I have seen that and sent you an email reg. this about 2hrs ago.
> I did not yet read the ressources you pointed me to. I'll do that
> tomorrow morning.
>
> > turn 40." It's not the age, it's the unwillingness to learn and apply
> > the better technology where it's appropriate that wrecks careers.
>
> Exactly. Where it's appropriate. As it is, I need to backup Oracle
> and some other directory. Those two need to be in sync. And here
> comes another reason against RMAN or even archived redo logs: As
> I wrote, the two directories need to be in sync. I take a backup
> of the directory and also Oracle every 24 hours. Suppose
> that the storage on tape is good (which is an entire different
> question...). What good would it do me in real life, if I could
> restore/recover the Oracle database to a PIT (point-in-time) it
> was 18 hours ago, when I cannot do the same to the directory?
> Yes, I know that there are setups, which would allow me to do
> even more snapshots, like NetApp filers. But we don't have that.
>
> It's all nice, that I can do a PIT of Oracle - but really, what
> do I do with that? Not in general or in a Oracle only world, but
> in the scenario I described.
>
> Alexander Skwar
> --
> It was a JOKE!! Get it?? I was receiving messages from DAVID LETTERMAN!!
> YOW!!
Note that if you want to, you can be shipping the archived logs somewhere off the server. That is how standby works, it sits there and applies logs so you can have your db up and in use before you even have to fix the original server. You have to pay extra for standby, but there is nothing stopping you from shipping logs whereever you want (well, networking costs can be a limitation). That is how you bring your restored database beyond the point of backup. And that is why you want your data in the database. You might even consider putting the data in the database even though that's not where you use it.

jg

--
@home.com is bogus.
Exigent circumstances.  http://www.wired.com/politics/law/news/2007/07/exigentinvestigation