My name is Mika Sutinen and I'm a Cloud DBA Practice Lead at the company called Nordcloud. I've been working in IT-industry for more than two decades, and I've spend most of my career working with SQL Server and other Microsoft technologies. In the past couple years I've been working on cloud only, on various types of projects and cloud platforms.
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.
I just realized that it has been awhile since my last post, so I figured it’s time to do one before the end of the year. Last few months have been rather hectic with me migrating new workloads to Cloud as well as taking the time to visit PASS Summit 2019 to learn more about Microsoft Data Platform.
I also wanted to finish up my year of blogging by writing about a topic close to my heart, the evolution of the DBA role in the Cloud era. I did have a session about this topic in SQLSaturday Finland earlier this year and I will be doing a PASS Cloud Virtual Group presentation about it on January 16th.
In this post we’ll be looking at one of the Cloud technologies that have significant impact on the DBA role in the future, Platform-as-a-Service databases.