Carry on
It turns out that the only thing harder than checking for new databases restored to a SQL Server, is checking a folder for a backup of a database that doesn't exist on another SQL Server.
Building stuff
I sometimes really hate coming up with ideas, and much prefer someone to just say "I want this" so I can go out into the world and figure out how to do that. Occasionally though, I realize that I'm not going to get all that much direction. That's what happened with sp_BlitzQueryStore.
In our Faux PaaS project, we need a backup plan - or rather, a restore plan.
On each SQL Server instance, clients can create as many databases as they want, anytime they want, with no human intervention. We need those databases covered by disaster recovery as quickly as practical.
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.
As I picked up a nutritious breakfast from my favorite bakery (love ya, Magnolia), I noticed a sign in the window saying they were certified Kosher. As I usually do, I thought about how that kind of thing applied to databases. The Star-K symbol on food products or restaurants means that the ingredients and processes have been…
You may have heard the term "commodity hardware" thrown around when describing solutions like Redis, Elasticsearch, or kCura's new Data Grid.
Commodity hardware refers to cheap, standardized servers that are easy to buy off the shelf from any vendor. Here's a typical example of a 2u, 2CPU commodity hardware server:
Today at Relativity Fest in Chicago, kCura Relativity 9 introduces the option to move some text storage out of Microsoft SQL Server and into kCura's new Data Grid, a tool built atop the open source Elasticsearch. Is kCura abandoning SQL Server? No, but understanding what's going on will help you be a better database administrator and developer.…
kCura Relativity is a software product for law firms to find interesting stuff to help their case. To get you up to speed on what it does, here's some of the posts I've written about Relativity in the past:
Performance Tuning kCura Relativity - explains what the product is for and how DBAs can help make it faster
When you're the database administrator working with a software product that stores every client's data in a different database, the sheer number of databases can be intimidating. As you grow from dozens to hundreds to thousands of databases, you can't treat all of them equally.
Start by making a graph of the database sizes - here's an example from one of my clients with 58 databases on a server (certainly not a big number, but just easy to digest in a blog post):
kCura Relativity is an e-discovery program used by law firms to find evidence quickly. I've blogged about performance tuning Relativity, and today I'm going to go a little deeper to explain why DBAs have to be aware of Relativity database contents.
In Relativity, every workspace (case) lives in its own SQL Server database. That one database houses:
In the e-discovery business, kCura Relativity is the big gorilla, and I've been working with kCura and their clients since 2011. I think it's one of the most interesting businesses I've ever worked with - up there with StackOverflow - and like Stack, they're really open with their customers. Today marks my second year being…
