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.
I’ve mentioned on this site that part of the reason I’m even writing my SQL Server notes here is because of my experience on Tech Outbound’s SQL Cruise Alaska last year. It was a more significant event for my career than I could have possibly imagined, and not just because of all the cool stuff I learned. I even found out I had something in common with Bob Ward.
But before I get to that, let me explain to you why I am investing in a second round for the 2018 Tech Outbound Alaska event next month.
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.
As I noted before, as a Senior DBA I’m occasionally asked to participate in interviews for other prospective data professionals. I really do love doing this, and if you want to know why go ahead and read the first paragraph of my previous post on Curiosity.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.