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.
Maybe I’m showing how old I am, but I remember as a kid hearing a song on the radio that went like this:
You don’t tug on Superman’s cape
You don’t spit into the wind
You don’t pull the mask off the old Lone Ranger
And you don’t mess around with Jim
You’ve probably heard it at some point, although likely you won’t remember the whole thing. This is because it isn’t played much anymore due to the lack of demand for ’70s folk-rock stations.
Recently we had Microsoft Risk Assessment Program (RAP) completed on some of our SQL Server instances. This is where Microsoft deploys some software that performs a similar function to when you go to the doctor for an annual physical. There’s a lot of poking and prodding, they draw samples, and at the end they tell you everything that is wrong. Your servers have high blood sugar, your databases need to take up yoga, etc. It’s pretty much everything except having the MS technician stroke his chin, saying “Hmmm.”
You are going to a doctor for a regularly scheduled checkup, right? Ok then.
I have a confession to make: Historically speaking, I don’t like deployments. I dread them with an unavoidable pessimism that asks “so what is THIS going to break?”
Now, I have worked with a lot of smart people who knew how to write some fabulous code. I don’t doubt that one bit. But I’ve also worked in several places where that code wasn’t rigorously tested before it was time to be deployed in Production. Maybe the business wanted a fix deployed immediately. Maybe the deployment instructions were incomplete. Maybe velociraptors invaded your workplace.