Re: Backup Tool Alternative to RMAN and BMC's SQL Backtrack

Joel Garry wrote:
> cdavis10717_at_comcast.net wrote:
> > Thank you for your helpful reply, I appreciate it.
> >
> > May I ask you more about using RMAN, since I have concerns about
> using
> > and maintaining it.
> >
> > Oracle Metalink seems to regularly issue patches/fixes for RMAN.
> Since
> > RMAN is within $ORACLE_HOME do you need to shutdown Oracle in order
> to
> > applyand relink software fixes? How often do you do apply fixes
and
> > how much work/time does it take you to review the patches and stage
> > them through your system landscape? How many separate installs of
> > Oracle do you need to maintain for RMAN?
>
> Yes, but not because of RMAN. Almost never, since I wait for a more
> mature release. Don't need any separate Oracle for RMAN.
>
> >
> > How many Catalog databases (RCAT) do you use? Where are they
hosted,
> > on the same or on different server from the target database? Do
the
> > Catalogs ever get corrupt or have other problems that complicate
the
> > use of RMAN.
>
> None. Merely use scripted maintenace to keep the control file up to
> date.
> About four simple commands, one of which is alter system archivelog
> current.
>
> >
> > Do you need to have separate Catalogs for separate version of
Oracle?
> > Do you use a naming convention to distinguish these to make then
> easier
> > to manage?
>
> nocatalog. I would use a catalog if I had dozens of databases to
back
> up.
>
> >
> > If RMAN aborts for any reason do you have to deal with manually
> > cleaning up processes, enqueues, etc? How are you notified of an
> RMAN
> > failure.
>
> Look at logs. I wrote a prototype script to ignore "usual" errors in
> logs, but don't use it because I have so little reason to look at the
> logs I would quickly forget what to look for, so I need the practice.
> I also have email notification if other things go wrong. Typically,
> the things are: tape didn't work (I do RMAN to disk, then copy to
> tape, because tape drives are pos. They ocassionally become
> disassociated with their device, but that's not RMAN's fault.), out
of
> disk space (someone ignored warnings), and there were a few
ORA-4030's
> or whatever when first bringing it into use, quickly resolved
searching
> metalink.
>
> >
> > How often do you use RMAN to restore a database to another server
and
> > rename the SID? Have you done a PITR using RMAN and many archives?
> > How did you manage the disk space requires of the archive directory
> > during that process?
>
> Every few months (using RMAN to generate standby or new clone). That
> was easy to script, too, cookbooks on metalink. Haven't got around
to
> a PITR with RMAN yet, but I put effort into avoiding situations where
I
> have to use it (besides,
> http://www.dizwell.com/html/pitr_alternatives.html ). After many
years
> of home-grown and Velpuri scripts, and I once saw a real screwup with
> Omniback/DLT's, I must say, RMAN is the way to go. After all,
recovery
> is more important than backup.
>
>

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_id=50875.1&p_database_id=NOT
>
> >
> > And lastly, thank you for not making some asshole assumption that I
> > would spend my company's money because I can't or won't open OEM.
>
> I don't use OEM with RMAN, since I'm a unix/command line scripting
> bigot for repetitive production procedures. I reserve the right to
> make any asshole assumption that does not conflict with postings.
>
> jg
> --
> @home.com is bogus.
>

http://story.news.yahoo.com/news?tmpl=story2&u=/nm/20050223/tc_nm/tech_ebay_dc

Thank you for your reply.

I am coping with about 60 separate Oracle installs on Unix for databases approaching 3TB in size.

Today on Metalink this RMAN technote was updated: 247611.1. How did you get notified of that today? Will you be reviewing that and updating your RMAN software immediately? How do you know the RMAN you are running is reliable? The note lists numerous problems with RMAN.

I manage a very small team of DBAs and I can not imagine committing DBA resources to them remaining vigilant for the almost constant RMAN fixes/problems, and yet still be accountable to Upper Management to provide a stable, mature backup/recovery tool for mission-critical databases. RMAN is too iffy for me. And its Total Cost Of Ownership seems high. Also, the frequent downtime it would take to maintain it precludes its use in a very large environment with 24x7 databases sized in TBs.

I just don't have the DBA Staff it would take to acquire, apply, test, deploy RMAN fixes across every Oracle installed, then to search the internet for whatever scripts might be available to enable RMAN's use.

This is mainly why I want to avoid RMAN and look for a separate out-of-the-box solution. You told me you are using RMAN for your backup/recovery solution, yet you have not tried a PITR with it yet. I could not get away with that.

I appreciate your reply to my posting, though.

C Received on Fri Feb 25 2005 - 17:34:28 CST