Sometimes, I see questions and go, "You know, I'd rather let other people answer this." And today, I'm gonna let you do it.
My blog post this week about PollGab.com and about its data model brought out all kinds of interesting Office Hours questions. I've selected 7 of them that I don't wanna answer - instead, I wanna hear your answers.
When you have a hammer, everything looks like a nail. Unfortunately, a lot of people don't even know how to use a hammer correctly.
You really shouldn't be doing queues in the database because:
Since the dawn of time, database vendors have called out to developers, "Store everything inside the database. You know you want to. Here, we'll make it easy for you by adding data types like binary and features like filestream."
Ah, but this siren song leads you to your eventual doom.
This month, to mark the 20th anniversary of BrentOzar.com, I’m stepping back and looking at the big picture rather than blogging about database problems & solutions like I usually do.
I'm going to generalize a little by decade here to keep things simple.
You're tired of taking outages to deploy changes to your database schema.
Wouldn't it be cool to have two different SQL Servers so that you could:
When the business decides it's time to give up fixing the old server because it's not fast enough or reliable enough, stop. The worst thing you can do is jump directly to the hardware vendor's site, check a few boxes, and order a new shiny server that ends up with exactly the same problems as the last server.
In our last episode, we found out what your server was waiting on. In the closing remarks, I mentioned that you should find out which queries are causing the problem, and focus your mitigation efforts there. You might have circled back to the episode where we covered sp_BlitzCache, used a @SortOrder parameter that lines up with your top wait type, and...
Before I give you the link to the next research paper in this week's series, I wanna give you a few questions to think about: If you had to build something to automatically add indexes to SQL Server databases, where would you start? What data would you use to make your decisions? How would you…
You've decided that you need to offload reports to a different SQL Server, and you're willing to pay the costs. Here are the most common ways to move the data from production to a reporting server, arranged roughly from easiest-to-implement to hardest: 1. Log shipping. Log shipping is more of a technique than a feature:…
When you first hear about it, SQL Server's In-Memory OLTP sounds like a new feature that's hard to implement, requires a lot of schema changes, and takes planning and downtime.
I'm here to tell you it's simply not true, and you can do it in just 3 steps. Here's how:
When you're building a new SQL Server, you're going to see a few intriguing checkboxes during setup.
The services are all free, right? You can just check the boxes for Machine Learning Services, R, Python, Data Quality Services, PolyBase, Integration Services, Analysis Services, and Reporting Services - it's not like you have to put more coins in the front of the server. So what's the drawback? Why not collect 'em all? What are the pros and cons?
Tipping the Kilter
I'm intentionally avoiding physical/hardware choices in this post, like how much hardware to buy, and scaling out vs. scaling up.
Last week, Azure suffered a day-long outage. One of the services involved was Visual Studio Team Services (aka Azure DevOps), and that team just published their outage postmortem.
The postmortem is FANTASTIC: open, honest (at least it reads that way), and goes into enough technical detail to satisfy a wide variety of readers from managers to technical implementers.
Our new SQL Constant Care® is an online service that analyzes your SQL Server's diagnostic data, then gives you personalized advice on what you should do to make your database app faster and more reliable. I blogged about the vision last week, and today let's talk about the things that drove our architecture decisions way back in 2015.
We've talked about how to do a free SQL Server health check, and then how to drill deeper with performance check.
After these two, management usually steps back and asks, "Wait a minute - how'd we get into this mess? And long term, strategically, what should we do next?"
The old advice went something like this: "Put your data and log files on separate drives and your server will be more reliable. If you lose the data drive, you can still do a tail-of-the-log backup, and you won't lose any data."
It's advice. But is it actually good advice?
Background: I'm working with kCura to build a Faux PaaS: something akin to Microsoft's Azure SQL DB, but internally managed. You can catch up with what we've discussed so far in Part 1 and Part 2 of the series.
In the last post, I talked about measuring backup and restore throughputs across different instance types, regions, storage configs, and backup locations. It's a lot of work to answer questions like "How should we configure our new SQL Server VMs?"
In the cloud, treat your servers like cattle, not like pets.
In the cloud, systems administration is very different than the on-premises stuff you're used to. When you build VMs in the cloud with Infrastructure-as-a-Service (IaaS, meaning AWS EC2, GCE, or Azure VMs), you expect them to die. It's just a matter of time. If you're lucky, it'll be years from now, but if you're unlucky, it'll be tomorrow.
"We'd like to offload our reporting queries to a separate SQL Server."
The first costs are fairly obvious.
Hardware and storage - even if you're running it in a virtual machine, you need to account for the costs of say, 4 cores and 32GB RAM. Not only will you need storage for the databases, but you'll also need to decide whether this server gets backed up, and copied to a disaster recovery data center.
If you've ever heard the Away From the Keyboard, a podcast that I co-host with Cecil Phillip, you'll quickly discover that I love hearing stories about how products are created. Now I get to tell you the story of how Paste The Plan became real and the architecture around it. In a world... Here at Brent Ozar…
