RMAN - in a nutshell!

[MCubitt]

Our company are struggling to limit server downtime which is caused by backups, where we currently down a database, copy files to a dump area and then start the database, backing up the dump later.

However, the day is lurking for our company to experience 24/5.. 24/6 uptime requirements.

I understand RMAN is a tool which can perform backups of active databases but have also heard it can be complex.

Can anyone offer opinions on using this kind of tool?

We have very limited Oracle knowledge (as anyone in this forum who knows my questions would agree!) but are keen to learn.. quickly!

I know there are variables including archive mode and such, but don't really comporehend.

thanks




Applications Support
UK

 

[ErrolDC]

Not an expert, but I manage several oracle installations and I do all our backup and recovery via RMAN. With that said, RMAN stands for Recovery Manager and it is a powerful backup and recovery tool that you really should look into. Can it be complex? Yes, but that really depends upon how you use it and how complex you as the admin try to make your backup/recovey plan for your Oracle installs. In my experiences with it, it's been just awesome. When you use cold or hot backup methods, you as the dba have to maintain the knowledge of where those files are on the filesystem. When you use RMAN, it takes care of the maintaining that knowledge for you. Anyways, the best advice I can give you is use it and get a good book. Rman has been out since 8.03 so there are plenty of good books for it.
Hope that helps.

 

[MCubitt]

Thanks, it is useful to know.


Applications Support
UK

 

[bookouri]

You can also do "hot" backups while the database is on line. If you dont have time to learn RMAN, hot backups always seemed, to me, to be a lot more straight forward and easier to understand and accomplish.

to do hot backups you just have to be in Archive log mode and as oracle would say you should NEVER run a production database except in archive log mode

if you are in archive log mode, you then just have to place each tablespace in backup mode, copy the data files and then take the tablespace out of backup mode, its really very simple

alter tablespace SYSTEM begin backup;
copy databasefile.dbf to backuplocation/databasefile.dbf
alter tablespace SYSTEM end backup;

an even simpler and more fool proof way to do a full backup is to do a full export of the database.

We always do both...

 

[MCubitt]

Well, we are NOT in archive mode. We have folders "archivelogs" but there're always empty.

Is turning it on simple and non-problematic?

I gues physical file copies always makes one feel safer, getting the file structure copied in the process. An export requires (or the import does) the structure exists.

thanks



Applications Support
UK

 

[KenCunningham]

Martin (I think?),

turning archive logging on is simple enough, but remember to monitor the space it's taking up on a regular basis - it can fill up pretty quickly if you've an active database! I clear any archive logs over a week old after verifying a full backup is OK. Instructions are:

http://www.dbaoncall.net/references/ht_archive_mode.html

Best wishes.

 

[Michael42]

MCubitt,

>> Well, we are NOT in archive mode.

Unless you have a business rule that directly instructs you to NOT use Archive Log mode, I would highly recommend you use this mode! It will bring into play several backup and recovery options that simply to not exist without it.

MCubitt, I think you will find the more you study what Archive Log mode can do for you any reasons for not using it will quickly fall away. RMan is just one cool possibility.

I have had to restore a mission critical databases with and without a DB in Archive Log mode and I have to tell ya...man...I hope you never experience it.

I hope this helps,

Michael42

 

[MCubitt]

Thank you all very much. Our supplier of our ERP system installed and configured Oracle so I guess they had their reasons (?)

But I think it's because their install was based on older versions of Oracle, perhaps it was not as desirable ?

Anyway, I will investigate switching this on in a test DB first..

cheers



Applications Support
UK

 

[MCubitt]

I have set on archive logs, adding the following to init.ora:
log_archive_dest_1 = 'LOCATION=/archivelogs/IFSD/ MANDATORY REOPEN'
log_archive_format = 'arch%S.arc'
log_archive_start = TRUE

Does this sound reasonable? The Mandatory Reopen seems to suggest better data integrity..

Thanks


Applications Support
UK

 

[MCubitt]

Actually, I was wrong.

I actuall am using this:
log_archive_start = TRUE
log_archive_format = arch%S.arc
log_archive_dest = /archivelogs/IFSD

I used console manager to set archive log on, which restarted the DB.

There are no files (yet) in /archivelogs/IFSD ... do these first get created upon redo logs filling up?

thanks


Applications Support
UK

 

[KenCunningham]

Yes they will. Always monitor the space used by them - they can kill the system if they fill the available space. Once you have a verified backup or two you should consider archiving them to tape or (as I do) deleting ones from before the good backup.

 

[MCubitt]

ken,

Thanks for the advice.

Will I expect to see a number of archive files, matching teh redo log IDs (eg if we have 5 redo logs, I'd see 5 archive logs, eventually) ?

This might be a silly question, but what exactly are the archive logs doing?

Are they archiving redo logs so that one can restore a system from the last full back up?

I assume when I perform a full backup of the DB it will reset the logs?

I am probably comparing archive logs to changed objects on an AS/400 box, where after a system save, changes to objects is recorded and can be saved later, allowing one to restore from the system back up and then apply the saved changes from each daily backup.

Or does this prove even better, allowing one to go BACKwards to get to a point in time?

Thanks in anticipation.







Applications Support
UK

 

[KenCunningham]

Yes, archive logging saves transactions allowing you to recover the database on a 'point in time' basis, so that as long as you have the files and a backup, you can revert the database to the point in time just before that silly user dropped the important table!! The files get written when the redo logs fill up, but there's no correllation in the numbering with the redo logs, the filenames just get incremented each time a new one is written.

 

[MCubitt]

OK, archivelog mode been active for a day or two, now have the following:

drwxr-sr-x   3 oracle   dba             512 08 Feb 09:44 .
drwxrwsrwx   8 oracle   dba             512 25 Mar 2004  ..
-rw-rw----   1 oracle   dba        52421632 07 Feb 09:39 arch0000000032.arc
-rw-rw----   1 oracle   dba        52428288 07 Feb 10:25 arch0000000033.arc
-rw-rw----   1 oracle   dba        52427776 07 Feb 12:58 arch0000000034.arc
-rw-rw----   1 oracle   dba        52428288 07 Feb 16:18 arch0000000035.arc
-rw-rw----   1 oracle   dba        52428288 08 Feb 00:43 arch0000000036.arc
-rw-rw----   1 oracle   dba        52428288 08 Feb 06:35 arch0000000037.arc
-rw-rw----   1 oracle   dba        52428288 08 Feb 09:44 arch0000000038.arc

Is the idea I keep them ALL until the next FULL backup? Do I back the arc files, 32-37 and keep 38?





Applications Support
UK

 

[KenCunningham]

Assuming you have space, keep them all until the next full backup. The files are cumulative (ie each contains transactions from a particular time period), so you would require all files since the last backup if you had to do a restore to a point in time. I've got a cronjob which periodically compresses the 'used' files so that they take up much less space and thus gives more time until the need to clear down becomes critical. Having said that, I tend to clear files > 3 days old anyway (our full backups are taken on a nightly basis).

 

[MCubitt]

I see... and if I do a backup, do I then have to manually delete the arc files (do I need to include them on my full backup?!) or does Oracle do that (no, how the heck would it know it's been backed up!).

Presuming Oracle does not delete them after backup, can I simply delete the physical archive files (all of them) while the DB is shutdown or running?

Sorry, I should probably get a good book about it.. any advice there? 9i book with backup/recovery strategies.




Applications Support
UK

 

[alexhu]

Martin

It may be helpful if other people tell you what they do (hope Ken can answer this as well !)

I do this

have archives sent to 2 areas on seperate filesystems

backup every day including all available archive logs from one of the filesystems - verify the tape after its been written

keep 3 days of archives on disk

compress and delete archive logs via cron on a 30 minute job(this keeps the filesystems to about 60% full)

To answer your question - Oracle does nothing with the logs apart from generate them !

There are books available, but I don't have any recommendations, sorry.

Alex

 

[MCubitt]

Alex,

Thank you for that suggestion. I think other people's tried & tested solutions offer more variety and ideas than most text books anyway, so good idea.

Just another Q (since I am getting close to understanding!), the archive log is just that, it is an archive of a full redo log. therefore, the written .arc file is not "live" but contains "live" data.. necessary for a restore.

In order to achive a backup and recovery strategy of Oracle, I have made a step forward by introducing archivelogs to our test DB (for now).

Once I have a better backup/recovery strategy, I can utilise these. Currently we perform cold backups.

Thanks all for your help.






Applications Support
UK

 

[alexhu]

Just another Q (since I am getting close to understanding!), the archive log is just that, it is an archive of a full redo log. therefore, the written .arc file is not "live" but contains "live" data.. necessary for a restore

Yes - it may also be the archive of a partially fully redo log if a 'switch logfile' command is issued

Alex

 

[KenCunningham]

Our approach is basically the same as Alex's, including the compression on a 30 minute cron job. One additional 'feature' (though whether it's necessary or not I don't know), is to amend the compression script to leave the latest archive log alone, since I have a (probably irrational) fear that one day, the compress might start at exactly the time the log is being written, thus possibly corrupting it. Belt and braces indeed!