A colleague of mine recently attended the VLDB 2007 conference. In his report of the conference he mentioned a talk by Werner Vogels of Amazon. Basically Werner seemed to be saying that for amazon traditional RDBMS’s were not necessarily suitable for all business processes in an ultra scalable distributed environment like amazon and that not all data is equally important. Coincidentally, Tom Kyte was talking about the data being the most important thing.
I think the top priority for any DBA is to ensure that when (not if) a failure occurs (whether that is human, mechanical or environmental) the data belonging to the business can be recovered. Sure you might call it a backup strategy, but it really should be a recovery strategy. I think Dataguard is ideal for this, but is it going to protect you from dropping a table? Well maybe if you have a long enough delay on applying your changes to your standby, or if you have flashback database enabled you could also pull yourself out the mud (would I run flashback on my production primary – probably not yet, would I run it on a standby? Hell yes!)
Don’t forget about rman as well, it really has come a long way from it’s first release and it is not all that scary now. I like the sound of creating image copies and having them lying round on disk ready to swap into place with one piece of sql rather than waiting to restore my 32GB file, but you still need something offsite for when the something goes badly wrong with the datacenter.
As I said backing up is all well and good, but unless you have tested it, it is just a fig leaf. You have to test that you can recover and a DBA that has not got confidence in his ability to recover his data from his backups is in the wrong job. A really useful way of testing your backups is to use them to create a clone of your production system for your developers to test on, maybe even a beta environment. (well, there’s a future blog posting).