I'll second what Ruth says about backup to disk then use the OS tape
routine to archive off of the diaks. I would keep at least 2 disk
backups available on disk. It is faster to perform a restore from a disk
based backup than from a sequential tape. 
 Restore on datafile from RMAN - 20 min. mount the OS tapes and search
for the backed up datafile - all day.  Now if I can get the sysadmin to
only backup the RMAN files daily rather than a complete disk image each
night.
Ron

>>> [EMAIL PROTECTED] 07/16/03 02:19PM >>>
MessageIf you have to work on the cheap, you can put the backups to
tape and then copy them to tape using the OS backup software.  It isn't
elegant, but it works!  

Ruth
  ----- Original Message ----- 
  From: Arup Nanda 
  To: Multiple recipients of list ORACLE-L 
  Sent: Wednesday, July 16, 2003 1:24 PM
  Subject: Re: RMAN & SQL Backtrack


  Wow! Heady!!

  It's mighty nice of you to include my name in this illustrious list,
Mladen; but I don't consider myself to be in the same league :) Better
yet, count yourself in there.

  Talking about the business at hand - you are absolutely right; one of
the "myths" (of the several) is that RMAN is free. It is, as long as you
don't put it on tape. Once you bring tape to the picture, you are
talking money, sometimes big money (as in Tivoli), sometimes small (as
in BrightStor). However, the solution to usedisk could still be relevant
and applicable in some cases, especially in small companies. 

  Besides the Freeman book, I would also suggest another one - Oracle
RMAN Pocket Reference by Darl Kuhn and Scott Schulze, ISBN
0-596-00233-5. It predates the Freeman book and I learned my ropes from
it. It's a pocket reference; but it's truly one of those things where
size belies the content.

  Learning curve could be formidable. Remember you need to learn a new
"language", and it is arcane. When youventure into territories of tuning
the tape buffers, etc, the process could be quite involved. I just
finished setting up and tuning a RMAN setup for a 2 TB database using
IBM Tivoli Storage Manager agent and the details of the process using
the IBM Red Books was nightmarish!

  Regards,

  Arup Nanda
    ----- Original Message ----- 
    From: Gogala, Mladen 
    To: Multiple recipients of list ORACLE-L 
    Sent: Wednesday, July 16, 2003 11:39 AM
    Subject: RE: RMAN & SQL Backtrack


    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:[EMAIL PROTECTED] 

      -----Original Message-----
      From: Smith, Ron L. [mailto:[EMAIL PROTECTED] 
      Sent: Wednesday, July 16, 2003 10:59 AM
      To: Multiple recipients of list ORACLE-L
      Subject: RMAN & SQL Backtrack


      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.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ron Rogers
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to