Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN: I don't trust it

RE: RMAN: I don't trust it

From: Craig Munday <Craig.Munday_at_ecard.com.au>
Date: Mon, 10 Feb 2003 18:48:37 -0800
Message-ID: <F001.00548DB3.20030210184837@fatcity.com>


I dumped my "home grown" scripts pretty soon after Oracle released RMAN (after they fixed a number of early defects of course) and have never looked back. Although the RMAN scripting language is yet another language to learn it is well worth the effort. It allows you to backup an entire database with a surprisingly small number of commands (in the order to 5 I think), I doubt a home grown script using shell script or perl could be as simple.

Also you will never be able to match the performance of RMAN with a home grown script simply because you do not have access to the data that RMAN has. Try doing incremental backups or optimising the backup of a data file that hasn't been used. A home grown script will backup entire data files whether used or not, while RMAN will only record the existence of the file, and rebuild the empty file during recovery. These type of optimisation greatly reduce your mean time to recovery.

Recovery is also a lot simpler because RMAN does most of the work for you. I've never had any problems with RMAN locating the correct backup of various files. And because it is simpler, less experienced DBAs (DBA's new to an organisation or more junior DBAs) can have a better chance of recovering a database correctly - if the case should present itself.

Having said all that....it is worth keeping yourself up to date with the latest RMAN defects....it is only software after all. :-)

Cheers,
Craig.

-----Original Message-----
Sent: Tuesday, 11 February 2003 11:39 AM To: Multiple recipients of list ORACLE-L

Lyndon,

Unfortunately Oracle is probably focused more on dealing with large databases with complicated uptime requirements. I can just imagine how long it would take to push 1TB through gzip. Doing a daily backup would require multiple CPU's just to deal with the fact that it would still be zipping up the previous day. There comes a time when an incremental backup makes "really good" sense.

Perhaps we'll have to stick with the RMAN concept until someone tweaks gzip a little further? Oh, and in response to your final comment... I don't think "easy" was (nor should have been) Oracle's number one priority when designing rman.  

                    Lyndon Tiu

                    <ltiu_at_alumni.s       To:     Multiple recipients of list
ORACLE-L <ORACLE-L_at_fatcity.com>       
                    fu.ca>               cc:

                    Sent by:             Subject:     Re: RMAN: I don't
trust it                                   
                    root_at_fatcity.c

                    om

 

 

                    11/02/2003

                    10:03

                    Please respond

                    to ORACLE-L

 

 





If only Oracle can come up with a Postgresql command such as:

pg_dump dbname | gzip > dbname_backup.gz

Then backups would be easy. I know, I know Oracle can do the same with export, and sqlplus but hell it ain't that easy with Oracle.

--
Lyndon Tiu

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Lyndon Tiu
  INET: ltiu_at_alumni.sfu.ca

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: ListGuru_at_fatcity.com (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).




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>
Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (61 3) 9612-6999. Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Transurban City Link Ltd shall be understood as neither given nor endorsed by it. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Richard INET: mrichard_at_transurban.com.au 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: ListGuru_at_fatcity.com (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Craig Munday INET: Craig.Munday_at_ecard.com.au 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: ListGuru_at_fatcity.com (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).
Received on Mon Feb 10 2003 - 20:48:37 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US