Not too long ago in the past I had really interesting afternoon. It wasn’t interesting because I had 3 Failover Clusters that exploded, that’s just horrible, it was interesting because they exploded exactly 40 minutes apart. While I do believe in coincidences, that was just way too precise to be a random occurrence. After looking into it, and engaging once more Microsoft Premier Support, I was eventually able to find the reason.
It turns out that patching Azure Hosts where your VMs are running can cause some bloodcurdling things to happen.
While I work 100% with cloud based SQL Server deployments these days, my life is not all unicorns and PaaS services. Surprisingly (or not) enough, many of the environments in the cloud are still build on top of good, trusty virtual machines. Except that sometimes they’re not good or trusty. There are definitely some good reasons for deploying VM’s in the cloud, however some decisions on the architecture can prove to be a challenge in a long run.
In this post, I’ll share my experience from struggling with some of these decisions, and hopefully help some of you make better decisions out there. Let me share a woeful story about Storage Spaces Direct and Cluster Shared Volumes.
I have previously written quite a few post about how much I like the Platform-as-a-Service databases for SQL Server (and for databases in general), and I do like them quite a bit. But would I recommend them for all use cases and workloads? Heck no! At the moment there are some features and limitations in Azure SQL PaaS databases that, with some of hte SQL Server workloads I have seen, wouldn’t just work all that well.
Also when we look at Azure, there’s some really cool features available for VMs that you can start using today, which are making the good old VMs an interesting option.
The answer to this question is not 2, happy and unhappy users. This time we’re discussing security, not the end user experience of your perfectly tuned databases.
I was recently having a discussion around SQL Server security, more specifically about the logins and user. The question I was asked after going through couple examples was, that how many different types of users there actually are. While this seems like a trivial thing to answer, I have to admit that even after thinking about this for a little while, and still got the answer off by 2. As it turns out there’s bit more complexity to this than might be obvious at the first glance.
Without checking from anywhere, can you name all the different types of users? Read onward to find out.
Sometimes I run into things in cloud that really just blow my mind away. Not that long ago I learned how you can give everyone in Azure, no matter what subscription or region they are in, an access to your database. And it was super easy too. It’s just one click to allow whole (Azure) world to start accessing your data.
Is this something I wanted to do, or would I recommend anyone to do it? No, not really. Also the documentation around this particular setting was less than great, so I decided to share what I learned.
Core responsibility of a DBA is to make sure that the databases they are responsible for are maintained properly. In a nutshell this usually means that you are taking backups of the data, checking the consistency of the databases and maintaining statistics and indexes. Performing these tasks gives the DBA the ability to provide the agreed SLAs for the system.
However the trade-off for doing all these tasks is that it requires some computing resources and it can sometimes impact the performance of the connecting applications, and through that the SLAs in a negative way.
In this post we’ll look at how to implement low impact database maintenance routines for environments that have large databases and are accessed 24/7 by the users.
Very recently I was working on a customer databases, when I more or less stumbled on a something I had not noticed before. Apparently at some point the latest version of SQL Server (I was working with Azure SQL DB) had a new security enhancement added into it called Feature Restrictions. As this was something I had not heard about before, I figured this would be a good opportunity to dig in and learn more about it.
Note: As I was finishing up this post to add links and such, I noticed that the official documentation from Microsoft regarding Feature Restrictions has completely vanished.