It’s been a while since I’ve had a new post here, and that’s largely due to the quantity of other things on which I’ve been working. This list of busy-ness – presumably completely uninteresting to you – includes making additional presentations for SQL Server training events.
Which makes for a nice intro to what I wanted to write about today – my first session I presented at a SQL Saturday last weekend in Orange County, California. I suppose some may read this a cautionary tale, but my intention is to let you know that even when you’re neck deep in the weeds (and I’m not even talking just about presentations here) you can still survive as long as you focus on one thing: delivering solutions to your audience.
But before I get to the parts where things went wrong…
Maybe more people would use the Central Management Server feature of Management Studio if it had a name that didn’t sound as utilitarian as a heat pump. Something like PowerServer. Or…Mega Instance Policy Ranger. Or…One Query To Rule Them All.
Because that’s what it really is.
As I’m sure you’re aware, the career path for a SQL Server DBA is a wonderful journey of growing your catalog of knowledge through unexpected lessons. For example: Did you find out the hard way you need to test restoring those backups? Did you discover you need to enable the dedicated admin connection after a server locked up? Did you learn the unexpected results of using reserved words as object names?
Don’t worry, you’re not alone.
Speaking of reserved words, I recently learned there’s a bit of a situation regarding a certain word and logical file names. Let me tell you a story.
Remember the Bill Gates email hoax? The one that claims to be some sort of Microsoft beta test saying Gates is going to pay cash money to anyone who forwards the email? I’m pretty sure it’s been around as long as actual email.
You knew that wasn’t real, right? It’s a myth. And speaking of perpetuated myths…
As Sinatra was fond of singing, “regrets, I’ve had a few.” And one of those came this week immediately after my presentation. This isn’t to say the presentation didn’t go well – it did. At least I think it did. I had several people come up and thank me afterwards for showing them things they didn’t know previously, so in that sense it went well.
But in hindsight, one part of it, well, it sucked. So I’m going to take a moment here and now to correct that.
As noted in the previous post, this month I got my learn on at Tech Outbound’s SQL Cruise Alaska. Which was awesome in so many ways, but I’m only going to tell you about one. Because this one just might be of some value to you.
First a little background: Continue reading
Although I have experience with In-Memory OLTP on SQL Server, I don’t anticipate I’ll be writing about it much. If you want to learn about that subject I highly recommend checking out Ned Otter’s blog. Much like Marcel Marceau is to miming, Ned has quietly become the master of documenting In-Memory OLTP. So much so I’ve even heard Microsoft’s Bob Ward refer to Ned’s posts.
Meanwhile, since you’ve decided to stick around this site, let me share some bad news about the files supporting your In-Memory OLTP.
In my previous post I discussed a particular query design that made the tempdb data files consume all available drive space. When discussing the resolution I noted one of the steps was to reduce the size of the data files. That’s means shrinking them, and I am fully aware that sometimes tempdb can stubbornly refuse to shrink. It’s kind of the reverse problem George Costanza mentioned about swimming.
So let’s talk about what you can do when tempdb requires shrinkage.
So much of being a DBA revolves around responding to the phrase “The database is slow.” If I had a dollar for every time I heard that phrase I’d could probably buy that unreleased Wu-Tang Clan album. Not that I’d want to. But I could. I think. Wait. . .don’t leave. This isn’t a post about rap music, I swear.
I want to continually make the point that nearly everything I post in this corner of the interwebs can be categorized as “Things I have learned” and not “Things I have made.” Despite my years of work with SQL Server databases, I have used learned concepts from others far more than I have discovered myself. And I’m not ashamed to say this, because for any given task we can either reinvent the proverbial wheel or we can use one of the many wheels in working condition that are already in existence. I would like to think my employers don’t care who made it, so long as it’s a correct, timely, and scalable solution.
Which brings us to Sven. Well, almost.