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: RE : RMAN Repository

RE: RE : RMAN Repository

From: Robert Freeman <robertgfreeman_at_yahoo.com>
Date: Sat, 18 Jan 2003 23:38:47 -0800
Message-ID: <F001.00533ED6.20030118233847@fatcity.com>


RE: RE : RMAN RepositoryIn your case, the recovery catalog makes it MUCH MUCH easier!!!!! :-))))) So, I'm not saying you are incorrect, only that nobody should ever think they are unrecoverable just because RMAN can not find a backup set record in the repository or control file. Even in the case you state, as long as you know which tape the backup is on, you can manually recover those backups using the dbms_backup_restore package within Oracle (which is available when the instance is started). Basically, as long as you have the media and it's not corrupted and the MML stuff is configured correctly, you can extract the backup sets from that media regardless of the presence or lack thereof of the control file or the recovery catalog. It's just going to be painful but far less painful than looking for a job because you couldn't recover your database.

RF
  -----Original Message-----
  From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Johnston, Tim   Sent: Monday, January 13, 2003 7:29 PM   To: Multiple recipients of list ORACLE-L   Subject: RE: RE : RMAN Repository

  I do have one scenario where you really have to use a recovery catalog... When attempting to backup a VLDB that uses read only tablespaces and extremely infrequent backups for most of the data (i.e. a large datawarehouse), a recovery catalog is very important... You just may not have the time to perform full backups of your multi terabyte database... In this case, you better hope that the backup of your read only tablespace from 15 months ago is still around... Since the CONTROL_FILE_RECORD_KEEP parameter only goes to 1 year, you may be stuck unless you have that data in a recovery catalog...

  Tim
    -----Original Message-----
    From: Freeman Robert - IL [mailto:FREEMANR_at_tusc.com]     Sent: Thursday, January 09, 2003 12:35 PM     To: Multiple recipients of list ORACLE-L     Subject: RE: RE : RMAN Repository

    The only things you can't do with controlfile RMAN/database metadata is:

  1. use previous "incarnations" of the database for recovery;

    Actually, you can, it's just a manual process. This is documented in the RMAN book. Also, in 9i you can do automated backup/restore of control files of your database in RMAN without the recovery catalog, and you can manually recover a control file if that is required using dbms_backup_restore.

    Robert

    Robert G. Freeman
    Technical Management Consultant
    TUSC - The Oracle Experts www.tusc.com     904.708.5076 Cell (it's everywhere that I am!)     Author of several books you can find on Amazon.com!

-----Original Message-----

      From: Orr, Steve [mailto:sorr_at_rightnow.com]
      Sent: Thursday, January 09, 2003 10:46 AM
      To: Multiple recipients of list ORACLE-L
      Subject: RE: RE : RMAN Repository


      If you aren't using a repository all you have to do is make sure
control file backups are part of the routine. There are 2 ways to backup the backup metadata: 1) the RMAN repository database; 2) backup controlfiles.

      Functionally and operationally they're pretty much the same. The only things you can't do with controlfile RMAN/database metadata is: 1) use previous "incarnations" of the database for recovery; 2) use database stored scripts. No big deal as far as I'm concerned.

      When RMAN first came out a separate repository database was a requirement. Subsequent releases added some functionality for using controlfiles. The vulnerability of losing the repository or losing the backup controlfile is about equivalent. The overhead of the repository database is more. With the initial releases of RMAN (EBU) Oracle was rightly criticized for the fact that you had to backup the database that holds information about the database you want to backup. Getting rid of this silliness seems reasonable to me.

      Steve Orr-man for RMAN,
      Bozeman, Montana




-----Original Message-----
From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com] Sent: Wednesday, January 08, 2003 2:14 PM To: Multiple recipients of list ORACLE-L Subject: RE : RMAN Repository Importance: High And how does one go about restoring a database when all control files are lost, and the only recovery data is stored in the control file? This doesn't sound very reasonable. Jared "Deshpande, Kirti" <kirti.deshpande_at_verizon.com> Sent by: root_at_fatcity.com 01/08/2003 11:44 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: Subject: RE : RMAN Repository Joe, That's what I have heard (from 2 Oracle University Professors/Lecturers/Demonstrators). But no one would tell me when it may happen. We do not use RMAN (yet) so I did not pursue it further. - Kirti
-----Original Message-----
Sent: Wednesday, January 08, 2003 1:08 PM To: Multiple recipients of list ORACLE-L <snip> Obilgatory oracle statement/question: rumor has it by some instructors that RMAN repository is going away and only control file recoveries will be possible, truth or fiction? joe
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Robert Freeman
  INET: robertgfreeman_at_yahoo.com

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 Sun Jan 19 2003 - 01:38:47 CST

Original text of this message

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