One of the things that drives me crazy as I’m getting older is that my brain is losing the capacity to differentiate version numbers. As I speak travel around speaking with customers and at conferences, I find my self saying things like “I can’t recall if this problem was fixed in SQL Server 2000 or 2005. But you don’t have to worry about that any more.” Or things like “That feature was added in SQL Server 2008 R2, eh, or was that version 6.5. DOH!” followed by a loud slapping sound as I whap my palm into my forehead.
The Internet doesn’t forget either. Recommendations that were once helpful, if not outright essential, now are neutral or even downright bad. So now, whenever I put together new presentations, I always spend a lot of time in research, reassessing my knowledge on the topic. (That doesn’t mean that I’ll extemporaneously say it wrong, because I speak in an off-the-cuff and rapid style. But at least my notes are usually correct).
Case In Point
Take backup and recovery (B&R), for example. I’ve been writing about and performing B&R for years. I’m even part of the team that builds the most popular B&R tool in the SQL Server space. It’s an extremely important part of what I do. And yet, even after spending a couple days re-researching topics (yet again), I still manage to get a few of the more specific details wrong because of changes over the years in the feature set. How so?
During an Expert’s Perspective webcast last week (and available on-demand) covering the top backup and recovery mistakes on Microsoft SQL Server, I mis-explained the details concerning how SQL Server performs a differential backup. A very clever SC on our team who was also attending the webcast pointed out to me after the session that I’d described differentials working at an 8k page-level when, in fact, they work at the extend-level (that’s a block of eight 8k pages). #FACEPALM!
When describing the differential backup I said that a bit was flipped on each page header and SQL Server would only back up those pages. Instead, whenever a page is changed a bit is recorded on the differential change map (1bit per extent), the backup process then queries these map pages and backs up those extents that have been marked as changed.
- Watch the on-demand video of Performance Tuning SQL Server for Backups and Restores, with me, Iain Kick, and Brent Ozar (blog | twitter). Free, but registration required.
- Watch the on-demand video of Ten Incredibly Painful SQL Server Backup and Recovery Mistakes, with me and David Gugick.
The Research Reveals
The cool revelation here is not that I can admit my mistakes. The take-away from this blog post are all the great articles I read writing my latest slide deck. These blogs and articles were so good that I needed to spread the word. Add these to your must read list:
Virtual Log Files must be tamed!
- Performance impact: a large number of virtual log files Part I and Part II by one of my favorite not-so-prolific bloggers, Linchi Shea (blog). The thing I love about Linchi’s content is its rich benchmarking information. Few SQL Server experts out there routinely test the behavior and performance of specific SQL Server features like Linchi does.
- Slow recovery times and slow performance due to large numbers of Virtual Log Files, by Graham Kent (blog) of Microsoft Sweden, shows that VLFs impact not only the processing time of transactions but also B&R processes.
- Lots of VLFs are Bad, by Tony Rogerson (blog | twitter), was the article that first got me interested in this behavior.
Backup and Recovery Myth Busting
- Breaking the Backup Chain – Redux (Or ‘Eating Crow’), by Michael K. Campbell (blog), shows that out-of-band database backups break differentials not transaction log backups.
- Backup with COPY_ONLY, How to Avoid Breaking the Backup Chain, by the eminent Paul Randal (blog | twitter), uses clear writing and first-class demos to illustrate the principle of breaking backup chains in Microsoft SQL Server. Other great blogs of a related nature from Paul include:
Other Good Sources
And just in case you need a refreshing in the basics of SQL Server backup and recovery, check these out:
Nice article.
May be off-topic but closely coupled with Backups : I wrote about trimming transactions log file http://slowquery.blogspot.com/2011/12/shrink-ms-sql-server-transaction.html
hopefully, that will help to give some insights to readers!