Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Backup trends (2): HOT or COLD

Re: Backup trends (2): HOT or COLD

From: Joel Garry <>
Date: 5 Apr 2004 16:01:24 -0700
Message-ID: <>

"Howard J. Rogers" <> wrote in message news:<406e65bd$0$4543$>...
> "Bob Jones" <email_at_me.not> wrote in message
> news:LDnbc.23629$
> >
> > "Sybrand Bakker" <> wrote in message
> >
> > > On Fri, 2 Apr 2004 07:37:30 +0000 (UTC), Lucyna Witkowska
> > > <> wrote:
> > >
> > > >Sorry, I made a stupid version error and discussion "went to raspberry
> > > >bushes" (as we say in Poland).
> > > >So I try again. ;-)
> > > >Oracle (version supported by the application developer).
> > > >Is there any admin (, that rely only on RMAN warm
> backups?
> > > >
> > > >Greetings,
> > > >Lucyna Witkowska
> > >
> > > Sure, why not.
> > > RMAN is much more stable than any home grown korn shell script.
> > > For some time I'm trying to get the home grown scripts out of the
> > > window. They are too inflexible and many of them require maintenance
> > > when datafiles are added. RMAN doesn't need that.
> > >
> > >
> > > --
> > > Sybrand Bakker, Senior Oracle DBA
> >
> > I have to disagree. We have been using shell scripts to backup for years
> and
> > never have any problem. They do not require maintenance if datafiles are
> > added. I have never used RMAN. Does it backup files with OS copy, or
> Oracle
> > special commands to backup only the data not the empty space in the data
> > files? I would consider RMAN only if the later is true.
> It is true. RMAN does an intelligent read of Oracle blocks and then an
> intelligent write. That's good because it understands the concept of an
> Oracle block, so yes it skips any that are empty. It does that
> automatically. Optionally, it also does something which no O/S script has a
> hope in hell of pulling off: namely, comparing the age of an Oracle block
> with the age of the same block in a prior backup, and if the two are the
> same, skipping the block. That, of course, is the basis for an incremental
> backup. At the Oracle block level. And in 9i, RMAN can recover at the block
> level too.
> So yes, it has lots of nice features. But those are merely incidental to the
> real reason why you should use RMAN in preference to O/S scripts:
> performance. RMAN doesn't cause the database to generate 20 or 30 times the
> amount of redo per transaction that O/S hot backups do. RMAN doesn't hammer
> one data file to death before moving on to another, but instead multiplexes
> across many datafiles, little bits being taken from each one in turn. RMAN
> parallelises in a way no O/S script never could. And you can throttle the
> I/O rate up or down for RMAN to minimise the impact on the production
> database or to maximise the speed at which the backup is done.
> RMAN doesn't require maintenance if datafiles are added, either, so I'm not
> sure what the point of mentioning that was.

I think Sybrand was pointing out that some scripts have been written with datafiles hardcoded rather than selecting from v$datafile, or to deal with cold backups.

> It's taken a while, but I think more and more people are coming to the
> conclusion that RMAN is not only a viable backup and recovery tool, but is
> actually rather good these days. (If you're still stuck on 8.0, I can
> understand your reluctance to use it rather better!).

I agree it is rather good these days. I would add the caveat that there does need to be maintenance as one goes up through the versions, for bug workarounds, non-obvious feature consequences and to use new desireable features. Some of these things are discovered the hard way in production because they are too obscure for reasonable testing by users.

The one thing I have seen gripes about and have not quite figured out is how to cut down on the information logged to that which is necessary and useful.


-- is bogus.
Computers do not help keep mortgage rates down.  They may not even
help keep mortgage companies profits up.
Received on Mon Apr 05 2004 - 18:01:24 CDT

Original text of this message