> f) I would suggest Jared Still, Cary Millsap, Rachel Carmichael,
> Jonathan Lewis, Wolfgang Breitling, Steve Adams, Gaja V., Arup Nanda,
> Kirti Deshpande and Anjo Kolk to start the Oracle List certification
> process. I would trust that one more then the OCP. I apologize to
> anyone who I might have forgotten.
You flatter me way more than I deserve, placing me in that company. I
would add to your list:
Mladen Gogala
Daniel Fink
Tim Gorman
Mogens Norgaard
Peter Sharman
Peter Gram
Bjorn Engsig (sp?)
Connor McDonald
Richard Foote
all of whom are on this list. And I know I've forgotten several!
- "Gogala, Mladen" <MGogala_at_oxhp.com> wrote:
> I don't have any experience with SQL*Backtrack and I do have some
> experience
> with RMAN. Here are my comments:
> a) RMAN is reliable. Once you write the backup scripts, they are
> executed by
> operations
> and there no surprises. In order to rely on those scripts, one
> needs to
> test them, especially
> the recovery part.
> b) RMAN needs a 3rd party backup software to run. Things like
> OmniBackup,
> Tivoli, Legato or
> SyncSort can be rather expensive. RMAN doesn't write to tapes
> itself.
> RMAN delegates a
> backup software contacted through the routines from libobk.so (or
> libobk.dll or libobk.sl) to
> do its writing. To get the "libobk.so" from you backup software
> vendor
> of choice, you generally
> have to write a check. That means that RMAN is NOT free.
> c) Before version 9, RMAN was arcane and hard to learn. Thanks to
> Robert
> Freeman, it is no
> longer so. You can learn how to configure and use RMAN and you
> can find
> a decent book
> to learn RMAN from. It's not very hard and it's fairly logical.
> One
> reading of the books suffices
> for a good general understanding.
> d) Quality of the software: RMAN leaves a lot to be desired. Its
> biggest
> drawback is the fact that
> it doesn't do any coordination with the underlying backup
> catalog. In
> other words, you can happily
> declare backup obsolete in RMAN and Legato will not know anything
> about
> it and vice versa.
> You can even delete backup in Legato and reuse the tape while
> RMAN
> knows nothing about it.
> On the other hand, RMAN, in contrast to all other methods, does
> not put
> tablespaces into the
> backup mode, thus generating floods of redo archives. RMAN
> doesn't
> backup data blocks that
> have never been used ("behind the watermark blocks"), which is
> great if
> you have a fresh new
> datafile which was added to the tablespace just in case
> something might
> run out of space.
> e) Personnel. Despite the certification process, it is not always
> easy to
> find a trained personnel
> which knows how to use it and how to recover the database. I
> consider
> the ability to recover
> the database a basis for someone to call himself/herself a DBA.
> You
> would be surprised how
> many people which claim that title do not know how to recover
> the
> database. Even smaller number
> knows how to use RMAN.
> f) I would suggest Jared Still, Cary Millsap, Rachel Carmichael,
> Jonathan
> Lewis, Wolfgang Breitling,
> Steve Adams, Gaja V., Arup Nanda, Kirti Deshpande and Anjo Kolk
> to
> start the Oracle List certification
> process. I would trust that one more then the OCP. I apologize to
> anyone
> who I might have forgotten.
>
>
>
> Mladen Gogala
> Oracle DBA
> Phone:(203) 459-6855
> Email:mgogala_at_oxhp.com
>
> -----Original Message-----
> Sent: Wednesday, July 16, 2003 10:59 AM
> To: Multiple recipients of list ORACLE-L
>
>
> We have been using SQL Backtrack for backup and recovery for about 6
> years
> now. We are being pressured to start using RMAN because it is free.
> Makes
> sense but I am wondering about reliability, complexity, learning
> curve,
> etc...
>
> Has anyone had experience with both products or anyone new to RMAN
> that can
> give me an idea of what to expect?
>
> Thanks!
>
> Ron
>
> If you are not the intended recipient of this e-mail message, any
> use,
> distribution or copying of the message is prohibited. Please let me
> know
> immediately by return e-mail if you have received this message by
> mistake,
> then delete the e-mail message. Thank you.
Received on Wed Jul 16 2003 - 10:12:06 CDT
