Cloud architecture, managed databases, migrations, and cloud operating tradeoffs.
131 associated posts50 primary posts
This week, Brent, Erik, and Richie discuss running SQL Server 2017 CTP on Linux, receive side scaling on servers and VMware, query tuning, nested roles vs. assigning roles to users, hierarchical data type, apps and scripts for automating restores, and learning Azure and AWS. The audio's kinda rough this week because Brent & Erik were…
This week, Brent, Erik, and Richie discuss disabling telemetry in SQL Server 2016, proper place for log files, Availability Groups, measuring data returned from a single query, whether CHECKDB should be done on tempdb, limiting tempdb usage for each session, transferring large amounts of data from on-prem to the cloud, and Iron Chef spoilers.
Here’s the video on YouTube:
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?"
This week, Erik, Tara, and Richie discuss enforcing password expiration for SA logins, keeping things in sync between servers, development/prototyping missions of on-premise vs. cloud, ways of backing up databases, and more.
Here’s the video on YouTube:
Background: I'm working with kCura to build a Faux PaaS: something akin to Microsoft's Azure SQL DB, but internally managed. In Part 1 of this series, I talked about why we're building it, and today, I'll talk about where.
The database team rarely gets to pick the cloud vendor.
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.
This week, Erik, Tara, and Richie discuss altered tables and update statements, parameter sniffing issues, their issues with Azure, a resource for column store indexes, AlwaysON availability groups, killing sleeping connections, and fill factor value for indexes.
Here’s the video on YouTube:
Listen, I can explain. Really.
We had a client with a 5GB database, and they wanted it to be highly available. The data powered their web site, and that site needed to be up and running in short order even if they lost the server - or an entire data center - or a region of servers.
I'm getting an increasing number of requests these days that say: "We're considering migrating our application from SQL Server to a cheaper, easier-to-scale database. Can you help?" Well, kinda: why are you doing it? If you're doing it to get easier scalability, we start by taking a step back and looking at the performance problems…
So you're hosting your SQL Server in the cloud - say Amazon EC2, Azure VM, or Google Compute Engine - and you've noticed that when you're running a backup or a DBCC CHECKDB, you suffer from extreme performance problems.
Queries run slow, and even worse, applications report timeout errors even just trying to connect to SQL Server. More symptoms can include database mirroring and cluster failovers. What's going on?
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…
This week, Erik, Tara, Jessica, Doug, and Angie discuss queries, installing multiple instances of SQL server on a Windows VM, using DENY Database rules, migrating databases to Amazon RDS, availability groups, using filtered indexes, and more!
Here’s the video on YouTube:
You're hosting your SQL Server databases in Amazon RDS, and performance has been getting slower over time. You're not sure if it's storage IOPs, instance size, SQL Server configuration, queries, or indexes. What's the easiest way to find out?
Ask a few questions:
Enter Query Store Query Store, in short, is a way to track query performance over time. In Microsoft's words, "The feature automatically captures a history of queries, plans, and runtime statistics, and retains these for your review". It's like sys.dm_exec_query_stats but it persists across reboots! And it has execution plans! The Query Store is a…
In Azure SQL Database, no one can hear you scream query common system objects that tell you when a restart happened. You don't get the access you need to sys.dm_os_sys_info, sys.dm_exec_sessions, sys.traces, or sys.databases. The closest I've been able to get is to query sys.dm_os_wait_stats for several common wait types that seem to correspond with…
... is to use a SQL Server where a robot does it for you! Let's take a look at how you can do this in AmazonRDS's hosted SQL Server these days. Normally, restoring transaction logs is super tedious. You've got to restore all the files in the right order, for every single database. Even if…
Microsoft just announced a new round of D-grade VMs that have 60% faster CPU and local SSD than can go up to 7,000 IOPS in a canned IOmeter test. Before jumping to conclusions or, even worse, picking a cloud provider, it's best to look at these numbers critically. CPU Speeds The new CPU is being…
Let's skip the shenanigans and get right down to it - you're responsible for SQL Server and someone in your company wants to move things into Amazon Web Services (AWS). You've got SQL Server setup covered thanks to our helpful SQL Server setup checklist and you're confident you've got hardware under control, but things are different up in the clouds.
Amazon Relational Database Service (RDS) now supports multi-availability-zone SQL Servers. This means you can have a primary database in one data center, and a secondary replica in another data center.
When your primary server goes down, OR when the entire AZ goes down, you can fail over to the secondary with zero data loss and keep right on going. When the primary comes back online, you can fail right back, again with no data loss.
As businesses grow, many teams start considering scale out database solutions but they're cautious - they want to know how to keep data up to date in multiple places. In theory, you can use log shipping, mirroring, or AlwaysOn Availability groups. While this answers the literal question, what people really mean is usually very different.…
