Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.
on October 9, 2012
I’ve been working with SQL Server databases, Windows administration, and software development an awfully long time. Once you have a lot of experience with something, it’s easy to forget what’s not obvious to newbies. But some things you have to learn the hard way.
There’s a lot of stuff that I “just know” now and have no idea when or how I learned them. But there’s a few things I remember being particularly ignorant about for a long time.
Log Backups Were Really Mysterious
I worked with SQL Server instances using the simple recovery model for years. I started out administering lab instances and automating whole environment build-outs. If anything went wrong we would never do a point-in-time restore, we’d just build out a fresh, clean environment.
After that I worked with high transaction systems, but we were shredding and importing data from tons of files. Instead of spending IO on log backups, our system was designed so that if there was an issue we’d restore from the last full and just re-import files.
I didn’t fully understand this at the time, but in both situations we benefitted a lot from minimal logging.
I’d worked as a DBA for four or five years before I ever needed to back up a transaction log, much less restore one. I’d never needed to learn about it, so it seemed really … DIFFICULT. There was something almost intimidating about it.
Eventually, I read through some MSDN topics and ran through the commands on a test database on my own SQL Server instance. Turns out running those log backups and restoring them wasn’t nearly as hard as I thought.
I Mispronounced “Cache” for Years
The first DBA team I worked with didn’t talk about the SQL Server buffer pool. Instead they talked about what was in cache or not in cache. This isn’t too unusual when it comes to SQL Server. After all, there’s the “Plan Cache”. There’s counters for various “Cache Hit Ratios”.
But I couldn’t pronounce the word properly. I read everything I could about SQL Server and I’d seen the word a lot before I ever heard it pronounced, and my brain was convinced that the word was pronounced “kayshe”. With an extra southern twist on it.
I got laughed at more than once for saying this wrong– literally a bunch of people laughing in that way which makes you feel like a complete ignoramus. I had a really hard time with it, so I just started saying “memory”, but that’s kind of awkward. Eventually I learned to just say “cash”, but I still kinda smile whenever I have to use the word.
Database Mirroring Seemed Like Witchcraft
I was fortunate to work a lot with clustered instances of SQL Server for high availability. I also got great experience working with high transaction SQL Server replication, which was used to distribute small subsets of data for programmatic access, data transformation, and reporting. I knew these technologies very well and got very comfortable with them.
Since I worked with a lot of pricy SANs in a large environment, disaster recovery was on a massive scale and involved SAN replication to remote datacenters.
To me, all of this was very normal, while technologies like database mirroring seemed weird. I came to understand how they worked, but it wasn’t until I moved into a smaller environment that solved problems without multi-million dollar storage appliances that I learned that database level technologies like mirroring aren’t anything crazy— and I got to come up with ways to make it work myself. But for a while I felt like Mrs Howell on Gilligan’s Island-- completely clueless.
Everyone’s Got Blind Spots
I’m grateful for all the experience I have. Lots of things in IT, particularly related to hardware, storage, performance tuning, and software development practices just aren’t things you’ll ever learn in school— you need to find the right situation where you have an opportunity to learn and have people who can help you through the hard points.
Even when you’re learning and absorbing and building on everything you come across in your path, in a rich technical environment there’s always a pattern you haven’t heard of, an opportunity you haven’t considered, or a gotcha you may have missed.
But as you build all that experience, this becomes easier and easier to forget— and it’s worth remembering that it’s OK that sometimes we’re all accidentally the nitwit in the room.