Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

recovery strategy check

Status
Not open for further replies.

patrick118

Technical User
Jan 14, 2004
315
NL
Backup database

At the moment we are using oracle 8i and we are going to move to 10g.

In oracle 8i we used the export utility to make backups and to be sure we made a cold backup of the entire database to disk and backup up that again to tape. We don’t use archivelogs. Works ok for us and we can use this same system under Oracle 10g.

But if you are using oracle 10g you have to make advantage of all the things it offers and the biggest one is RMAN. Only I don’t completely see how to make sure I have it all in a disaster recovery and would like for you to give me some pointers.

My Oracle 10g backup strategy.

Make sure the database runs in archivelog.

I made sure I always backup the controlfile and I want the backupsets to be compressed.

Every day I run the follwing RMAN script

Run
{
backup database;
backup (archivelog all);
}

I then backup the entire flash recovery area to tape.

When I get an error or something I just restore/recover it from a backupset. No problem

If the server completely burns out I would do the following.
I get a new server and install the same oracle version. I place back the flash recovery area from tape. Then what? My repository was in the controlfile.

So I do the following
RMAN> connect target /
RMAN> set dbid number from the burned out database;
RMAN> restore confrolfile from autobackup;
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open resetlogs;

Is this an ok idea?
 
I guess I'm "old school" (OCP'd on 7.3 in '98) but I don't /have never seen a real compelling reason to use rman. I'm not saying it's "bad", I'm just a "KISS" guy by nature and like to see the gears turning w/my own eyes. I've yet to find anything I can't do as or more reliably w/bash, sqlplus and cron (though in the last couple of years I have finally accepted PERL w/DBI as a legitimate tool).

am I the only "Commander Adama" left out there? :)
 
I think i got the big picture complete.

for DBAwhosaysNIE i can only say. Your missing some great stuff. Perhaps it's got a little advantage you never thought of, but perhaps i just like new stuff. I joking but take a look it is a good tool.

Patrick Netherlands signing off
 
The biggest advantage that you are missing is the ability to keep your database up while your backup (rman) is running. I have one server, in archive log mode, that I am using cron, compress, and a mapped drive to backup to a server, that is backed up to tape. However, all other oracle servers at my site use rman and it has been a solid and reliable product.

Bill
Oracle DBA/Developer
New York State, USA
 
I'm confused:

"The biggest advantage that you are missing is the ability to keep your database up while your backup (rman) is running"

implies you think you have to use rman to make a hot backup (sad) but:

"I have one server, in archive log mode, that I am using cron, compress, and a mapped drive to backup to a server"

implies you know better.
 
mufasa/sem/carp (/others w/7.3 & < experience):

is there acually anything you can do w/rman that you can't from a shell & sqlplus? I have looked at it in the past (years ago) and it seemed to me all it did was abstract the alter tablespace/database/system (& cp/dd shell) commands from the user.

am I missing something?
 
Yes you can do a hot backup using UNIX scripts (and I have), but rman automates the backup and handles selecting the correct backup, archive logs, loading the database, and applying the archive logs when a recovery is needed.


Can you build a car from a kit, sure! But it is much easier to buy one already made.

Bill
Oracle DBA/Developer
New York State, USA
 
Hmmm, can you do a:
Cross-Platform Tablespace Conversion

The RMAN command CONVERT TABLESPACE enables you to transport a tablespace from a database running on one platform (for example, Solaris) to a database running on a different platform (for example, Windows).

 
Cross-Platform Tablespace Conversion"

o.k., that's kind of cool (we don't use windoze but solaris<->linux could be useful) but (at the risk of being obstinate) what's the advantage of a TTS over exp/imp if you can't reuse the physical dbf? in fact if it is (by definition) having to physically rebuild the datafile(s) is it truly a TTS?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top