Operating System - HP-UX
1748209 Members
2748 Online
108759 Solutions
New Discussion юеВ

Re: Recommend backup for this Oracle database

 
Leon Allen
Regular Advisor

Re: Recommend backup for this Oracle database

I was put off using rman when I had to fork out big bucks (big for us) to enable omniback to integrate with rman.

Instead, I do both a logical backup (export) and a physical backup (hot backup) on a nightly basis.

Time's fun when your having flys (ancient frog saying)
Yogeeraj_1
Honored Contributor

Re: Recommend backup for this Oracle database

hi again,

For Backing Up in NOARCHIVELOG Mode, you should do the following:

# Shut down the database cleanly using immediate priority. This type of shutdown lets
# current calls to the database complete, but prevents further logons or calls.
# If the database is not up now, you will get a message saying so but RMAN will not
# treat this situation as an error.

shutdown immediate;

# Start up the database in case it crashed or was not shutdown cleanly prior to
# starting this script. This will perform a crash recovery if it is needed. Oracle
# uses the default INIT.ORA file. Alternatively, use this form: startup force dba
# pfile=. Use the DBA option because you are going to shut down again right
# away and do not want to let users in during the short interval. Use the FORCE
# option because it cannot hurt and might help in certain situations.

startup force dba;
shutdown immediate;

# Here, we know that the database is cleanly closed and is now ready for a cold
# backup. RMAN requires that the database be started and mounted to perform a backup,
# so do that now.

startup mount;
run {
# duplex the backup
set duplex = 2;

# allocate channel t1 type 'SBT_TAPE';
# allocate channel t2 type 'SBT_TAPE';
allocate channel t1 type disk;
allocate channel t2 type disk;

set limit channel t1 kbytes 2097150;
set limit channel t2 kbytes 2097150;

backup
incremental level 0
filesperset 5
database;
}

# now that the backup is complete, open the database.
alter database open;

============================================

see also: http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76990/usingrma.htm#435660

I would recommend that you turn on ARCHIVELOG mode.

Hope this helps!
best regards
Yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
R. Allan Hicks
Trusted Contributor

Re: Recommend backup for this Oracle database

I use the standard RMAN and the Legato that comes with 9i and came with 8i.

To your question about being or not being in Archive log mode (from a more recent post). You definitely need to be in Archive log mode. The only exception to this dogma is if you are doing developmental work and really don't care if you have to throw everything away.

I'll bore you with a basic description of archive log mode. (Feel free to skip ahead if you've already endured a similar lecture)

I. Archive Log Mode Lecture

Archive logs are simply copies of the redo logs. All changes made to the database are written to the db via dbwr (database writer) and when you are in archive log mode, they are written to the redo logs via lgwr (log writer). Yes, archive log mode has more overhead because there are more processes. But, it's a form of automatic incremental backup. When the database starts, it checks change numbers for each tablespace to determine if the change number in the tablespace matches the controlfiles. (BTW multiple control files are a real good idea as well as multiple redo logfiles in each group). If the change numbers do not match up, then the archivelogs and the redo logs are searched. The changes are pulled from the logs and applied to the tablespaces.

If you are not in archive log mode, then you can get the changes out of the redologs. Otherwise, if the changes weren't applied to the tablespace and the redo log have been overwritten then you are out of luck.

II Dangers of Archive Log Mode

BTW if you go to archivelog mode, realize that you may have to add redolog groups. In non-archivelog mode, switching from one redo to the next is no big deal and two redo groups is fine. However, in archivelog mode, you cannot switch to the next group until that group is archived. You cannot switch from group 1 to group 2 until the archiver has completed copying it. Oracle will go into a "polite" wait and simply hang until the archive is complete. The more groups you have, the less likely you'll enter this wait state.

You also need to be mindful of the number of log switches that occur at peak times. Not only will the system hang if there is not an available redo log group, but if the archive destination fills up, the system will enter another polite wait until there is space in the destination.

III Back Up with RMAN

As far as backup schemes go, RMAN is a very good solution. However, years ago there was a backup and recovery workshop from Oracle. I cannot recommend this course strongly enough.

1.) It lets you practice recovery when you job is not on the line. Ask yourself. "What would I do if I completely lost my controlfile?" "What would I do if the building housing my server and my backup tapes burned completely to the ground?" If you have a chance to see and successfully recover under a various set of disasters, you will have the confidence that you will need to face a real one. I once ran the wrong script and completely wiped out my production database. (I still have a job go figure) I got the whole thing back except for one hour.

2.) You gain a complete understanding of archivelogs, redologs and system change numbers (SCN). This lets you use RMAN wisely. It's not magic anymore.

I have used legato for my tape backups mainly because it was included in 8i release. You can use omniback or other media library management. I have issues with legato.

1.) Legato is not really supported by Oracle unless you get nasty with them. I don't like getting nasty. However, if you are willing to pay Legato, they are willing to help you. Not something you really want to have to deal with when you are putting your system back together.

2.) Legato knows what you want to do with your tapes better than you. For example, Legato knows that if you made a backup on computer A that there is no way that you'd want to do a restore to computer B. So, it protects you from yourself. It does set expiration dates on your backups to keep you from shooting yourself in the foot by writing over a recent backup. You can override this protection with very minor pleading with the admin product.

3.) Watch your /etc/hosts file like a hawk. If you put another machine in it and it the new machine appears before the local machine, Legato may give you a cryptic error message and refuse to work.

If I had the disk space, I'd do hot copies of the tablespaces to an alternate area of the disk and then do a tape backup of it using standard UNIX backup utilities. I lose the protection that Legato provides, but I feel more in control of things.

IV. Disc to Disc to Tape (D2D2T)

I recently attended a backup and recovery seminar hosted by some SANS and NANS people and they were recommending disk to disk to tape backups. Basically use RMAN or some scripts of your choice backup data across the network to a place where a tape librarian can handle the backups.

V. Diaster Recovery

I'd like to encourage you to think beyond just getting the data to tape, and think of a disaster recovery plan. Recent events have made people more aware of the legal responsibilites of maintaining a recoverable database. I'm in the process of reading Unix Backup and Recovery by (Preston or Curtis or Preston Curtis) I forget his name published by O'Reilly. I heard him speak and he makes you think beyond what you're doing and on to why you are doing it.

--Best of Luck
"Only he who attempts the absurd is capable of achieving the impossible
Steven E. Protter
Exalted Contributor

Re: Recommend backup for this Oracle database

How to go depends on a couple of simple factors in my opinion.

1) Is it a 24 x 7 system? If so, you need to minimize downtime.

In that scenario I recommend OnlineJFS be purchased and snapshots be made to disk. This lets you down the database, set up that changed blocks go to an alternate disk during backup. This lets you bring up the database after a disruption of less then 5 minutes.

2) If you can tolerate some downtime then down the database and copy the files to tape/disk or your choice of media. When the copy.

I like option 1, simply because it deals with a future that squeezes backup windows. Even if you use rman, the snapshot idea works nicely because its fast and just because you have an hour, why use the hour. All you need is a temporary logical volume equal to about 20% of the actual space allocated to the database to handle block updates.

The part I think is cool is you get a good cold backup, the best kind to have while the databse is hot, up and running.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com