I've just been itching to post this one.
I'm doing a chalk-talk (AKA cabana session, this year AKA Technical Learning Centre session) at TechEd next Wednesday (8.30am 6/14) called 'DBCC CHECKDB: Magic, Monsters, and Myths'. A lot of the material in this will be included in the mega-whitepaper on DBCC I'll be writing over the summer, but it also slices nicely into blog-size posts so I'm going to do a series of them over the next month or two covering everything from today's topic to very deep drilldowns into how specific repairs work. If there's anything specific you'd like to see, let me know.
Billy Connolly (a great Scottish comedian) tells a story from his childhood about his father listening to the radio at breakfast while eating his outmeal, and every so often shouting 'No!!!' at the radio. Eventually the radio had a nice spackling of dried outmeal. I usually read the newsgroups and various MS and non-MS forums every day or so - and if I were to read them at breakfast, my laptop screen would very quickly get a nice spackling too (not of oatmeal though - nasty stuff).
I really despair to see some of the 'advice' that's out there, even though its all well-intentioned. Here are some of the gems related to disaster recovery - and I'll try not to rant.
"Just run REPAIR_ALLOW_DATA_LOSS and you'll be fine..."
"Just rebuild your transaction log using these steps..."
"Just restore your database and carry on..."
"Run CHECKALLOC, then CHECKDB, then CHECKTABLE on all your tables, then..."
"Just flick the power switch on and off a few times on one of the drives..."
These are the worst ones around disaster recovery. I could go on all day about not shrinking database and not blindly rebuilding all indexes every night but it's lunchtime so I won't go there - yet :-)
I work in the DR Environment. Thousands of companys test at our facility. Many fail to recover. The problem that I see daily is that.. Some has a recovery plan, and they really try to recover from a disaster and they still fail. Just imagine .. the ones that don't have a plan. The biggest problem that I have seen is ..1. Back up Software: Reaction to the OS. 2: Restoring to dissimiliar hardware. 3: Time Restraints. Now put them all together with about 20 techs.. who have been working for at least 8 hrs and you have back up software running that does not tell if it is running or erred out. Especially with large dbs like SQL. How would you like to be running a restore for 6 hrs or so.. and find out then that It crapped out 4 hrs ago... More to come....
Just think about this for a moment.. Lets use Tivoli as our back up software ... We're backing up a SQL database. Using LTO 2 tape drives, Our current servers are DL 380 G3's dual processors, 4 g mem, Licenced for 2 processors. ( Recovering to a ML570 G3 Server, 32G mem, Quad Processors, Quad Nics, Gige connections , P600 Raid Controller etc. DO THINK YOU WILL RECOVER OR "blue screen"
See .. Backup is not the problem, but rather utilizing that backup file to restore your db. Backup software, Media Plays an enormous role in how and what you will restore to in order to recover.
I mentioned a the storage engine blog recently and was reading the latest post Common bad advice around
PingBack from http://music.247blogging.info/?p=1355
PingBack from http://outdoorceilingfansite.info/story.php?id=22128
PingBack from http://outdoorceilingfansite.info/story.php?id=4492