Re: using rman

From: Holger Baer <holger.baer_at_science-computing.de>
Date: Tue, 07 Jan 2003 18:13:34 +0100
Message-ID: <3E1B0ABE.8050801@science-computing.de>

Igor wrote:
> Holger Baer wrote:
>
> Hi Holger,
>
>

>>You don't need a second db, rman can track everything in the target
>>databases controlfile - but only for a limited time. And besides, the OP

>
> You consider this acceptable? All right, I never really worked with rman,
> and as I said, I didn't state it a bad product. The things I caught in the
> course were not really encouraging and besides we were already using shell
> scripts for online backups.
> But returning, you consider storing rman info into the target database's
> controfile acceptable? When you have to restore an hot backup-ed db you
> have to recreate controlfiles, AFAIK, so where do you get restore info
> from?
> And, what does "for a short time" mean? How far can you go back in time for
> a restore with rman this way?
>

A proper backup strategy will include the controlfiles. So no harm in using them if you don't want to use a catalog db. The usage of the controlfile is limited because it only can hold a limited amount of backup records. Since they are used in a round robin fashion, they'll be reused. Of course this can be configured (but since I never used this I don't know the settings by heart).

And compared to a home grown skript where the admin will be required to identify the files needed for recovery, I'll indeed prefer the target databases controlfile. But I suppose, this depends on what database losses you're addressing. But putting this aside, of course a catalog database is preferable.

>

>>said he wanted to use rman, but not for how many databases it will be

>
> Right.
>
>

>>tape directly if that's needed. Considering todays hd prices you better
>>throw in an additional disk just for the backups and use it as primary
>>backup target (which will speed up backup as well).

>
> I suppose, you did not really mean it litteraly, _one_ disk, what do you do
> with db with 200, 500, 1000 GB? One disk? What about CEO that just does not
> accept the "one disk more"?

It depends on your needs. I wasn't suggesting to move away from tape backup, I merely offered an additional option to consider. Archiving a database larger than a few hundred GB to anything else but tape is probably out of question. But then, you'll be having hot spots in the database which need frequent backup because they changed, and large amount which don't.

>
>

[...]

> What about time of backup and unavailability of backup destination? How does
> rman handle a situation where backup destination is not available (server
> down, tape unit broken, no tape space left)? How do you add the rest of the
> db to backup after you (admin) have fixed things next morning?

Time of backup? Scheduled by what scheduler you like (I prefer pre-exec skripts of the backup software...)
This all depends on what outage actually occured and what database size we're talking about, doesn't it? But just in case, you can even do an incremental backup with rman (not the first option to use because I think it's only incremental to the last successful backup).
>
>

>>not really necessary.

>
> IMHO, yes. If you want call it effort. And we are talking about roughly 700
> lines of shell script.
> I, we, made the experience, that with the shell script we know what happens,
> as you have to ask the db for some info for what to backup, you get to know
> db details better. I have learned a lot with this method. We can backup
> parts of tablespaces a later moment (see unavailability issues above).
> I don't know with rman, but with my shell script I would be able to get
> things together for a complete restore manually also.

Granted, but depending on the database size you'll be forced to learn the same things with rman. And the skripts tend to be shorter. And if you have a heavy used OLTP DB, putting tablespaces in hot backup mode might result in a heavy hit of redo contention.

>
> And finally, but maybe things changed or are not as I have understood and
> read white papers, using rman and having to store centrally on a Storage
> Manager you have to buy additional integration software (between rman and
> Storage Manager), which is $$ our CEO is not willing to spend.

Well, I suppose this thread started because we both have a different OS back ground, don't we? Most of the time I'm forced to support windows installations where skripting is more a burden than an option and I bet you're more the unix kind...

So consider: getting a rman script running on any os will be much less effort than trying to convert a csh skript to a dos batch file.

> Have a nice day and thanks for your comments,
> Best regards,
> Igor

Thanks and the same to you, reading your comments I learned again some things I never had to consider just because of the rather small databases I have to support. In many cases I just know of some features rman is supposed to have but I never actually used them and have to come across the problems they impose...

Have a nice evening and let's settle this for now ;-)

Best regards,

Holger Received on Tue Jan 07 2003 - 11:13:34 CST