A Fine Slice Of SQL Server
Anthony Nocentino makes an announcement:
I’m excited to announce the release of a new open-source project that fully automates HammerDB benchmarking for SQL Server using Docker. If you’ve ever needed to run TPC-C or TPC-H benchmarks multiple times, you know how time-consuming the manual setup can be. This project removes the hassle and gets you up and running a single command:
./loadtest.sh.
Click through to learn more and to grab the code.
Leave a CommentBrent Ozar has a new animation:
Let’s use the Users table from the Stack Overflow database, and let’s pretend that the Users.Location column is stored as JSON rather than letting users type in whatever they want. Let’s pretend we make them pick their Country, Province, and City. Then, let’s use one of my Database Animations to illustrate the pain of querying it without the JSON index, and then the cake-y-ness of the added index:
Brent also has an issue with the phrase “have your cake and eat it too” but I think it’s a proper phrasing that relies on a temporal understanding and pushing a past-tense verb into the present. The idea is that you cannot simultaneously have eaten your cake, while also maintaining it for later. I can understand Brent thinking the common phrase is a temporal slight of hand, but that one never bothered me.
The one that has bothered me for decades is “the proof is in the pudding.” The proper aphorism is “the proof of the pudding is in the eating.” The latter actually makes sense, whereas the former is an abbreviation that changes the meaning so much enough to remove most of its value as a folksy saying.
Leave a CommentJerry Nixon performs a change:
Schema change is inevitable. We do not get everything right the first time, and even when we do, the world around the database keeps changing. Requirements mature, products evolve, and assumptions that made sense years ago eventually stop matching reality.
Businesses change too. We acquire companies, merge with other customers and systems, enter new markets, and adapt to new opportunities. Sometimes a schema has to change because the original design was wrong. More often, it changes because the business is no longer the same business that existed when the schema was designed.
That is normal. The challenge is not avoiding schema change. The challenge is making those changes without interrupting the applications and users that depend on the database.
Click through for an example of a schema migration. I disagree with Jerry about doing the work in “the application,” mostly because it’s rarely one application controlling a database. If it is, and if there are no automated jobs, ad hoc PowerShell scripts, secondary applications, or other processes in place that could write data to the same database, then fine. But I typically find that to be less common than the alternative.
Leave a CommentErik Darling makes an admission:
Erik Darling here with Darling Data, and in this video, we’re going to talk about mostly AT TIME ZONE performance, but also some other interesting stuff about AT TIME ZONE. I’m going to be real honest with you, I hate timezone stuff. I hate all of it. I’ve never taken naturally to it. It’s all too weird, and managing it is just such a nightmare.
I agree with Erik’s point about storing everything in UTC. Click through to learn how you can slow things down considerably using AT TIME ZONE in certain ways.
Gilbert Quevauvilliers performs some measurements:
Before using Fabric Capacity operation events, you need to have a Fabric capacity.
In my testing, Capacity Operation Events consumed approximately 230,000 CUs per day.
Based on my usage, an F4 capacity was required to run this continuously each day.
NOTE: This is based on my usage. Your consumption may be slightly higher or lower.
That’s a fair amount of capacity to track how much capacity you’re using.
Leave a CommentReitse Eskens debugs an issue:
This is a very common setup that usually works just fine.
Yet, I ran into something weird that I wanted to share with you. When I set up this copy job, I could reach the database, preview the data, and create the job. No issues. But when I started the actual data transfer, the job ran for two minutes and thirteen to sixteen seconds before throwing an error. On every table.
Click through for the error message, the cause of the error, and how to solve it.
Leave a Comment