Database Backup Method
Hamid, August 15, 2002 - 1:53 pm UTC
Not sure I agree with RMAN being the 'best' solution for backup/restore. 'Catalog' piece is another Oracle instance, which needs to be maintained and can go down just like any other database..!
RMAN may be a good choice for a small operation, however, I would not recommend it for an enterprise enviornment. I have experience with RMAN/EMC/others, and I personally prefer EMC solutions/OS backups. I think the restore time is faster and the operation is clean and it works! Plus let UNIX admin take on some responsibility he/she is there anyway :)
August 15, 2002 - 7:23 pm UTC
To each their own I suppose. The catalog is the key feature of RMAN, not a downside.
I personally wouldn't let a UNIX admin take responsibility for my databases (small, med or large). I've seen more than one "oh, you mean I cannot just copy the files while its running -- I have to do something special" in my life -- usually right after we ask them to restore.
Backup using RMAN
Keanu, August 15, 2002 - 9:47 pm UTC
Tom, can you tell which backup method you are using ? I am still thinking which backup method that we'll provide to our customer (OS method and RMAN method )
Can you provide me some link about clone database ? Is is the same as "duplicate database"
August 15, 2002 - 10:05 pm UTC
clone = duplicate
We use rman internally here at Oracle, we use OS backups, we use everything under the sun probably. Me -- I don't actually backup databases, Fred does (and currently Fred uses tar)
Agreed...
Connor, August 16, 2002 - 3:48 am UTC
Being a "long termer" DBA and unix admin I was the ultimate RMAN cynic, and that distrust was well warranted in 8.0.x!
But I recently worked on a site that was deploying their "Enterprise Backup Solution", and they had decided on rman for all db's (8.1+). With my sceptics hat firmly in place, I struggled for days to make rman fail but it stood up to the test. We went through dozens of possible recovery scenarios and rman did what was expected each time. I'm now an RMAN convert...its top notch
Database Backup Method
Hamid, August 16, 2002 - 11:48 am UTC
If a UNIX admin does not know how to make backups then in my humble opinion he/she is in the wrong line of work...!
August 16, 2002 - 12:41 pm UTC
Why? Most unix admins I know don't know the database from a hole in the ground. They naively assume "its just files, let me copy them like I do for all other backups" and away they go.
There are DBA's
There as SA's
In small shops there are SA's who are forced to be DBA's or DBA's forced to be SA's.
They are two different people where I come from generally.
Backup Method
Hamid, August 16, 2002 - 12:59 pm UTC
Well, I do not agree with that, just like there are some overlaps with DBA/developer role, I see an overlap with DBA/SA groups. This makes the 3 groups developer/DBA/SA working together mandatory to the level that warrants smooth operation of Databases.
I just find it easy to ask the Unix admin to restore files and apply the redo logs for recovery. I have not had a problem yet. We have mapped out our mount points for each database in detail and where files are located etc.
With RMAN I would have to come up a plan to backup RMAN also-i do not want to be concerned about my 'backup media's failure'...!
With OS/EMC all this is not needed. This is my understanding unless i missed some piece of the RMAN process.
August 16, 2002 - 1:28 pm UTC
Overlap yes, same jobs, no. Restoring a file from a backup tape is quite different from developing and implementing your backup and recovery plan. Working together is HUGELY different from "SA backs up database". It is more like "SA runs scripts developed by DBA to backup database" or "SA uses piece of software that is Oracle aware and nows how to put Oracle into hot backup mode and do all of the book-keeping necessary". Anyway...
So tell me -- with EMC/OS -- where is your recovery catalog? (it's equivalent). Is it on a piece of paper? Is it in your head. Or -- do they have it in a database on their equipment and you are just neglecting to back that up yourself manually?
Think about it -- the recovery catalog is just book-keeping information. All backup tools *need to have book-keeping information*. If you percieve that it is "easier" with EMC cause you don't have to back up the book keeping info, maybe you are just neglecting to back that up (and are in for a surprise someday).
All backup stuff needs it. With RMAN you don't HAVE to use a recovery catalog, it is not mandatory. We stuff the minimal needed info into the control files of the database itself. It just opens up lots of opportunities.
Tell me, when one 8k block goes bad in a 16 or 32gig datafile -- what will EMC/OS backups do for you? (nothing, you'll have to take the affected tablespace offline, restore the entire backup file, apply all of the archived redo log to the entire file to restore it). With RMAN, take NOTHING offline -- restore just 8k of data and apply archives only to 8k of data.
Amongst other things.
Restoring datafiles backed up without begin backup
David, March 05, 2003 - 7:31 pm UTC
Let me explain...
I usually use standard hot backup routines with begin/end backup in "my own territory". They work pretty well -- no problem with them.
But one day, a big big big boss (from sky high) told me to fix the problem in an SNOC (Security Network Operating Center) in another department.
To my surprise, their mission-critical Oracle crashed. They only had OS backups. I remembered my old Oracle classes and the AskTom forum. I said... "Your backup is UNUSABLE" (I trusted Tom, who said it would be)
But just in case, we tried to restore their datafiles from the OS backup. It asked for some archives (there were archives btw).
Finally their batabase came up ok, and they looked at me like "Hey, didn't you say the backup was unusable ?"
1) Is it possible that their database only *seemed* to come up okay, but some internal structures (fractured blocks, whatever) were no good -- but Oracle couldn't spot them ? They might discover that some day in the future ?
2) What should I say instead of "Your database is UNUSABLE" so I wouldn't look like a clown ? Maybe "You'd better not trust your backup, although it might come up ok ?"
3) How can i know it "came up ok" ? Should I do some testing ? They may be trusting a system that's corrupted ?
March 05, 2003 - 7:36 pm UTC
they got lucky. you can get lucky.
1) no, it recovered.
2) I'd rather put the fear of whomever you believe in in everyone.
3) no, the recovery process should have taken care of all of that.
they got very very very lucky. More often then not, it can go the other way. I've seen it time and time and time again.
RMAN versus User managed
scott, May 06, 2005 - 1:37 am UTC
We have used user managed backup and recovery techniques sucessfully four years. We have recovered from a variety of hardware and environmental failures and always met stated business expectations. (Of course, business expectation have always changed post recovery....however that is a different conversation)
My alliance to user managed backup and recovery comes from experience, knowledge of the process, a warm fuzzy feeling (being able to "touch" the files) and trust in the ability to bring back our databases. My FUD of RMAN relates to inexperience, lack of knowledge and subsequent distrust.
My dilema:
I need to rely on my backups
I need to stay current with available technology
I'll start with the documentation on RMAN.
That said, I think it beneficial to have a thread with the purpose of proving, or disproving, RMAN. (versus user managed backup and recovery). Do you agree?
If AskTom already has a similar thread please direct me (I looked but could not find).
Thanks.
May 06, 2005 - 7:36 am UTC
it is one of scaling and features.
If you have a single (or few) small databases (under say 150 gig), do it yourself works (as long as you don't get hit by a bus, or have really superb documentation skills).
If you have a couple or more of databases to worry about, you need a book keeper and that is rman.
If you want to backup without backup mode (without the redo hit), that is rman.
If you want to catch physical/logical corruption issues near to the point of introduction, that is rman (a bad block can go unnoticed for months -- and then it is too late, rman will let you know sooner)
If you want to minimize recovery time with things like block level recovery, that is rman.
In some ways it'll appear more complex than do it yourself methods, because you don't know the commands and the archticture.
But the same is true of do it yourself methods when you use them for the first time ;)
A reader, May 07, 2005 - 6:14 am UTC
OK, then lets proof this out. Based on your answer I think we should prove or disprove the following. Do you agree with the points / interpretation below?
User managed backup and recovery works when the infrastructure has 1-5 databases less than 150 gig
I need a bookkeeper if I have more than 2 databases
Less redo hit if I backup in backup mode with RMAN
A bad block can go unnoticed for months
Recovery time is reduced with RMAN
May 07, 2005 - 8:10 am UTC
well, technically, user managed backup and recovery works with an infinite number of databases -- however, it gets to be a great burden on you from a book keeping perspective and a tool such as the RMAN catalog comes as a benefit at that point as it automates that which you would have to otherwise do manually.
So that is points 1 and 2 from your list.
The next two are facts -- you need not put the tablespaces in backup mode and backup mode causes more redo to be generated than normal. A bad block can go unnoticed for a long time.
The last one is probable and possible but not assured.