Can anyone recommend a decent Oracle v9.2 database backup and recovery
software solution that is positioned in the niche between RMAN on the
low-end and BMC's SQL backTrack on the high-end.

Back-Track is so grossly expensive, and RMAN is so, well, gross. :-)

Any opinions and/or hands-on experience would be appreciated.

Thank you.

On 22 Feb 2005 13:03:48 -0800, cdavis10717@comcast.net wrote:

>and RMAN is so, well, gross. :-)

Why?
At least it works, and it automates your backups.
Which can not be said from many other third-party products.


--
Sybrand Bakker, Senior Oracle DBA

What kind of backup, tape or disk? What storage vendor for tape and/or
tape management products? What server environment?

Once you get to 9.x there is really no good reason at all to not learn
and use rman. There are just too many good features and it actually
works!

Yes it is different, very. But gross is kind of strong.

BMC is losing marketshare back to oracle with just rman ... it's that
good. Time to start learning it, sorry if that's not the advice you
wanted to hear.

>>>> RMAN is so, well, gross.

How?
Could you give one situation?
It is stable / flexible than any other backup tools that is intented
to be used with oracle.
And I dont need to spend a penny more!!!.

cdavis10717@comcast.net wrote:

> Can anyone recommend a decent Oracle v9.2 database backup and recovery
> software solution that is positioned in the niche between RMAN on the
> low-end and BMC's SQL backTrack on the high-end.
>
> Back-Track is so grossly expensive, and RMAN is so, well, gross. :-)
>
> Any opinions and/or hands-on experience would be appreciated.
>
> Thank you.

There is nothing wrong with RMAN of which I am aware. What,
specifically, is your problem? Why should your company spend
thousands of dollars because you can't or won't open OEM?

--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

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?

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.

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?

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.

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?

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.

Thank you.

cdavis10717@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/...abase _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?tmp...m/tech_ebay_dc

snip

cdavis10717@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.

Someone (Joel?) appears to have put out some good answers to your
questions already.

Think about buying the RMAN book written by Robert Freeman, and read it
several times.

Start slowly and do some experimentation on a test system first.

It will not seem so weird after a while!

Joel Garry wrote:
> cdavis10717@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/...abase _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?tmp...m/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

Well, you won't appreciate this one. Are you, like, stupid or
something? All of those things in Note: 247611.1 are fixed or easily
worked around by 9206.

Don't you realize a third party solution will have worse problems? If
your management is prone to finger-point won't having another vendor
involved hurt? And what about when your vendor gets bought by Sybase?
Don't you realize anything other than RMAN will have worse problems?
Didn't you notice the link to PITR workarounds? Haven't you read about
how RMAN is the only solution that can avoid split-block issues? What
are you doing now that you think is better? Have you searched metalink
for BMC? Do you think it is a bad thing that Oracle is upfront about
bugs? Do you think a product doesn't have bugs because it doesn't have
patches? Do you really think there is any out-of-the-box solution?
There is a whole industry of "integrators" based on making these things
work. Where in the world did you get a high TCO for RMAN? Why would
you search the internet for scripts? They're right there in the fine
manual, just a few lines long!

Sorry to make it rude or personal, but that's what I see. I'll wager
you have management that thinks yelling at vendors and staff makes
things get fixed. And it sounds like they haven't sprung for the
proper number of 9's if they have too small staff and no way to perform
periodic maintenance.

jg
--
@home.com is bogus.
The crooks are getting smarter.
http://www.signonsandiego.com/uniont...5identity.html