Wow! Mladen, thanks for listing my name in your list.
As Arup mentioned, you forgot yourself. I would also suggest Dan Fink, Tim Gorman, and Dr. Mogens!
Gaja is moving the other (dark) side, so I won't mind excluding him :)
When it comes to RMAN, I am not even in the rookie stage. We bought a few copies of RF's book. But
mine has now found its place under my desk! The Damagement is not yet willing to commit any time
and resources to "play" with RMAN and without the Tivoli API, we can not do much.
Although RMAN is free and the MML API may not cost as much, but when you have a merged Company
like ours (VERIZON=GTE + BellAtlantic), we have our own 'sand boxes' and playing fields. Old BA
stuff still uses SQL*BT while we, the fGTE DBAs want to move to RMAN.... But may be we all leave
that decision to Amdocs, as they might get our IT business pretty soon, per some official rumors.
Till then we will continue to use good old, and aged, hot backup scripts to backup databases of
all shapes and sizes (from 1G to over 500G)
Cheers!
- Kirti
- "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
>
>
Received on Wed Jul 16 2003 - 15:29:11 CDT
